Makefile: Add make clean cmd

Cleans up celestia bin from build/ dir.
Based on #575.

What do you mean @adlerjohn? You can only run the make commands from the same directory as the Makefile

https://linux.die.net/man/1/make

+-f file, --file=file, --makefile=FILE
Use file as a makefile.

https://linux.die.net/man/1/make

+-f file, --file=file, --makefile=FILE
Use file as a makefile.

wdym @adlerjohn ?

using the makefile 's flag -f --file is just to specify which file you want to use as a makefile. Such as make -f /swamp/ogre/shrek and the shrek is the name of the makefile
using the -C flag to only point to a directory where the makefile is used (considering that the name of the makefile is Makefile)

I don't think we are going to move the existing makefile somewhere else from the repo's root. In addition that I highly doubt that any future inner makefiles will make their own make clean cmd(still a .phony will be a nice touch, which will be added)

We may not move the makefile, but it's possible the makefile is called from a different directory. I remember I had to do that a lot with C++ because C++.


Make a Name logo of the site

Current Behavior
currently there is no logo, whereas logo enhances the look of the website.
Desired Behavior
I wish to contribute in making the logo of the site.
Screenshots / Mockups
Here are some examples-

@thekavikumar Why did you close this issue? I've made the logo-

but didn't fix it in the code yet

I see you have uploaded the logo in a changed font, but please give me this chance, I have done a lot of work to come up with the design, and I can redesign if you don't like this.

This won't be fitting for the navbar, find a logo with icon and name in a row.
See the logo that I have on my website in simple and neat. Like that something you can come up

@thekavikumar Sure I understand, I will make the logo as you suggested.

@thekavikumar I have made a pull request for this task, please verify.


[Testing] Add story pages for the source data screen for each interface

@garrettmflynn To more easily catch events like the one detected in #247 I think it would be useful to have chromatic stories for the source data screen for each interface in order to track and detect unintended changes to global components
This might increase our snapshot usage, but TBH chromatic is proving invaluable for this kind of stuff so I'd say it's worth it if we have to pay for a few months during active development

To do this, we'll need an active instance of the NWB GUIDE backend running somewhere (e.g. the cloud) so we can get the proper schema. That or a simple way to request the schema using Pyodide or some other Python + browser solution.
Would you want to do this or would these considerations preclude such use of Chromatic?

What about vitetest? Is there an easy way to add something analogous for that?

We still need access to the outputs of Python functions. We could spin up the server and make API calls to the local instance if we're using vitest. Though actually confirming that we get what we expect requires exhaustive, hardcoded objects to match—and if we're setting a heuristic rule (e.g. only x,y, and z metadata property), it'll be pretty simple to modify the script to have the rule hold.
We just haven't explicitly noted the rule to follow here across different interfaces. Previously, we just were showing required properties—but then sometimes we needed non-required properties to get an interface to pass.
The inclusion of load_sync_channel is quite predictable given that the onlyRequired property has been unset and we are now working an explicit list of properties to ignore on this form.
Can you think of other interface metadata properties that we'd want to hide off the top of your head?

Can you think of other interface metadata properties that we'd want to hide off the top of your head?

They will only be discovered as I try things out; I no longer recall off the top of my head how each was designed lol
What if we stored a bunch of pre-calculated and cached (in CI or perhaps Git if not that heavy) all the source schemas for each interface corresponding to the currently used version of NeuroConv? Could you harness those in any way for a story to 'accept' the schema as if the back end had calculated it on the fly?

That would work. Would be simple enough to generate them.
I’m essentially already doing that for the current demo data—but it’s
hardcoded rather than generated.
On Tue, Aug 8, 2023 at 1:12 PM, Cody Baker @.***> wrote:

Can you think of other interface metadata properties that we'd want to
hide off the top of your head?
They will only be discovered as I try things out; I no longer recall off
the top of my head how each was designed lol
What if we stored a bunch of pre-calculated and cached (in CI or perhaps
Git if not that heavy) all the source schemas for each interface
corresponding to the currently used version of NeuroConv? Could you harness
those in any way for a story to 'accept' the schema as if the back end had
calculated it on the fly?
—
Reply to this email directly, view it on GitHub
https://github.com/NeurodataWithoutBorders/nwb-guide/issues/274#issuecomment-1670244055,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALDAY5OG46AI3RWLF56QNATXUKMSFANCNFSM6AAAAAA3IZB2KA
.
You are receiving this because you were mentioned.Message ID:
@.***>

OK then, let's tackle this in our meeting tomorrow. There are a couple ways of going about it depending on how the chromatic generation works


hash_to_curve uses rejection sampling for EdwardsPoint

Hi, I'm new to this project so I'm not sure whether you use this function but it looks like the current implementation of hash_to_curve for EdwardsPoint uses rejection sampling, which is sensitive to timing attacks and strongly advocated against in https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/

Agreed -- ccing @huitseeker, the problem is that we currently do not have an Elligator-2 implementation in Rust. Hopefully we can fix this soon!

Fixed in #46


Feature for PowerToys Run

Description of the new feature / enhancement
The ability to search for windows settings (like Bluetooth Devices) in the PowerToys Run bar
Scenario when this would be used?
I like using the this feature but, I often try to search for certain windows settings and I can’t do that here so, I have to use the windows search bar.
Supporting information
No response

We do already have this feature in PowerToys run. Is there any setting you can't find? /needinfo
cc: @htcfreek

You can search for them by using $ as keyword.

Thanks. I did not know that the $ would search for settings.

we have such key chars for multiple plugins. You can look for it at the settings.


Update link to doc on transactional licence page

Changes in this PR:
Update link to doc on transactional licence page
Trello card / Rollbar error (etc)
https://trello.com/c/AVHWYqMm/1547-update-computational-analysis-word-document-form-on-the-transactional-licence-page
Screenshots of UI changes:
Before

After

[ ] Requires env variable(s) to be updated

 Update computational analysis word document form on the transactional licence page


namespacing of link rels?

https://github.com/ESA-APEx/apex_algorithms/blob/99a92be5fcd44435e20586379a09c59e45a833a3/algorithm_catalog/worldcereal.json#L85-L90
udp is quite short as rel value, risking collision or confusion. Maybe we should at least namespace it a bit e.g.
"rel": "openeo-udp",

?

related: https://github.com/Open-EO/openeo-api/issues/539


can you explain what dyn is and what values can be?

dyn | How many row you want to utilize when using dylora, if you set to 0, it will disable the dylora
i use lbw
here I understand - the weights of the text, the unet and the weights of all blocks
<lyco:"lora name":1:1:lbw=1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0, 0,0,0,0,0,0,0,0>
But I don't understand what is dyn...
lyco:Model:1:0.5:dyn=13
13? - 20? -1000?
Please help
maybe it's the Network Rank (Dimension) at which the locon was made?

if you are not using dylora model, you can simply ignore dyn.
for dylora, we use larger matrix to train but will only utilize few of them. And the training method can ensure that you don't need to use svd or other deomposition method to "resize".
And the dyn value is to indicate "What size you want", and you can refer it as the "rank" or "dim" for dylora.
It should be 1~n, which n is the original size of dylora.
if you use dyn value for non dylora model like locon or lora. It will break your model. (or, it should)

what parameters for Kohya DyLoRA are you using?
I make lora, lokon, with these settings they work, but dylora does not work...
I do different options, a my-dylora.safetensors file is created, but it does not affect the image in any way.
I see the output in the console but dilora does not change the output:
lyco:000test:4:1:1
Apply LyCORIS model: 000test
Text encoder weight: 1.0
Unet weight: 1.0
DyLoRA Dim: 4
I used different parameters, optimizers
like this
network_dim=32
network_alpha=16
conv_dim=32
conv_alpha=16
unit=8
Can you tell me if I missed something?
I:\KOHYA_GUI\kohya_ss>git rev-parse HEAD
30b054b29b4611e19d0c13a63fff402ed0bef4cc

If your dylora is from kohya's sd-script but not LyCORIS.
I think you should use additional-network.

I don't think my extension will support kohya dylora
It may need some convertion

@vladmandic as info/reminder for you if such errors should come up, so you dont have to spend time on troubleshooting.

@TheOnlyHolyMoly thanks for the heads up


⚠ Bofrost.lu has degraded performance

In 124cddb, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1089 ms

Resolved: Bofrost.lu performance has improved in e04c488.


Undefined function or variable 'read_img_rgb'

I made ucm.mat file using matlab and also ran the predict_depth.m, but it throws this error and in the code I do not know whether read_img_rgb is a user defined function or not but if not then the chunk of read_img_rgb in not described. I installed matlab with R2017a to run this script

Hi,
Can you specify the file you run when this error occurred ?

The file was predict_depth.m, but i solved the error as read_img_rgb is a function which defined in different git folder, so I linked up the function with predict_depth.m file & error solved.

Yes, good, this was the solution because i encountered the same error too.
Good luck.
On Tue, Jul 18, 2017 at 4:49 PM, gauravpar<EMAIL_ADDRESS>wrote:

Closed #61 https://github.com/ankush-me/SynthText/issues/61.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ankush-me/SynthText/issues/61#event-1168613683, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AacoyU0ZwajwWjtl9bgketeoY8cEtdvLks5sPNNWgaJpZM4ObGIS
.


bug: aws-s3-enable-versioning rule needs update

Describe the bug
In the latest AWS terraform provider the versioning parameter of aws_s3_bucket is depreciated and replaced with a separate object.
Looking at https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket we see:
S3 Bucket versioning can be configured in either the standalone resource [aws_s3_bucket_versioning](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket_versioning) or with the deprecated parameter versioning in the resource aws_s3_bucket. Configuring with both will cause inconsistencies and may overwrite configuration.

Looking at https://aquasecurity.github.io/tfsec/v1.28.0/checks/aws/s3/enable-versioning/ we see that tfsec is not aware of this object so gives a false error when versioning is enabled via the peferred method.
Same is true for aws-s3-enable-bucket-logging, aws-s3-enable-bucket-encryption

Hi @zfLQ2qx2
I was trying to reproduce this issue. Even I had this issue some time back and seems like the issue has been resolved now in the latest version. Could you please update to the latest version and try to reproduce this issue?

I still get this issue. My module uses the aws_s3_bucket_versioning resource instad of the s3 bucket parameter that is deprecated. TFSEC not detecting this.
TFSEC version v1.28.1
AWS Plugin version v.0.18.0

I'm encountering this as well for enable-bucket-encryption with tfsec v1.28.1.

also encountering it here with v1.28.1

Hi @zfLQ2qx2 !
Now Trivy supports the above resources.
/cc @simar7


add why command

honestly these are coins on dependencies, so maybe they're just options, or tasks in a task? like :foo:dependencies --info ... or :foo:dependencies:info
Why
gradle why <dependency>

given a dependency (directory or transient) gradle would tell you exactly why you have the dependency. Inspired by https://yarnpkg.com/cli/why
So by example
gradle why oorg.apache.logging.log4j:log4j-api

testRuntimeClasspath - Runtime classpath of source set 'test'.
+--- org.springframework.boot:spring-boot-starter-log4j2 -> 2.4.0
|    +--- org.apache.logging.log4j:log4j-slf4j-impl:2.13.3
|    |    +--- org.apache.logging.log4j:log4j-api:2.13.3
|    |    \--- org.apache.logging.log4j:log4j-core:2.13.3
|    |         \--- org.apache.logging.log4j:log4j-api:2.13.3

Info
might return
gradle info org.junit.jupiter:junit-jupiter-engine

testRuntimeClasspath - Runtime classpath of source set 'test'.
+--- org.junit.jupiter:junit-jupiter-engine -> 5.7.0
|    +--- org.junit:junit-bom:5.7.0 (*)
|    +--- org.apiguardian:apiguardian-api:1.1.0
|    +--- org.junit.platform:junit-platform-engine:1.7.0
|    |    +--- org.junit:junit-bom:5.7.0 (*)
|    |    +--- org.apiguardian:apiguardian-api:1.1.0
|    |    +--- org.opentest4j:opentest4j:1.2.0
|    |    \--- org.junit.platform:junit-platform-commons:1.7.0 (*)
|    \--- org.junit.jupiter:junit-jupiter-api:5.7.0 (*)

What would this do that dependencyInsight does not do already?

yeah, I didn't know that existed, sorry.


LSP attaches to all buffers.

Currently the LSP client appears to attach to all buffers, including ones like Packer, nofile, etc.
It would be nice to have it take a table of ignored file and buffer types.

Currently the LSP client appears to attach to all buffers, including ones like Packer, nofile, etc.
It would be nice to have it take a table of ignored file and buffer types.

I realized this the other day and was thinking about how to best go about it. I would rather not use a hard coded blacklist, but if I can't find some bufvar they have in common, I will.
I may move this functionality to the user config, so that they can write exceptions for whatever plugins the use, and put packer, nofile, etc as defaults.

Ok so I took a bit to look into this and there are a few things:
First, copilot is in an interesting position as it has no dedicated filetype. I was thinking about making a whitelist since that's what other lsp do, but I think a blacklist makes much more sense.
That said, there's some strange behavior with filetype detection for some filetype i experimented with as an upstream issue.
I managed to fix it and get a functional blacklist going, but to make sure it doesn't break with 0.6 I had to do some messy stuff. Since 0.7 releases in 3 days I really, really don't want to add more junk to work around 0.6's limitations.
I'll consider adding this for 0.7 immediately if the way I implement it for just 0.7 doesn't affect current 0.6 behavior, but not if it breaks current 0.6 behavior.

Got it. I'm using nightly anyways.
I think this is similar, as fidget.nvim which has an ignore list: https://github.com/j-hui/fidget.nvim/blob/main/lua/fidget.lua#L334

The primary issue is that plugins have a tendency to set its their own filetypes. For example, :LspInfo window is lspconfig, packer window is packer, with a blacklist, people will be stuck adding to it constantly. With a whitelist, the number of programming languages people feasibly use is set. Even if it's not, the number that copilot has been trained on certainly is.
It's a bit difficult to decide tbh. I'll push an update in a minute with a blacklist, but I may swap it to a whitelist at some point, just a heads up.

So all those non 'real' buffers like packer, terminal, lspinfo, etc, have two traits:

They aren't listed
They generally have a special buftype like 'help' 'nowrite' etc

I wrote in a check independent of ft_disable in the parameters, so you should be fine, but if, for instance, you want to disable copilot for C or something, you can do so through ft_disable.
For now I like this method so unless something comes up it should stay this way.


zipkin-ui does not support non-shared spans

Feature Request
With the advent of the X-Ray compatible modes for zipkin/brave comes the fact that X-Ray spans (segments) are not shared by client and server so the UI ends up losing the hierarchy information. It still orders correctly because of timestamps. I would be great to support this model of spans in the native zipkin UI

With the advent of the X-Ray compatible modes for zipkin/brave comes the
fact that X-Ray spans (segments) are not shared by client and server so the
UI ends up losing the hierarchy information. It still orders correctly
because of timestamps. I would be great to support this model of spans in
the native zipkin UI

I suspect this is related as well (notably the parent isn't propagated)
https://github.com/openzipkin/zipkin/pull/1745

possibly a dupe of #963?

In the current api, I think maybe cheapest win is fusing single-host spans together. Basically move the server span into its client and adjust ids. However, I think possibly there's something more to ask you about.
You suggest the hierarchy is wrong.. which is a different problem then seeing things in the same detail screen. Can you give an example of this? It would seem a broken hierarchy would also be a problem in X-Ray..

the logic has been completely written and so has the UI, so it might be easier to notice any new problem vs think through what's changed

one note relevant here is that lens allows multiple spans to be expanded which compensates somewhat for usability concerns on client and server spans that don't share an ID. I'm not sure it is worse than other tools like jaeger or stackdriver in this regard or not.


Charge port latch status used to get updated accurately, but not anymore

Version of the custom_component
v3.10.0
Describe the bug
I used the "Charge port latch" for an LED on my custom EV charger, but since a couple of updates of the integration, that value doesn't get updated anymore, or lagging behind by a huge amount.
When I look at the history of the charge_port_latch entity in config/entities, I can see it's just stuck at 'Locked' most of the time.
Looking at charger_door, it's updated correctly.
Any clue what's going on here?

@maximevince please see issue 523, I, along with others, are seeing the same with other statuses.

Possibly related to https://github.com/alandtse/tesla/issues/523


No longer support armv7?

zigbee2mqtt add-on version (if edge, please report commit hash):
1.14.4
Operating environment (HassOS, Virtual Machine, Device/platform running Hass.io):
Home Assistant 0.114.0
Supervisor 242
Docker version 19.03.12, build 48a6621
Raspbian GNU/Linux 10 (buster) armv7l GNU/Linux
Description of problem:
This add-on is not available on your system.
Your entire configuration from the frontend (with sensitive fields redacted):
// replace this line with your pasted configuration

Your logs from Hass.io
20-09-11 02:25:35 INFO (MainThread) [supervisor.store.git] Clone add-on https://github.com/danielwelch/hassio-zigbee2mqtt repository
20-09-11 02:25:39 INFO (MainThread) [supervisor.store] Load add-ons from store: 80 all - 2 new - 0 remove
20-09-11 02:25:46 ERROR (MainThread) [supervisor.addons] Add-on 7ad98f9c_zigbee2mqtt not supported on that platform
20-09-11 02:25:52 INFO (MainThread) [supervisor.store.git] Update add-on https://github.com/Poeschl/Hassio-Addons repository
20-09-11 02:25:52 INFO (MainThread) [supervisor.store.git] Update add-on https://github.com/danielwelch/hassio-zigbee2mqtt repository

Was this working in the past?

Yes. Installed and used it flawlessly until a week ago. It just disappeared from add-on store (reposity is already added).
But I can find and install it on same Pi, same Raspbian, same Home Assistant with 64bit kernel (so aarch64).

The image seems to be there: https://hub.docker.com/r/dwelch2101/zigbee2mqtt-aarch64. Maybe some local caching. Try removing and adding the repository itself.

This might be the same as #366 so I linked it there. If you are no longer experiencing the issue it's probably related.

Thanks but no image for armv7. Is it removed or never been there? But we all used it on Raspbian before.

Maybe it was using armhf before and something changed in HA that no longer knows to use armhf image?
According to https://superuser.com/questions/1009540/difference-between-arm64-armel-and-armhf armhf should work.
Maybe you have a problem closer to: https://community.home-assistant.io/t/installing-hassio-with-docker/101118

See this relevant PR here: https://github.com/danielwelch/hassio-zigbee2mqtt/pull/124
My understanding has been since then that armv7 would "fall back" to armhf if not specified as a supported architecture, and that seems to have been working for quite some time. Will have to check if something changed within HA.

See this relevant PR here: #124
My understanding has been since then that armv7 would "fall back" to armhf if not specified as a supported architecture, and that seems to have been working for quite some time. Will have to check if something changed within HA.
Should be related to some recent Supervisor updates? This is my first though but some other add-ons work well and I do not have much time to investigate. Move zigbee2mqtt to docker container anyway.

This is tentatively fixed by #388. I'll close for now, but please feel free to re-open if there are continued issues with armv7 architecture


fix[core]: async test actually running now

as mentioned here test on async consumer in core was not being awaited and always passed.
Simplified and made sure it does run now.

I haven't the foggiest how me changing a unit test would break the system tests...

I haven't the foggiest how me changing a unit test would break the system tests...

Ah this is the flakiness of the ftps server, which I think @milanmlft is going to work on to use the python server as you suggested


Manually backport release notes to 2.3.

Release notes for 2.3.0
(cherry picked from commit b0c564338323056d33fddf30e70a5b0e59b69c6a)
Description
Backport release notes to 2.3.
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass, including unit test, integration test and doctest

[ ] New functionality has been documented.

[ ] New functionality has javadoc added
[ ] New functionality has user manual doc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #461 (f7ec9f6) into 2.3 (cefc610) will decrease coverage by 2.26%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                2.3     #461      +/-   ##
============================================
- Coverage     74.12%   71.85%   -2.27%
  Complexity      383      383
============================================
  Files            94       64      -30
  Lines          4008     2061    -1947
  Branches        649      229     -420
============================================
- Hits           2971     1481    -1490
+ Misses          903      449     -454
+ Partials        134      131       -3

Flag
Coverage Δ

dashboards-reports
?

reports-scheduler
71.85% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

dashboards-reports/test/propsMock.js

...ublic/components/main/report_definitions_table.tsx

...ublic/components/report_definitions/utils/index.ts

.../components/main/report_details/report_details.tsx

...ic/components/main/loading_modal/loading_modal.tsx

...main/__tests__/__utils__/main_utils_test_utils.tsx

...ashboards-reports/server/utils/validationHelper.ts

...ashboards-reports/server/routes/utils/constants.ts

...orts/server/routes/utils/converters/backendToUi.ts

dashboards-reports/public/components/main/main.tsx

... and 20 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.