Coordinate system conversion

Hi, thanks for your great work. I used my lidar and imu to record the data set and run it in DLO. The following figure is the map generated by the algorithm. I found that IMU drift is very serious. Is this related to coordinate system transformation? How can I set up and configure files to improve this situation?

Add something. When my coordinate system is velodyne and the topic is changed to /robot/dlo/map_node/map, it is empty on rviz. When my coordinate system is changed to robot/odom, nothing is displayed on rviz.

Looks like an extrinsics issue if I had to guess.
Does it work if IMU is disabled by setting imu: false? If so, then your IMU is probably flipped and providing DLO with a wrong scan-matching prior. The current implementation assumes that the LiDAR and IMU coordinate frames coincide, so if it's possible try rearranging your sensors to ROS convention (forward-left-up). Otherwise I can add support for extrinsics.

Does it work if IMU is disabled by setting imu: false? If so, then your IMU is probably flipped and providing DLO with a wrong scan-matching prior. The current implementation assumes that the LiDAR and IMU coordinate systems coincide, so try rearranging your sensors to align (preferably in ROS forward-left-up) if possible. Otherwise I can add support for extrinsics.

Thank you for your reply. When imu is disabled by setting, its map has not changed. I checked the defined lidar coordinate system and the defined IMU coordinate system. They are coincident. But I found that my lidar and imu still drifted seriously. The following two figures are the coordinate system of lidar and imu. Do I need to recalibrate the lidar and imu?

Hmm... which sensors are you using? There was a similar issue a while ago which was fixed through some configuration. Otherwise if you record a bag for me I can help debug.

Hmm... which sensors are you using? There was a similar issue a while back which was fixed through a configuration change, so try checking your driver settings. Otherwise if you record a bag for me I can help debug.

Well, thank you for your reply and I have solved some issues. The data set with serious drift before recorded all topics of IMU and lidar. When I recorded the topic of using only IMU acceleration data and lidar pointcloud data in the data set, the drift situation was basically solved. Could you please tell me whether the motion trajectory, attitude and other sensor information of IMU will affect the accuracy of mapping?
When the lidar system moves unsteadily on the carrier, the built map will have errors in the horizontal direction. As shown in the following figure. But this problem does not exist on the stable moving carrier. Do I need to calibrate the random error of IMU?

By the way, is there any setting for the joint calibration of the coordinate system of lidar and IMU in the program?

Thank you for your reply and patience. I have solved the above problems.
By the way. How to generate .pcd format file? I use the official order to get the following information.

Happy to help. You need a space between the two arguments, and the last argument should be the parent folder for the file, i.e.
rosservice call /robot/dlo_map/save_pcd 0.5 ~/Downloads

will save the map as ~/Downloads/dlo_map.pcd.

Thanks for your great work and attentive reply. I have successfully got the .pcd file.
Now I found new problems. Here are some pictures that are the results of the data set I recorded in the outdoor environment. There is no problem in  the map in the horizontal direction, but there is a slight drift at the bottom of the map in Figure 2 (the influence of terrain has been excluded). When the path of motion returns to the origin, the map will drift in the vertical direction (as shown in Figure 3). Have you ever encountered this situation when you were building a map? How did you solve it?
By the way, there are obvious pause (not jitter) when building the map. What is the reason for this?

I don't see any obvious drift with your map itself, but if you are referring to the map's tilt, make sure you start on flat ground as I mentioned previously (i.e., Z is axis-aligned to gravity). If you're using our gravity alignment procedure, the IMU and LiDAR needs to be rotationally-aligned on your platform (I can't tell if they are from your second reply).
Regarding the periodic pauses, our map publisher is on a one second ros::Timer, so RViz may slow down / delay as the map grows. This was done in the event of lost communication with our robots for SubT so that the robot could send the full map once it came within range again. I added an option in v1.4.2 to turn this off and only publish keyframes individually as a solution. Make sure to turn up the Decay Time if you want to see the full map.

I don't see any obvious drift with your map itself, but if you are referring to the map's tilt, make sure you start on flat ground as I mentioned previously (i.e., Z is axis-aligned to gravity).  If you're using our gravity alignment procedure, the IMU and LiDAR needs to be rotationally-aligned on your platform (I can't tell if they are from your second reply).
Regarding the periodic pauses, our map publisher is on a one second ros::Timer, so RViz may slow down / delay as the map grows. This was done in the event of lost communication with our robots for SubT so that the robot could send the full map once it came within range again. I added an option in v1.4.2 to turn this off and only publish keyframes individually as a solution. Make sure to turn up the Decay Time if you want to see the full map.

Thank you for your patient reply. I think maybe my statement is not accurate enough. You can pay close attention to my latest reply (the reply with three photos) because this data set is a new recording package. My data set starts from the starting point and finally returns to the starting point. You could see in my last picture that there is a height difference between my starting position and my final position.  This height difference is the problem I want to solve. Do you know the reason for the inaccurate vertical positioning?
And I'm sure I set gravityAlign:true and the IMU and lidar coordinate system are physically consistent, but there is no rotation alignment. Do I need to rotate and align the IMU and lidar? How to achieve rotation alignment? Can rotating alignment solve the problem of inaccurate vertical positioning? We look forward to your reply.

Try playing around with the voxelization (i.e, turn off submap voxelization), the number of keyframes used in submapping (maybe increase it), and the maximum correspondence distances for S2S and S2M.

Hi, thank you for your good work and reply. I'm trying to adjust these parameters these days. I want to ask you something I'm not very clear about.
When I changed the parameters of submap voxelization, I found that the clarity of its mapping has changed. When I looked at the code, I found that this parameter is related to the keyframe of the point cloud. Is that right? But when I turned down this parameter, I found that the mapping was clearer. When I turned up this parameter, I found that the number of keyframes become less. So I want to ask, is this parameter a filter? Does it take the reciprocal when used? Or in other forms?
And when I adjusted the parameter of maximum correspondence distances, I knew nothing about the changes in the mapping process. But it is clear that the coordinate error of the map has changed a lot. I can't find its rule for the time being. I want to know what factors affect the mapping process by adjusting the maximum correspondence distances parameters of S2S and S2M in GICP.
Thank you for your answer. We look forward to your reply

A voxel filter downsamples a pointcloud depending on the leaf size of each voxel. Think of this as the size of each "3D pixel," so the larger the number the bigger the voxel and vice versa. Then, for a leaf size of 0.1 (for example), there will be one point per 0.1 cubic meters in the cloud.
This can affect DLO's adaptive keyframing from our spaciousness metric, which computes the median point distance.
Maximum correspondence distance affects scan-matching and which pair of points to consider during optimization. In larger environments, a larger distance is generally good since points are probably more spread out. In smaller environments (like your dataset), bad correspondence matching can corrupt the optimization process and therefore the overall result. This holds true mainly for S2M; for S2S, the search is purely between two instantaneous scans. In that case, it's slightly dependent on walking speed and the rate of the LiDAR (but in general it's not as sensitive as S2M).
Here is a nice tutorial on what voxel filtering is, and you can read more here about correspondence-based registration.

Thanks for your reply. I will understand this part carefully.
I recorded a dataset in the business district and built a map. We took the escalator from the second floor of the mall to the first floor of the mall. After turning around on the first floor, I returned to the starting point of the second floor. The effect of the map is good.

You can see a slash across the second floor. Don't worry. This part is the escalator from the second floor to the third floor.

Nice! Thanks for sharing your results with us :^)
If there are no more questions, I'll be closing this thread. Feel free to reopen or create a new issue if you have any further questions or comments about our work.


Add options to add socials for club and leaders in the Slack Bot

Self-explanatory title.

Done in commit bb8a8cebd73489ed00591fa94fbcf6241f6e0671.


CSS ?

It is not clear how we can get a stylesheet for this jquery autocompletion.
I am using rails-sass, am I supposed to also grab jquery-ui-sass-rails and add a require line for jquery.ui or something like that ?
Unfortunately I added jquery ui only for this purpose, it would be great if the readme could mention the steps to get some basic working css.

If you are using Bootstrap, paseto wrote styling for the autocomplete.
https://gist.github.com/paseto/5b0f626bbf4ccdcc0b09


build(vue-model-api): remove faulty caching for package.json

Caching resulted in publishing the vue-model-api with under the wrong version. This made the publishing workflow fail.
This was the reason for the last two failing publish workflows:

https://github.com/modelix/modelix.core/actions/runs/6863094083
https://github.com/modelix/modelix.core/actions/runs/6875497304

The build failure looks temporary to me?

:tada: This PR is included in version 3.15.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add JS from Digital Marketplace frontend toolkit

This pull request brings back:

Word count on the service summary field
Add/remove item functionality for features and benefits

The tooling is Gulp include which uses Sprockets-style directives to concatenate multiple Javascript files into one.
It also makes some minor template changes for compatibility with the toolkit Javascript.

Apart from my comment, looks good to me.


Under window, ffmpeg relative path cannot be found, must absolute path be used?

Which version are you using?
v1.8.4
Which operating system are you using?

[ ] Linux amd64 standard
[ ] Linux amd64 Docker
[ ] Linux arm64 standard
[ ] Linux arm64 Docker
[ ] Linux arm7 standard
[ ] Linux arm7 Docker
[ ] Linux arm6 standard
[ ] Linux arm6 Docker
[x] Windows amd64 standard
[ ] Windows amd64 Docker (WSL backend)
[ ] macOS amd64 standard
[ ] macOS amd64 Docker
[ ] Other (please describe)

Describe the issue
Description
Describe how to replicate the issue

When using ffmpeg to transcode 265, relative paths cannot be used and absolute paths must be used. Even if the system environment variables have been added to ffmpeg, it still cannot be found. Is there any way to use relative paths?
The following are the error messages：
runOnDemand command exited: exec: "ffmpeg": cannot run executable found relative to current directory

Did you attach the server logs?

no
Did you attach a network dump?

no

Found the problem, medicamtx and ffmpeg cannot be placed in the same directory, otherwise even if the environment variables are configured, they cannot be found


problem

Hey,
sorry for the late reply.
Which calibre version are you using so that I can reproduce the error?


Composite builds including projects with platform dependencies may fail with circular task dependency error

Description
Composite builds including projects with platform dependencies may fail with a circular task dependency error if the platform contains a constraint on the included project.
Steps to reproduce

Clone repository: https://github.com/ndru83/gradle-composite-build-error
Perform a composite build by running:

./gradlew clean build --include-build library-project

Observe the build failing with a circular dependency error on task :library-project:compileJava

Dependency graph overview
compileClasspath - Compile classpath for source set 'main'.
\--- com.example:library-project:1.0.0
     \--- com.example:platform-project:1.0.0
          \--- com.example:library-project:1.0.0 (c)

(c) - dependency constraint

Dependency setup overview
// Dependencies in project under test
dependencies {
   implementation 'com.example:library-project:1.0.0'
}

// Dependencies in 'library-project'
dependencies {
    api platform('com.example:platform-project:1.0.0')
}

// Dependencies in 'platform-project'
dependencies {
    constraints {
		api 'com.example:library-project:1.0.0'
    }
}

Expected Behavior
Expecting build to complete with BUILD SUCCESSFUL the same way it does for...

./gradlew build builds, that relying on using published dependencies from the same ./platform-project and ./library-project projects.
./gradlew build --include-build library-project --include-build platform-project composite builds that also includes the platform dependency in the composite build.

Current Behavior
Running ./gradlew build --include-build library-project yields the following error:
FAILURE: Build failed with an exception.

* What went wrong:
Circular dependency between the following tasks:
:library-project:compileJava
\--- :library-project:compileJava (*)

(*) - details omitted (listed previously)

Excerpt of stack-trace:
at org.gradle.execution.plan.DefaultExecutionPlan.onOrderingCycle(DefaultExecutionPlan.java:464)
at org.gradle.execution.plan.DefaultExecutionPlan.determineExecutionPlan(DefaultExecutionPlan.java:294)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph.ensurePopulated(DefaultTaskExecutionGraph.java:311)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph.populate(DefaultTaskExecutionGraph.java:158)
at org.gradle.initialization.DefaultTaskExecutionPreparer.prepareForTaskExecution(DefaultTaskExecutionPreparer.java:41)
at org.gradle.initialization.BuildOperatingFiringTaskExecutionPreparer$CalculateTaskGraph.populateTaskGraph(BuildOperatingFiringTaskExecutionPreparer.java:117)
(...)

Context
The error occurs when a composite build includes a project that inherits dependency constraints on itself from a platform dependency.
Performing a build relying only published artifacts of each individual project with no composite build involved works without an error.
Interestingly, including the platform project in the composite build will also resolves the error.
The error makes testing modules with such platform dependency setups hard to test using composite builds.
Environment:
Build scan URL: https://scans.gradle.com/s/7r6x47jakglra
Versions:
------------------------------------------------------------
Gradle 6.5.1
------------------------------------------------------------

Build time:   2020-06-30 06:32:47 UTC
Revision:     66bc713f7169626a7f0134bf452abde51550ea0a

Kotlin:       1.3.72
Groovy:       2.5.11
Ant:          Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM:          1.8.0_212 ( 25.212-b03)
OS:           Windows 10 10.0 amd64

This issue seems to be fixed on master. Would you mind trying this snapshot and confirm that it works for you? https://services.gradle.org/distributions-snapshots/gradle-6.7-20200816220041+0000-bin.zip

Related fix: https://github.com/gradle/gradle/pull/13804

Thank you, I've tried the provided build and can confirm that the error is resolved.


fix dataSourceName not found exception in dab validate

Why make this change?

Closes #2039
dab validate was throwing exception stating dataSourcename is not found. This PR aims to fix it.

What is this change?

RuntimeConfig object stores dataSourceName information.
previously the RuntimeConfig object was created in CLI during deserialization and sent to Engine Code. And In engine code when we setup metadatprovider we again create the dataSourceName info, due to which there is a mismatch.
So, we are not sending the RuntimeConfig object from CLI, and in Engine we are sourcing it directly from RuntimeConfigProvider. (similar to how it's done while starting the engine).
Therefore, Doing the deserialization only in a single place in the engine itself, improving performance as well.


The data used in for this code is 3d array so what changes need to be done to make it run for 2d array dataframe(for single varient time series)

Hi, probably the easiest way to make it work would be the following hack:
In your dataset class inside data.py, replicate the single column that currently defines your single variable into one or more copies, in a way that you end up with e.g. 3 identical columns. You won't need to change anything else in the code for this.
An alternative, more nuanced way would include defining a single 1D-convolutional layer with M filters (M is a hyperparameter) such that you end up with M features per time step. This way you could also do "smart down-sampling" (feature extraction) in case your temporal resolution is very high and results in a large number of time steps.
So basically right after your input X you would only need to add a layer like this:
out_channels = M
kernel_size = 1
stride = 1
conv = torch.nn.Conv1d(in_channels=1, out_channels=out_channels, kernel_size=kernel_size, stride=stride)
X = conv(X)

The above doesn't do any feature extraction/down-sampling, so if you do want this, then you can set stride and kernel_size as hyperparameters to larger values.


Package name collision in spring graalvm native and spring kafka

There are two packages sharing exactly same  name
org.springframework.kafka.annotation
This package exists in spring-kafka as well as spring-graalvm-native artifact
This is resulting in below error after successfully compiling and trying to run spring native graalvm image
Caused by: java.io.FileNotFoundException: class path resource [org/springframework/kafka/annotation/KafkaBootstrapConfiguration.class] cannot be opened because it does not exist
Full log attached
spring_native_graal_startup_error.log
Is there any workaround?

I would like to second a support for spring kafka please

Is it definitely the duplicate package situation that is causing an issue? I'm more likely to suspect that we've done no work to support Kafka. Gary started working on Kafka sample, we should pursue getting that working: https://github.com/garyrussell/spring-graalvm-native/tree/kafka/spring-graalvm-native-samples/kafka

@don-mayur i was able to fix it by removing @EnableKafka in my boot app, boot should be able to pick it up as long as kafka is in class path. The image was built but ended up with
@Configuration classes need to be marked as proxyBeanMethods=false. Found: [org.springframework.retry.annotation.RetryConfiguration]
Currently I can't find a way to fix this other than requesting people to update spring-retry to disable proxy

@sadew145  We do have kafka starter and thus we don't explicitly specify@EnableKafka but it will be used, So I cannot remove it, moreover as you pointed out it might still fail if you I remove starter also.

@aclement That’s great that spring kafka official support is in works, to answer your question I think package situation won't solve all support issue for spring kafka. But I faced error(attached) while running native app.

@don-mayur just to clarify, I dont remove kafka dep, I only remove @EnableKafka. Spring boot should be able to pick it up by itself. Also, it didn't fail because of kafka. If i build without native-image, the app runs normally with kafka enabled

@sadew145 Same for me, if I run normally it works just fine but when I compile it to native image that's when I face this issue while running native app

@don-mayur i think you miss understand me. All i wanted to said is you dont need to have @EnableKafka to get kafka running when i compile my app with native image it runs ok only get blocked by spring-retry

I just pushed an initial kafka sample that is working. There are some tweaks we need to make so it works 'out of the box' (that will fix the problem like you have in the first comment 'classpath resource cannot be opened') but to get it going I just ran with the agent to collect valid config then built using that, crudely:
mkdir -p src/main/resources/META-INF/native-image
 java -agentlib:native-image-agent=config-output-dir=src/main/resources/META-INF/native-image -jar target/kafka-0.0.1-SNAPSHOT.jar

Then a maven build using the native profile in the pom.xml.

I've polished the sample today - it no longer requires any agent collection. The feature supports everything this sample needs, and it builds and runs fine. Please take a look and if your usage of kafka differs, let's capture those differences in a test project and get that working too. Sample is in the project here: https://github.com/spring-projects-experimental/spring-graalvm-native/tree/master/spring-graalvm-native-samples/kafka

@aclement I am facing Caused by: java.lang.NoSuchMethodException: org.springframework.context.annotation.ConfigurationClassParser$DefaultDeferredImportSelectorGroup.()
with Kafka sample, I am attaching log for reference
spring-graal-native-kafka-sample-run-error.log

Are you building spring-graalvm-native locally for yourself? If you aren't then you may be picking up an old snapshot of 0.8.2 that doesn't include the change for that (I doubt the build has finished yet). The current codebase includes the necessary hint for that: https://github.com/spring-projects-experimental/spring-graalvm-native/blob/master/spring-graalvm-native-configuration/src/main/java/org/springframework/context/annotation/ContextAnnotationHints.java#L47

You are right @aclement  I was not and now I tried and kafka sample is working for me. I can now close this issue.
Although for my app some configurations file when marked with proxyBeanMethod=false then app fails while running even with normal spring-boot run.


who_id_original

Add column who_id_original to data copying the column who_id.
Add in postprocess.py.

Addressed in #99.


Capitalized GitHub in comment replies, basic a-centralized-mirror support

It's GitHub not Github - critical bug that needs fixing.
I've also included super basic support for a-centralized-mirror. A few things to mention:

I haven't written Python in 5 years now, and I'm pretty sure the last time I did it was Python 2. This appears to be Python 3.
This is untested, but VS Code doesn't show any syntax or usage errors
I included absolutely no error handling in this
I would probably separate the reddit reply and acm updates into their own functions with their own error handling

You have a typo in the header method. The letter "R" is capitalized. Which is iRonic because you claim the "H" in "Github" is not capitalized.
I'm done.

But I'm not done with this pr.
Why do you see fit to deliver this code with any test to prove it is indeed doing what you claim it does?

Why do you see fit to deliver this code without any test to prove it is indeed doing what you claim it does?

As mentioned, I haven't written Python in a very long time. Unfortunately I no longer possess the knowledge of best-practices when writing it and I'm not going to re-learn it for a cousin mirror-bot project.
It's a proof of concept and starting point as I've discussed this with @jonnotjohn multiple times over the past 6 months or so while the project was in planning
I totally welcome your Python knowledge and therefore any/all modifications and tests you'd like to provide on this pull request

Yes, it's ironic that the 'r' was capitalized. Not sure why VSCode didn't catch that but a pull request could've fixed that without the attitude. I don't know if it's the tone given off because it's written text and not spoken or if it's intentional but I don't see the reason for the attitude.

My point is if you had tested this then you would have caught the typo. Which tells me this is untested code. I know that you've said that you haven't tested this. That's not what I am arguing.  Are we ok with the fact we have untested code?
I'm not.

My point is if you had tested this then you would have caught the typo. Which tells me this is untested code. I know that you've said that you haven't tested this. That's not what I am arguing. Are we ok with the fact we have untested code?
I'm not.

I await the results of your testing, though they will be invalid since the proposed code change is not against the current source of the project.


Promise files for caching not reliably deleted

🐛 Describe the bug
With version 0.5.0 the promise files for caching are no longer reliably deleted. Instead of trying to delete the file as soon as the cache has been created torchdata seems to wait for the end of the data pipe before it tries to delete it. I did not encounter this issue with version 0.4.1
Versions
PyTorch version: 1.13.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A
OS: macOS 13.1 (arm64)
GCC version: Could not collect
Clang version: 15.0.4
CMake version: version 3.24.3
Libc version: N/A
Python version: 3.10.8 (main, Oct 13 2022, 09:48:40) [Clang 14.0.0 (clang-14<IP_ADDRESS>)] (64-bit runtime)
Python platform: macOS-13.1-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True
Versions of relevant libraries:
[pip3] numpy==1.23.4
[pip3] pytorch-lightning==1.8.1
[pip3] torch==1.13.0
[pip3] torchdata==0.5.0
[pip3] torchdistx==0.2.0+cpu
[pip3] torchmetrics==0.10.2
[pip3] torchtext==0.14.0
[pip3] torchvision==0.14.0

Yeah. We did that to make sure the cache working with 1-to-N scenario like caching the result from untar an archive.
It would be good if you can share a minimum scripts to understand your use case.

Would be nice to have a flag to alter the behavior for each use case. For me the current behavior just results in a caching timeout and the DataLoader2 only outputs the first element from the data pipe. I'll try to write a minimum script, but that may take some time.

Thank you for providing the pipeline. I will take a look!


Using last cartoassets changes

Related ticket: https://github.com/CartoDB/cartodb/issues/8081.
But, in fact, it is a task from https://github.com/CartoDB/cartodb/milestone/139 milestone.
Basically making use of the new changes added in CartoAssets https://github.com/CartoDB/CartoAssets/pull/162.
But, before merging this, we need to merge those changes in CartoAssets, then in CARTO.js, after that in Deep-insights, and finally here. 💃
cc @CartoDB/frontend

No need to change NEWs, I feel.

Deploying it in ded04 servers.

Tested it in ded04 server and looks ok, from private builder to public embed, but could anyone ( @CartoDB/frontend ) take a look please? 💋

It works smoothly, I couldn't find any flaws. Also, some savings in the final bundle:

5kb en editor3css y 2 kb en deep_insights.css, uncompressed.
gzips remain in almost the same value, totally understandable.

But the main goal of this ticket was not the final weight, so kudos :)

So... starting the party with CartoAssets ---> CARTO.js ---> Deep-Insights.js ---> Builder

Again, deployed in ded04, just in case someone wants to check it (again). If nobody complains about it, we will deploy it tomorrow morning 💃 .


OCPCLOUD-2703: OWNERS: update subcomponent

Signed-off-by: Nolan Brubaker<EMAIL_ADDRESS>

/retest


Need detail on what Marketo fields need to be added

This article needs to explain what additional fields need to be added to the Marketo form. At this time, the documentation is to vague on this point. Essentially, this text needs to be expanded a LOT: "4. Fill in the required fields in the New Form dialog box, and then select Create."

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

ID: 052f5dca-5b4f-81d4-35c7-b8ff7cfe7458
Version Independent ID: dd023ce4-c24d-4f53-24b1-30e30ff643ea
Content: Lead management in Marketo - Microsoft commercial marketplace
Content Source: articles/marketplace/partner-center-portal/commercial-marketplace-lead-management-instructions-marketo.md
Service: marketplace
Sub-service: partnercenter-marketplace-publisher
GitHub Login: @trkeya
Microsoft Alias: trkeya

Thanks for bringing this to our attention. Your feedback has been shared with the content owner for further review.

Cross reference with #70237

We are looking into these details with Marketo and will update the documentation to reflect this in an upcoming release. Thanks for your interest in our docs! #please-close


Fix Orbitals Not Showing Up

Issue: https://github.com/Autodesk/notebook-molecular-visualization/issues/38
This seems to be caused by a bug in the v6 beta releases on ipywidgets (I tried both b1 and b2).  I submitted an issue: https://github.com/ipython/ipywidgets/issues/876.  But the workaround in the meantime is to use a Dropdown instead.

@avirshup Review please!

Looks good, thanks! :+1:


Error for multiple gpu training

In the config file trainer part, if I set auto_select_gpus: true and devices: 2, I got an error like
AttributeError: Can't pickle local object 'FeatureExtractor.get_features.<locals>.hook', it comes from this line trainer.fit(model=model, datamodule=datamodule) in anomalib/tools/train.py script but for single GPU it works without an error. Any comments about this error / is it possible to use multiple GPUs for training and testing?

Hi @udasinnayan that's a known issue. This might probably be solved when me move towards torchfx but the only option is to use single GPU for now.

@ashwinvaidya17, I'm wondering if this is the case even when we use timm's feature extractor


link underlines not showing on chrome

Hi Toma,
I am using your theme for my website which I'm hosting on github pages. When viewing the website locally I can see the link underlines which I understand is created using a combination of a background image and text shadow. The strange thing is that the underlines do not show up on chrome when I view the online version of my website. They show fine on Safari and on my iphone. They also show fine when I view my website on chrome locally.
If you visit "Future of Work" post on my website for example and search for "Whitebox Consulting", that should be a link. If you hover over it, it'll get highlighted. But the underline should not show up if you are viewing on chrome.  I'm using the most recent version of chorme : 68.0.3440.106
So I started inspecting and figured out that if I change the .content a css and instead of background-size: 1px 2px I set it to background-size: 2px 3px then the underline starts showing up! It seems like the image has been too small and 1 pixel has been lost somewhere.
Do you have any idea why this is happening?

I figured that the underline was not showing because the page was zoomed out to 90%.

Hey @mkhezr, thanks for figuring that out!
I thought the issue might have been related to Chrome, which recently implemented a style change with underlined words. Since Chrome 64, the browser creates the same "ink skipping" effect by default as I have done with the links of this themes. https://superuser.com/questions/1293529/when-did-chrome-start-underlining-links-differently
I've noticed that this may sometimes mess with the theme's link underlines on Chrome at different resolutions.


CircuitVerse Favicon Logo

We have a decent CircuitVerse logo but we do not have a good square logo which can be used as favicon or for places we need a shorter form of the logo.
Not sure what is needed. I am thinking similar to the current Favicon logo would do.

Is there a file type preference?

Is this issue resolved ?

@shubhankarsharma00 I checked the svg image in your PR. Though you have designed as asked, something seems to be missing. Maybe the shorter logo should not be "CV" and instead be a circuit design type logo similar to the current logo.

@satu0king I completely agree with the point that there seems to be something missing in the short logo that I designed. If you're thinking of designing a circuit design type logo I'll be happy to assist.

https://circuitverse.org/img/favicon.ico like this.

Hey, is the issue still open.
I would like to take this up

Hi @sarthak77 Please make a new favicon for CIrcuitVerse somewhat like the current one and then we will see. As of yet, this issue is still under discussion and no one has claimed it..so, I believe that you can.

Ok I'll be on it

@satu0king @Parikshit-Hooda is the issue still open? I have a few ideas. Can I work on this issue?

Hi @pradnyasd , @sarthak77 is working on it and is coming up with a design. If you have any designs in mind please feel free to post them here.

jbj

@armudgal I have made 2 designs. Kindly review it and let me know about the changes if any.

I like the second design, but I'm not sure how well it will scale..

This is one of my own design.
@satu0king @blane1257  @armudgal Please review it.

@satu0king @Parikshit-Hooda @armudgal I have made one more favicon logo

I really like the second logo. If we can make it more simple and remove the background it will look really good. @satu0king and @tachyons comments?

@armudgal I will make the changes and send it to you.

@armudgal How is this. Is this as per your expectation?

An advice : use all the above candidates as favicons in your own browser and compare them with some well known ones like FB, GitHub. My personal favorite is this so far :

What is the update on this issue?

@satu0king @blane1257  @shubhankarsharma00 @armudgal @tachyons  Any update on this issue??

Please keep the logos simple, Logos like this have too much detail which will be lost when made into a favicon

I like the second design, but I'm not sure how well it will scale..

I agree, we should give it a try.

@blane1257, I am not able to find the logo, you designed, could you share it again here?

@armudgal @Parikshit-Hooda I have made 2 designs. Kindly review it and let me know about the changes if any.

These are the rough designs just to showcase the ideas.
I have tried to include "C" and "V" in both of them.

Thanks for these designs!
The second and fourth look good. Can you try making them simpler. Remember, the size of the image will be scaled down to this size, and things will not be visible then.

@armudgal How are these? Are these as per your expectations?

Hello, these look nice for analog design circuits, not so much for CV

This one looks good.

@armudgal How are these? Are these as per your expectations?

Hello, these look nice for analog design circuits, not so much for CV

The second one in this looks good.

This is the logo by @blane1257. It is my favourite so far. Not very circuity but elegant and recognizable like the GitHub logo. What do you say @armudgal ?

@Parikshit-Hooda @satu0king
Kindly finalize a logo and in case if you need any help do let me know. :blush:

I made these Favicon Logo.

Sorry for the delay, we have shortlisted these two logo.
@blane1257's logo

@pradnyasd's logo

Please fine tune your logos. @pradnyasd a black and white logo would be good.

@pradnyasd  please make the whole logo(the one that looks like a voltmeter) in black and white. We will make a final decision based on how that looks.

@Parikshit-Hooda @satu0king
I have made 2 black and white logos. Kindly review it.

@pradnyasd looks good! Will you be able to generate SVGs of the same?

@satu0king How should I send you the SVGs?
This doesn't support SVG format.

Send a PR with the SVG logos. Or else post the code of the SVG here(not recommended).

@armudgal  @satu0king
I have created a PR. Kindly review it and merge it.


the taskbar flashes when you open the start menu

the taskbar flashes when you open the start menu
To Reproduce
set taskbat to blur
It happens some time
1.press windows button
2.taskbar flashes
Or (It happens all the time)
1.drag a window
2.press windows button
3. the taskbar flashes
Expected behavior
stop the taskbar flashes
Screenshots
video
Desktop (please complete the following information):

OS: [Windows 11]
Version [22000.348]

Additional context
an other small bug when the tackbar is set blur and the rounded corner are enable we must press windows button to show the rounded corne
https://user-images.githubusercontent.com/80718477/143676656-fe554d20-1dc0-472f-8a65-c37aff9de685.mp4
rs

I have Windows 10 and version (I don't know if you meant OS Build) 19043.1348 is it. My taskbar flashing when open Start Menu, how can I fix it?

@Fefedu973 This should only happen with the Acrylic effect.. but you are having it with blur too! The Taskbar refreshes itself when the start button is hit. Sadly i can't make it stop doing that :/


How to upgrade versions?

How should we upgrade from 20.1 to 20.2?

Backup all your data in KodiPortable\App\Kodi\portable_data
Use KodiPortable_20.2.0.paf.exe to upgrade or reinstall
Copy the backup data folder back to KodiPortable\App\Kodi\portable_data


Icons are not aligned in the farming page

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
Copy icon is not aligned with the input in tfchain secret field.

Steps To Reproduce
check your farm in farming page.
Relevant screenshots/screen records

Relevant log output
-

Also, can we rephrase the tfchain hint?

Work Completed:

Icons aligned && Message updated.


Masks

zigzags, scoops, scallops and corner cuts
discussion in #71
todo:

[x] add 3 angle cuts
[x] add 3 square cuts
[x] update docsite with example section
[x] update docsite with usage section
[ ] add tests

I think if the mask are going to be static we can still optimize them. My initial idea was to have the same code for all and only adjust the angle as a variable but we can still have an optimized version for each case.
For the Square cut we can do it with one gradient like below:
--mask: conic-gradient(from -90deg at 1rem 1rem,#0000 90deg,#000 0)  0 0/calc(100%  - 1rem) calc(100%  - 1rem)

Demo: https://codepen.io/t_afif/pen/OJxpyOo

For the angle one we can do this: https://codepen.io/t_afif/pen/YzrZyaY

nice, something to see here https://open-props--pr126-mask-props-81xijln5.web.app/#masks

need to fix scalloped vertical

You can fix it that way:
--mask-edge-scalloped-vertical: linear-gradient(#000 0 0) center / 100% calc(100% - 2 * 20px) no-repeat, radial-gradient(circle farthest-side,#000 97%,rgba(0,0,0,0)) 50%/ calc(1.9 * 20px) calc(2 * 20px) repeat space

I updated 0 to 50% so it becomes centered

by the way, it looks super cool on the website. Can't wait to have more variations! :+1:

I see you made different sizes for the cut-corner which is good. Can we do the same for the edges?
I know we may end with a verbose code if we will have different variations but I was thinking about a variable --mask-edge-size: 20px that will replace the 20px you are setting.
We can have the variable inside :where(html) {}. If anyone want to update it, he can. Otherwise the default 20px will apply.

Also, I just got a better idea for the circular cut
instead of this
--mask-corner-cut-circles-1: radial-gradient(circle 1rem,#0000 99%,#000) 10000% 10000% / 99.5% 99.5%;
--mask-corner-cut-circles-2: radial-gradient(circle 2rem,#0000 99%,#000) 10000% 10000% / 99.5% 99.5%;
--mask-corner-cut-circles-3: radial-gradient(circle 4rem,#0000 99%,#000) 10000% 10000% / 99.5% 99.5%;

We can do this
--mask-corner-cut-circles-1: radial-gradient(1rem at 1rem 1rem,#0000 99%,#000) -1rem -1rem;
--mask-corner-cut-circles-2: radial-gradient(2rem at 2rem 2rem,#0000 99%,#000) -2rem -2rem;
--mask-corner-cut-circles-3: radial-gradient(4rem at 4rem 4rem,#0000 99%,#000) -4rem -4rem;

Sorry for the last minute changes 😅 but this last syntax should be better (I just got the idea now) and also give better result. The first one relies on calculations that involve rounding so it can break in very rare case while the last one relies on integers


Cannot open configuration

When i try to open autosync i got this error:
Could not setup the execution monitor "access is denied"
I press OK
then i got :
Could not reload the configuration from the server "access is denied"
Then the autosync editor open with nothing.
If i try to do file + reload configuration from server i got  Could not reload the configuration from the server "access is denied" again.
from the log, i see that the service can read my Management Agen and run profiles and end with
2020-11-05 16:48:11.8171| INFO|Initialized service host pipe
2020-11-05 16:48:11.8171| INFO|Creating execution engine
2020-11-05 16:48:11.8171|TRACE|Replaced service debug behavior
2020-11-05 16:48:11.8327| INFO|Initialized named pipe event service host
2020-11-05 16:48:13.3483| WARN|Service is not yet configured. Run the editor initialize the configuration
For me all the rights are ok but maybe I missed something.
Best Regards,

It is now solved.
MimSync is installed on d:\ and Autosync was installed on d:.
If I install Autosync on c:\ its work fine.
Best Regars,


Prometheus too old sample issue

What did you do?
I am using Prometheus v2.47.0 in a production environment, and samples are sending from the Prometheus Agent to the Prometheus Server via remote write. At first, everything was normal, but one day both the Prometheus Agent and the Prometheus Server started logging errors simultaneously. Subsequently, remote write encountered exceptions, and samples could no longer be sent from the Prometheus Agent to the Prometheus Server. The Prometheus Server was unable to retrieve any data. The related logs are as follows.
What did you expect to see?
No error or warn logs are present, and the Prometheus remote write is working properly.
What did you see instead?


Alarmo changed to armed when restarting HomeAssistant

I don't know exactly why, if I miss something. But when doing a Home Assistant restart to apply some config changes, and when it started again Alarmo changed to Pending. And then to armed, and triggered when a sensor triggers the alarm.
It's normal behaviour or I'm doing something wrong?

Alarmo is supposed to restore its previous state, so it sounds like something is going wrong.
I must say there is some difficult code in there, because sensors might not be available immediately after restart and Alarmo needs to wait for them to be initialised.
Could you enable debug logging for Alarmo?
This way we could trace back what happens in your situation.
You can do so by add something like this to the configuration.yaml:
logger:
  default: warning
  logs:
    custom_components.alarmo: debug

Please post your findings next time it happens.

There is problem when the alarm fail to arm then if you restart Homeassistant alarmo arm again

Tried to Arm with one door opened. Failed to arm. Then restart home assistant, first time no issue. Restart again, and alarmo tried to Arm again.
Here is the debug from second restart:

2021-03-05 11:17:33 DEBUG (MainThread) [custom_components.alarmo.mqtt] MQTT config was (re)loaded
2021-03-05 11:17:33 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] alarm_control_panel.planta_baja is added to hass
2021-03-05 11:17:33 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] Initial state is disarmed
2021-03-05 11:17:33 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] Waiting for all sensors to be ready...
2021-03-05 11:17:33 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] alarm_control_panel.primera_planta is added to hass
2021-03-05 11:17:33 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] Initial state is disarmed
2021-03-05 11:17:33 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] Waiting for all sensors to be ready...
2021-03-05 11:17:33 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] alarm_control_panel.jardin is added to hass
2021-03-05 11:17:33 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] Initial state is disarmed
2021-03-05 11:17:33 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.jardin was updated from None to disarmed
2021-03-05 11:17:33 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] alarm_control_panel.master is added to hass
2021-03-05 11:17:40 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.livingroomdoor_contact changed: old_state=unknown, new_state=closed
2021-03-05 11:17:40 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.kitchensmoke_smoke changed: old_state=unknown, new_state=closed
2021-03-05 11:17:40 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.livingroomwindowsensor_contact changed: old_state=unknown, new_state=closed
2021-03-05 11:17:40 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.maindoor_contact changed: old_state=unknown, new_state=closed
2021-03-05 11:17:40 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.kitchenwindowsensor_contact changed: old_state=unknown, new_state=closed
2021-03-05 11:17:40 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.officewindow_contact changed: old_state=unknown, new_state=closed
2021-03-05 11:17:40 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garagesmoke_smoke changed: old_state=unknown, new_state=closed
2021-03-05 11:18:03 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Not all sensors are initialized yet, starting anyway.
2021-03-05 11:18:03 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm is now armed (armed_away).
2021-03-05 11:18:03 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.planta_baja was updated from None to armed_away
2021-03-05 11:18:03 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Not all sensors are initialized yet, starting anyway.
2021-03-05 11:18:03 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm is now armed (armed_away).
2021-03-05 11:18:03 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.primera_planta was updated from None to armed_away
2021-03-05 11:18:25 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.shelly_shdw_1_f02fa2_door_window changed: old_state=unknown, new_state=closed
2021-03-05 11:18:25 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.shelly_shwt_1_b050fd_flood changed: old_state=unknown, new_state=closed
2021-03-05 11:18:25 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.shelly_shdw_2_483fda81f255_door_window changed: old_state=unknown, new_state=closed
2021-03-05 11:18:25 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.shelly_shdw_2_483fda81f16f_door_window changed: old_state=unknown, new_state=closed
2021-03-05 11:18:25 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.shelly_shdw_1_f03338_door_window changed: old_state=unknown, new_state=open
2021-03-05 11:18:25 DEBUG (MainThread) [custom_components.alarmo.sensors] Alarm is triggered due to sensor: binary_sensor.shelly_shdw_1_f03338_door_window
2021-03-05 11:18:25 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.planta_baja was updated from armed_away to pending
2021-03-05 11:18:25 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.planta_baja is updated from armed_away to pending
2021-03-05 11:18:25 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.master was updated from disarmed to pending
2021-03-05 11:18:25 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: default_config, homekit, transmission, met, unifiprotect
2021-03-05 11:18:25 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.master is updated from disarmed to pending
2021-03-05 11:18:28 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.shelly_shgs_1_500291c3a904_gas changed: old_state=unknown, new_state=unavailable
2021-03-05 11:18:28 DEBUG (MainThread) [custom_components.alarmo.sensors] Entity binary_sensor.shelly_shgs_1_500291c3a904_gas should not trigger on unavailable state, ignoring
2021-03-05 11:18:45 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] async_entry_timer_finished
2021-03-05 11:18:45 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.planta_baja was updated from pending to triggered
2021-03-05 11:18:45 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.planta_baja is updated from pending to triggered
2021-03-05 11:18:45 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.master was updated from pending to triggered
2021-03-05 11:18:45 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.master is updated from pending to triggered
2021-03-05 11:18:45 DEBUG (MainThread) [custom_components.alarmo.automations] executing automation<PHONE_NUMBER>
2021-03-05 11:19:23 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] alarm_disarm
2021-03-05 11:19:24 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] alarm_disarm
2021-03-05 11:19:24 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.planta_baja was updated from triggered to disarmed
2021-03-05 11:19:24 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] alarm_disarm
2021-03-05 11:19:25 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.primera_planta was updated from armed_away to disarmed
2021-03-05 11:19:25 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] alarm_disarm
2021-03-05 11:19:25 WARNING (MainThread) [custom_components.alarmo.alarm_control_panel] Cannot go to state disarmed from state disarmed.
2021-03-05 11:19:25 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.planta_baja is updated from triggered to disarmed
2021-03-05 11:19:25 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.master was updated from triggered to disarmed
2021-03-05 11:19:25 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.primera_planta is updated from armed_away to disarmed
2021-03-05 11:19:25 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.master is updated from triggered to disarmed

This line provides a good clue:

2021-03-05 11:18:03 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Not all sensors are initialized yet, starting anyway.

It suggests that Alarmo was unable to start properly since there are sensors which remain in undefined state for too long (more than 30 seconds).
Does this sound familiar to you?
Besides this, I also see an issue in the Alarmo code that may lead to the starting in the wrong state (armed instead of disarmed).
I will update this code, hopefully it resolves the problem for you.

👍

This line provides a good clue:

2021-03-05 11:18:03 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Not all sensors are initialized yet, starting anyway.

It suggests that Alarmo was unable to start properly since there are sensors which remain in undefined state for too long (more than 30 seconds).
Does this sound familiar to you?

The only sensor unavailable showed on the log, Alarmo says ignoring it. It should not be a problem, correct? It there's another sensor undefined, shouldn't it show up in the log?

Besides this, I also see an issue in the Alarmo code that may lead to the starting in the wrong state (armed instead of disarmed).
I will update this code, hopefully it resolves the problem for you.

Great! Will update and test it when available. Fast for me to test with some restart

There is problem when the alarm fail to arm then if you restart Homeassistant alarmo arm again

That's exactly what happened to me as well. Without going too deep into the code, I think that adding an additional condition and not self.open_sensors to the async_added_to_hass functions in alarm_control_panel.py should fix it:
         _LOGGER.debug("Initial state is {}".format(initial_state))
        if initial_state == STATE_ALARM_TRIGGERED:
            await self.async_trigger(skip_delay=True)
        elif not self.hass.data[const.DOMAIN]["sensor_handler"].all_sensors_available_for_alarm(
            self.area_id,
            initial_state
        ):
            _LOGGER.debug("Waiting for all sensors to be ready...")

            @callback
            async def async_initialization_timer_finished(now):
                """Update state at a scheduled point in time."""
                _LOGGER.info("Not all sensors are initialized yet, starting anyway.")
                if self.arm_mode and not self.open_sensors:
                    await self.async_arm(self.arm_mode)
                else:
                    await self.async_update_state(STATE_ALARM_DISARMED)

            self.async_set_timer(const.INITIALIZATION_TIME, async_initialization_timer_finished)
        elif initial_state in ARM_MODES and not self.open_sensors:
            await self.async_arm(self._arm_mode)
        else:
            await self.async_update_state(STATE_ALARM_DISARMED)

        self.async_write_ha_state()

It seems to work, but I am not completely sure that I am not breaking any other thing. :sweat_smile:
If you think it the correct solution, I wouldn't mind creating a pull request.
Btw, thanks very much for the project! It helped me a lot with some automations (especially with the notifications!). :clap:

That's exactly what happened to me as well. Without going too deep into the code, I think that adding an additional condition and not self.open_sensors to the async_added_to_hass functions in alarm_control_panel.py should fix it:

The self.async_arm function checks all conditions prior to arming, so it would not arm your system if there are sensors preventing this.
Therefor I don't think your proposed change is an improvement, in fact it's rather dangerous as the self.open_sensors property may be outdated (so the system might disarm itself after restarting HA due to making false decisions).
If you want to help solving this issue, please update to v1.5.5, enable debug logging (see my earlier post) and share a log file covering the moment where alarmo starts up in the wrong state.
I cannot reproduce the scenario that you're experiencing, so I rely on your input for solving this case.

The proposed change was inside the async_added_to_hass function that I thought it was only invoked after a restart (I read it from here. Maybe my assumption was wrong :sweat_smile:
The way to reproduce the problem is the following (I always had the version v1.5.5):

Open a contact sensor (e.g. a door)
Arm the alarm (e.g. in arm home)
The arming process fails because there is an open sensor
The home alarm stays as DISARMED
I restart the Home Assistant
It will restart and will arm the alarm as ARMED_HOME

Here there are the logs from step 1 to step 3:
2021-04-06 12:46:08 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] alarm_arm_home
2021-04-06 12:46:08 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Cannot transition from state disarmed to state armed_home, there are open sensors
2021-04-06 12:46:08 DEBUG (MainThread) [custom_components.alarmo.automations] alarm_control_panel.home_alarm has failed to arm
2021-04-06 12:46:08 DEBUG (MainThread) [custom_components.alarmo.automations] executing automation *******

The state of the alarm as in step 4 is set to "disarmed". The rest of the state attribes are as follow:
code_format: number
changed_by: ***
code_arm_required: true
arm_mode: armed_home
open_sensors:
  binary_sensor.contact_door_front_contact: open
bypassed_sensors: null
delay: null
expiration: null
friendly_name: Home Alarm
icon: 'mdi:shield-home'
supported_features: 7

Finally, step 5 and 6 logs are:
2021-04-06 12:47:01 DEBUG (MainThread) [custom_components.alarmo.card] registering card
2021-04-06 12:47:01 DEBUG (MainThread) [custom_components.alarmo.mqtt] MQTT config was (re)loaded
2021-04-06 12:47:01 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] alarm_control_panel.home_alarm is added to hass
2021-04-06 12:47:01 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] Initial state is disarmed
2021-04-06 12:47:01 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] Waiting for all sensors to be ready...
2021-04-06 12:47:31 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Not all sensors are initialized yet, starting anyway.
2021-04-06 12:47:31 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm is now armed (armed_home).
2021-04-06 12:47:31 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.home_alarm was updated from None to armed_home

And the home alarm state after step 6 is set to armed_home and the attributes are:
code_format: number
changed_by: ***
code_arm_required: true
arm_mode: armed_home
open_sensors: null
bypassed_sensors: null
delay: null
expiration: null
friendly_name: Home Alarm
icon: 'mdi:shield-home'
supported_features: 7

Anyhow, I invested a little more of time in understing those conditions in the async_added_to_hass function and I think that the problem has an easy fix.
If I understood it correctly, the second branch checks if all sensors are available to arm the system. However the condition that the system should be armed is not checked there. Therefore the self.async_set_timer(const.INITIALIZATION_TIME, async_initialization_timer_finished) is called even in the case that there is no need to wait for sensors to arm the system because the initial state is disarmed.
I think that if we add the condition of initial_state in ARM_MODES in the second branch should be enough to solve this issue.
Here is a fragment of the function async_added_to_hass with the proposed fix and it worked witth my current configuration.
        if initial_state == STATE_ALARM_TRIGGERED:
            await self.async_trigger(skip_delay=True)
        elif initial_state in ARM_MODES and not self.hass.data[const.DOMAIN]["sensor_handler"].all_sensors_available_for_alarm(
            self.area_id,
            initial_state
        ):
            _LOGGER.debug("Waiting for all sensors to be ready...")

            @callback
            async def async_initialization_timer_finished(now):
                """Update state at a scheduled point in time."""
                _LOGGER.info("Not all sensors are initialized yet, starting anyway.")
                await self.async_arm(self.arm_mode)

            self.async_set_timer(const.INITIALIZATION_TIME, async_initialization_timer_finished)
        elif initial_state in ARM_MODES:
            await self.async_arm(self._arm_mode)
        else:
            await self.async_update_state(STATE_ALARM_DISARMED)

Btw, it seems that maybe the previous code can be refactored by checking if initial_state == STATE_ALARM_DISARMED. The  code before the snippet already sets initial_state for the cases of pending and arming, setting it to triggered and arm_mode respectively. However I didn't change it in case I am overseeing something.
Thanks and let me know if I can help with something.

If I understood it correctly, the second branch checks if all sensors are available to arm the system. However the condition that the system should be armed is not checked there. Therefore the self.async_set_timer(const.INITIALIZATION_TIME, async_initialization_timer_finished) is called even in the case that there is no need to wait for sensors to arm the system because the initial state is disarmed.

The reason behind this, is that some sensors (smoke/flood sensors, etc.) can always trigger the alarm.
So while the chance is very low that the system starts with the activation of such sensor, it cannot be ignored.
As long as the sensor states are not known (due to taking too long to initialize), the initial state cannot be assumed.

I think that if we add the condition of initial_state in ARM_MODES in the second branch should be enough to solve this issue.

I think indeed this is the root-cause of the problem.
The arm_mode should be null when the alarm is disarmed, for some reason this is not the case.
I will check what causes this and work on a fix.

I am assuming this problem is fixed since the last update.
Please let me know if there are still problems.

Whenever i restart home assistant alarmo arm itselfs, even though that it was not armed before the reboot. Not very nice when you are tinkering your HA config and then suddenly lights start blinking after a reboot :/
Im in the latest version in alarmo and home assistant


weather.device_name entity is unavailable

System Health details
System Information

version
core-2024.11.3

installation_type
Home Assistant OS

dev
false

hassio
true

docker
true

user
root

virtualenv
false

python_version
3.12.4

os_name
Linux

os_version
6.6.54-haos

arch
x86_64

timezone
Pacific/Auckland

config_dir
/config

Home Assistant Community Store

GitHub API
ok

GitHub Content
ok

GitHub Web
ok

HACS Data
ok

GitHub API Calls Remaining
4980

Installed Version
2.0.1

Stage
running

Available Repositories
1469

Downloaded Repositories
41

Home Assistant Cloud

logged_in
true

subscription_expiration
May 6, 2025 at 12:00 PM

relayer_connected
true

relayer_region
ap-southeast-1

remote_enabled
true

remote_connected
true

alexa_enabled
true

google_enabled
false

cloud_ice_servers_enabled
true

remote_server
ap-southeast-1-1.ui.nabu.casa

certificate_status
ready

instance_id
5bf1a599c99a48e59324384e44e7f3f2

can_reach_cert_server
ok

can_reach_cloud_auth
ok

can_reach_cloud
ok

Home Assistant Supervisor

host_os
Home Assistant OS 13.2

update_channel
stable

supervisor_version
supervisor-2024.11.4

agent_version
1.6.0

docker_version
27.2.0

disk_total
46.5 GB

disk_used
16.3 GB

healthy
true

supported
true

host_connectivity
true

supervisor_connectivity
true

ntp_synchronized
true

virtualization
kvm

board
ova

supervisor_api
ok

version_api
ok

installed_addons
Studio Code Server (5.17.3), ESPHome Device Compiler (2024.11.2), Let's Encrypt (5.2.5), Samba share (12.3.2), Terminal & SSH (9.15.0), Samba Backup (5.2.0), Mosquitto broker (6.4.1), NGINX Home Assistant SSL proxy (3.11.1), FTP (5.1.1)

Dashboards

dashboards
11

resources
33

views
34

mode
storage

Recorder

oldest_recorder_run
November 21, 2024 at 4:30 AM

current_recorder_run
November 30, 2024 at 7:26 PM

estimated_db_size
946.36 MiB

database_engine
sqlite

database_version
3.45.3

Xiaomi Miot Auto

component_version
0.7.24

can_reach_server
ok

can_reach_spec
ok

logged_accounts
1

total_devices
1

Checklist

[X] I have filled out the issue template to the best of my ability.
[X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
[X] This issue is not a duplicate issue of any previous issues..

Describe the issue
After switching back to the Public API from the Mobile API on v0.8 most entities are populated, except the weather.nz_metservice entity (with forecast information).
I tried configuring the location as Cambridge, then I tried Hamilton. The same result happened.
I deleted the nz_metservice device I had created from the integration, rebooted and recreated it. No difference.
The entity is correctly created (the device has 21 entities, up from the 19 on the mobile API), but I open the weather.nz_metservice entity it says "This entity is unavailable".
I noticed these two errors in the system logs:

Logger: homeassistant.components.weather
Source: helpers/entity_platform.py:599
integration: Weather (documentation, issues)
First occurred: 7:26:24 PM (4 occurrences)
Last logged: 7:31:16 PM
Error adding entity weather.nz_metservice for domain weather with platform metservice_weather
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 599, in _async_add_entities
await coro
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 918, in _async_add_entity
await entity.add_to_platform_finish()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1368, in add_to_platform_finish
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1007, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1132, in _async_write_ha_state
self.__async_calculate_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1073, in __async_calculate_state
if extra_state_attributes := self.extra_state_attributes:
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/metservice_weather/weather.py", line 340, in extra_state_attributes
'forecast_daily': self.forecast_daily
^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/metservice_weather/weather.py", line 424, in forecast_daily
for day in range(0, num_days):
^^^^^^^^^^^^^^^^^^
TypeError: 'NoneType' object cannot be interpreted as an integer

and also:

Logger: custom_components.metservice_weather.coordinator
Source: custom_components/metservice_weather/coordinator.py:358
integration: MetService New Zealand Weather (documentation, issues)
First occurred: 7:26:24 PM (11 occurrences)
Last logged: 7:34:53 PM
Error retrieving public forecast daily sensor '' for day 0: 'days'

Reproduction steps
Install integration v0.8
Create a new device with the name "NZ MetService".
Set town to Cambridge or Hamilton.
Look for the weather.nz_metservice entity in Developer Tools or Device Entity view.
Entity has the error "This entity is unavailable"
Debug logs
No response
Diagnostics dump
No response

Confirming the same issue for me, this is not an isolated case.
For further reports of the same fault, please 👍 the OP rather than commenting a +1 or similar.

Couldn't for the life of me figure this out... works for almost everyone, didn't work for Hamilton...
Turns out that due to a typo, it only worked when Tides were configured, and of course Hamilton doesn't have a tide.
V0.8.1 coming shortly.

Heh - same issue for me, living in Palmerston North :)
I found a work around yesterday, which was to use the Mobile API key.

@sultanoswing or others can you confirm v0.8.1 solves for you? It did in my testing

Sorry for the delay,  Ive just installed v0.8.1 and it this has fixed the issue for me. Thanks heaps for the quick fix, and for your work on this integration.

Fixed it for me, thanks.  Mind you,  I disabled tide info, given I'm in Palmy. Great to have the integration working fully,  as its now powering my Custom Weather Chart Card properly for the first time (so I've been able to stop using Openweather, and don't have to try Weather.com).


mxgpu: adapt to changes in kernels >= 4.11.0

Signed-off-by: Christian Brauner<EMAIL_ADDRESS>

Not sure if Tonny Wong is on Github otherwise I'd ping him. :)

I will forward to Tonny.
Thanks,
Kelly
From: Christian Brauner<EMAIL_ADDRESS>Sent: Friday, July 27, 2018 7:53 AM
To: GPUOpen-LibrariesAndSDKs/MxGPU-Virtualization<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [GPUOpen-LibrariesAndSDKs/MxGPU-Virtualization] mxgpu: adapt to changes in kernels >= 4.11.0 (#9)
Not sure if Tonny Wong is on Github otherwise I'd ping him. :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/GPUOpen-LibrariesAndSDKs/MxGPU-Virtualization/pull/9#issuecomment-408396744 , or mute the thread https://github.com/notifications/unsubscribe-auth/ASfsUxf-V5EunOvfYPugQoqp9b_2QJJjks5uKv8tgaJpZM4VjX3h .  https://github.com/notifications/beacon/ASfsU3mkx-W4Q4cmYuSUqHsnxecy8tQBks5uKv8tgaJpZM4VjX3h.gif

It looks like this PR can be closed. Current master seems to have the changes proposed here.

It looks like this PR can be closed. Current master seems to have the changes proposed here.

Can you point to the commit or code by any chance?

There are very few commits, apparently one per release. The code I checked was https://github.com/GPUOpen-LibrariesAndSDKs/MxGPU-Virtualization/blob/master/drv/gim_drv.c where I can find things such as #if LINUX_VERSION_CODE < KERNEL_VERSION(4, 14, 0)


doc: Update release notes.

I will probably update these a couple more times before cutting the release on Monday, but I figured folks could take a look at them sooner rather than later.

This change is

PTAL. Getting ready to cut the release.


Performing zero-shot forecasting

Hi,
Thanks for sharing the good work.
I am using Moment models for zero-shot time series forecasting. The result of forecasting a synthetic sine wave is really bad. I wonder if I've missed anything. Or is Moment intended to work in a fine-tuned manner?
The model I used was:
model = MOMENTPipeline.from_pretrained(            'AutonLab/MOMENT-1-large',              model_kwargs={                 'task_name': 'forecasting',                 'forecast_horizon': prediction_length,                 'head_dropout': 0.1,                 'weight_decay': 0             }, )
The prediction horizon is 64, and the lookback horizon is 512.

Best,
Pengrui

Hi Pengrui,
Thanks for you interest in MOMENT!
I see that you are using MOMENT in forecasting mode (task_name = 'forecasting'):
model = MOMENTPipeline.from_pretrained( 'AutonLab/MOMENT-1-large',
model_kwargs={ 'task_name': 'forecasting', 'forecast_horizon': prediction_length, 'head_dropout': 0.1, 'weight_decay': 0 }, )

In this mode, a randomly initialized linear layer maps embeddings of historical time series to the forecasting horizon. Hence, the forecasts are essentially random.
Here's 2 ways to use MOMENT:

(Option) You can initialize MOMENT in reconstruction mode (task_name = 'reconstruction'), and use masked reconstruction for forecasting by masking the last 1 or 2 patches, corresponding to a forecasting horizon of $8$ and $16$, respectively. You can use mask in the model forward pass, as shown in the imputation notebook to reconstruct the patches and forecast future time steps.
(Highly Recommended) You can fine-tune the forecasting head on limited data.

Let us know if you have any more questions! And thanks again for your interest in MOMENT!

Thanks so much for the detailed illustration!


Add prettier-tailwindcss plugin and config

This pull request includes the addition of the prettier-tailwindcss plugin and the corresponding configuration file. The plugin is added as a dev dependency and the configuration file sets the tab width, disables semicolons, enables single quotes, and includes the prettier-plugin-tailwindcss plugin. The import statements in the App.vue file have also been refactored.

bagus wahai anak muda, lanjutkan


[62] Feature/Edge Label Backgrounds

Update label style for both nodes and edges: (is nested under style.label)
type LabelStyle = Partial<{
  color: string
  fontFamily: string
  fontSize: number
  wordWrap: number
  background: string
  backgroundOpacity: number
}>

why delete this? no other way to style label edges?


Replace node renderable ( same rotation, position and scale ) with another node renderable

Hello,
I am new to sceneform sdk . I have added one Transformable Node , then i applied some rotation , scalling and changed its position also. Now on click of button i need to place second node with same rotation , scalling and position. For that what  i did is:
Node nodeTwo = new Node();
nodeTwo.setLocalPosition(nodeOne);
nodeTwo.setLocalRotation(nodeOne);
nodeTwo.setLocalScale(nodeOne);
nodeTwo.setRenderable(renderable);
I have also tried with globalPosition() , globalRotation(). But nothing works , second node got placed on fix position and rotation.Can I do something to 'fix' this?

@malik-at-work
Please help me find any solution on this.

it was just a silly mistake. I was adding one Base below Anchor node as parent which is the cause of problem.Resolved at below link:
see here

Great that you were able to solve it!


Can't Train Azure Model?

Hello There!
I wanted to do a quick project with machine learning and followed:
https://docs.microsoft.com/en-us/dotnet/machine-learning/tutorials/object-detection-model-builder
BUT I ran into a problem; Visual studio thinks that the training failed when it did not according to Microsoft Azure Machine Learning Studio. I did it 3 times but got the same resultat. I can assure you I have a good internet connection because I am writing this and talking to people on discord. I even restarted visual studio, nothing helped.
Any help appreciated,
Best regards
Philip Magyar
IMAGES:

LOG:
logfile.txt

BTW I downloaded the latest verion from:
https://marketplace.visualstudio.com/items?itemName=MLNET.07 earlier today, as I found; https://github.com/dotnet/machinelearning-modelbuilder/issues/1793

I think I found out what I did wrong but correct my if I am incorrect, I had WAY too little to train on, only 9 images and all failed or "skipped"?

@ Philip2809 please send your data.
Assume your data is not in the proper format, are you expecting to get information on the data page if there is something wrong with your data instead of your training failure?

@JakeRadMSFT  @LittleLittleCloud  and @beccamc  arr all data issues in OD notified to the user in data page?

@v-Hailishi Can you try to reproduce this with the training data above?

@beccamc This issue is not repro on the latest main branch: <IP_ADDRESS>2101 when I using above training data ml_train_data.zip

Run link in Azure portal:
https://ml.azure.com/experiments/id/8ad34cd8-0b2e-445b-a3a7-5760c3306ece/runs/AutoML_5dd26aea-c5d5-4d2d-902a-ea6d8ebdb336?wsid=/subscriptions/83635e26-687a-4333-a2a0-33e3cd1f573a/resourceGroups/FullTestPass/providers/Microsoft.MachineLearningServices/workspaces/FullTestPass&tid=72f988bf-86f1-41af-91ab-2d7cd011db47#details

@Philip2809 Can you update your Model Builder version and see if the problem is still happening?

Hello! I no longer use this to image recognition, I used Custom Vision for a while to make a model and use it but later found out it wasn't what I was looking for. Also it turned out image recognition was not really used in the project I was working on so I stopped using it.
Sadly I no longer have the project where I was testing this stuff out as I have a new computer, the old one was erased. It it trains as it should now I would guess either the bug was fixed or something was wrong in my environment.
Best Regards
Philip Magyar

Thanks for the response Philip! Let us know if you run into any other problems using our product in the future.


Bug: service not listening on localhost:8000 after make run-dev

What happened?
Opening http://localhost:8000/ in a browser, as described in "Running API development" in Readme, fails. Also, the docs don't make it clear what to expect.
As per docker-compose.yml, the "api" service listens on the default port 80, and the "web" service (file server) listens on port 8080. Should the docs maybe point to one or both of those?
What steps did you take?

Followed Readme instruction until (including)  make run-dev
Opened http://localhost:8000/ in a browser

What behavior did you expect?
Anything, but a failure.
Relevant log output
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

I can confirm the bug.
The RSTUF API runs on http://localhost (http://localhost:80), and the TUF metadata is exposed on http://localhost:8080 after the bootstrap.
Thank you @lukpueh ! 🎉

Hey, I confirmed this too. So, the "bug" is in the README.md if I understand correctly. Should we just update it?

It seems that's what we need.
For anyone who wants to work on this: please check if there are other instances of http://localhost:8000 in the repository.
For extra bonus points 😀 it will be awesome if we check that string in the RSTUF Worker repository as we can deploy RSTUF instance from there as well.

I can pick this up :smiley:
Thanks for the pointers @MVrachev

Thank you @KAUTH that you will work on this!


flag icons are broken in Studio translations tab

There is an issue with the CDN that Twemoji (used by the internationalization plugin) uses, causing the flag icons to be broken links.
This has been fixed by the Sanity team in v0.3.9 of the plugin

lgtm!


CloudWatch: Apply startTime and endTime similarly to AWS

Hi, I've noticed several small differences in handling startTime and endTime in GetMetricsData and GetMetricsStatistics compared to AWS (based on docs and my experience).
Summary:

Metrics timestamps in AWS seem to fully disregard miliseconds (docs: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html) - i.e. metric recorded in 2023-06-08T09:04:37.431Z should be accessible even using startTime of 2023-06-08T09:04:37.000Z --> solved by setting microsecond field of each timestamp to 0.
AWS tends to throw exceptions when startTime and endTime are either equal or endTime is greater than startTime --> added exception throwing.
Added test cases.

Thank you for contributing to Moto!
To show our thanks, we'd like to share some of the donations that we've received with you. PR's like this are the big reason that Moto is as successful as it is - so it's only fair that you, as a contributor, gets to share the spoils.
We've created a companion website with more information:
https://payments.getmoto.org/
This website is still in beta, but everything should work. Feel free to open a bug or discussion if you run into any problems:
https://github.com/getmoto/payments


CommandBarFlyout - Calling Show after Hide quickly doesn't actually show the floatie.

Describe the bug
Calling Show after Hide quickly doesn't actually show the Floatie.
In OneNote, when we double click on a text, we show the transient floatie.
But one thing users do is double click > right click
In code, what it would do is a quick Hide then Show.
Expected = the full context menu shows
Actual = full context menu does not show.
Steps to reproduce the bug
Min repro:
myComandBarFlyout.ShowAt(senderElement, new FlyoutShowOptions { Position = e.GetPosition(senderElement)});
myComandBarFlyout.Hide();
myComandBarFlyout.ShowAt(senderElement, new FlyoutShowOptions { Position = e.GetPosition(senderElement)});
Expected behavior
The 2nd ShowAt does not show.
BUT, we found a work around... if the position in 2nd ShowAt changes by 1 pixel then the ShowAt would work.
Version Info
19H1, build using WUX RS5 SDK.
will update to MUX soon...

@llongley can you help take a look?

I am afraid, without WinUI 3 there isn't much we can do here. The CommandBarFlyout has the following event cycle with the repro code of this issue (note that opened doesn't even get raised):

Opening
Closing
Reopen
Closed

Even if we process the ShowAt in the CommandBarFlyout, the internal event cycle of Flyout seem to interrupt here and force to close that element. Even if we try to show it again, it still is closed after we called ShowAt for the second time.
Maybe I am missing something here, but I don't think there is something we could do here right now. I've created a branch on my fork with an interaction test for this issue here if someone wants to work on this.


The word "started" should be "starting", if it's in yellow, and process hasn't full started

Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information. If you repeatedly fail to use the issue template, we will block you from ever submitting issues to Homebrew again.
Please always follow these steps:

[ ] Confirmed this is a problem with running a brew command and not brew installing or the post-install behaviour of one or more formulae? If it's a formulae-specific problem please file this issue at the relevant tap e.g. for Homebrew/homebrew-core https://github.com/Homebrew/homebrew-core/issues/new
[x] Ran brew update and retried your prior step?
[x] Ran brew doctor, fixed all issues and retried your prior step?
[x] Ran brew config and brew doctor and included their output with your issue?

To help us debug your issue please explain:

What you were trying to do (and why)
What happened (include command output)
What you expected to happen
Step-by-step reproduction instructions (by running brew commands)

Features
Please replace this section with:
See this StackOverflow issue:
https://stackoverflow.com/questions/46437670/brew-services-not-completely-started-mongodb/46437716#46437716
thanks
We will close this issue or ask you to create a pull-request if it's something we're not actively planning to work on.

Can you please update the issue with the details of what you actually want (following the template) rather than just linking us to an StackOverflwo, thanks?

sure, regarding this image:

"started" in yellow should say "starting" instead. It makes more sense. Because if the process crashed, then it's not started.

That's because it's not starting or crashed: we don't have the status on whether it is running or not. In future: please provide significant more details in your issues.

mmm, @MikeMcQuaid  let me help you more.
so in this case it was a mongo process, and it definitely crashed..it tried to start and failed. the started in yellow was there for more than 20 minutes, etc. So brew should know that the process did not start successfully.

I mean, wouldn't you say that Brew was lying to me when it said "started" in yellow, when the process crashed? that's the point.

So brew should know that the process did not start successfully.

Sorry, we don't as this is a thin wrapper around launchctl which doesn't provide this information. Also, please file future issues to the Homebrew/homebrew-services repository and provide significantly more information.

it was neither started

It was started and then it crashed.


Updating stars

Many components have not been updated for a long time - the github star count is obsolete.

#24


python client library link needs update

[Enter feedback here]
I think "storage client library for python" should probably link to here:
https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/storage/azure-storage-blob
The current link takes us to a very out of date repo, and the notice at the top of it is not so very clear to find the above page.

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

ID: 2550031e-4cf6-8d15-84e3-1c2b58951f80
Version Independent ID: 1a927119-0540-dfd9-9435-5c29c014daff
Content: Introduction to Azure Storage - Cloud storage on Azure
Content Source: articles/storage/common/storage-introduction.md
Service: storage
Sub-service: common
GitHub Login: @tamram
Microsoft Alias: tamram

@lindacmsheard
Our SME will review this issue and get back soon.

@lindacmsheard The PR request has been initiated, We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


[WIP] Patch2Self Denoiser

Adds Patch2Self
Hi Everyone,
This PR adds the basic version of our method: Patch2Self: Denoising Diffusion MRI with Self-supervised Learning
The paper was published in NeurIPS 2020. Link: Paper

[x] Make Interface via DIPY (added to dipy.py)
[x] Add to workflows
[x] Add tests

@mattcieslak Does this look okay? Let me know if I missed something!
Where would this workflow ideally go?

Thanks for getting this started! Which version of dipy has the current stable implementation of Patch2Self?

Thanks for getting this started! Which version of dipy has the current stable implementation of Patch2Self?

1.4.0+ will have Patch2Self  👍🏽

Is that version available on pypi?

Not yet. @skoudoro : when is DIPY 1.4.0 scheduled for release?
A potential stop-gap would be to release the prototype (
https://github.com/ShreyasFadnavis/patch2self) to pypi and then replace
that when DIPY 1.4.0 is released.
On Wed, Dec 16, 2020 at 9:29 AM Matt Cieslak<EMAIL_ADDRESS>wrote:

Is that version available on pypi?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PennBBL/qsiprep/pull/203#issuecomment-746683910, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA46NQLF3YMBUBSJPQJKRDSVDU53ANCNFSM4U5ROSRQ
.

If patch2self can work as a standalone package that would make it much easier to get into qsiprep. There is a delicate and old combination of vtk and fury that works to make the odf images in the html reports. If patch2self doesn't depend on dipy it would be awesome to be able to install it by itself

Not yet. @skoudoro : when is DIPY 1.4.0 scheduled for release?

DIPY 1.4.0 Release expected December 28th if no surprise.
For your information, all DIPY workflow/command-line are available in Nipype. No need to do them again. When you import Nipype, it checked your DIPY version and the available workflows, and then convert DIPY workflow to the Nipype interface. You can look at the code here at dipy_to_nipype function  and here for the import
So in this case.
from nipype.interfaces.dipy.preprocess import Patch2Self
for a reconstruction method (syntax to check):
from nipype.interfaces.dipy.reconstruction import ReconstDti,  ReconstMAPMRI, ReconstCSD, ReconstCSA, etc...
for tractography
from nipype.interfaces.dipy.tracking import PFTrackingPAM, etc...
I know, it is not well documented, but feel free to try them. I hope it helps.

If patch2self can work as a standalone package that would make it much easier to get into qsiprep. There is a delicate and old combination of vtk and fury that works to make the odf images in the html reports. If patch2self doesn't depend on dipy it would be awesome to be able to install it by itself

I can make this happen too (quite simple actually)! I can make a package on my repo and then we can see how the DIPY version can be integrated 👍🏽

Hi @mattcieslak ! After brainstorming with @Garyfallidis we came to a workaround where Patch2Self can be just added to the codebase of QSIPrep until the newer version of DIPY is supported. The code is very modular, i.e. just 1 file, without any dependencies on other DIPY modules. Does that sound like a reasonable stopgap?

That sounds great! You can add it in where you're already working and I will add in the commandline options to use it. Thanks!

That sounds great! You can add it in where you're already working and I will add in the commandline options to use it. Thanks!

Should I create a new file named patch2self.py or do you want me to add the code to dipy.py within interfaces?

How about putting the patch2self code in qsiprep.interfaces.patch2self and having the qsiprep.interfaces.dipy.Patch2Self class call it? Than when the algorithm gets into Dipy or its own package we can just switch the import

How about putting the patch2self code in qsiprep.interfaces.patch2self and having the qsiprep.interfaces.dipy.Patch2Self class call it? Than when the algorithm gets into Dipy or its own package we can just switch the import

On it! Thanks @mattcieslak 👍🏼

@ShreyasFadnavis What is the preferred way to calculate a 3D summary of the amplitude of the noise? dwidenoise has a --noise-image option, which I believe is just the RMS of the noise over all the volumes

@ShreyasFadnavis What is the preferred way to calculate a 3D summary of the amplitude of the noise? dwidenoise has a --noise-image option, which I believe is just the RMS of the noise over all the volumes

@mattcieslak : Yes! We also follow a similar strategy. I generally compute an RMS error (residuals) per gradient direction.
rms_diff = np.sqrt((noisy_img - denoised_img) ** 2)
So we can return a 4D noise image instead!

@ShreyasFadnavis What is the preferred way to calculate a 3D summary of the amplitude of the noise? dwidenoise has a --noise-image option, which I believe is just the RMS of the noise over all the volumes

@mattcieslak : Yes! We also follow a similar strategy. I generally compute an RMS error (residuals) per gradient direction.
rms_diff = np.sqrt((noisy_img - denoised_img) ** 2)
So we can return a 4D noise image instead!

@mattcieslak : I added this functionality from within Patch2Self. Let me know if this is not suitable, I can always revert changes!

@mattcieslak Do you have an example dataset I can test this on? How do you generally go about doing sanity checks?

@ShreyasFadnavis I'm testing this locally tonight and should have a working version soon

@ShreyasFadnavis I'm testing this locally tonight and should have a working version soon

Hey, let me know if you face any issues 👍🏽 It could have happened that I broke something when porting! I can fix it ASAP :)

Looks like it's working! Here is the report from using patch2self and here is the same data using mp-pca.
I still need to fix the boilerplate to cite you correctly, but was also wondering what you would recommend as defaults for the parameters. For dwidenoise I have the default window size set to (5, 5, 5).

Looks like it's working! Here is the report from using patch2self and here is the same data using mp-pca.
I still need to fix the boilerplate to cite you correctly, but was also wondering what you would recommend as defaults for the parameters. For dwidenoise I have the default window size set to (5, 5, 5).

Hi @mattcieslak ! Thank you for this 👍🏽 For patch2self the default patch_radius should be [0, 0, 0]. If the number of gradient directions is less than 20, then increasing the patch_radius to [1, 1, 1] = patch_size of [3, 3, 3] is required (very rare for connectome data -- required for spinal cord or other body parts). This is the best part! We discovered that if the number of gradient directions is more than 50, which is generally the case, spatial approximation does not add any value.
Users don't need to tune any parameter! 💯
Maybe we can document somewhere that: if the number of gradient directions is less, increase the patch radius?
(perhaps raise a warning)

@mattcieslak 1 more thing: patch2self can be applied at any point in the pipeline... So can we try it after motion correction?

That should probably get its own PR, since it would require some larger changes to the overall workflow.

That should probably get its own PR, since it would require some larger changes to the overall workflow.

Sounds good! Will follow up with a separate PR for that!

Hi @mattcieslak, is this good to go? Do you need something else on my end?

Hi @mattcieslak, is this good to go? Do you need something else on my end?


Last week for monthlydowtrigger

I'm having an issue creating a task for last week of the selected months.
I searched the discussions and found a thread back in 2009 with a similar issue, except it dealt with FifthWeek.
new MonthlyDOWTrigger is expecting 3 parameters.
If I pass WhichWeek.LastWeek - I get an exception saying only one single week is allowed.
If I pass some other week and then set RunOnLastWeekOfMonth = true - the task gets created for the last week and other week that has been passed when object was initialized.
Basically it's not allowing me to set last week only.
Please help.
Originally posted: 2010-10-26T12:54:44

Thanks for finding this bug. I have corrected it in source code change set 58843 and have updated the assembly available in the download forRelease 1.5 Beta 3.
Originally posted: 2010-10-26T14:12:10

Thanks dahall,
Just to clarify, if I want to create a task that will run only on last week, do I pass WhichWeek.LastWeek to the MonthlyDOWTrigger?
Or do I pass null or something else for WhichWeek and set RunOnLastWeekOfMonth = true?
Thanks again!
Originally posted: 2010-10-27T07:13:57

Well, I tried to just use WhichWeek.LastWeek when I initialize the trigger object and it worked, so I'm just going to omit using RunOnLastWeekOfMonth parameter.
Thanks for taking care of a new compile this quick dahall!
Originally posted: 2010-10-27T12:05:47


isort ordering of imports not being enforced.

I'm experimenting replacing isort with ruff but it doesn't seem to be enforcing the order of imports even if I explicitly set order-by-type = true.
Here's what is in pyproject.toml:
[tool.ruff]
line-length = 100
target-version = "py39"
src = [
    "src",
    "test"
]

[tool.ruff.isort]
known-first-party = [ "my-package" ]
order-by-type = true
force-sort-within-sections = true

Here's the test Python file my-package/__init__.py:
from .shared import IMPORT_ME  # first-party

import json  # standard lib
import requests  # third party

print(requests)
print(json)
print(IMPORT_ME)

isort properly returns an error when it checks this file:
ERROR: /path/to/my-package/__init__.py Imports are incorrectly sorted and/or formatted

Ruff is at version 0.0.252.

Ignore that I opened this...

All good! Is it just that you needed to enable the I rules?

I had it in the wrong place in the pyproject file 🤦♂ Saw it after I hit save on the issue.

Happens to the best of us :D


Feature Request: Support for downloading videos in multiple threads.

Checklist

[X] I'm reporting a feature request
[X] I've looked through the README
[X] I've verified that I'm running yt-dlp version 2022.02.04. (update instructions)
[X] I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue

Description

The download of some niche websites or large websites is between 400KB/S.
I hope to use multi-threading to download him. This is very important.
I hope you can play it while downloading, use the default player or choose the player.

Duplicate of #1918


Minor tidy-up of Investment bits

Remove project_section_complete (no longer relevant)
Add additional metadata models to admin pages
Update some model verbose names

Codecov Report

Merging #204 into develop will decrease coverage by <.01%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #204      +/-   ##
===========================================
- Coverage    91.62%   91.62%   -0.01%
===========================================
  Files           47       47
  Lines         1672     1671       -1
  Branches       146      146
===========================================
- Hits          1532     1531       -1
  Misses         119      119
  Partials        21       21

Impacted Files
Coverage Δ

datahub/metadata/admin.py
100% <ø> (ø)
:arrow_up:

datahub/investment/serializers.py
100% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2bcc446...7cd9983. Read the comment docs.


chore: move customProptypes to a separate package

Addresses #433.

moves customPropTypes to a separate package
adds docs about managing packages and dependencies
adds syncpack to align package.json files and our dependencies across packages

Warnings

:warning:
There are no updates provided to CHANGELOG. Ensure there are no publicly visible changes introduced by this PR.

  Generated by :no_entry_sign: dangerJS

Marking as blocked as we decided to include these changes to a release after the next.