Detected that custom integration 'homematicip_local' calls .... will stop working in Home Assistant 2025.12.0

I agree to the following

[X] I have read the documentation right now
[X] I have read the FAQs right now
[X] I am aware of the latest release notes
[X] I am aware that an integration that was installed via HACS also needs to be updated via HACS
[X] The Backend (CCU/Homegear/...) is working as expected, devices are taught in and are controllable by its own UI.
[X] I am running the latest version of the custom_component (and Home Assistant)

The problem
[\e]0;\u@\h:\w\a]\W $ cat home-assistant.log
2024-12-26 20:37:51.726 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-12-26 20:37:51.727 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration dwd which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-12-26 20:37:51.727 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration homematicip_local which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-12-26 20:37:51.728 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration tapo which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-12-26 20:37:52.718 WARNING (Recorder) [homeassistant.components.recorder.util] The system could not validate that the sqlite3 database at //config/home-assistant_v2.db was shutdown cleanly
2024-12-26 20:37:52.763 WARNING (Recorder) [homeassistant.components.recorder.util] Ended unfinished session (id=28 from 2024-12-25 10:04:47.161730)
2024-12-26 20:37:58.343 WARNING (MainThread) [homeassistant.components.netatmo] API error: 500 (Internal Server Error)
2024-12-26 20:38:08.382 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'homematicip_local' calls device_registry.async_get_or_create referencing a non existing via_device RaspberryMatic, with device info: {'identifiers': {('homematicip_local', 'HmIP-RCV-1@RaspberryMatic-HmIP-RF')}, 'manufacturer': <Manufacturer.EQ3: 'eQ-3'>, 'model': 'HmIP-RCV-50', 'name': 'Virtuelle_FernBedienung', 'sw_version': '1.0.0', 'via_device': 'RaspberryMatic'} at custom_components/homematicip_local/control_unit.py, line 295: device_registry.async_get_or_create(. This will stop working in Home Assistant 2025.12.0, please create a bug report at https://github.com/sukramj/hahomematic/issues
What version of HomematicIP (local) has the issue?
2.0.1
What was the last working version of HomematicIP (local)?
???
What type of installation are you running?
Home Assistant OS
What type of installation are you running for your homematic backend?
CCU2
Which version of your homematic backend are you running?
No response
What hardware are you running for your system?
Raspberr< Pi 5
Which config details do you use

[ ] TLS
[ ] callback data (see)

Which interfaces do you use?

[X] Homematic IP
[ ] Homematic (Bidcos-RF)
[ ] Groups (Heating-Group)
[ ] BidCos-Wired (HM-Wired)

Diagnostics information (no logs here)
No response
Log file extract. Anything in the logs that might be useful for us? The log (Setting/System/Logs -> load full log) is the best source to support trouble shooting!
No response
Additional information
No response

Thanks fixes with #782


bug: plugin updates do not update existing tags

Did you check docs and existing issues?

[X] I have read all the lazy docs
[X] I have searched the existing issues of lazy
[X] I have searched the exsiting issues of the plugin I have a problem with

Neovim version (nvim -v)
NVIM v0.8.1
Operating system/version
MacOS 12.8
Describe the bug
I am using { 'folke/lazy.nvim', tag = 'stable' } as a temporary workaround for https://github.com/folke/lazy.nvim/issues/260. This morning when I did :Lazy update, it did not update to the latest stable version v7.7.0 (cba99de). Doing a git log in ~/.local/share/nvim/lazy/lazy.nvim, I observed that while the latest cba99de commit is present in the tree, the stable tag had not been updated. I suspect the cause is related to the following:
$ git fetch --all --tags
From https://github.com/folke/lazy.nvim
 ! [rejected]        stable     -> stable  (would clobber existing tag)

Steps To Reproduce
require("lazy").setup({
  { 'folke/lazy.nvim', tag = 'stable' },
})

Expected Behavior
I would expect setting tag = stable in the config would result in the tag being updated when it changes in the plugin repo, and hence the plugin updating to what is now stable.
Repro
No response

Use version=* instead

I am now. Does this behaviour need to be fixed?

The problem is that the stable tag for lazy gets updated after every release.
Lazy would not do an update when tag=stable, since the local repo would already be on stable.

Will fix it so it also works in that case


Mention GitHub Actions on README

might be worth show it in context with a fuller yml examle?

done :)
Merge on green


Remove color from headings?

Foundation sets the color property on all heading tags to #222 (or the specified value of Body Font Color in custom builds).
Should this declaration exist?
Let's say we have a slider at the top of a page. Inside it sits both a h1 and a p tag.

This is a heading

This is a paragraph

The slider has a blue background, so we want all text inside it to be white.
.slider {
	background: blue;
	color: white;
}

Our color declaration doesn't cascade through to all children. It works on paragraphs, but not headings as their color property is set by Foundation. Instead, we must be more explicit.
.slider {
	background: blue;
	color: #fff;
}

.slider h1 { color: white; }

It's only a small issue, but one that has bugged me for years.
What are people's thoughts?

I definitely come across this a lot when I use Foundation, so we can look into it.

We'll be doing this for Foundation 6, but it seems like changing this for 5 will be a breaking change for some people, so I'll close this. We agree with the idea though!


First draft of units tutorial

Closes #421
I will probably continue to revise this before and after the tutorial on 2023-10-03.

@cmungall sent me this link, that I don't remember seeing before https://linkml.io/linkml/howtos/model-measurements.html. My first thoughts are that (1) this tutorial feels like an introduction to the issues discussed there, (2) I won't have time to dive into LinkML. So my plan is to add a "next steps" conclusion that links to that LinkML page.


Cleanliness of presentation and additional resources

After you merged my last pull request I noticed a few mistakes, and I didn't like that I used some formatting that wasn't the same as the rest.
This time I went through and cleaned up anything I thought could use it, added resources for hyperledger foundation and evernym\sovrin\indy, and made the formatting more uniform across the entire document.
I just like for things to be neat and thorough, especially since I contributed to the mess, I felt compelled to do something.

Great, thanks for more amazing work to improve this!


Windows: don't install java sources, html_developer

Fixes #722
Brief summary of changes

On Windows, do not put Java source code or html_developer files in the installation.
Renamed CodeExamples to Code in anticipation of https://github.com/opensim-org/opensim-core/pull/2175.

Testing I've completed

I did not test this at all! @aymanhab would you be willing to test this?

LGTM, please let me know when ready so I can test @chrisdembia

This is ready to test. Looking at the AppVeyor logs, it is likely that this PR is working as intended. The following line from a previous build:
[copy] Copying 6976 files to C:\projects\opensim-gui\Gui\opensim\dist\installer\opensim\sdk

is now:
[copy] Copying 3471 files to C:\projects\opensim-gui\Gui\opensim\dist\installer\opensim\sdk

in theAppVeyor build for this PR.
We might wait to merge this until https://github.com/opensim-org/opensim-core/pull/2175 is merged.

Thanks @chrisdembia I'll test after opensim-core PR is merged.

@chrisdembia To force installation of resources using the new layout you can either manually installResources() or if you wanted this detected/automated (on windows), change BuildDate in
opensim-gui\Gui\opensim\utils\src\org\opensim\utils\Bundle.properties

@aymanhab I'm not sure what you're suggesting. I did not think about that BuildDate property but I do think it would be good for that property to be updated in this PR. I'll go ahead and do that.

I've updated BuildDate.

I'm testing this locally now.

Okay I've finished testing: the distribution no longer contains java source files or html_developer, and the resource folders are renamed as expected.

Thanks @chrisdembia Merging. I was thinking of changing BuildDate to ResourcesVersion since it's only used for that purpose at the moment. May do that as an effort to rename/group Preferences ina logical manner in a future PR.

I like that name more. However it would still be great to find a netbeans mechanism for detecting first launch. We could simply check for the presence of a file in the userdir.


Tests for Date & Calendar converter

Some test for the 2 converter types

This change is

Coverage decreased (-0.02%) to 66.505% when pulling 09704d93daa8a191da0bae3ab991e157b946109d on converter-tests into 9d4cc90f063c53fae15b9e301f5309f527faefcd on master.

Coverage remained the same at 66.523% when pulling b4101cf492a9597d4d833d876a2fa8bb197e1ddf on converter-tests into 9d4cc90f063c53fae15b9e301f5309f527faefcd on master.

Coverage remained the same at 66.523% when pulling b4101cf492a9597d4d833d876a2fa8bb197e1ddf on converter-tests into 9d4cc90f063c53fae15b9e301f5309f527faefcd on master.


Remove the extra close bucket

Description
There is an extra close bucket.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/5223/
Test PASSed.

alluxio-bot, merge this please


Set the test host for RealmSwift iOS tests so that they can run on-device

Running the swift tests on-device (and thus the perf test CI job) was broken by #2008.

TEST_HOST should already be set for iOS device builds in RealmSwift/Configuration/Tests.xcconfig. Is the value wrong (your patch includes Contents/MacOS in the path, which AFAIK isn't necessary for iOS apps), or is it not taking effect for some reason?

The executable actually is ending up at TestHost.app/Contents/MacOS/TestHost when built for iOS, so that's probably the root cause of the problem. I have no idea what needs to change to fix that, though.

I opened PR #2074 with a similar fix that also avoids breaking the Mac tests.


Question

The parent process then sends a user-supplied string to the child process. The string is displayed to the console in the child process.

When creating these two projects server and client I only have to start the server project as its exe calls the client process (client.exe).
The client process is the child process in my case, but this console app is not visible during execution, therefore the above sentence makes no sense here:

The string is displayed to the console in the child process.

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

ID: 5c8d1d0b-4416-60f7-d609-a0c2edf0756a
Version Independent ID: d473211b-eeda-a0f6-1979-e8b12d3251ed
Content: How to: Use Anonymous Pipes for Local Interprocess Communication
Content Source: docs/standard/io/how-to-use-anonymous-pipes-for-local-interprocess-communication.md
Product: dotnet
Technology: dotnet-standard
GitHub Login: @mairaw
Microsoft Alias: mairaw

@Legends The child process does not get a separate console, it uses the console of the parent process.  I just now ran the example to verify that it does work as described. I'm closing this issue now, but feel free to reopen if you have additional questions.


Remove circular package dep

OpenAI LLM depends on OpenAI Agent which depends on OpenAI LLM which.... yea
While this doesn't break pip per say, other systems in the python ecosystem may not like this
Instead, factored out the common code into a new openai utils package

Can't we just move resolve_tool_choice into the LLM package and remove its dependency from the Agent package?

ah ya, that makes more sense

(box tests failing are ok, they are aware)


Java 11: Encoder kills application

Sadly, I do not have the time to investigate this further ;(
I have a spring boot 2 project were we log to sysout in json to be collected with fluentd.
java
openjdk11
Dependency
  <dependency>
      <groupId>net.logstash.logback</groupId>
      <artifactId>logstash-logback-encoder</artifactId>
      <version>6.1</version>
  </dependency>

Config
  <?xml version="1.0" encoding="UTF-8"?>
  <configuration debug="true">
    <include resource="org/springframework/boot/logging/logback/default.xml"/>

    <appender name="JSON" class="ch.qos.logback.core.ConsoleAppender">
      <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
        <providers>
          <timestamp timeZone="UTC"/>
          <tags/>
          <mdc/>
          <logLevel/>
          <logLevelValue/>
          <threadName/>
          <message/>
          <stackTrace>...</stackTrace>
        </providers>
      </encoder>
    </appender>

    <root level="INFO">
      <appender-ref ref="JSON"/>
    </root>
  </configuration>

The application would terminated immediately after start without any log or error written.
      17:17:48,542 |-WARN in Logger[org.hibernate.validator.messageinterpolation.ResourceBundleMessageInterpolator] - No appenders present in context [default] for logger [org.hibernate.validator.messageinterpolation.ResourceBundleMessageInterpolator].
      17:17:48,574 |-WARN in ch.qos.logback.core.joran.action.IncludeAction - Could not find resource corresponding to [org/springframework/boot/logging/logback/default.xml]
      17:17:48,574 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
      17:17:48,574 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [JSON]
      17:17:48,582 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [net.logstash.logback.composite.loggingevent.LoggingEventJsonProviders] for [providers] property
      17:17:48,596 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [net.logstash.logback.composite.loggingevent.LoggingEventFormattedTimestampJsonProvider] for [timestamp] property
      17:17:48,597 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [net.logstash.logback.composite.loggingevent.TagsJsonProvider] for [tags] property
      17:17:48,597 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [net.logstash.logback.composite.loggingevent.MdcJsonProvider] for [mdc] property
      17:17:48,598 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [net.logstash.logback.composite.loggingevent.LogLevelJsonProvider] for [logLevel] property
      17:17:48,599 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [net.logstash.logback.composite.loggingevent.LogLevelValueJsonProvider] for [logLevelValue] property
      17:17:48,599 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [net.logstash.logback.composite.loggingevent.ThreadNameJsonProvider] for [threadName] property
      17:17:48,600 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [net.logstash.logback.composite.loggingevent.MessageJsonProvider] for [message] property
      17:17:48,602 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [net.logstash.logback.composite.loggingevent.StackTraceJsonProvider] for [stackTrace] property

I figured out that by adding this dependency, the logs get written correctly:
    <dependency>
        <groupId>javax.xml.bind</groupId>
        <artifactId>jaxb-api</artifactId>
        <version>2.2.11</version>
    </dependency>

Impact
If you are using a regular configured spring boot 2 application with spring-boot-starter-data-rest this dependency  (jaxb-api & Co)  seems to be added by a sub-sub-sub dependency so there is nothing that needs to be done.

What specifically indicates this is a problem in logstash-logback-encoder?
Does the application work if you use a standard logback pattern layout in the ConsoleAppender?


[REQ] Additional Audio option

Hi,
Would it be possible to implement the following:

Seperate the audio-bitrate setting for iOS and normal audio
Implement 'profile'  for audio (or just iOS audio)? This allows you to set -profile:a:0 he_aac  / he_aac_v2
Audio -cutoff 180000 or configurable setting?

The postopts/preopts don't really allow me to specify the audio stream so can't pass those reliable

If i were to make a pull request, can you integrate it?

cutoff will go into postopts & for profile I will submit a pull request soon.


refactor: Moved function from watcher before the for loop (#416)

Description
This should fix SonarCloud issue:
Defining a function inside of a loop can yield unexpected results. Such a function keeps references to the variables which are  defined in outer scopes. All function instances created inside the loop therefore see the same values for these variables, which is  probably not expected.
Related issue(s)
#416

Thanks @slavakr! In case you are interested in more hacktoberfest related issues from AsyncAPI, they are all listed here https://www.asyncapi.com/blog/hacktoberfest-2020

@slavakr would you mind sharing with me how did you find out about AsyncAPI and this issue? we made some effort into Hacktoberfest and want to identify what efforts were the best for contributors and how they learned about us, so next Hacktoberfest is even better


Theme detection and update improvements

Hi,
as mentioned in the issue #236 I did a first draft of a possible implementation of dynamic styling based on the napari viewer theme.
This rework completely omits the concept of static style sheets for the different napari theme and instead translates the current viewer theme into a matplotlib compatible style dictionary.
This happens upon widget initiation and the style dictionary is stored in the attribute: napari_theme_style_sheet.
The style dictionary can be directly used for a motplotlib.style.contect.
Additionally, I fixed the viewer theme callback and the style change upon theme change works now properly.
I encountered some strange during the rework, if I set the facecolor of the figure or axes to something other than transparent (none) the color will stay. Seems like the facecolors are not updated by redraws. I'm feel this is a matplotlib bug, but I could be wrong, maybe I just used the wrong functions for redrawing the figure and axis faces.
EDIT:
I can reproduce this behaviour with pure matplotlib, if I explicitly set the facecolor and redraw it changes, but if I use a style context it stays the same.
If you find the implementation suitable you or I would need to give the test an update as well.

pre-commit.ci autofix

I really like this approach! Not having to deal with custom matplotlib style sheet paths makes life a lot simpler for us, and also gives the user only one place to customise the theme instead of having to do it for both napari and napari-matplotlib. I need to do some manual testing, but in the meantime would you be happy chaging either the code or tests to make the tests pass?
I automatically fixed formatting issues, so there's now an extra commit on your branch. If you want to do taht yourself locally you can install and run pre-commit: https://pre-commit.com/

Hi, I'm happy you like my suggestions. I can take a look at the tests but I'm rather short on time at the moment so this could take some time.
If you are fine with taking a look at the image tests, I would go through the rest.

I've updated the image tests, and cleaned out the old styling code that isn't needed any more. I still need to debug some of the new images, as the text colour doesn't look right. Manual testing indicates this is looking good otherwise though 👍

Looks like all the tests work now. Is there still something I should check?

pre-commit-ci autofix

Nope, I think this all looks good now 👍 . I'll wait for the tests to pass again then merge. Will try and get this in a new release in the next few weeks or so, thanks a lot for the PR!

Happy I could help ^^


Minor fixes for some Scum and Villainy ships

fc797e2 changes the order of actions for the Fang Fighter so that it matches the card exactly (first Barrel Roll > Focus, then Boost > Focus, rather than the other way around).
f700737 fixes some typos and other minor differences between the data and the actual card text.

Thanks!


[Gradle] Do not force use of ENVFILE for basic commands

When running very basic commands such as gradlew tasks command fails since no ENVFILE is specified.
Not sure about proper solution. Maybe fallback to "debug" configuration (if found) and inform user about this fallback.

This should be working as expected now – running without ENVFILE will just make it read from .env (as much as it doesn't matter if you're just running gradlew tasks).
Let me know if you can think of a way to not load our dotenv unless building the actual app!

+1


Eo288 topbar button and logo update

Description

Adds new styling for the start button inside the topbar.

References

https://github.com/Energinet-DataHub/energy-origin/issues/288

@frontend-specialisten Are the Inset Squish mixins exported so that they available outside of the Watt library? It seemed we were only able to use the Inset Squish classes.

@LayZeeDK they should be, if they're not it's a clear mistake. So if thats the case I will create a bug and fix it.


about result

I am not sure the all_scores.txt first row is LSE-C or LSE-D

According to this, LSE-C and LSE-D can be found in output of the script


Update Federated_Pytorch_MNIST_Tutorial.ipynb (Delete one-hot encoding)

While running the openfl-tutorials/Federated_Pytorch_MNIST_Tutorial.ipynb file, an error occurred: ''' File /opt/anaconda3/envs/openfl/lib/python3.10/site-packages/openfl/federated/task/runner_pt.py:486, in PyTorchTaskRunner.validate_(self, validation_dataloader) 484 # get the index of the max log-probability
485 pred = output.argmax(dim=1)
--> 486 val_score += pred.eq(target).sum().cpu().numpy() 488 accuracy = val_score / total_samples
489 return Metric(name="accuracy", value=np.array(accuracy))
RuntimeError: The size of tensor a (32) must match the size of tensor b (10) at non-singleton dimension 1 . '''
I modified it according to the commit contents, and the code worked well after that.
Signed-off-by<EMAIL_ADDRESS>

Hi @tonywjs, Thanks you for resolving this. Can you please fix DCO by signing off your commit?
After that we can proceed to merger this PR.

Closing this as this issue is resolved in https://github.com/securefederatedai/openfl/pull/1116.


Vendor pseudo elements

Vendor parts of pseudo elements are grey, please close if on purpose.

input[type="number"]::-webkit-inner-spin-button,
input[type="number"]::-webkit-outer-spin-button {
	appearance: none;
}

input[type="search"]::-webkit-search-cancel-button,
input[type="search"]::-webkit-search-decoration {
	appearance: none;
}

input::-ms-clear,
input::-ms-reveal {
	display: none;

	width: 0;
	height: 0;
}

@sandrojohanides This is indeed on purpose, the vendor-prefixes should stand out from the keyword itself. These look correct to me.
Thanks by the way for all the reports. You make it super easy to work with, with each separate issue and the code snippets. Really appreciated! 🏅 💯 👍

Thank YOU.


deletions fix

no more reorganizing before this is merged thanks
someone review pls

nice pr number

no more reorganizing before this is merged thanks
Sorry 'bout dat

nice pr number

no more reorganizing before this is merged thanks
Sorry 'bout dat

Should I merge master into this branch?

Should I merge master into this branch?

This should not be a get request. Maybe make it an HTTP delete code (that's a thing) for /edit instead?

I dunno, when I go there it gives me a 405 when it was a post request, so I assume the same with a delete, so I set it to get. I'm not sure why that happened, so I'll refrain from making it a delete. Also yes DELETE is an http method

This should not be a get request. Maybe make it an HTTP delete code (that's a thing) for /edit instead?

I dunno, when I go there it gives me a 405 when it was a post request, so I assume the same with a delete, so I set it to get. I'm not sure why that happened, so I'll refrain from making it a delete. Also yes DELETE is an http method

deletions should now work...

deletions should now work...

We already agreed on holding off deletions, and I agree  with what you say, I'm just maintaining this branch
Sure though, I can make a few changes:

[ ] Only unlisted entries can be deleted
[ ] Security to prevent unintended deletions

We already agreed on holding off deletions, and I agree  with what you say, I'm just maintaining this branch
Sure though, I can make a few changes:

[ ] Only unlisted entries can be deleted
[ ] Security to prevent unintended deletions

We already agreed on holding off deletions, and I agree with what you say, I'm just maintaining this branch
Sure though, I can make a few changes:

[ ]  Only unlisted entries can be deleted
[ ]  Security to prevent unintended deletions

Those are great ideas, what we prob should do is add a way to turn on deletion and some features in config.json but leave them off on repldex.com (maybe something like
config.json:
{
    "deletions": true",
    "deletion_features": [
        "unlist_only"
    ]
}

We already agreed on holding off deletions, and I agree with what you say, I'm just maintaining this branch
Sure though, I can make a few changes:

[ ]  Only unlisted entries can be deleted
[ ]  Security to prevent unintended deletions

Those are great ideas, what we prob should do is add a way to turn on deletion and some features in config.json but leave them off on repldex.com (maybe something like
config.json:
{
    "deletions": true",
    "deletion_features": [
        "unlist_only"
    ]
}

We already agreed on holding off deletions, and I agree with what you say, I'm just maintaining this branch
Sure though, I can make a few changes:

[ ]   Only unlisted entries can be deleted
[ ]   Security to prevent unintended deletions

Those are great ideas, what we prob should do is add a way to turn on deletion and some features in config.json but leave them off on repldex.com (maybe something like
config.json:
{
    "deletions": true",
    "deletion_features": [
        "unlist_only"
    ]
}

don't quite understand?

We already agreed on holding off deletions, and I agree with what you say, I'm just maintaining this branch
Sure though, I can make a few changes:

[ ]   Only unlisted entries can be deleted
[ ]   Security to prevent unintended deletions

Those are great ideas, what we prob should do is add a way to turn on deletion and some features in config.json but leave them off on repldex.com (maybe something like
config.json:
{
    "deletions": true",
    "deletion_features": [
        "unlist_only"
    ]
}

don't quite understand?

We already agreed on holding off deletions, and I agree with what you say, I'm just maintaining this branch
Sure though, I can make a few changes:

[ ]    Only unlisted entries can be deleted
[ ]    Security to prevent unintended deletions

Those are great ideas, what we prob should do is add a way to turn on deletion and some features in config.json but leave them off on repldex.com (maybe something like
config.json:
{
    "deletions": true",
    "deletion_features": [
        "unlist_only"
    ]
}

don't quite understand?

Make deletions a feature that has to be explicitly enabled (or disabled) with config.json

We already agreed on holding off deletions, and I agree with what you say, I'm just maintaining this branch
Sure though, I can make a few changes:

[ ]    Only unlisted entries can be deleted
[ ]    Security to prevent unintended deletions

Those are great ideas, what we prob should do is add a way to turn on deletion and some features in config.json but leave them off on repldex.com (maybe something like
config.json:
{
    "deletions": true",
    "deletion_features": [
        "unlist_only"
    ]
}

don't quite understand?

Make deletions a feature that has to be explicitly enabled (or disabled) with config.json

We already agreed on holding off deletions, and I agree with what you say, I'm just maintaining this branch
Sure though, I can make a few changes:

[ ]     Only unlisted entries can be deleted
[ ]     Security to prevent unintended deletions

Those are great ideas, what we prob should do is add a way to turn on deletion and some features in config.json but leave them off on repldex.com (maybe something like
config.json:
{
    "deletions": true",
    "deletion_features": [
        "unlist_only"
    ]
}

don't quite understand?

Make deletions a feature that has to be explicitly enabled (or disabled) with config.json

I mean... sure but why

We already agreed on holding off deletions, and I agree with what you say, I'm just maintaining this branch
Sure though, I can make a few changes:

[ ]     Only unlisted entries can be deleted
[ ]     Security to prevent unintended deletions

Those are great ideas, what we prob should do is add a way to turn on deletion and some features in config.json but leave them off on repldex.com (maybe something like
config.json:
{
    "deletions": true",
    "deletion_features": [
        "unlist_only"
    ]
}

don't quite understand?

Make deletions a feature that has to be explicitly enabled (or disabled) with config.json

I mean... sure but why

alright will start testing now that it should be done

alright will start testing now that it should be done

Tested, did not see any bugs, seems like it works

Tested, did not see any bugs, seems like it works

If someone could test this :D then I can accept Lmao

If someone could test this :D then I can accept Lmao

It's already tested and everything works.

It's already tested and everything works.

If someone could test this :D then I can accept Lmao

I tested it

Just take a quick look at the code and unrequest changes and approve pls

If someone could test this :D then I can accept Lmao

I tested it

Just take a quick look at the code and unrequest changes and approve pls

@mat-1 pls re-review funny number pr

@mat-1 pls re-review funny number pr


Support deprecating records

OpenAPI supports the possibility to deprecate a record by simply adding  a field:
            "transportEquipment": {
                "deprecated": true,
                "example": {
                    "description": "Europallet with boxes of bananas",
                    "quantity": 3,
                    "loadMeters": {
                        "value": 3,
                        "unit": "m"
                    }
                },

As far as I know this is currently not possible in endpoints4s. It would be great if we add a method deprecateRecord to the JsonSchemas algebra. This method would simply return the same record in the json interpreters, but would tag the record in the OpenAPI interpreter as deprecated.

I would also like to deprecate variants of oneOf:

You can get this behavior by marking the type deprecated (which is not completely the same thing, but closest to what I would like to see)

Hey @julienrf, I see you gave a thumpsup. So, I can make a PR and you can make some time for the review (not in a hurry though, so if the timing is bad it can wait for a bit)?

Yes, feel free to go ahead!


[BUG] .env_sample file missing

Description
When setting up the project for dev, there's no .env_sample file as stated in the docs
Screenshots
No response
Additional information
No response
🥦 Browser
Other
👀 Have you checked if this issue has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Contributing Guidelines?

[X] I have read and understood the rules in the Contributing Guidelines

Are you willing to work on this issue ?
None

Oh shot, I knew I was forgetting something, if anyone wants this, let me know, I would give you what to add to it on discord(link in project Readme) 💪🏽

Hey @Dun-sin, I'd like to work on this issue.

Hey @Dun-sin, I'd like to work on this issue.

Alright, Wil assign you to it, join the server, tag me in coding-talk channel, and I will give you the content of the sample file.
But when making a pull request, make sure to follow the project guidelines💪🏽

th

Hey @Dun-sin, I'd like to work on this issue.

Alright, Wil assign you to it, join the server, tag me in coding-talk channel, and I will give you the content of the sample file.
But when making a pull request, make sure to follow the project guidelines💪🏽

Thanks, will do right away


Pull & Generate latest changes from SpaceTraders

TL;DR
Didn't look at every file yet, cause there are 64 of them and a lot of breaking changes.
Explicit notes:

Generated using OpenApiGenerator 6.6.0
Pulled newest SpaceTraders/api-docs

The switch from OpenApiGenerator 6.3.0-Snapshot to OpenApiGenerator 6.6.0 may be the reason for a lot of the APIs losing the content length (which is nice since it was useless and just making the calls longer as far as i can tell but a very breaking change). I am also still reviewing the changes.

Made this update myself per our discussion


Use user source location in more panic messages

This should cover the missing cases mentioned in #188

Thanks! This is ideal.


[BROMELIA-2268] Include run attempt in asset name for all scearios.

Include run attempts on asset names also when platform name also exists.
Signed-off-by: Martin Perez<EMAIL_ADDRESS>

Thx!


poke

📑 Description
poke build

✅ Checks

[x] My pull request adheres to the code style of this project
[ ] My code requires changes to the documentation
[ ] I have updated the documentation as required
[x] All the tests have passed
[x] I have selected a committee co-chair to review the PR

ℹ Additional Information

Two thumbs up!


Revert "fix: Do not recreate namespace jx-git-operator"

Reverts jenkins-x-plugins/jx-gitops#836 - connected to revert https://github.com/jenkins-x-plugins/jx-gitops/pull/838

/ok-to-test
/lgtm


Add csharp solution for 338 Counting bits

File(s) Modified: 338-Counting-Bits.cs
Language(s) Used: csharp
Submission URL: _https://leetcode.com/submissions/detail/778940113/_

Thanks, @pontusdacke!


form_builder_validator is not compatible with intl. 0.19.0

Is there an existing issue for this?

[X] I have searched the existing issues

Package/Plugin version
9.1.0
Platforms

[X] Android
[X] iOS
[ ] Linux
[ ] MacOS
[X] Web
[ ] Windows

Flutter doctor
not needed
Minimal code example
dependencies:
  flutter:
    sdk: flutter
  flutter_localizations:
    sdk: flutter
  intl: ^0.19.0
  form_builder_validators: ^9.1.0

Current Behavior
Because form_builder_validators >=9.1.0 depends on intl ^0.18.1 and my_app depends on intl ^0.19.0, form_builder_validators >=9.1.0 is forbidden.
Expected Behavior
form_builder_validator should be compatible with intl. 0.19.0
Steps To Reproduce
add intl: ^0.19.0 to your pubscpec.yaml dependencies...
Aditional information
No response

Flutter SDK on 3.16.x depends on intl 0.19.0?

@deandreamatias, not sure if I understand your question.
The reason I pinpoint that compatibility is not that I am interested in finding out what version works with what dependency exactly for how long. I am interested in using the newest packages for my new App. And if I find a package that is not catching up with its sub-packages, then I will always pinpoint the incompatibiltiy.

If you see the package flutter_localizations that use the dependency intl, on Flutter stable version, use de version number 0.18.1.
So, if I upgrade the dependency to 0.19.x, the form_builder_validator will be not build because flutter sdk use the 0.18.1 version

ah I understand , I did not see that - it makes sense then to wait with intl 0.19.x until flutter sdk also uses it.   Sorry did not want to stress things...

Any update on this? Many packages now depend on intl ^0.19.0
The limitation of form_builder_validators is making many other packages unusable :(

Flutter SDK on 3.16.x depends on intl 0.19.0?

Now - yes
https://github.com/flutter/flutter/blob/master/packages/flutter_localizations/pubspec.yaml#L14

you can try this for temporary. update the pubspec.
  form_builder_validators:
    git:
      url: https://github.com/ariefsn/form_builder_validators
      ref: intl-v0.19.0

Shouldn't this issue be reopened?

up

up

for reference: #90, #91 and #92

@deandreamatias
The update to 10.0.0 seems to be missing some files

I'm getting this error when running the project

The update to 10.0.0 seems to be missing some files.

Same behavior here:
[WARNING] build_resolvers:transitive_digests on package:form_builder_validators/form_builder_validators.dart:
Unable to read asset, could not compute transitive deps: form_builder_validators|lib/localization/intl/messages_de.dart

This may cause less efficient builds, see the following doc for help:
https://github.com/dart-lang/build/blob/master/docs/faq.md#unable-to-read-asset-could-not-compute-transitive-deps
[WARNING] build_resolvers:transitive_digests on package:form_builder_validators/src/form_builder_validators.dart:
Unable to read asset, could not compute transitive deps: form_builder_validators|lib/localization/intl/messages_de.dart

This may cause less efficient builds, see the following doc for help:
https://github.com/dart-lang/build/blob/master/docs/faq.md#unable-to-read-asset-could-not-compute-transitive-deps
[WARNING] build_resolvers:transitive_digests on package:form_builder_validators/localization/l10n.dart:
Unable to read asset, could not compute transitive deps: form_builder_validators|lib/localization/intl/messages.dart

Version 10.0.1 of form_builder_validators published. That should be fix the error


Error handling for ES Modules

ChakraCore does not currently propagate relevant information in error messages from within ES Modules; it would be good to see this fixed.
I think I could make a PR to address all of the below points - but a couple of them involve decisions - particularly the fact that currently there is no interface to set a URL for a module see related issue #3618
Please let me know what the view of the team is on the below points and if a Pull Request for one or all of them would be welcome.
Examples - make any error in a module in ch, standard cases:

Syntax error - an error message is given along with the name of the top level parent module but not the file the error is actually in - and no line number (line number is a ch issue - CC provides it)

import/export name not found as above, name of top level module and - SyntaxError: Module import insert_name_here cannot be resolved

Run time error - stack trace with no filename or URL or specifier

Looking into this in ChakraCore - key information is not provided when errors are set within modules:
1. As far as I cans see syntax errors can be thrown from these two places:
https://github.com/Microsoft/ChakraCore/blob/9b255666b90e8594054ad851cb88d27675353582/lib/Runtime/Language/SourceTextModuleRecord.cpp#L174
https://github.com/Microsoft/ChakraCore/blob/9b255666b90e8594054ad851cb88d27675353582/lib/Runtime/Language/SourceTextModuleRecord.cpp#L834
In both cases the "optional" 3rd parameter of a URL for JavascriptError::CreateFromCompileScriptException is not provided. Meaning that the host receives no specifier/url/filename for the error.
I note that as discussed in issue https://github.com/Microsoft/ChakraCore/issues/3618 modules don't have URLs set at the moment (as there is actually no API to provide the URL) BUT the specifier is available this->GetSpecifierSz() and for most cases could be usable for error handling.
2. import/export names not found
https://github.com/Microsoft/ChakraCore/blob/9b255666b90e8594054ad851cb88d27675353582/lib/Runtime/Language/SourceTextModuleRecord.cpp#L630
https://github.com/Microsoft/ChakraCore/blob/9b255666b90e8594054ad851cb88d27675353582/lib/Runtime/Language/SourceTextModuleRecord.cpp#L979
https://github.com/Microsoft/ChakraCore/blob/9b255666b90e8594054ad851cb88d27675353582/lib/Runtime/Language/SourceTextModuleRecord.cpp#L1111
The property name that can't be found is given but the specifier is not provided - for debugging any large module based codebase this will be painful to work with, particularly as default exports will always come up with "default" as their name. In these cases the "fix" looks to be to change the sahpe of the error message slightly, possibly concatenating module specifier with the name of the import/export that can't be resolved.
3. Run time error - no filename/URL in stack trace
This comes back to the no URL issue (#3618) I pointed at above and the choice in https://github.com/Microsoft/ChakraCore/blob/09ab25c9a4e28dba22d2130ed323ab791676b11d/lib/Jsrt/Core/JsrtCore.cpp#L80 to give a nullptr as the URL for CreateSourceContextInfo as opposed to setting the specifier in the absence of a URL.

Further to the above, thought more on this:
Proposal

Add URL as a property of a moduleRecord that can be set with JsSetModuleHostInfo

If this is set prior to the call to JsParseModuleSource set it as the URL for debugging purposes when parsing the script (otherwise leave as nullptr as it currently is)

in all places where an error message is given for a module check if the URL property is nullptr, if it is not include it in the message.

Possitives

Significantly better error handling will be available for module code

No new API required

No breaking changes to any existing API

Negatives

will take a bit of time to write + time to review etc...

I will aim to make a Pull request  that does the above at some point in the next 5 days; please let me know if this is not wanted.

Points 1 and 3 fixed by PR #4080 which has been merged.
Still need to revisit point 2.

@curtisman This needs to be reassigned.

@kfarnung https://github.com/Microsoft/ChakraCore/pull/4080 fixed most of this issue (for JSRT users at least not sure if it's also an issue in Edge)
I was intending to revisit and fix the rest of the issue later (point 2 from the original post) i.e. that if you import an import that doesn't exist the error message tells you the name of the top level parent module and not the name of the module that actually has the wrong import in it.
When I last looked at it I didn't understand enough of your codebase. I'll take another look shortly and see if I can provide a fix.

I had looked into this a bit. IIRC;The remaining part of the issue is the concern of the consumer (mostly)

I'm going to close this issue - as really the key point was resolved in 4080 as I noted above.
The remaining point was just that some error messages aren't great but they're not terrible either and I couldn't see a way to present a more helpful message without some invasive changes which seemed more effort than they were worth.


SPDX license identifier warning

Hi, I have a custom build process and I'd like a way to get the plugin to ignore this, as my deployed (and flattened source) has them inserted, as well as other build info.  I've checked the docs (and the running config) and it appears as if the plugin is using neither solhint or (the other one). Thanks

That is a warning / error of the solc compiler

Ah, appreciate the feedback... I'll go looking to see if it permits a config to ignore this, thanks

No worries, I guess that a feature that could be added to the plugin is to "filter" those warnings from the compiler.

Hey there! Was this ever implemented?

@JetDeveloping no, I asked around and there was not much uptake on this feature.

Continuing with this thread, it could be interesting to filter some specific warnings from the compiler, defined by the user.


Use createQueuedSender for all IPC

Is this ok, or is there a reason why we don't use this for all IPC channels? I'm seeing this problem with search on Windows. https://github.com/nodejs/node/issues/7657
I can add an option somewhere to limit it to the search worker processes if needed.

Maybe we only want to opt-in to it, only in cases that may be problematic, since it could slow down the channel due to only handling one message at a time.

@roblourens I see no issues adopting this there other than the possible performance hit. If you run into the freeze we need to add it in for Windows at least. When do you see it, is it reproducible?
One thing to be aware of: we are using ipc.cp in many places (e.g. for file watching, git, telemetry). Maybe this should be an option for clients to enable and we only do it for now for search?

I'll put it behind an option


Implement operating status sensors including current stage

Checklist

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

Is your feature request related to a problem? Please describe.
Required to open app to see current compressor stage.
Describe the solution you'd like
Implement “Operating Status” sensors, particularly the current compressor stage.
Describe alternatives you've considered
Use vendor app.
Additional context
NA

Closed by 766b8d9a6532686ecbcf85056f46ce293717ced2

I upgraded to this new version that said it included 'airflow_cfm, indoor_unit_operational_status, and outdoor_unit_operational_status sensors' but I'm not seeing anything new when I look at the Sensors under the Entity.  I did have the configuration.yaml manual add for these sensors, but I thought from notes, these would natively appear.  Is that a false assumption?

check your logs and that your on the latest version, it should look like this

Thanks, I did a full restart of HA instead of the prompted Restart after HACS updated. Now I see the new sensors.

Thank You for the Operating Status Sensor access.....this was the missing
link to my automations!
On Tue, Jun 11, 2024 at 6:11 PM Bren Dahl @.***> wrote:

check your logs and that your on the latest version, it should look like
this
Screenshot.2024-06-11.at.7.10.12.PM.png (view on web)
https://github.com/dahlb/ha_carrier/assets/54117/a2fb1b69-d18c-4c1a-ac93-c0b9d957627e
—
Reply to this email directly, view it on GitHub
https://github.com/dahlb/ha_carrier/issues/116#issuecomment-2161748752,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASDP6F36QNOD3ICQDC7L6NDZG57ZDAVCNFSM6AAAAABI5CBWK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRRG42DQNZVGI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Identity comparison vs. value comparison

Perhaps mostly a pet peeve, but I would like to enforce the following styles:

Use be_nil instead of be(nil) or eq(nil).
Use be(true) instead of eq(true).
Use be(false) instead of eq(false).

Maybe also

Use to be_nil instead of not_to be.
Use not_to be_nil instead of to be.

What about be_empty instead of eq([])?

What about be_empty instead of eq([]) (or eq({}) or eq(""))?

Seems reasonable as an option but I wouldn't use it. I like knowing the types of the objects I'm asserting, not just that they're empty

Yeah, I have the same reservations about be_empty.
How about the other examples?

Personally, I like using the strictest matcher that works. Therefore I prefer be(nil), be(true), be(false). I think it would be inconsistent to prefer be_nil instead of be(true) if you are going to enforce identity comparison for some it seems reasonable to enforce it consistently.
I would agree with not writing not_to be and to be. I didn't even realize you can do that

Yeah, be_true and be_false were removed in favor of be_truthy and be_falsey in RSpec 3, as I recall it. It would be nice if we could have be_true and be_false back soon, matching strictly against boolean values.

be_true/be_false are gone, and it's unclear if they'll re-appear.
There's also an RSpec/Be cop to discourage using those two:

use to be_nil instead of not_to be
use not_to be_nil instead of to be

be_empty is less specific than eq({})/eq("")/eq([]), and some prefer the examples to be more indicative and strict.
So, with the current state of things, we can consider a cop that would suggest to:

use be_nil instead of be(nil) or eq(nil)

but it's going to be inconsistent with be_truthy/be_false.
It's also tracked in #693.
Am I missing something? Does it make sense to keep this issue open?

I believe the points 2 and 3 from the original issue are still valid:

Use be(true) instead of eq(true).
Use be(false) instead of eq(false).

I guess the opposite argument could be made. If you want to test that a methods outputs an (the) instance of TrueClass and not just a “truthy” value, you probably want to use eq(true). And in all other cases where be(true) could be used, we could recommend be_truthy to emphasise that we are doing value comparison.

That makes sense. Sounds like a cop with two enforced styles.

If you want to test that a methods outputs an (the) instance of TrueClass and not just a “truthy” value, you probably want to use eq(true).

Why eq instead of be in this example? It'd be weird to do, but there could potentially be classes that override == in such a way that this wouldn't be testing that it's really an instance of TrueClass so I'd always use be. RSpec's output formatting on be mismatches is a little less graceful than eq/eql though.

And in all other cases where be(true) could be used, we could recommend be_truthy to emphasise that we are doing value comparison.

Wouldn't eq(true)/eql(true) be what you wanted for "value" comparison? If I just cared about something being not nil/false, then be_truthy would make sense.

Why eq instead of be in this example? It'd be weird to do, but there could potentially be classes that override == in such a way that this wouldn't be testing that it's really an instance of TrueClass so I'd always use be.

Yes, you are right. I think I was confused when I wrote the comment above.

Wouldn't eq(true)/eql(true) be what you wanted for "value" comparison?

Again, you are right.
So, I remembered that we have an RSpec/BeEql cop, and looking at its history I found this interesting discussion: https://github.com/rubocop/rubocop-rspec/issues/16#issuecomment-237363015. I thought that maybe I could just add :eq matching to the BeEql cop, but after reading that comment again, I think it might be better to have a separate cop, e.g. RSpec/BeEq to fix just eq(true) and eq(false). The eq(nil) → be_nil and be(nil) → be_nil should be in a separate cop.

be(nil) → be_nil

Does it have to? Both are seemingly readable.
Not in the same weight as a pretty common "override ==", but still, there might be cases when classes would override nil?, and be(nil) and be_nil would behave differently. This makes it an unsafe cop, and users won't be running it by default.

there might be cases when classes would override nil?

I can’t think of any such case. If you have an example, I would like to see it.

Right, please disregard this. Overridden nil? seems to be ignored by e.g. Array#compact, and supposedly others, that makes it pointless.

#1238 is ready for review, handling the eq → be recommendation.


feat: tictactoe UI

Type of change

New feature

Changes
The following changes have been made:

Create a ui for the tic tac toe app

Related Issues
Closes #110

When trying the Vercel preview I'm getting Error: it is not your turn. Please switch to the correct player. on both accounts.

same

@K1-R1 @sarahschwartz I think I fixed all the ui errors.  After testing the only error I have been encountering is the one discussed with the ts sdk team and at the moment I can't fix that on my end.

Awesome, it's working great now! Would you mind linking the TS-SDK issue on this PR? Do you think we should wait for the TS-SDK fix before merging? And just as a nice addition in the meantime; is it possible to prompt the account switch between turns, or add a switch account button?

I don't think an issue was created for this bug, but the sdk team said they are looking into it. Looking at the wallet sdk I don't see a way to add a button to switch accounts.


Unable to open a file named "t_JNB01.ipynb"

We have written the needed data into your clipboard because it was too large to send. Please paste.
Issue Type: Bug
Created a file named "t_JNB01.ipynb" (using another program eg touch).  Tried with a file size of 0 or more.
Tried to open it with vscode and get message "Unable to open 't_JBN01.ipynb': Unexpected string in JSON at position 2".  I assume that refers to the underscore in the filename.
I disabled all extensions and got the same problem.
I renamed the file to "t-JBN01.ipynb" and the file opened correctly.
I'm running Windows 10 and VSCode automatically updates.    I didn't try it with all extensions disabled because I didn't realize that you had to close VSCode and reopen it for the disable all extensions to take effect.
When I did restart VSCode "t_JNB01.ipynb" did open.
Further more, after re-enabling all extensions, restarting VSCode, the problems seems to have gone away.

Well no the problem didn't go away.  I tried it with "t_JFN02.ipynb" and got the same problem.  Other than changing my naming conversion (I use 't_' in my .gitignore file) I don't have a solution.

I wonder if this issue is being caused by an installed extension. Can you try to run VS Code without extensions? From the command line (NOT the integrated terminal in Code), execute: code --disable-extensions and try your steps again to see if it reproduces. If you see it is an issue with the extension, please file it against the extension repository itself.

I did as suggested and ran "code --disable-extensions"  I was then able to open t_JNB01.ipynb without a problem.
I then closed code and reopened it normally.  Again I was able to open this file.
The problem went away.
Looking at {home}.vscode\extensions\ I see that the following were updated on 2021-06-24 (yesterday):

ms-toolsai.jupyter-2021.6.999662501
ms-python.vscode-pylance-2021.6.3
ms-vscode.powershell-2021.6.1

Maybe one of these updates fixed the problems.
Thanks for looking into this for me.


Add a number of progress indicators to Cargo

This commit is an attempt to stem the tide of "cargo is stuck updating the
registry" issues by giving a better indication as to what's happening in
long-running steps. The primary addition here is a Progress helper module
which prints and manages a progress bar for long-running operations like git
fetches, git checkouts, HTTP downloads, etc.
The second addition here is to print out when we've been stuck in resolve for
some time. We never really have a progress indicator for crate graph resolution
nor do we know when we're done updating sources. Instead we make a naive
assumption that when you've spent 0.5s in the resolution loop itself (not
updating deps) you're probably done updating dependencies and on to acutal
resolution. This will print out Resolving crate graph... and help inform that
Cargo is indeed not stuck looking at the registry, but rather it's churning away
in resolution.
Downloading all Servo's dependencies

Long running resolution

r? @matklad
(rust_highfive has picked a reviewer for you, use r? to override)

cc @rust-lang/cargo, a relatively significant change to Cargo's UI!

Just to make sure, did we check that these have marginal impact on overall time spent on these steps?
I'm excited to see this happening, though it does seem rather unfortunate about the crate resolution being non-progress bar, and instead just "..."

@Mark-Simulacrum We absolutely do need to measure this, before and after. I've seen reports of an issue with npm where ripping out progress reporting provided an order-of-magnitude performance improvement.

@Mark-Simulacrum @joshtriplett good points! I haven't done much benchmarking yet because anything that touches the network is super variable, but there's a number of mitigations in place to avoid such a performance pitfall in the implementation.

@alexcrichton looking at the first video, it looks like the Fetch progress bar can be repeated more than once, which looks confusing. So we might want to provide some more details, like printing an url you are fetching.
From the tool's perspective, I think in the far future it would be nice to be able to post progress in JSON messages, so that tools could also display progress. In IntelliJ at the moment we just draw an "indetermined" progress bar (always spinning one) and use the last Cargo message as a status. It's a surprisingly good user experience actually, but showing some real percentages would be better of course.
I haven't review the implementation to closely, but the two thoughts jump to mind:
I'd rather extract console progress bar into a separate crate (if there isn't one already): I expect there'll be a lot of interesting corner cases there for different OSes, so it should be easier to maintain this code outside of Cargo.
We have concerns about performance, and there's this funky waiting logic, so perhaps we could spin a separate thread to do all printing to the console?

@matklad yeah the multiple "fetch" bars I believe are git submodules. Unfortunately we can't ever provide an actual progress indicator that's correct because we don't even know what submodules there are until we're done fetching the git repo itself. Sort of like resolution, the best I wanted to do was to indicate Cargo's process at a particular point in time. Ideally if Cargo's just sitting there you should be able to glance at the output and see what's happening is sort of my goal.
I don't really want to get into the business of extracting this to a separate crate. Sort of like the file locking implementation I'm sure it's useful to others but I'm already maintaining far too many crates as it is, and adding yet more where all we really need them to do is work for Cargo's needs would be a bit of a pain... I wouldn't be opposed to someone else extracting it, but there's certainly a plethora of progress indicator libraries on crates.io already and it may not be too beneficial to add one more?
I'm also not really sold on the need for a lot of performance tuning here personally. Updating the console at most 10 times a second seems like it shouldn't really cause problems, and otherwise all of Cargo's console I/O is on the main thread so I'm not sure why this would want to be different?

We don't print the ==> thingy if stdout is not a tty, right?

@alexcrichton
This looks great! Should help a lot with perception.
Any chance we can detect and differentiate submodule fetching? If we don't, we will get questions about this forever.
Also, I naively found it confusing that the fetching steps seem to take quite a while, but the "downloading" steps don't. What's the difference, and can we communicate that a bit more clearly?

@lukaslueg
Indeed yeah, this only all gets printed if stderr is a tty (aka a human is probably watching)
@aturon

Any chance we can detect and differentiate submodule fetching?

We can yeah, we certainly know when we're fetching for a submodule vs fetching for a "main repo". Note though that most projects don't have git deps, much less git deps with submodules, though.
Did you have something particular in mind in terms of what it would look like? There's not a huge amount of screen real-estate to work with, but I could imagine we could say something like "Fetching sub [=== ..."

What's the difference, and can we communicate that a bit more clearly?

Ah so today Cargo prints Updating https://... when it clones a git repository (or updates the registry's index). It then prints Downloading ... whenever it downloads a crate file from crates.io. These are actually very different steps in Cargo!
When we print Updating Cargo has no idea how many it's going to print, but in theory for Downloading Cargo always knows how many it's going to print (it doesn't today in the code, but we could figure it out).
Given that existing implementation my intention here was to just explain to the user what was happening if Cargo ever appeared to hang.  Note that Fetch [===...] shows up for Downloading as well, but in the videos above my network was just too fast to trigger that.
Does that make sense? Maybe we should rename the Downloading? Or maybe fold the Downloading into the progress bar entirely?

RE: downloading vs fetching. I think what this UI highlights which surprises people is that fetching git sources is part of the same step as updating the index, instead of part of the step in which crates are downloaded from crates.io.
servo is an interesting example in that it has so many, and such complex, git dependencies. Most crates will not see a status bar more than once because they exists entirely within the crates.io ecosystem.

ping r? @matklad
This would be quite useful in debugging issues like #4187

Oh, yeah, sorry for forgetting about this :(
r=me with \t removed from here: https://github.com/rust-lang/cargo/pull/4646/files#diff-b53e068c2a295bd3080db1f2a6491fcfR319 :)

@bors: r=matklad

:pushpin: Commit 143b060 has been approved by matklad

:hourglass: Testing commit 143b060025b3e2bcd52ce28d1f3509cf3fbcce4f with merge bac4884daeed6c1d18442d39e8e465daee0a18b9...

:sunny: Test successful - status-appveyor, status-travis
Approved by: matklad
Pushing bac4884daeed6c1d18442d39e8e465daee0a18b9 to master...

Is this eventually going to be extended to show compilation progress as well? The current problem is that you have no idea what crates are actually being compiled, you just have the last few crates which started compiling (and you don't know when they finished). We don't need to show the progress of individual compilations, but being able to tell which compilations are currently running would be a major UI improvement.

Thank you so much for this feature! I have to pull big repos all the time, and even though it's just a cosmetic change, it makes the experience a lot better :)


Investigate INT8 support for Torch MIGraphX

Discover how Torch TensorRT does it
Check if models can be passed pre quantized

Notes:

TRT doesnt seem to have support for quantized layers (ie. modules under torch.nn.quantized.*)
Both dynamo and fx can trace pre-quantized models
Quantization in torch can happen in statically and dynamically:

Dynamic pre-quantizes weights but activations are quantized on the fly (quantization params are also chosen during runtime it seems? https://github.com/pytorch/pytorch/blob/cc03e3a8922d286931bf5468e6dea9e82ff95625/aten/src/ATen/native/quantized/cpu/QuantUtils.h)

Traceable by both fx and dynamo
Conv has no dynamic quantization

Static does both weights and activations (This is probably the one we want to focus on supporting

Traceable only via fx currently (dynamo errors out when dealing with quantized tensors)

Summary of supported ops b/w static and dynamic: https://pytorch.org/docs/stable/quantization.html#quantization-api-summary

Next Steps:

Build simple converter for quantized (static) Linear and Conv layers to test functionality and accuracy
Design how to handle quantized workflow if the initial tests work


Powertoys Update Bug

Microsoft PowerToys version
0.43.0
Running as admin

[X] Yes

Area(s) with issue?
Installer
Steps to reproduce
更新完0.43.0后，打开power toys依然提示下载失败
✔ Expected Behavior
No response
❌ Actual Behavior
我在更新完0.43.0后，打开power toys依然提示下载失败
Other Software
No response

Thank you for reporting! This is duplicate of https://github.com/microsoft/PowerToys/issues/12614. We're working to resolve this by the next release.


DDP-5235 | ability to update email first last name

Requirements:
DSM user should be able to change participant's information(first name, last name, email).
While changing process happens on the server-side, waiting indicator should appear on user side.
Changes have been done:
Added input fields and buttons for each, first name, last name and email.
If input field is empty or value has not been changed, button is disabled.
Added websocket to keep stable connection with server until participant is updating.
When server will return response, simple dialog will appear with relevant message.
Things to pay attention:
web-socket-service.service.ts - to setup and manage websocket.
participant-page.component.ts - where main changes have done, for listening server through websocket and according to response updating user side.

Not relevant branch anymore


Gekko live don't work

2018-08-19 08-28-49.zip
Note: this is the technical bug tracker, please use other platforms for getting support and starting a (non technical) discussion. See the getting help page for details.
I'm submitting a ...
[ x] bug report
[ ] question about the decisions made in the repository
Action taken (what you did)
When i open gekko every time appear the screen that tell me i'm disconnected, after when i want make a live trade and i push start gekko doesn't make nothing there's only the animation that works. I've upload a video in zip format so is more clear.
Expected result (what you hoped would happen)
Actual result (unexpected outcome)
I can't use gekko in live mode.
Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, etc)
I've installed gekko following the official website, https://gekko.wizb.it/docs/installation/installing_gekko_on_windows.html my system is windows 10 but i've tried on virtual machine with linux mint and give me the same problem.

That looks like microsoft edge, do you get the same result with firefox or chrome?

In the video that i've uploaded here i've used firefox all software both windows and firefox at the last update. I've tried more times also with Google Chrome but unfortunaly with the same results. I've delated the folder of gekko and re-downloaded more times in the hope that changes something but nothing.
(In the video i've open the Edge browser only for search how use OBS because i've never used this software)

As to your your second error (trader won't start). People have reported problems with the websocket connection. A fix has been submitted but it is part of a stable release yet. See here: #2454. Would you mind trying that out and see if it solves your issue, you can get that version by following these steps: https://gekko.wizb.it/docs/installation/updating_gekko.html#Updating-the-develop-branch
As to your first error (ECONRESET), most likely the same as here: #2442 I'll keep that issue updated in regards to fixing it.
So I'll close this issue, but if the dev branch still does not fix your live trader please comment here and I'll reopen!


Shared attention

Hi @shahrukhx01,
Thank you so much for sharing a nice repo. How can we combine the attention of all task heads for the shared encoder model and multiple prediction head model? Any lead in this direction will be very helpful.
Thanks

Hi @MehwishFatimah  Thank you for your feedback. This can be done by modifying the multitask_data_collator and adding parallel batches for all tasks. Then in the forward function of the model aggregation losses for all tasks into joint loss i.e., L = loss_task1 + loss_task2 + ... + loss_taskn. Please let me know if you have follow up questions about this.

Hi @MehwishFatimah Thank you for your feedback. This can be done by modifying the multitask_data_collator and adding parallel batches for all tasks. Then in the forward function of the model by doing aggregation losses for all tasks into joint loss i.e., L = loss_task1 + loss_task2 + ... + loss_taskn. Please let me know if you have follow-up questions about this.

Thank you, @shahrukhx01, for your quick response. We aggregated the loss; however, I think (cross) attention should be concatenated in a Seq2Seq task.


Use coredns to ease install on baremetal

I'm not sure I like it. It will affect the testing

And might hide some gaps.

It's also important to distinguish things we put in place to make development easier, versus things we recommend real-world users do (and therefore that we should support)
If we wanted to use coredns to make development easier (by making it easier to replicate a real-world environment, in this case where an external DNS server is configured with the *.apps wildcard), I'd say we should run it on the development machine ... not on the node.
If we think this is a useful thing for real-world users to do, then we need to think carefully about how we enable it - we would not, for example, document that they hand-craft a coredns static pod and its configuration file, and merge that into the machine's ignition

This is definitely helpful development, our current POC works only for Libvirt VMs and whenever someone tries it on baremetal they forget to setup DNS.
I think this might be useful for real-world as well so I think we can start with this PR adding it on top of the openshift-installer generated ignition.
We should start drafting an enhancement for adding this functionality to bootstrap-in-place single node.

Setting up DNS is currently a prerequisite that must be made clear to real-world users
If we believe something like this is a good way of eliminating this prerequisite, then start with an enhancement to explore this idea and gain consensus for adding it in the installer
I would only add something like this here if we're very sure we will be adding something like it to the installer very soon
Please let's not pretend that this is prerequisite has been removed by embedding a hack (which we would not support in the real-world) in our development clusters

I didnt expect this to be merged, but rather launch the discussion, so maybe an enhancement would be a better place for this.
Nevertheless, I think there is a need to overcome the dns requisites we have when we deploy Openshift that don't make sense in a single node context.
Actually, it's not that much about easing development, libvirt dns records are fine for that, although the proposed procedure allows to deploy SNO anywhere, baremetal or other virtualization platforms without any requirement.
Finally, if it was actually to be implemented, it would be better to have it as part of the ignition generated by the single-node-ignition subcommand instead of hacking the generated master ignition.


Localization does not work with cocoa pod

Same as #42
using pod to get Armchair as a dependency, but the alert is always in English
Has this something to do with the swift+pod+framework issue?
Any help would be very appreciated.
Thanks

Are the localization files present in your app once built?

Same here, any updates on that?

Are the localization files present in your app once built?

Same issue here, and yes -- the localization files are all present in the archive.

I wound up adding references to all the localization files in my main project to get it working. Great library, btw!

@claygarrett : how did you do that?

Using master head code or tagged one: 0.1.2( Dec 10, 2015) ?
Fix localization by getting the framework bundle ce4d4a42ff62dcffec56fd7980e8d61ad1814f6e committed on Dec 11, 2015


[CWS] add CWS 7.53 release notes

What does this PR do?
Add 7.53 release notes for CWS.

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


updated caption

TLDR: I am updating my slide comment.
This PR fix bug xxx, resolves #6
Done

made commit
created a branch

To do
-[] merge the branch
cc: @SCHJihong

Pull request Jihong


Permissions/Scopes required for REST APIs with old API docs

Is your suggestion related to a missing or misleading document? Please describe.
All the API docs which are pointing to old swagger docs, do not mention the required permissions/scopes to invoke them.
Eg: https://is.docs.wso2.com/en/latest/develop/using-the-account-recovery-rest-apis/
Currently, the information has to be derived from the ResourceAccessControl section of the identity.xml.

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Fabric React Image not re-rendering on Property Pane update (reactive mode)

Category

[x] Question
[x] Bug

Expected or Desired Behavior
I'm pretty new to SPFx so I'm not sure if this is a bug or lack of my understanding.
While prop pane is in Reactive mode, I would expect Fabric React Images to automatically update when properties are changed.
Observed Behavior
In my case, I have Fabric React Pivot and Fabric React Image in the same web part.  When I change a property of the Pivot, it automatically re-renders.  But I have to refresh (F5) the page to see the updated Image component.  Things I am changing via props include imageFit choices.  The only other real difference is that the Pivot is in my main react component class and the Image is in a child of that.
Steps to Reproduce
Since my project does require a list to fetch data from, I'm attaching a quick youtube video showing behavior and summary of my repo below:
Thanks for any help you can provide.
My branch referenced in the youtube video

I figured out my problem.
In my case, the array for the tiles was created during the componentDidMount method of the web part.  So even though I added code to update the properties, I had not updated the array data.
In the end, I added some code in componentDidUpdate which pushes any props changes down to my item array and then updates the state with the new array and everything works!


FIX - Update noencryptwallet to noseedbackup (testnet)

WARNING: Do not merge this change until sparkswap#LND is updated to 0.5: https://github.com/sparkswap/lnd/pull/13
This PR addresses a deprecation change of noencryptwallet to noseedbackup in LND 0.5. LND-Engine will continue to use this flag during testing.
More info: https://github.com/lightningnetwork/lnd/pull/1843

 Update lnd-engine to use noseedbackup flag instead of noencryptwallet (0.5 BETA)

 Merge upstream LND 0.5 BETA


Events/ event attributes on reply

Currently we append them as new custom events or wasm event (with attributes).
This means there can be duplicate events for wasm or custom event types. Not sure if this is (still) an issue for Tendermint.
I would also be important to document the desired behaviour in cosmwasm. On Reply the data would be overwritten but events/attributes are not.

This definitely needs documentation. The whole events system does.
Tendermint does still have this issue... It will improve in 0.35, see comment and https://github.com/tendermint/tendermint/pull/6634
It would also be good to write some tests to demonstrate expected behavior as those seem to stay up-to-date much better than docs. (And are always more clear)

Defined in #581
Closed by #586
We will have multiple wasm events, but separated by the various entry point events


Add Style and FontAwesome

Changes :

Moves MergeRequest Components in src/components/MergeRequest/
Adds Fontawesome packages
Adds a Navbar with title and github link
Adds style for Merge request table

Should I rename Pill as Badge maybe ?
I'm gonna fill an issue to list our need of a linter / prettier

Good job 👍


Add Web Workers API support

Description
The following changes add support for 'worker threads' as per the Web Workers specification. A new thread is created which communicates with the main through a simple messaging model, described in the linked article. Workers are meant to offload heavy non-ui work from the main thread.
Currently neither ArrayBuffers, nor Java objects (js objects holding a reference to the underlying java instance) can or should be sent from one thread to another using the messaging API.
NOTE: Sending ArrayBuffers and native objects using 'postMessage' is not supported
Does your commit message include the wording below to reference a specific issue in this repo?

Implements https://github.com/NativeScript/android-runtime/issues/532
Does your pull request have unit tests?
Unit tests are included in the runtimes-common tests repo
@NativeScript/android-runtime

:+1: looks good


Feature Request: GM commands to toggle challenges

Loving the module and working great after your assistance on the player settings toggle.
One amazing option would be a .gm command to toggle players challenges on and off so we don't have to directly edit the DB (what i'm currently doing).
No rush - thanks.

+1 to this suggestion can I also ask jshplayer how you are editing the DB to adjust challenges?


[TACHYON-1208] Simplify NonByteBufferOperations

https://tachyon.atlassian.net/browse/TACHYON-1208

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/6461/
Test PASSed.

LGTM


Uncaught Exception - SerialPortError: The operation completed successfully., errno = 0

I am unsure if this is a bug or a misunderstanding from me but, when I close a port via port.close(), a SerialPortError exception is thrown with the message, "The operation completed successfully. erno = 0".

The stack trace provides little information with no trace to my code.

I have tried wrapping the close() call in a try/catch statement which isn't catching the exception.

Found where to catch the exception. The exception is being called in my port reader stream listener, handled by invoking onError callback.


Cleanup Justfile

The Just file is a little bit cluttered. For example we use once web-build and once build-android. This needs to be refactored.
🤔 Expected Behavior

😯 Current Behavior

💁 Possible Solution

🔦 Context

💻 Code Sample

🌍 Your Environment

Desktop

Operating System: Windows/Linux/macOS
Display Server: Xorg/Wayland/-

Web

Browser: Firefox/Chrome/Safari
Version: 100

Mobile

Operating System: Android/iOS
Version: 11

related to #306


Diffeomorphic Demons

Class itkProcessRegistrationDiffeomorphicDemons, toolbox in Registration workspace.

[ ] I may use it badly, but if I open an MRI and CT data in the Registration workspace, open the Diffeomorphic toolbox and launch it, i've got a failure.

[x] I'm trying to add this toolbox into the SRS documentation, and i need to understand it. Did you work on it, or use it? --> NOT ADDED IN CERTIF

I'm not familiar with it.

Updated issue: this toolbox is not needed in the certification

Update with a MRI and a CT dataset, and then the CT+its mask (same size):
DEBUG - mar. févr. 14 10:24:15 2017 - "ExceptionObject caught ! (startRegistration) Unexpected error: itk::ERROR: DiffeomorphicDemonsRegistrationFilter(0x7fc69400a560): Inputs do not occupy the same physical space!
InputImage Origin: [8.3658803e+01, -3.8590387e+02, 2.1123165e+02], InputImage_2 Origin: [8.3658806e+01, -3.8590388e+02, 2.1123165e+02]
	Tolerance: 1.8203120e-06
InputImage Spacing: [1.8203120e+00, 1.8203120e+00, 3.6406159e+00], InputImage_2 Spacing: [1.8203120e+00, 1.8203120e+00, 3.6406081e+00]
	Tolerance: 1.8203120e-06

Solved in https://github.com/Inria-Asclepios/medInria-public/pull/254


Fix issues raised during beta test

💡 Description

https://github.com/NASA-PDS/doi-service/issues/413
https://github.com/NASA-PDS/doi-service/issues/387
https://github.com/NASA-PDS/doi-service/issues/386
https://github.com/NASA-PDS/doi-service/issues/385
https://github.com/NASA-PDS/doi-service/issues/384
https://github.com/NASA-PDS/doi-service/issues/383
https://github.com/NASA-PDS/doi-service/issues/382
https://github.com/NASA-PDS/doi-service/issues/381

📆 01/2024 status: Deferring UI updates due to other higher priority efforts for Web Modernization. This UI is not in operations, and current operations processes suffice for the time being. No review with SWG needed.


Schema DDL: Consider whether enums should be text255 rather than lzo

Migrated from https://github.com/snowplow/schema-ddl/issues/37

Migrated to https://github.com/snowplow-incubator/schema-ddl/issues/36


Improve SpecH5Group.get to take care of getlink and getclass

SpecH5 have enough information to return request using getlink and getclass without loading the data at this level. This patch takes care of it.

I've added additional improvements implemented while troubleshooting #995. But the issue with the Qt thread slowing down spech5 is still to be solved.

LGTM

Sorry. Remember me the behaviour of the links?
f[.../data]
f[.../info/data] # is it already cached?

If you already know the way to convert ".../info/data" -> ".../data" it would be easy to cache the links with a small patch on _get_full_key.


class md-primary md-accent

Is it possible to pass class name like md-primary, md-accent , .. as specified in Angular Material instead of filling color by our own?

Using the hack mentioned in #12 (overriding md-icon directive), that may be possible.


fix(config): update LZW30 parameters to match documentation/latest firmware

LZW30 does not have parameter 8 (that is for lzw30-sn only). Added parameter 13 added in fw version 1.17. Added parameter 51 added in fw version 1.19. Also added White as an LED option also added in fw 1.19.
For reference:
https://support.inovelli.com/portal/en/kb/articles/firmware-v1-17-beta-lzw30-switch-black-series-gen-2
https://support.inovelli.com/portal/en/kb/articles/firmware-v1-19-beta-lzw30-switch-black-series-gen-2

Thanks!


Connect R Shiny to the Google Spreadsheet

Rather than work with static CSV's, we should connect Shiny to the master Google Spreadsheet on parks so we can keep the data consistently up-to-date.

We could look into the googlesheets package.


Get document by id

How to query for specific document, by it's _id? like localhost:9200/indices/type/1

you can do the following Model::search()->ids(1)->get(); or Model::search()->ids([1,2,3])->get();

This way is returning:empty result, even if the product exists on the elastic index
object(Sleimanx2\Plastic\PlasticResult)#277 (7) {
  ["took":protected]=>
  int(10)
  ["timed_out":protected]=>
  bool(false)
  ["shards":protected]=>
  array(3) {
    ["total"]=>
    int(5)
    ["successful"]=>
    int(5)
    ["failed"]=>
    int(0)
  }
  ["hits":protected]=>
  object(Illuminate\Support\Collection)#280 (1) {
    ["items":protected]=>
    array(0) {
    }
  }
  ["totalHits":protected]=>
  int(0)
  ["maxScore":protected]=>
  NULL
  ["aggregations":protected]=>
  array(0) {
  }
}


Fast Sync Must Execute Blocks To Current

[ ] Allow the ContractRuntime to make execute block execution calls with a responder (PR #1669)
[ ] Call ContractRuntime from the fast-sync loop (PR #1712)

Closed with #1669


Training time and params

Hello,
First, thank you for you amazing work ! I tried to launch a training on a SLURM cluster and get these results  (it has been training now for 10hours on 2 A100 GPUs and has still 10 hours to go). The reconstruction does seem weird to me compared to the segmentation, can you tell me if this seems alright ? The training loss is decreasing very slowly, while the var loss seems better.

Yes sorry, here is the figure :

I use the config file "sa_ldm_dino_coco_params-res224.py" from img_based configs folder

Attached is one result I have, which shows some rough appearance of objects, but the details are wrong. It is true that SlotDiffusion still cannot reconstruct natural images very well (We do acknowledge this in the limitations & future works):

With the help of pre-trained encoders such as DINO ViT [ 7 ], SlotDiffusion is able to segment objects from naturalistic images [ 21 , 54]. However, we are still unable to decode natural images faithfully from slots.

However, your reconstructed images seem too bad (no object at all). I don't really understand why. Have you tried other training configs (e.g. CLEVRTex), and are those reconstruction results also this bad?

Hi yes I never saw this in my experiments. And I know someone is able to get reasonable reconstruction results using this repo (though not on this dataset). So, the first thing to check is, if you just do encoding-decoding (auto-encoding) using the VQ-VAE, can you get good reconstruction results?

Feel free to re-open the issue if you have further questions


Issue with tf.gradients() taking too long

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 16.04 LTS
TensorFlow version (use command below): 1.8.0
Python version: 2.7.12
CUDA/cuDNN version: 7.5.17
GPU model and memory: GeForce GTX 1080 Ti
Bazel version: N/A
Exact command to reproduce: tf.gradients()

Describe the problem
So I am using tensorflow/models/object_detection with different networks (Currently using a SSD MobileNet network). I am trying to prune the network and I am using tf.gradients(total_loss, activation_tensor) on the activation tensors to see which filters need to be pruned. However, the issue I am currently facing is that each call to tf.gradients is costing me at least 3 seconds regardless if I am doing this on the GPU or CPU. Is this a known issue and is there a fix or a replacement for tf.gradients?

Thank you for your post. We noticed you have not filled out the following field in the issue template. Could you update them if they are relevant in your case, or leave them as N/A? Thanks.
TensorFlow installed from
Bazel version
Exact command to reproduce

It has been 15 days with no activity and the awaiting response label was assigned. Is this still an issue?

Yes the issue still persists.

Nagging Assignee @tatatodd: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @tatatodd: It has been 29 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @tatatodd: It has been 44 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @tatatodd: It has been 59 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @tatatodd: It has been 74 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @tatatodd: It has been 89 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @tatatodd: It has been 104 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @tatatodd: It has been 119 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

@felsabbagh3 Sorry for the late response. I think this is a stale issue.
This issue is more related to models. You could post issues related to object_detection under models repo https://github.com/tensorflow/models/issues
Please share simple standalone code to reproduce the issue. Thanks!


Banner to let users know where to manage certificate for an org, on the account settings page

Fixes #6072

@xavierdecoster  Can you post a screenshot?

@anangaur any changes required to the wordig as per @loic-sharma's suggestion? Or good to go?


Add free automated flake8 testing on all pull requests

The owner of the this repo would need to go to https://travis-ci.org/profile and flip on the repository switch to enable free automated testing on each pull request.  This could be adapted to run pylint instead of flake8

Thanks for your interest in King Phisher. After careful consideration and discussing it with the other team member I have decided to reject this pull request for the following reasons:

We have used Travis-CI in the past and ultimately opted to remove it due to it being problematic and requiring us to constantly tinker with it.
We (the core development team) are already automatically using autopep8 and pylint in a pre-commit hook.
Finally, this is a solution to a problem we simply don't have. You are the third person to submit a pull request to King Phisher, and none of the three have changed any of the Python code.

Once again thanks for your interest and understanding. I hope this doesn't deter you from wanting to contribute in the future.


Update for libpostal 1.0?

I'm in the process of updating to 1.0 and it appears that the C api is slightly different. It's been a while since I did any C stuff so I might be wrong in my assessment.
I'm going to take a crack at updating the code in jpostal and that will eventually tell me the answer one way or another. (If I'm right, this issue# gives me something to track against)

Hmm. I see a commit for the update: https://github.com/openvenues/jpostal/commit/0364c0d35694d2c6800805e2adc2b9122aa5d207
For some reason git just can't see the latest commits when I fetch.


NV_CONTROL (nvidia-settings) is non-functional

Describe the bug
On a NixOS unstable from earlier today running nvidia-settings -q all returns nothing. Also launching the GUI doesn't allow for any settings. If I try to run gwe from the cli, it informs me that the "nv-control x extension is not found".
These tools used to work several years ago, but something has broken since then.
Steps To Reproduce
Steps to reproduce the behavior:
nvidia-settings -q all
Expected behavior
I need nvidia-settings to control my GPU fans, so I would like it to function as expected
Screenshots

Additional context
Not sure if it is something specific to my setup (PRIME laptop with render offload) or if it is broken for everyone?
Notify maintainers

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.54-xanmod1, NixOS, 22.11 (Raccoon), 22.11.20220819.1882611`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.10.3`
 - nixpkgs: `/nix/store/jqqk07gssjg81hzas06966cdczg83c8v-z72lgm9v5mlq5819wa9a5qbbijz5x4rv-source`

Are you using the proprietary nvidia drivers, i.e. have you set the option services.xserver.videoDrivers = ["nvidia"]?

yes i am

Same here. Laptop with an Intel + Nvidia GPU setup and render offload configured. nvidia-settings also doesn't mention the GPU, nor does it give me any options related to the GPU. No apps are able to recognize the coolbits option set in my xorg config either.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/getting-help-for-configuring-nvidia-driver-on-nixos-22-11/25093/14

This has been fixed on my end on nixos-unstable (rev f99e5f03cc0aa231ab5950a15ed02afec45ed51a to be specific).


remove superfluous $scheme empty test

$scheme is never empty as it was initialized to 'http'

Thanks, @pine3ree.


Use type aliases

Improve function signatures by introducing type aliases instead of coercing them to the underlying primitives.

This relies on the upcoming Dart 2.13 feature.

This seems not to be practical at present, unfortunately. I was excited about this as a way to help delineate between the many ways that types like int are used in Win32 programming.
As an example, take a Win32 HWND: a window handle, which is a pointer-width integer. In most cases, I want to declare:
typedef HWND = int;

so I can declare a function like void ShowWindow(HWND hWnd) in a nice idiomatic way. In many cases, the type alias would greatly enhance readability of the code.
But elsewhere, this is passed as a pointer, such as int GetControlWindow(HWND *phWnd). Here, the Dart equivalent of Pointer<HWND> won't work, since HWND needs to be aliased to IntPtr in this context.


Allow for customization of errors thrown when APIs are rate-limited in RateLimitController

Currently a static error is thrown. We may want to allow implementations to specify other errors.

Not planned as of right now


Suggestion formatters should include pascal case

Right now it's titled as hammer however pascal is the common definition.
Could be added in addition to?

anyone object to this? @pokey @knausj85 @splondike ? I guess the only principle it violates is that we shouldn't have duplicate names for formatters.

I'd be tempted to just pick one, and I'd also be tempted to make that one be "pascal", tho it's going to be rough for people who merge and all of a sudden "hammer" breaks. Argues for defining formatter spoken forms using csv default setup

But I have no strong objection to aliases in formatters

I think I like the idea of just having one way to do it; more commands -> more misrecognitions.
We could deprecate the hammer command with a notification balloon like we did for the 'M grid' command, but I'm not sure if it's worth retraining everyone's muscle memory?
@douglasg14b What do you think, is this more of an issue while you're learning knausj, or is it something that trips you up regularly as you've gotten more experienced? For me there are a lot of semi-arbitrary command words to memorise :).

@splondike
I am a new user of course, however, the goal of not having duplicate commands, and not breaking commands, kind of sets in stone any and all ideas & implementations doesn't it?
If something has a more broadly known term, that isn't a conflict for speech recognition, it would be my opinion that that term would want to be used. There are a lot of arbitrary words and commands to learn, If possible, making them less arbitrary sounds beneficial.
In this case, I believe that Pascal is far more known than Hammer, however, that's what this discussion is for.

This is a little unrelated to this issue, but in my case it's not a prohibition, but a slight bias against new and duplicate commands. They have to present a reasonable amount of 'usefulness' before I think they should be included in this repository.
Having more (or duplicate) commands increases the chance of misrecognitions, collisions with other commands, makes documentation (like cheat sheets) longer, and gives us maintainers more things to think about (we have no way of knowing if a given command is being used or by how many people). This has meant in the past for example that I have pushed back around adding commands that would be very easy for somebody to put together in their personal setup, and would likely take almost the same time as learning whatever words we used for it. To exaggerate a bit, the bad end state I'm trying to avoid is we have 100s of globally scoped commands taking all the 'good' prefix words and offering functionality of marginal utility. And we don't know which if any are being used so we have to maintain them all. So that's why I have a bias (but not a prohibition).
Anyway, this case is a combination of that and also considering existing 'muscle memory'. We've probably got 10s or maybe 100s of people using 'hammer' already, so if we swapped it out we'd be asking them all to notice that and then retrain themselves. This is potentially fine if pascal is mnemonically more useful than hammer (it probably is, but I didn't know that was what this was called prior to this issue).
I think I'd be fine with either not doing this issue, or with making pascal the default and causing usage of hammer to display a notification balloon telling people to move to 'pascal' (like we did with M grid). It seems like douglasg14b and pokey would both find 'pascal' more pleasant mnemonically or aesthetically, so probably you represent a reasonable slice of users.

@splondike
I believe you're highlighting what is both a growing pain and process issue. This thread has speculation that would be resolved by process precedent, I assume a process that typically hasn't been necessary and has been resolved on ad-hoc basis?
It sounds like there is a need for a strategy that covey both command proposal/change, as well as low-impact deprecation of changed/replaced/removed commands. A basic change process even?
But there is a little bit I'd like to unpack and share:

Note: This isn't arguing for or against my suggestion, you could almost think of this as a side effect of the conversation, just thinking from a project standpoint. The following is separate from the OP.

They have to present a reasonable amount of 'usefulness' before I think they should be included in this repository.

I don't really disagree, though there is serious hidden nuance here:
If every decision and command that exists in the repo has been evaluated with the same level of due diligence that you wish new commands are evaluated with then this makes sense. If they have not, which I bet is the case (no negative connotation here,  that's just how projects grow), then only evaluating new propositions with due diligence and not what they aim to replace/change cements both good & bad decisions in stone.
Guaranteeing backwards compatibility for bad ideas seems like a poor maintenance strategy, and an even poorer growth/adoption strategy.

pokey would both find 'pascal' more pleasant

No I'm sticking with "hammer" no matter the outcome here.  Too deeply ingrained at this point 😅.  Pretty sure @AndreasArvidsson is a "pascal" guy tho

Definitely pascal here since I use that terminology as long as I can remember.

Re backwards compatible spoken forms, fwiw in Cursorless we have machinery where we take a snapshot of the current default spoken forms when a user first installs Cursorless, in the form of csvs that the user is free to edit, and then if we change the default spoken forms, they'll keep the original ones.  They will still get any new spoken forms going forward; they'll be appended to the end of their csvs.  See https://github.com/cursorless-dev/cursorless-vscode/blob/main/docs/user/customization.md
It's similar to knausj csv support, but a bit more powerful because it can add new spoken forms
We might consider doing more like this in knausj in the future

@douglasg14b Yeah, discussing this is probably worthwhile. Since knausj_talon is pretty central to the current Talon experience I'd be in favour of discussing and codifying some aspects of how to maintain it. To keep the issues separated though, would you like to create a new issue about this governance topic?
FYI I'm going to be out of town for the rest of the week, so am unlikely to respond to things over the next few days.

I think we've probably settled on hammer after leaving this alone for 3+ years. 🤣
Closing.

I'm still of the opinion this should be Pascal. As that's the broadly known and understood terminology. Maintaining past decisions into perpetuity even if they are esoteric is pretty awkward.
Thankfully this is something that can be modified with individual configuration.