Entity status updates requires periodic integration restart

The problem
It seems that at least once a week, I find that automations relying on Vivint entities are no longer firing. Home Assistant is able to send commands (unlock doors, disarm/arm Vivint system, etc) but the status of all entities is not updated. Looking through my logs, this is the only thing I'm able to see:
Restarting the Vivint plugin always solves the issue.
What version of Home Assistant Core are you running?
core-2024.10.3
What was the last working version of Home Assistant Core?
No response
Anything in the logs that might be useful?
Logger: custom_components.vivint.hub
Source: helpers/update_coordinator.py:367
integration: Vivint (documentation, issues)
First occurred: October 18, 2024 at 11:55:06 PM (1 occurrences)
Last logged: October 18, 2024 at 11:55:06 PM

Error requesting vivint data: 500, message='Internal Server Error', url='https://www.vivintsky.com/api/authuser'

Additional information
No response

Adding more logs:
This error originated from a custom integration.
Logger: custom_components.vivint.hub
Source: helpers/update_coordinator.py:354
integration: Vivint (documentation, issues)
First occurred: 4:15:17 PM (1 occurrences)
Last logged: 4:15:17 PM
Unexpected error fetching vivint data
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 354, in _async_refresh
self.data = await self._async_update_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 271, in _async_update_data
return await self.update_method()
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/vivint/hub.py", line 80, in _async_update_data
return await self.account.refresh()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/vivintpy/account.py", line 153, in refresh
await system.refresh()
File "/usr/local/lib/python3.12/site-packages/vivintpy/system.py", line 59, in refresh
system_data = await self.api.get_system_data(self.id)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/vivintpy/vivintskyapi.py", line 156, in get_system_data
resp = await self.__get(
^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/vivintpy/vivintskyapi.py", line 570, in __get
return await self.__call(
^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/vivintpy/vivintskyapi.py", line 654, in __call
raise cls(message)
vivintpy.exceptions.VivintSkyApiError: Attempted to access an unauthorized Smarthome System

This follows immediately after:
This error originated from a custom integration.
Logger: custom_components.vivint.hub
Source: helpers/update_coordinator.py:367
integration: Vivint (documentation, issues)
First occurred: 4:10:17 PM (1 occurrences)
Last logged: 4:10:17 PM
Error requesting vivint data: 500, message='Internal Server Error', url='https://www.vivintsky.com/api/authuser'

I'm getting same behavior, but nothing in my logs about it. I see on my physical panel that my alarm gets successfully set, but then homeassistant doesn't see the status change until much later.

I’m experiencing this issue as well, however there is nothing in my logs either. I use the door and motion sensors in several automations and after a period of time after a restart those automations no longer fire because Vivint stops communicating with home assistant.
Going to try and track down more information from my system, but just wanted to make sure you knew there were more people seeing this.

Got another error yesterday- this time bad gateway.
Logger: custom_components.vivint.hub
Source: helpers/update_coordinator.py:367
integration: Vivint (documentation, issues)
First occurred: October 25, 2024 at 8:05:11 AM (2 occurrences)
Last logged: November 4, 2024 at 11:57:23 AM
Error requesting vivint data: 500, message='Internal Server Error', url='https://www.vivintsky.com/api/authuser'
Error requesting vivint data: 502, message='Bad Gateway', url='https://www.vivintsky.com/api/systems/3527906212567390?includerules=false'

My best guess right now is that when these server error / authentication issues happen, it somehow terminates the connection with pubnub for push updates to the component, which then introduces the lag. I haven't had a chance to test that theory though, or to test a fix that would try to resubscribe yet.

I’m having the same issue where it’s taking a long time for automations to fire and state to update on home assistant. Sending a command like arming and disarming instantly updates the pens but opening/closing doors or windows takes 3-4 minutes to update on home assistant and I have to constantly reload to have it work normally.

I’m having the same issue where it’s taking a long time for automations to fire and state to update on home assistant. Sending a command like arming and disarming instantly updates the panel but opening/closing doors or windows takes 3-4 minutes to update on home assistant and I have to constantly reload to have it work normally.

I was able to set an automation to reload the Vivint integration couple times a day to temporarily fix this issue but the annoying thing is the automation that Vivint used last gets triggered every time it reloads.


fails to build on ruby-head(2.3.0)

working on getting sintra-contrib green in ruby-head
machine: debian(jessie), ruby-head(2.3.0)
error output and mkmf.log here: https://gist.github.com/ashleygwilliams/97dc7eb34f43fdbf3952
any help would be appreciated!

@nobu fixed this here: https://github.com/ruby/ruby/commit/356baf95db7162b5a964dd17a8fe871afe805cf5

woo!fix confirmed :)


Repository size field does not support long values.

If retrieving repositories with where the size of the repository is rather large, then the JSON object mapping fails with the following exception:
Exception in thread "main" org.azd.exceptions.AzDException: ApiResponseParsingException: Numeric value<PHONE_NUMBER>9) out of range of int (-2147483648 -<PHONE_NUMBER>)
 at [Source: (StringReader); line: 1, column: 261214] (through reference chain: org.azd.git.types.Repositories["value"]->java.util.ArrayList[270]->org.azd.git.types.Repository["size"])

Steps to reproduce
Run the following Java code:
public class Example {

    public static void main(String[] args) throws AzDException {
        var organisation = "<my org>";
        var personalAccessToken = "<access code>";
        var webApi = new AzDClientApi(organisation, personalAccessToken);
        var core = webApi.getCoreApi();
        System.out.println(webApi.getGitApi().getRepositories());
    }
}

Have a large Git repository. For example the following JSON response on the repositories API:
{
  "value": [
    ...
    {
      "id": "<private>",
      "name": "<private>",
      "url": "<private>",
      "project": {
        ...
      },
      "size":<PHONE_NUMBER>9,
      ...
    }
    ...
  ]
}

Expected behavior
Status code 0

Actual behavior
Exception was raised by `JsonMapper`

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields
otherwise the issue template will be treated as an incomplete report.

[x] Bug Description Added
[x] Reproduce Steps Added
[x] Expected Behaviour Added
[x] Actual Behaviour Added

@stil4m thanks for pointing this out and for the PR.


Go Generate from IDL

This has been on my wish list for a long time and with Go Generate tool, I think it could finally be achieved within a reasonable amount of time.
The idea is to generate the marshal code for structures and methods (and, or functions) based on the interfaces and classes found in the IDL, if one exists.
So the tool would generate all or most of the code required to interop with COM or OLE with the command:
go generate
with the comment:
//go:generate go tool ole -o something.go -p idl_file
The idea would also try to investigate searching for registered COM servers and pulling interface information like the Visual Studio tool shows to also build a go file. If possible it might look like:
//go:generate go tool ole -o something.go -p uuid
or
//go:generate go tool ole -o something.go -u uuid
This might be incredibly difficult to implement, but as much as I hate porting existing code, I'm hoping it is possible.
Another option would be to accept a yaml or json file that describes the interface and classes. I would also suggest reading C or C++ for information as well, but that would require a more complicated parser.
The generated code will use library functions and helpers. I'm unsure how everyone does their COM code. If I can get some examples, I might be able to have a better idea how the Go code should look like.
One possible solution would be to generate structure types that match the class name and add methods for retrieving class properties and calling interface methods. So the structure types will be empty, possibly allowing for the programmer to extend the generated code.
If the generator only creates empty structure types, then it will ignore and not replace any attributes contained in that type. Documentation should potentially suggest that generated types are extended in a separate file and not directly modified.
Goal:
The goal is to generate as much code as possible for the programmer through the go generate tool, by creating a tool that parses IDL file for COM type information.
Secondary goal is to look up by system registry based on UUID or com server name.
Optional 3rd goal is to accept json or yaml or both file formats and creating functions from that.

Well, should also generate some *_test.go files as well, if reasonably possible. Most likely based on an existing template.

That sounds difficult. IDL and variations like ODL are fairly complicated in terms of parsing, from what I know about them. The language grammar is a weird superset of a subset of C's grammar. ;-)
I've used Microsoft's Type Information Library (tlbinf32.dll) in the past to read interface information from COM libraries - it's a COM DLL that can read type libraries in binary form, so it can load interface information directly from COM binaries (i.e. DLL's and OCX's), as well as from compiled type library (TLB) files.
The library's API is a little difficult to deal with, and it isn't documented very well, although there are some resources online, such as this Dr. Dobb's article:

Accessing Type Libraries from VB

...and this MSN Magazine article:

Visual Basic: Inspect COM Components Using the TypeLib Information Object Library

Since tlbinf32.dll can read the interface in compiled form, this also means you don't need to have the original IDL in order to generate the code in Go. Instead, you need a TLB file for the COM library, or, in most cases, the COM DLL or OCX file itself, since the type library is usually embedded in the binary file.
You can also load type libraries using the LIBID (the GUID for the type library) and the type library version you want, which is really mostly useful for cases where one DLL contains type libraries for multiple COM API's (which seems rare).
tlbinf32.dll is also redistributable, so it could be packaged with a helper program that actually generates the Go code.
We could write the code generation tool in C#, VB.NET, or even VB6 (!), because we can easily use tlbinf32.dll from any of these. If we don't want to ship a tool written in another language, we could write an initial implementation of the generator in one of those languages, and then run tlbinf32.dll through the tool to generate a pure Go implementation of a tlbinf32.dll wrapper, which in turn could be used to write a generator in Go with no other languages needed.
The catch is that tlbinf32.dll would need to distributed and registered on end-user machines for this approach to work, but using this library would keep us from having to implement our own IDL/ODL parser from scratch, which could save time and effort.

Excellent. I think I am going to switch to this instead using the information you gave me. Having a tool that generates Go COM code would be much better and allow me to get some practice with C#. I'm still reading through the .NET COM book, but it is slow.
I like your idea of having C# program, but just have the C# program use the tlbinf32.dll to get the type information and then convert it to JSON. That way the go tool would be able to call into the C# program, get the JSON and then generate the Go code for output. The primary reason for this is that Go already has Go language libraries that should reduce the work and hopefully allow generating updated Go code with minimal work.
I'd have to look at how the other go generate tools work, but I'm hoping that it is almost as simple as generating the AST nodes and passing it to the library function. If I remember correctly, that might be close to correct with a few nuances I'm forgetting or misunderstanding from the library's function descriptions.
 And so on for 2.x and X.x, if at all possible.
The other go generate tools either include or require external tools, so even if the C# program isn't included, part of the process would be to download the tool. Going to need to check with how this is going to work with Linux or if it will work with Linux.
Is it possible to download tlbinf32.dll and register it as part of the tool process? Or would it be better to include it in the repository? The reason I ask is whether license would restrict having it in the package.

Having this tool should actually allow for generating the COM code for the COM test server.

Is it possible to download tlbinf32.dll and register it as part of the tool process? Or would it be better to include it in the repository? The reason I ask is whether license would restrict having it in the package.

I don't think Microsoft has a public download link for the file. It was originally shipped with VB6. I'm not sure if it is included with Visual Studio/.NET.
We use it in one of our legacy applications where I work, and the version we use works on Windows XP and all later versions of Windows, and I believe it would also work on Windows 2000.
My understanding is that the library is not officially supported by Microsoft, but the licensing allows you to redistribute it without any restrictions.
The REDIST.txt file that ships with VB6 installation lists tlbinf32.dll as REDISTRIBUTABLE CODE - Standard, for example, which seems to be the least-restrictive category for the files included with VB6.
So, I think it would be fine to either include the file in the repository or host it publicly somewhere. If we decide to add an explicit license to go-ole, we might have to host it outside of the repository, depending on what license we would choose.
Right now, without an explicit LICENSE file, there isn't any restriction on putting closed-source binaries in the repository, but if we were to use GPLv3, that would change, because tlbinf32.dll doesn't meet their definition of "system library."

@mgspross Doing some research, you can just inspect using ITypeInfo through COM. This will read the TypeLibrary file, if it exists, and allow for you to reflect on the methods and properties. The API for doing so, seems to be very convoluted, so the implementation could be pretty involved.
I think for the moment, I'm going to go with this, since, I think tlbinf32.dll will essentially be giving the same information. I haven't been able to check the API of tlbinf32.dll, or if it would be easier than ITypeInfo.
I think I'm going to have to still do some of the work on the library, but I know what I'm going to try ITypeInfo first. If the tool's only dependency is COM, then it won't require a separate Windows / WINE application. I am hoping that just sticking with the COM library will provide enough support to complete this project.
I have a feeling that it won't solve 100% of all of the cases. I think, even if it solved 50%, then that might be good enough of a start. The tool could always be extended later to support more use cases. Doing so would be outside the scope of my current ability.
I am still thinking of allowing for JSON or YAML or both formatted file for providing basic type information in the instance that no type library is provided or registered. The other reason for still supporting the JSON or YAML or both, is so that it would provide the user the choice of which parts of the API to output as Go code.
Also, if this could be done in the Go tool, then the Go tool could also output the JSON or YAML or both formatted file to allow for the developer to choose which parts of the API are outputted as Go code.
If ITypeInfo provides a solution, then I think at a future date whether or not to add tlbinf32.dll and other reflection techniques to the tool should be evaluated. The resources I have seem to suggest that most COM APIs will come with a TypeLibrary, but I'm not sure of the accuracy of that claim.

I would assume that tlbinf32.dll uses ITypeInfo and other related interfaces internally - using tlbinf32.dll directly occurred to me first because it's the easiest way to use that functionality from languages that support COM. I'm fairly certain tlbinf32.dll is just a wrapper for ITypeLib, ITypeInfo, and other related interfaces. I'll refer to the ITypeInfo API the "native API" to differentiate it from tlbinf32.dll in this post.
In the native API, it looks like ITypeLib is the top-level interface - you can then get the ITypeInfo for each type in a type library through that interface.
Here are some reference articles:

Type Description Interfaces: This describes the main interfaces in the native API
Type Description Functions: This describes the functions for accessing the native API interfaces, such as the LoadTypeLib, LoadTypeLibEx, and LoadRegTypeLib functions, which can be used to retrieve an ITypeLib instance.

tlbin32.dll exposes a similar API, but with different names for things, and in a way that would be a bit more compact perhaps, because it's wrapping some of the more complex functions and functionality in the native API in "nicer" patterns, like using collections for lists instead of list-accessor functions.
That said, I agree using the native API seems preferable, since it removes the dependency on tlbinf32.dll.
The native API is still a COM API, however, so it would only work from Windows (and would probably work in WINE too).
The main difference is that the native API is available as part of COM/OLE, so no extra files need to be distributed or registered.
Lastly, I can tell you the tlbinf32.dll is pretty convoluted too, as I've used it many times myself. I've actually never used the native API directly, but as I said, I tend to agree it would probably be the better choice in this situation.

I have been looking at those. Right. So I have all of the information I need now. I'm kind of excited to finally work on this after doing all of the research. You did provide the final piece for me with the ITypeLib.
I was wondering how to actually get all of the interfaces in the Type Library. ITypeInfo does not give this, so that is why I was confused.
 It does seem however that it shouldn't be that difficult, since GetTypeInfo() gives you a ITypeInfo object, which you can then get all of the methods and properties.
I will need to do some restructuring of the code first. I think putting this in its own package would make sense, given that I don't think many will require it. I also don't want the tool to require the complete COM package.

This have moved to another repository.


Stackable Item in Inventory

Hey, I love the idea but always stumble about the problem with stackable items. Once rendered, two translated items would only be stackable if in the same language, right? So items like currency that people actually drop to each other could not use the system.
I thought about it and whats needed is a mechanism to recognize a rendered component as a serverside translatable component.
What I came up with is using the vanilla translation key
"createWorld.customize.flat.layer": "%s",

One could send it with the key as seccond argument and rendering as first argument. It would render just as supposed to, but then when this particular key is being send to the server, its first argument will be set to Component.empty() to make items stackable again.
It brings in a bit of extra work for the server though. What are your thoughts?

This plugin doesn't actually change items serverside. It uses ProtocolLib to just render the items in the packets

Yeah but when your server sends a modified packet to client, the client sends the modified itemstack back. Saying "I picked up itemstack xy". Afaik there are issues because items are compared via nbt and then name differs. Server side its a translatable and clientside its a rendered component

Only in creative mode, where the client sends a Creative Mode Slot packet.
This could be fixed by adding the original name as a second tag, then when the Creative Mode Slot packet is received the name is replaced with original name from the custom tag.
I don't want to do any custom NBT business with this plugin though, it's just supposed to apply Adventure translations on a packet level.


CFE SB Pipes not safe across multiple tasks

Is your feature request related to a problem? Please describe.
Some "worker" software design patterns involve multiple threads reading from a common/shared work queue.
However due to the way SB buffers are managed, this is not currently possible with CFE child tasks and SB pipes.  The "current" (i.e. most recent) buffer is stored in the Pipe descriptor structure, and upon the next entry to CFE_SB_ReceiveBuffer() this function assumes that the last buffer stored in the Pipe descriptor can be freed.  But when multiple tasks are reading a single SB pipe, this model breaks, because only one buffer can be remembered.   The current buffer is likely still in use by the other task when the next worker thread calls
This necessitates some new APIs to actually make this work.  Each worker task will need to individually indicate to SB when it is actually done with the buffer, it can't rely on entry to to CFE_SB_ReceiveBuffer() to indicate this.
Describe the solution you'd like
Short term fix: Just document that only one task may operate on a pipe ID at a given time.  App developers must externally sync their worker tasks to ensure this.
Recommendation would be to have one designated task (i.e. the main task) act as the delegater - it reads the SB pipe, identifies the request, and copies the request data to an available worker thread.  After this it can get a new request from the SB pipe while the worker goes on.
Longer term fix: Expose the SB buffer refcount increment/decrement routines separately in the public API, and decouple the previous buffer refcount decrement from CFE_SB_ReceiveBuffer().  So each worker task can safely get a buffer from SB without inadvertently freeing any previous buffer that may be still in use by other worker tasks.
However, this is an API change that would affect all apps, as they now must make a new/additional call into CFE_SB when they are finished with a buffer as CFE_SB_ReceiveBuffer() cannot not do that automatically.
Describe alternatives you've considered
Could feasibly have a task-based buffer record so that each CFE task will have its own "slot" so to speak, and thereby CFE_SB_ReceiveBuffer could free the previous buffer from that task rather than having the single buffer associated with the pipe ID.
But this has weakness too- SB has to have a slot for every possible task whether it uses SB pipes or not.  It also means the only way to free your previous buffer is to call CFE_SB_ReceiveBuffer() again and get a new buffer.  So if the work is a long-running job it will "own" the buffer the entire time and prevent its re-use (and long-running jobs would likely be the reason for using a worker model in the first place)
Additional context
Found when reviewing race conditions in SB as part of #1073.  Supporting multiple threads reading the same pipe might be a nice to have but will have inherent race conditions with the current API design.  So to keep the API design as is for this cycle we will have to restrict this.
Requester Info
Joseph Hickey, Vantage Systems, Inc.

Related issue #216 - this is pretty much the same as the "longer term fix" above, looks like general use case for SB buffer refcount control was identified a long time ago.

Related issue #216 - this is pretty much the same as the "longer term fix" above, looks like general use case for SB buffer refcount control was identified a long time ago.

Started searching for where I saw the "worker" use case.. but I did find the restriction documented here:
https://github.com/nasa/cFE/blob/1ede295c3874e6571aca965a7850d950cf7aa1a3/docs/src/cfe_sb.dox#L100-L102

Started searching for where I saw the "worker" use case.. but I did find the restriction documented here:
https://github.com/nasa/cFE/blob/1ede295c3874e6571aca965a7850d950cf7aa1a3/docs/src/cfe_sb.dox#L100-L102


NV data mnt directory is missing with MT6768 SOC

Hello, it is mentioned in the paper that FIRMWIRE supports the simulation of MT6768,but the following errors will be encountered when running it:
[INFO] firmwire.vendor.mtk.loader: Parsing debug info...
[INFO] firmwire.vendor.mtk.loader: SoC <MediaTekSOC MT6768 - 2020/04/22> (automatic)
[INFO] firmwire.vendor.mtk.loader: Loaded MTK image with 19 sections
[INFO] firmwire.vendor.mtk.loader: Loading cached MTK debug database...
[INFO] firmwire.vendor.mtk.loader: Loaded database with 49507 trace entries
[ERROR] firmwire.vendor.mtk.loader: NV data mnt directory is missing
[ERROR] firmwire.loader: Loading failed!
[ERROR] firmwire.loader: No more loaders to try
[ERROR] firmwire: Failed to load firmware

Heya, even though you closed the issue:
You will need the nvdata extracted from a physical phone for proper operation. By default, FirmWire expects this to be located in /mnt, but you can override this with the --mtk-loader-nv_data CLI flag.

Thank you for your patient reply!


[1.18.2] Random Crash shortly after joining World (only with the enchantment module disabled)

After disabling the enchantment module in the config, it seems that after a short amount of time (~30 seconds?) after joining a world the game just crashes. The log seems to mention something about Apotheosis and a bit of Sophisticated Backpacks?
log: https://mclo.gs/4QKj4tg
Versions:
Minecraft 1.18.2
Forge 40.1.59
Apotheosis 1.18.2-5.3.6

Yeah it's currently broken, you can rollback to the previous version of placebo/apoth and it'll stop

Fixed in 5.4.0


Remove background mode

Thanks for the PR, after testing this I've put together https://github.com/ChunkyTofuStudios/native_geofence/commit/b0f66363293468eba4117075376076b37b04732d to remove this dependency. Appreciate your interest and contribution!


[r] Two-sided R pin for release-1.10 branch

Issue and/or context:
[sc-46600]
Changes:
Notes for Reviewer:
@mojaveazure I am following https://github.com/single-cell-data/TileDB-SOMA/wiki/Branches-and-releases#incrementing-core-versions
However, since that was updated we do have #2540 and #2546 on main; I'm not sure what's the right thing to do here on the release-1.10 branch, as I am going to create a release-1.11 branch today -- @mojaveazure let's work together on this.

If tiledbsoma 1.10 uses core 2.22/tiledb-r 0.26, then in addition to the following change we'll also need #2540 and #2546 backported to release-1.10
As shown previously, the doublepin does not affect installation or library loading, only R CMD check; as such, you need the two aforementioned PRs to get CI to install the correct version of tiledb-r


goofcord: 1.5.0 -> 1.6.0; build from source

Description of changes
Updated GoofCord to 1.5.1
Build from source :3
Technically, GoofCord relies on Electron 31, but that isn't packaged in nixpkgs yet (#325428), I'm 95% sure it's fine though, since GoofCord doesn't rely on anything introduced in Electron 31

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/4359

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/4384


Change the license to Apache 2.0

According to discussion in #105, we decided to change the license of all code to Apache 2.0.
Before that, the license was GPL with linking exception.
Apache license is widely used. It is permissive, free software license. It is easier to use in commercial projects. See wiki for more information.

@CANopenNode That's great, thank you. I think you may have missed the CANopen.h one location in CANopen.h (the doxygen intro text).

I changed the license of the files I own in this project (CANopenNode). Also updated README and forgotten CANopen.h.
I also plan to change to the Apache license in other two my projects CANopenPIC and CANopenSocket in next few days. If there are any pro or cons, please let me know.
In this project, there are some files (which I don't own) still with the old license:

Third-parity or old driver files: It is a plan to split those files from the main project. Author of specific driver is responsible for the license. See also #108.
CO_time.h/.c: @JuPrgn, you are the author. Can you change the license of your files to Apache? Or give me a permission? You also have to specify the copyright holder.
CO_LSS* and neuberger-socketCAN: @martinwag, will you please update your files.

@CANopenNode you have my permission please do as if this was a part of your stack/work. I did not know what to put in copyright I am not very familiar with this...

I've changed our part in 5ff34938597593ed5c17411b62a2ee65ed19ae4c

Reopened discussion?
I heared, that changing GPL like licenses requires consent of all contributors,
not only the current ones.


Broken Sample

https://microsoft.github.io/monaco-editor/playground.html#creating-the-editor-syntax-highlighting-for-html-elements

This is caused by us no longer knowing when a mode is finished loading. Needs further thinking...

Dup of #151


Update JavaScript grammar git submodule

See https://github.com/atom/language-javascript/issues/142#issuecomment-96462283

Grammars are updated with each new release ;)

Well, the Supportocat who responded to my bug report said to file a Linguist issue if a grammar submodule update was necessary.

No worries. It changed recently.
@arfon Any way we could prevent support that this has changed?

@arfon Any way we could prevent support that this has changed?

@pchaigno Thanks! I'll pass this info along to the other Supportocats :+1:


Signatures not getting sent with data by Beaker

Beaker isn't sending a signature with its proofs. I'm still isolating why. Here's what I've got so far:

Feed.prototype.proof() is calculating needsSig to be false. This causes Hypercore to avoid fetching the signature.
needsSig is false because TreeIndex.prototype.proof() is returning verifiedBy: 0
TreeIndex.prototype.proof() is returning verifiedBy: 0 because it reaches https://github.com/mafintosh/hypercore/blob/master/lib/tree-index.js#L67

I don't totally understand the logic of https://github.com/mafintosh/hypercore/blob/master/lib/tree-index.js#L53-L65 so I can't trace the cause further. I ran audit() on the metadata and content hypercores and got no invalid blocks.
There's a pretty good indication that this is affecting multiple people. Fritter went quiet!
LMK what else you need.

Should be fixed now


(TWILL-115) Added support for passing in Yarn scheduler queue name

Also refactor the internal ProcessLauncher class to simplify usage.

LGTM.
Just one comment about logging delegation tokens... that code was there before, so it is not strictly a comment about this patch. But please think about it, perhaps we should change that?

Merged to master.


Wrong sorting in the UI

Hi,
I have a problem with the depiction of my URIs in the UI. I want to sort them in Data and Auth but they are sorted in data_controller and auth_controller.

#[derive(OpenApi)]
#[openapi(
    paths(
        data_controller::get_user_data,
        data_controller::get_user,
        data_controller::get_all_statistics,
        data_controller::get_specific_statistics,
        auth_controller::signup,
    ),
    components(
        schemas(
            data_controller::Data,
            data_controller::ErrorResponse,
            auth_controller::UserData
        )
    ),
    tags(
        (name = "Data", description = "All endpoints to show the collected data."),
        (name = "Auth", description = "All endpoints for user and access management.")
    ),
    modifiers(&SecurityAddon)
)]
pub struct ApiDoc;

Do I have to fix the attributes which above the ApiDoc struct or the documentation attributes above my URI functions:
#[utoipa::path(
    context_path = "/dashboard",
    responses(
        (status = 200, description = "Endpoint to get all data from all devices for the dashboard.", body = Data)
    )
)]
#[get("/statistics/all")]
pub fn get_all_statistics() -> Json<Vec<String>> {
    let cache: RedisCache = RedisCache::default();
    let vec: Vec<String> = vec![cache.get_str("statistics").unwrap()];

    Json(vec)
}

I'm using rocket 0.5

I also run into this problems. I think the cause of the problem is that we use BTreeMap to store paths with path name (/auth/signup, /dashboard/stats/ ...) as a key.
BTreemap will always maintain order by keys hence when we iterate over it, it's in alphanumeric order or path name?

I don't have a specific order of the path names.

Same problem with axum

As @pongsakornsemsuwan said, I had to change the crate name to the keyword to get the correct sorting.

@EvilWatermelon
There is also coming a new feature in next release preserve_path_order that can be enabled if seen valuable. That will do the same for paths as the preserve_order does for ToSchema derived struct fields which is keeping the order same as they are being declared.
You can already use the feature if you use the master as the version in your Cargo.toml file.
Also to map your handler function correctly to the tag you must declare the tag on #[utoipa::path(...)] as well. The default tag will be the path to the registered handler e.g. data_controller as seen in the pictures above.
#[derive(OpenApi)]
#[openapi(
    paths(
        data_controller::get_user_data,
        data_controller::get_user,
        data_controller::get_all_statistics,
        data_controller::get_specific_statistics,
        auth_controller::signup,
    ),
    components(
        schemas(
            data_controller::Data,
            data_controller::ErrorResponse,
            auth_controller::UserData
        )
    ),
    tags(
        (name = "Data", description = "All endpoints to show the collected data."),
        (name = "Auth", description = "All endpoints for user and access management.")
    ),
    modifiers(&SecurityAddon)
)]
pub struct ApiDoc;

#[utoipa::path(
    context_path = "/dashboard",
    tag = "Data", // <-- ........ see here
    responses(
        (status = 200, description = "Endpoint to get all data from all devices for the dashboard.", body = Data)
    )
)]
#[get("/statistics/all")]
pub fn get_all_statistics() -> Json<Vec<String>> {
   // ...
}

Ok, thanks! I will wait for the new stable release.


docs: document Node.js' --enable-source-maps flag

Description of the Change
Newer versions of Node.js introduce the --enable-source-maps flag which, when enabled, caches source-maps and provides accurate stack traces to users running transpiled code, e.g., TypeScript.
Benefits
Many users of Node.js are writing TypeScript, this allows them to receive better stack traces in mocha without installing any dependencies.
Drawbacks
There's still work to be done to polish this feature in Node.js (would very much appreciate getting feedback).

Coverage increased (+0.07%) to 92.925% when pulling 184c16b10994fb3aa95aa2877f1919bec628ef3a on bcoe:note-about-source-maps into 883ae4b5e1aacd8cf30694da33b391ce58f4cca8 on mochajs:master.

@bcoe thank you for this PR.
We do not whitelist or document NodeJs options in our documentation. There are just a few exceptions like --inspect/--inspect-brk or --experimental-modules.
IMO we should not start doing this, it's abottomless task.
In our repo mocha-examples we offer some working samples incl. TS setups, maybe that's the place to recommend the  --enable-source-maps flag.

IMO we should not start doing this, it's a bottomless task.

I understand 100% where you're coming from.
Worth considering though, something like 60% of folks writing JavaScript these days spend at least some time writing TypeScript. Rather than just documenting this flag, it might be worth having a section of docs that speaks to making mocha work well with TypeScript:

speaking to which reporters work well with TypeScript (I believe some have source-map-support as a dependency?).
documenting the -enable-source-maps flag.
speaking to the source-map-support library.

I think this is worth adding.  I realize that documenting node flags is a slippery slope (as @juergba wrote, there's no end to it), but I think we should take it on a case-by-case basis.  It's plainly useful information, and I'd like to see more of this on the docs site.  That said, we should add to the examples repo.
@bcoe can you please resolve the conflict?

@boneskull 👍 will try to get this done ASAP.

@bcoe The build is failing because there's an incorrect anchor link.  Also, @outsideris had a request

@boneskull done 👍


Correlation IDs for query logging

There are different logging levels at which it make sense to log information about queries at different level of detail, e.g. Information would probably include information about the fact that a query is being executed, Verbose would include the SQL (in case it is relational) and Debug would include parameter values. If we duplicate the information, e.g we also include the SQL in the message for the Debug level, then a logger listening for Debug will get the duplicate information. On the other hand if we don't duplicate the information, chances are that the messages will end up logged out of order and it will become impossible to correlate them.
Rather than duplicating the information in the message sent at different levels we can create a correlation ID (which could be a unique identifier) which would uniquely identify all the messages produced for a particular query execution.

It appears that we should use scopes (e.g. ILogger.BeginScope()) for this purpose. We still need to discuss and investigate.

We are already using scopes in 1.0.0


offset x/y

I want an offset x , currently seems offset only applies vertically offsetting the tip.

+1


don't use exported spec file

in reality, this UI could be used with a graph which has custom nodes, so the spec file in the library will not cover them, we need to use the graphRegistry to generate the spec object (using writeNodeSpecsToJSON)

now uses getNodeSpecJson function with cache


README example shows incorrect model path and command line options after recent changes

The "Basic usage" section in the README contains several inconsistencies that were introduced when PR #137 was merged. Additionally, a related issue #138 has been identified regarding the command line argument handling.
The example in the README currently shows:
# Run inference with the quantized model
python run_inference.py -m models/Falcon3-7B-Instruct-1.58bit/ggml-model-i2_s.gguf -cnv "You are a helpful assistant"

# Output:
# Daniel went back to the the the garden. Mary travelled to the kitchen. Sandra journeyed to the kitchen. Sandra went to the hallway. John went to the bedroom. Mary went back to the garden. Where is Mary?
# Answer: Mary is in the garden.

This example has several problems:

The model path is incorrect. This appears to be caused by not distinguishing Instruct variants when the model was added to setup_env.py.

Current: models/Falcon3-7B-Instruct-1.58bit/ggml-model-i2_s.gguf
Actual: models/Falcon3-7B-1.58bit/ggml-model-i2_s.gguf

The command line option -cnv is incorrect and should be -p. However, this is pending the fix for issue #138.

The example prompt and output do not match:

Prompt: You are a helpful assistant
Output: Mary is in the garden.

Proposed Changes:
Update the example to correctly demonstrate the command that generates the shown output:
python run_inference.py -m models/Falcon3-7B-1.58bit/ggml-model-i2_s.gguf -p "Daniel went back to the the the garden. Mary travelled to the kitchen. Sandra journeyed to the kitchen. Sandra went to the hallway. John went to the bedroom. Mary went back to the garden. Where is Mary?\nAnswer:" -n 6 -temp 0

This update:

Uses the correct model path that matches what setup_env.py actually generates
Uses the proper command line option (-p)

Note that this command will not work correctly until issue #138 is resolved, as there are currently problems with the command line argument handling. Additionally, instead of modifying the model path in the README, it might be better to update setup_env.py to properly distinguish between Base and Instruct model variants.

Thanks for pointing this out! Should be fixed in https://github.com/microsoft/BitNet/pull/141.


CompositeBus not exist in W10 arm64 at drivers folder

Must be copied to DriverStore manually from W8.1

601198f73e9611d41df6e25a590692bb99f2afee fixed


Openvpn updates

Cherry-picks kubernetes/charts#5173, kubernetes/charts#5174, and kubernetes/charts#5404
[PLAT-711]

I'm not sure that we want this any longer.


Add progress messages when script is run in an IDE

The Create NG9-1-1 File Geodatabase script outputs tons of useful progress messages when run in an ArcGIS application. It does not output anything when run via a Python IDE.
Since the script is intended to run via either (i.e., it includes local_params for running in an IDE), it would be useful to print the same messages to console as are added to the Geoprocessing progress window. Otherwise, it just looks like it's hanging for 10 minutes until it returns.
Perhaps create a function that would do both arcpy.AddMessage/arcpy.AddWarning/arcpy.AddError and a print statement of the same message.
def addMsg(message):
    arcpy.AddMessage(message)
    print(message)
def addWarn(message):
    arcpy.AddWarning(message)
    print(message)
def addErr(message):
    arcpy.AddError(message)
    print(message)

This is is an enhancement request, not a bug report, but it would greatly improve the user experience (and make troubleshooting easier).

The Python script was initially developed to run solely through ArcGIS Toolbox and only recently changed to run from an IDE. Would you see any benefit to also creating a log file, in addition to the print()?
For example using logging like this:
def log(level, msg, logger):
	logger(level, msg)
	if level == 'WARN':
		arcpy.AddWarning(msg)
	elif level in ('ERROR', 'CRITICAL':
		arcpy.AddError(msg)
	else:
		arcpy.AddMessage(msg)

Yes, I think logging would be useful. I'd like to see the output in the console, not just a logfile. That way I could watch progress in the console AND have a log of the run as a file (if this is how you choose to implement it).

The Python logging module provides both logging to file and console.
The script is very chatty since our tests generally show it takes about 8-9 minutes to run through the entire script. We will definitely consider this as an enhancement to discuss with the Working Group.

Enhanced logging has been added including the creation of log files.


static const with in-class initializer should be converted to a constant rather than extern static

Currently, static consts in class are all converted to extern "C" pub static, however, when the static const has in-class initializer, we should be able to convert it to a constant like macro.
FWIW, C++ only allows static const which has integer type or enum type to have in-class initializer.

I think this makes #84 less urgent.

Currently the following code doesn't generate any extern "C" pub static:
class Foo {
  static const int I = 0;
};

And generates the proper constant. Probably with enums doesn't work though, if that's the case you're asking for. Do you have a test-case I can look when I arrive from class? Thanks! :)

Oh, interesting. This code does generate extern "C" pub static:
typedef unsigned int uint32_t;

struct A {
  static const uint32_t kA = 0;
};


Introduce enable password to eos_cli_config_gen Closes #202

Change Summary
New Template for domain-lists.  See Issues #202
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes)
[x] Documentation content changes
[ ] Other (please describe):

Related Issue(s)

#200
Component(s) name
ansible_collections/arista/avd/roles/eos_cli_config_gen/templates/documentation/enable_password.j2
ansible_collections/arista/avd/roles/eos_cli_config_gen/templates/eos/enable_password.j2
ansible_collections/arista/avd/roles/eos_cli_config_gen/templates/eos-intended-config.j2
ansible_collections/arista/avd/roles/eos_cli_config_gen/templates/eos-device-documentation.j2
ansible_collections/arista/avd/roles/eos_cli_config_gen/README.md
Proposed changes

Updated above components to expand data model and templates to handle domain-list.
How to test

leverage iterations of
enable_password:
  encryption: < md5 | sha512 >
  hash: "< hashed_password >"

Checklist:

[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[ ] I have updated molecule CI testing accordingly
[x] I have read the CONTRIBUTING document.
[x] All new and existing tests passed (pre-commit, make linting and make sanity-lint).

Hello @ryanmerolle
After discussion, in order to standardize the keys across AVD, we will use the key hash_algorithm every time it is needed to describe the encryption method.
We will also refactor codes not using this approach in the next versions.
So, please could you update templates to replace method by the key hash_algorithm and hash by key?
enable_password:
  hash_algorithm: < md5 | sha512 >
  key: "< hashed_password >"

Please note that we added a table of contents in the eos device documentation and reorganized the different documentation sections. Please add the new feature to the file eos-device-documentation.j2 as follows and reference your documentation in the right place in the file:
...
- [Authentication](#authentication)
  - [Enable Password](#enable-password)
  - [Local Users](#local-users)
...

## Enable Password

{% include 'documentation/enable_password.j2' %}
...

Closed as covered by PR#613

Closed as covered by PR#613


feat: configure the SDElement with enterpriseId

This feature supports to configure the Syslog SDElement with  enterpriseId and applicable further configuration
similar to jla_04

it listed on the jsa_0


Feature Request: Support nginx style rewrite rules via rds.RedirectAction

Currently, routes defined via RDS can have a RedirectAction that specify the host and path a matching Route will be redirected to. This works for the cases where one knows what the destination path is up front but not so much for the cases where prefix/suffix rewriting is needed. Nginx does this by allowing one to specify a matching regex on the original path and being able to reference capture groups in the destination:
rewrite ^/foo/(bar)/(.*)$ https://$server_name/$1/$2 permanent;

Ideally, envoy would able to support that kind of referencing but, in lieu of that, being able to at least refer to the original path in a RedirectAction.PathRedirect would help get us most of the way there. The same goes for protocol rewriting.
Context: https://envoyproxy.slack.com/archives/C78M4KW76/p1510966916000159

Hello @mattklein123, I can work on this issue. Made a sample implementation here : https://github.com/srikailash/envoy/commit/54745c23052032052e4386d05ac38074c08b6cf3 . Once we decide on what exactly is going to be the name in configuration(rds.proto) for the regex entries. I can change code accordingly and submit a working pull request. Let me know if that looks good.
Thanks in advance!

Thanks for the patch!  @mattklein123 is (mostly) out for the next few weeks so I'd encourage you to do best-effort naming and send out a PR for the data plane change, and your reviewer will help on naming support :-)

I think this is done.

The pull request was closed 6 days ago. What is the status of this feature?

Is this not possible yet?

The original PRs that would have implemented this were never merged. PR #8462 resurrects that implementation.

/assign @cmluciano

This would benefit us too!

I would live this feature. It would make envoy sidecars extremely usable.

We need this feature as well, since we are replacing nginx with envoy..any ETA on this?

The referenced issue didn't add this for redirects :(

I may have duplicated this issue in https://github.com/envoyproxy/envoy/issues/14348. The associated PR is merged.
If we feel like the above issue is in fact the same thing and the associated PR fixes it, we can close this out.


[Honeybadger] @project should not be nil within the TigerdataMailer Class

Please see the following for reference: https://app.honeybadger.io/projects/113559/faults/104748482#notice-trace
Ideally, @project, in the case that this is nil, should either raise a human readable-error, or, the error should be logged, and the response should be a redirect:
https://github.com/pulibrary/tiger-data-app/blob/main/app/mailers/tigerdata_mailer.rb#L7

Two possible approaches to this might be the following:
class TigerdataMailer < ApplicationMailer
  def project_creation
    config = Rails.application.config.tigerdata_mail[:project_creation]

    if !params.key?(:project)
      Rails.logger.warn("Failed to resolve the project using ID #{params[:project]} within #{self.class}")
      return
    end

    @project = params[:project]
    filebase = @project.metadata[:project_id].tr("/", "_")

Two possible approaches to this might be the following:

Hey team! Please add your planning poker estimate with Zenhub @hectorcorrea @JaymeeH @leefaisonr

Please add your planning poker estimate with Zenhub @jrgriffiniii


Increase duration from 3 to 6 digits to match ffmpeg

I noticed that ffmpeg uses 6 digits instead of 3 for the duration and wanted to match that.

Coverage remained the same at 75.365% when pulling 24ba41914c7e45deb4a72a07df10388ee0c87fc9 on fancybits:extend-extinf-to-6-digits into 036100c52a87e26c62be56df85450e9c703201a6 on grafov:master.

Coverage remained the same at 75.365% when pulling 24ba41914c7e45deb4a72a07df10388ee0c87fc9 on fancybits:extend-extinf-to-6-digits into 036100c52a87e26c62be56df85450e9c703201a6 on grafov:master.


remove sympy dependency, add basic unit tests

remove sympy dependency
add a vanilla unittest to be run with python3 -m unittest
readme example in test

@arcturusannamalai Thanks a lot for your contribution, I will review it soon.
Could you please add a reference to the isprime function in the docstring, please.
To better understand what are the limits and exceptions of such a few-lines function.
Thanks!

@danieleongari - this 'isprime' is a basic primality checker in a somewhat slow method; it works fine AFAIK - not sure if this basic code needs any kind of docstrings

Looks good to me.
Thanks a lot for your contibution!


Updating the saltstack version deployed by script/cmtool.bat from 2019.2.2 to the "latest"

Right now the saltstack version deployed by script/cmtool.bat is hardcoding version 2019.2.2 as the latest. This was being done because issue saltstack/salt-bootstrap#1394 shows that the developers had broken the "latest" parameter that gets passed to the installation script.  It seems that the issue is now just waiting for the OP to confirm that the changes actually fix things.
Once the fix is confirmed, we can then likely revert part of commit 14259e45ef604e27d374f79589e745f25a304238 so that "latest" will always correspond to the most recent version of saltstack. To deal with the unsupported ssl-based protocol issues in powershell on the w7 and w2k3 platforms, we can also consider adding KB3154518 to the list of scripts to install.

This is being worked on by PR #252. Linking it.


ngOninit to ngAfterContentChecked

Changed ngOninit to ngAfterContentChecked for already filled textareas.
Plus a package.json error fix.

Looks good, thank you.


feat: add event to disable selecting in group

Codecov Report
Attention: Patch coverage is 0% with 14 lines in your changes are missing coverage. Please review.

Project coverage is 7.48%. Comparing base (a080700) to head (9c7a97f).
Report is 107 commits behind head on main.

Files
Patch %
Lines

packages/core/src/middleware/selector/index.ts
0.00%
6 Missing and 1 partial :warning:

packages/core/src/middleware/selector/config.ts
0.00%
4 Missing :warning:

packages/idraw/src/idraw.ts
0.00%
2 Missing and 1 partial :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff            @@
##            main    #307      +/-   ##
========================================
- Coverage   7.49%   7.48%   -0.02%
========================================
  Files         92      92
  Lines       5869    5880      +11
  Branches    1113    1115       +2
========================================
  Hits         440     440
- Misses      4371    4380       +9
- Partials    1058    1060       +2

Flag
Coverage Δ

unittests
7.48% <0.00%> (-0.02%)
:arrow_down:

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

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


docker: command not found error on host server

I was watching the Introducing MRSK Youtube screencast, and one of the steps early on was to run mrsk deploy. But I was getting the following error:
$ mrsk deploy
Acquiring the deploy lock...
Log into image registry...
  INFO [347dbde0] Running docker login -u [REDACTED] -p [REDACTED] as jerome@localhost
  INFO [347dbde0] Finished in 1.225 seconds with exit status 0 (successful).
  INFO [63af6e8d] Running docker login -u [REDACTED] -p [REDACTED] on [REDACTED]
Releasing the deploy lock...
  Finished all in 2.5 seconds
  ERROR (SSHKit::Command::Failed): Exception while executing on host [REDACTED]: docker exit status: 127
docker stdout: Nothing written
docker stderr: bash: line 1: docker: command not found

It turned out that the video is out of sync with the current way of doing things. I should have followed the README instead, which mentions that you need to run the following command to install Docker on the server:
mrsk setup

This fixed the issue. Hopefully this writeup helps anyone who might have blindly followed the video like me.

Related issue: https://github.com/mrsked/mrsk/issues/301

Hello. I have to this issue even though I'm running kamal setup.
Basically, I added the second server and it seems that it isn't detecting that docker is installer in the first server, but not in the second.


Getting list of all groups and nested group memberships

I want to get all the groups my users are members of, not just the first-level groups. E.g. if I have a user "bob" who is a member of group "A". And group "A" is a member of group "B", then I want user "bob" to show both groups "A" and "B".
With the following settings I only get group "A" when looking up user "bob":
LDAP_BASE_DN="dc=myrealm,dc=com"
LDAP_REALM_NAME="MyFunRealm"
LDAP_OBJECTS_DN="dn"
LDAP_USER_OBJECT_FILTER="(&(objectclass=inetorgperson)(uid=%s))"
LDAP_GROUP_MEMBERS_FIELD="member"
LDAP_GROUP_OBJECT_FILTER="(&(objectclass=groupofnames)(member=%s))"
LDAP_GROUP_MEMBER_FILTER="member=%s"
LDAP_GROUP_MEMBER_FILTER_FIELD="cn"

Is it possible to get the group info I want by altering the settings or is this something that needs to be changed in the library?

Hello,
I don't think it's currently possible, but I am not 100% sure. If I understand the use-case correctly, it you'd like to get both group "A" and "B" when doing a get_user_groups() on user "bob"?

That is correct. So I want to get both direct and indirect group memberships. I couldn't find a way to query for this against my FreeIPA installation. I think there is some support for it in AD though.


Autofocus

it might be interesting to add the autofocus on the object that is at the center of the preview image, like doing the vendor app for camera. you know how to add this feature?

I search on the web and try to apply some solution i've read, but i'm not practice with Android Native and much more i don't know if i set the operation in right place.
My application didn't crash, but the auto-focus dosn't work.
Here a snippet of the code 've added to CameraPreview.java:
private boolean startCamera(final JSONArray args, CallbackContext callbackContext) {
        if(fragment != null){
	        return false;
        }
		fragment = new CameraActivity();
		fragment.setEventListener(this);

		/* ***** Setting Autofocus parametr ***** */
		Camera camera = fragment.getCamera();
		if (camera == null){
			return true;
		}
		Camera.Parameters params = camera.getParameters();
		if (params.getSupportedFocusModes().contains(Camera.Parameters.FOCUS_MODE_CONTINUOUS_PICTURE)) {
			params.setFocusMode(Camera.Parameters.FOCUS_MODE_CONTINUOUS_VIDEO);
		}
		fragment.setParameters(params);

		/* *****     ***** */
........


Column lookups on GroupBy with arbitrary Series in by

Is your feature request related to a problem? Please describe.
Trying to groupby a column and an arbitraty calculated value as follows, but feature not implemented.
df.groupby(by=['categorical',df.date.dt.month_name() ])['another_column'].mean()
'''
NotImplementedError: Column lookups on GroupBy with arbitrary Series in by is not yet supported.
'''

@alejandro-ponder thank you for reporting this! I see it's a duplicate of #3285.

Duplicate of #3285


Could you please add an example specific to seeding pattern?

Hi,
Could you please add some more documentation on how to ensure initial data is seeded in Cosmos with an example specific to it?
Thanks!

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

ID: 738deb7b-d752-f628-3860-fe53891cadb0
Version Independent ID: e0a18db9-d605-2a78-b77a-d22375dcfd4e
Content: Azure Cosmos DB Provider - EF Core
Content Source: entity-framework/core/providers/cosmos/index.md
Product: entity-framework
Technology: entity-framework-core
GitHub Login: @AndriySvyryd
Microsoft Alias: ansvyryd

@blueelvis What specifically is different about Cosmos from the other providers when it comes to seeding?

EF Team Triage: Closing this issue as the requested additional details have not been provided and we have been unable to reproduce it.
BTW this is a canned response and may have info or details that do not directly apply to this particular issue. While we'd like to spend the time to uniquely address every incoming issue, we get a lot traffic on the EF projects and that is not practical. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we use canned responses for common triage decisions.


[Select] Fix classes leaking on the DOM

closes #25893

[x] I have followed (at least) the PR section of the contributing guide.

Has the shouldForwardProp option performance implications? I personally find it more intuitive when reading the source to intercept the classes early. But not strong preferences as I believe we already use both patterns in the codebase.

Has the shouldForwardProp option performance implications?

Haven't measured, but I think that emotion by default implements it, so I don't think us adding more conditions changes much.

I personally find it more intuitive when reading the source to intercept the classes early. But not strong preferences as I believe we already use both patterns in the codebase.

I also don't have a strong preference either, we may change it anytime if we find out something is off with any of the approaches.


Generator class needed.

I need a Generator class for the entity class for Primary Id.

I have already developed it. I can do it.

Ok Sure.


I couldn't see the text on the SQL editor

Bug report :
I could see the text on the SQL editor when I changed the appearance to Dark Theme. Please see the image attached.

Could you try to restart DBeaver after changing the theme?

I did multiple times. I also,resetted perspective too.

I remember,having the same issue earlier. But,unfortunately I couldn't find the ticket to see the resolution mentioned on it.

I can't reproduce this. So I believe this is because of some workspace cache. Version 5.1.4 is based on new Eclipse platform which contains a lot of fixes/improvements and bugs by itself.
Could you try to reset workspace? https://github.com/dbeaver/dbeaver/wiki/Reset-workspace


Support for new distributions - April 2024

I mentioned this to @steelhead31 earlier as i hit an issue with this earlier today. There are some more distributions that we should look at adding to the ones that "just work" in the JFrog repos:

Debian trixie
Ubuntu 24.04 LTS noble
Fedora 40
If we can get these operational for the April PSU updates I think that would be very useful.

Reopening this because adoptium-ca-certificates is not available when attempting to install on trixie/noble - I expect it needs some redirects added to those paths on the JFrog artifactory instance:
oot@9d8ee135c1cb:/# apt install temurin-17-jre
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 temurin-17-jre : Depends: adoptium-ca-certificates but it is not installable
                  Recommends: fonts-dejavu-extra but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
root@9d8ee135c1cb:/#

Additional work is needed to update the CA-CERTIFICATES if adding debian/ubuntu distributions..
This PR has details, https://github.com/adoptium/installer/pull/868

Bug raised with jf-cli upstream as error encountered when trying to upload ca certs for multiple distros..
https://github.com/jfrog/jfrog-cli/issues/2532

The above PR has now been merged with appropriate fixes for the cli . Tested installation of JDK/JRE11,17 & 21 on both Noble & Trixie successfully.


Bug: Dependencie DSSP

Describe the bug
The link given for the installation of the dependencie of DSSP is outdated, and leads with multiple steps to an outdated version of DSSP.  Should/can this still be used or should the newer version of DSSP at https://github.com/pdb-redo/dssp be used?

The package has been tested with both DSSP 3 and DSSP 4 (although the continuous integration only runs on DSSP4). Depending on your system (ubuntu version), sudo apt install dssp will install one of these. It should work either way, but probably safest to install newest version of DSSP.
I will update the readme.

Good to know, just one more question about it. What to do if you don't have sudo priveledges, do you only need to install DSSP or also the requirements which are necessary for DSSP?

you need the requirements as well, otherwise dssp won't work


add option to use multiple defaults sections

If there is interest in this feature I will add documentation and spec tests. The patch add the option to use multiple defaults section, as described in the haproxy documentation:

A "defaults" section sets default parameters for all other sections following
its declaration. Those default parameters are reset by the next "defaults"
section. See below for the list of parameters which can be set in a "defaults"
section. The name is optional but its use is encouraged for better readability.

It's completely optional. Additionally if defaults are used, then the frontend and backend section are kept together in the haproxy configuration file if the frontend has the option default_backend or the frontend and backend are identical named. We are using multiple defaults and the improved ordering to improve the readability in our very long haproxy configuration files.

@vicinus This is a good start and extension of the haproxy module. And as far as I can tell, it maintains backwards compatibility as well. I'd be on board with moving forward with docs and tests.
/cc @hunner for 2nd opinion

I have added documentation, spec tests and acceptance tests. Please let me know if documentation or spec tests needs to be expanded further.
Also as far as I can tell, the failed checks are not caused due to my changes. One issue is that haproxy::params::merge_options is used as a default value in haproxy::instance without inheriting haproxy::params.

@bmjen Does this look good to you now? I managed to re-run the travis/docker build and got it passing.


Rename az acr build --no-push to az acr build --dry-run

Describe the bug
The argument --no-push causes the image is build within agent but is not accessible any way.
To Reproduce
Run any az acr build command with --no-push
Expected behavior
I'd expect the image won't be pushed into the registry but it will be accessible somehow, perhaps could be available for download for few minutes.
Environment summary
Azure CLI installed on Linux machine.
Additional context
This is not a bug per say but more a documentation issue.

route to service team

Shall I close the issue?


Improved Telescope mappings in normal and insert mode

I saw @Cretezy 's pull request and realized I made the same modifications in my own config, but with move_selection_next and move_selection_previous instead of cycle_history. So, this PR

In insert mode

Adds <C-j>/<C-k> to scroll in results list
Adds <C-n>/<C-p>  to scroll in preview

In normal mode

Adds q to quit

Made the same mod in my config, thanks for adding here!

Thank you @folke for accepting the PR. On the Telescope subject, in my config I also have nvim-telescope/telescope-file-browser.nvim setup in the following way
{
    "nvim-telescope/telescope-file-browser.nvim",
    dependencies = { "nvim-telescope/telescope.nvim" },
    config = function()
        require("telescope").load_extension "file_browser"
    end,
    keys = {
        { "<leader>fd", "<cmd>Telescope file_browser<cr>", desc = "File Browser (cwd)" },
    },
}

Would you be interested in having this merged too ?

I don't think it's all that useful, given that we already have neo-tree and Telescope find_files.

I agree. I just though it would be worth it asking.
Finally, I also have vim-slime setup to work with the Julia and Python REPLs with tmux. I think this is even less worth it merging, but I think others would like having this template to build their configs upon (there aren't that many examples on how to nicely work with REPLs and NeoVim).
Where do you think would be the ideal place to showcase it?

You can use https://github.com/LazyVim/LazyVim/discussions/categories/show-and-tell for that.

Hi! I just wanted to let you know that I changed the Telescope keybindings to make them more consistent with cmp / signature help and hover.
<c-f> and <c-b> should now be used for scrolling the preview. This is the same as used for the cmp doc window, signature help and for scrolling the hover window.
I've also removed the new <c-i> and <c-j> mappings since in other places we also use the default way of navigating a list with <c-n> and <c-p>. Again this is to make all mappings more consistent.
You can of course still override this in your own mappings if that's what you prefer.


⚡ Improve melos and workflow setup

Reduce separate workflows and matrices to the minimum.
Add a script to apply file patches for corresponding SDKs.
Add a script to produce MELOS_PACKAGES for bootstrap.
Add a script to produce ignored packages for exec.
Annotate test platforms for plugins.
Fix linter recognition between Dart SDK versions.

New Pull Request Checklist

[x] I have read the Documentation
[x] I have searched for a similar pull request in the project and found none
[x] I have updated this branch with the latest main branch to avoid conflicts (via merge from master or rebase)
[ ] I have added the required tests to prove the fix/feature I'm adding
[ ] I have updated the documentation (if necessary)
[x] I have run the tests without failures
[x] I have updated the CHANGELOG.md in the corresponding package

Additional context and info (if any)
Melos has poor support around versions and packages filtering. It has MELOS_PACKAGES and packageFilter for sessions, but those fields are not working well across its major versions.
The main idea about filtering our packages is to prevent unsatisfied packages from being handled by melos process. For example, if native_dio_adapter requires Flutter 3.13.0 and the current Flutter is 2.15.1, exclude it from packages.
To do this, I've added a script to serialize the melos workspace first, then determine whether the Dart version satisfies the package version. It produces package lists according to demand (satisfied packages or ignored packages).

native_dio_adapter has a different SDK requirement than others, so the min workflow fails. I didn't figure out a proper way to handle this with melos at the moment. Leaving this until I finish my exam. Any ideas are welcomed.

Melos. :)

See the edited top comment for more info.

Also cc @CaiJingLong to see if you have any idea regarding infrastructure abstraction abilities.

Personally, I don't like the combination of format/analyze/tests as this makes it harder to determine why the build failed, especially for new contributors.
Are there any CI limits reached regarding execution time or matrixes?

Personally, I don't like the combination of format/analyze/tests as this makes it harder to determine why the build failed, especially for new contributors.

Good point. If we break it into steps, would it be good enough too?

Are there any CI limits reached regarding execution time or matrixes?

As far as I know there are no limitations for public repos.

https://github.com/cfug/dio/actions/runs/6785748920/job/18444745192
Steps were split in the job. Now you're able to identify every verify step in a single workflow.
The core is time trade with speed. If we still use job strategies, it will cost massive redundant time since the workspace needs to be reconfigured each time a job starts. But it can display every action as a workflow.


Instantiate to bound errors for constructors issued prematurely.

The following code should be valid, because inference will fill in the type parameters to the Foo constructor call.  Instead an error is issued prematurely because Foo has no default bounds.
class Bar<T> {}

class Foo<T extends Bar<T>> {
  Foo(T y);
}

class Baz extends Bar<Baz> {}

void test() {
  Baz a;
  var x = new Foo(a);
}

This doesn't seem to reproduce, can we close?

Closing as obsolete. Please re-open if that's not the case.


CIV-14011 submit cya response

Before creating a pull request make sure that:

[ ] commit messages are meaningful and follow good commit message guidelines
[ ] README and other documentation has been updated / added (if needed)
[ ] tests have been updated / new tests has been added (if needed)

Please remove this line and everything above and fill the following sections:
JIRA link
https://tools.hmcts.net/jira/browse/CIV-14011
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

This may be blocked by: https://tools.hmcts.net/jira/browse/CIV-14720 as we need to change the model to allow multiple application concurrent response. Pls check


Handles constructor return types

Hello !
I need to get documentation about an interface constructor that returns a different type.
https://www.typescriptlang.org/docs/handbook/interfaces.html
interface ClockConstructor {
    new (hour: number, minute: number): ClockInterface;
}
interface ClockInterface {
    tick();
}

Currently, this typescript usage is not handle by Typedoc. Typedoc overrides the return type by the parent type.
Do not hesitate to comment if you need me to update something.
Great lib by the way !

Do we know why one of the tests times out in Node 6?

Converter access converts fixtures:

Error: Timeout of 4000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.

O_O No idea, I just merge master by converting var into const.

@aciccarello Legacy. It seems to happen randomly sometimes. Just restarted, we'll see if it passes this time.


Clarification: diagnostic ranges

VSCode supports a few diagnostic ranges that aren't documented in the LSP spec:

If a diagnostic's range has start and end position the same, then VSCode will squiggle the word at that position.
If a diagnostic's range has end position at character Number.MAX_VALUE, then VSCode will squiggle to the end of the line.

I think the LSP spec should call out these two cases, so that other clients implementing it will be sure to do the same.

Good catch.

Looks like this has caused 535165 in LSP4E.

I don't think it's necessary to specify anything here. It's fine to get each client dealing with it as they prefer, and the best thing when this occur is to report issues to the LS that produce such ranges to get something more explicit.

There are at least two clients now that don't deal nicely with these ranges. (intellij and codemirror)
Some language servers thus don't work nicely for all clients. (Admittedly, these servers don't follow the spec, but it should be reasonable to assume that the server is doing ok, when it works with some clients).
Would be nice if the spec got updated.

What VScode does is irrelevance to the protocol. I think the protocol should stay as is and any server doing any thing else declared nonconformist

If a diagnostic's range has start and end position the same, then VSCode will squiggle the word at that position.

I don't like the client interpreting special ranges in general, but this is especially weird. How does the client know the range of a "word"? I know the client might have something like a "word regex" defined, but this is an approximation at best. Isn't the whole point of the language server to understand the language, and handle things like knowing word boundaries, etc.

it should be reasonable to assume that the server is doing ok, when it works with some clients

I don't agree at all. As a client implementer, what choice do I have but to implement the specification. If VSCode is the "de facto" specification, then why have LSP at all? I mean sure, I get that there is a certain bias towards testing with that client for obvious reasons, but I think server authors should implement the specification and lobby for changes to the specification (or the client) where there is a deviation in the client implementation they test with.

I don't like the client interpreting special ranges in general

How would you show a range of length 0? If you underline or highlight something that has no length then the underline will have 0 length and that means you cannot see it.
I don't think the protocol should specify exactly how a client should visualize problem markers. These kinds of visuals depend on the specific client. To me vscode highlighting a word is a reasonable choice on how to visualize a 0 length range. It is better than drawing nothing at all (make it 'invisible'). Other choice could be to try and highlight the character before or after the range instead. Though it may still be hard to see.
Anyhoo... I think there is nothing wrong with leaving this sort of decision up to the client. I wouldn't mind seeing some words added to the spec to encourage/advise clients should try their best to show markers in some way that the user can actually see them, especial for cases where the range is of length 0.

How would you show a range of length 0?

However best works for my client.
But it seems you agree with me; this should not be specced by the LSP. How a client wants to show the declared lints is irrelevant to the communication between client and server. If the server really did mean the problem was with the nearest word, then it should have returned that range in the first place. Otherwise, it's just a matter of how the client displays zero width lints.
Sure, the spec should note zero width lints are possible. I also think it should discourage servers from using them unless absolutely necessary though.

But it seems you agree with me

Yes, I think so. I didn't think so at first as you seemed to be objecting to vscode deciding to extend the range of a zero-length range to a 'word'. But yes, I agree, this should not be specced. Clients should be free to decide what is the best way to visualize problem markers. And to me this includes choices like what vscode is doing to extend the range of a 0 length range. Other clients should be free to do the same... or not (and then they can find some other way to visualize a 0 length range instead).