Add support for dynamically attaching the allocation-tracker-agent.

Introduced an agentmain method and enabling retransform support for the agent allows to dynamically attach the allocation-tracker.
The following is an example for dynamically attaching a the agent locally.
The Application that produces some garbage: AllocationTrackerExample
package de.tutorials.training;

import java.lang.management.ManagementFactory;
import java.util.Date;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;

/**
 * @author Thomas Darimont
 */
public class AllocationTrackerExample {

    public static void main(String[] args) throws Exception {

        System.out.println(ManagementFactory.getRuntimeMXBean().getName());

        System.out.println("Started");

        Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(() -> new Grabage(), 1, 2, TimeUnit.SECONDS);
    }

    static class Grabage {
        Grabage() {
            System.out.println("Created new Garbage@" + new Date());
        }
    }
}

The AgentAttacher helper performs the dynamic attachment of the agent programmatically by using classes
from JDK tools.jar.
run with the following arguments:
$PATH_TO_AGENT_JAR% %PID_OF_ATTACH_TARGET% %PACKAGE_PREFIX%
e.g.:
"D:\development\java\repos\git\github\allocation-tracker\target\allocation-tracker-agent-0.0.1-SNAPSHOT.jar" 5012 de.tutorials.training

package de.tutorials.training;

import com.sun.tools.attach.VirtualMachine;

/**
 * @author Thomas Darimont
 */
public class AgentAtacher {

    public static void main(String[] args) {

        assert args.length == 3;

        String agentPath = args[0];
        String pid = args[1];
        String packages = args[2];

        try {
            VirtualMachine vm = VirtualMachine.attach(pid);
            vm.loadAgent(agentPath, packages);
            vm.detach();
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
}

Hello Thomas,
thank you for your interest and contribution! This is a really useful feature, and I would like to merge it with a few changes we should discuss:
a) The tools jar dependency will not work in jdk9. Not sure how to tackle it however.
b) with the addition of agentmain, it looks like it is work extracting and OO-fying the code a bit more. I dont really like that agentmain invokes premain. Also the check for the agent being loaded already looks like this should be a stateful object instance which is created by agentmain or premain and then configured.
c) the retransform logic duplicates the candidate checking from https://github.com/codecentric/allocation-tracker/blob/master/src/main/java/de/codecentric/performance/agent/allocation/AllocationTrackerClassFileTransformer.java#L36 - yes its only minor, but if one day someone would change how the naming works (like regex) this could get out of sync.
d) we should document how to do attach (using a jdk) in the readme.
what do you think?

Hi Fabian,
I'm glad you like it - I just stumbled upon your toy and gave it a quick spin :)
a) yes you're right but I don't think that this will be a problem for a while ;-)
Nevertheless one should have an eye on how others are going to tackle this problem, e.g.:
https://issues.jenkins-ci.org/browse/JENKINS-25993
b) Yes, I realized that too - I didn't want to mess around with the code to much in the first place - to reduce the example to the bare minimum. I can give it another round of oo-love :)
c) see b) :)
d) Yep - the plan was actually to add the attaching capability to the allocation-tracker.jar itself so that people could just attach the agent with the agent...
Cheers,
Thomas

ad a) I don't know whether it will always stay that way but as I found out here: https://gist.github.com/thomasdarimont/dbb6796505eeaa692c91
the stuff that was in the tools.jar is available from within jrunscript. So it might be worthwhile so check how those classes are provided in that environment.

i have 9 running on my mac. I will try to come up with a maven config which includes the attach dependencies for you.
I am fine with making the change bigger to make it more OO. i prefer that over a refactoring step afterwards.
Attaching itself would be a fancy feature :) I once considered making the whole control controlled by attaching, rather than by jmx.

@thomasdarimont I created #16 - does that work for you? then I will merge it.


Fix bug in limiting rendered suggestions (#189)

As the title says: fixes the bug reported in #189 where the more suggestions there are to render, the less will be rendered, due to faulty render limit logic

"Switch to this package, that other one is dead"

I have the same issue.
I have solved by just increasing the limit to 100.
Then on server side I limit the result to 10, by paying attention to not set more than 100.
I think that should not be show all results if database has many data.
Am I missing something?

I believe this same bug was fixed a long time ago in #52

As noted in #189, this bug was fixed several years ago. Please be sure you're using the latest release of corejs-typeahead from https://www.npmjs.com/package/corejs-typeahead (and not the official Twitter version, which still contains this bug).

Apparently the bug wasn't fixed properly with #52.
See where I forked off of for this PR: the master of this repo
So please reopen and consider this PR for merging


Fixed unit tests to work with Chrome browser

Hi n3-charts team,
Here is a PR that fixes the unit tests to also work in Chrome.
Best,
Christoph

Wow this looks great, thanks fro your contribution !

Hmm the tests were passing on my Linux (FF 38), apparently Travis runs FF 30. I will have to check this again.

This can be updated in the travis.yml file.

Fixes #158

:poultry_leg:

Also here, #158 was not closed automatically - I think I should have referenced the issues in the first comment. sorry for that


New version: TransformVariables v0.3.4

Registering package: TransformVariables
Repository: https://github.com/tpapp/TransformVariables.jl
Created by: @tpapp
Version: v0.3.4
Commit: cb3b8f07c04f00dc024b23bacad2f72844e487e6
Reviewed by: @tpapp
Reference: https://github.com/tpapp/TransformVariables.jl/commit/cb3b8f07c04f00dc024b23bacad2f72844e487e6#commitcomment-34549681
Release notes:

minor bugfix: make inverse(::ArrayTransform, ...) accept AbstractArray

Is there anything else I need to do to get this merged?


IRQ not working

The Micropython implementation isn't firing interrupts on pins. Writing C code directly in a micropython function to register handlers also doesn't work. The same code in a non-upy environment does work, so something about the build or setup is breaking interrupts.

@MatthewWilkes am I missing something, or does our version of esp-idf not have the fix from the issue you linked?

I thought it did? Thought it was merged into 4.4 a few months before release. The issue linked is about interrupts on the 2nd core anyway, and we are using core 1. I only linked to it as a source of small interrupt testing code.

Hmm.... there is a tag called v4.4 which points to 8153bfe4125e6a608abccf1561fd10285016c90a which seems to be what we're using and doesn't include the fix, but there's a branch called release/v4.4 which is more recent and does. I'll try rebuilding against release/v4.4 and see what happens. (Aside, quite how git clone --branch v4.4 selected a tag not a branch I won't even attempt to figure out...)

Resolved by #24


Should we get the orchestrator log output in the Unity log for the session creator?

@troeggla assigning this to you for initial feedback.
I'm thinking that it would be a good idea to get the orchestrator log output into the Unity log, for at least one of the users. The best candidate is probably the session creator.
The implementation would be rather simple: there would be a completely independent thread in VR2Gather that would use the orchestrator log-reading interface, and it would simply dump anything it gets into the Unity log. So, it would contain all orchestrator log messages, including those for other sessions and so. Especially those, I might say, because they could pinpoint obscure problems where different sessions somehow influence each other.
First question: is this feasible from the orchestrator side? Can there be multiple readers of the log?
Second question: what is the orchestrator API for reading the log files? Is it simple streamed HTTP or is it socketIO?

Yes, there can be any number of readers of the log. It is implemented as a Socket.IO endpoint named log under the namespace /log, that will fan out anything dumped into it to all listeners


Add/Edit BGP Session: don't see Peer group names

NetBox version
3.6.3
Describe the bug
In form to add/edit BGP Session I don't see "peer group names"
To Reproduce
Steps to reproduce the behavior:

Create PEER GROUP (BGP - Peer Groups)
Create BGP Session (BGP - Sessions)
Scroll down to 'Peer Group'
See error

Expected behavior
View Peer groups names
Screenshots

Same problem is in BGP Sessions filters

This seems to be caused by the missing 'display' value in the NestedBGPPeerGroupSerializer class here

We are seeing the same thing.

@k01ek Can you take a look at this pull request?

Fixed


Improve xargs command

wait for CommandChild to finish so we can return
CommandResult
This is more useful for the user, since it has things like .stdout .stderr that returns the result as a string
also add a test to make sure this actually works
In theory xargs should really chain like the other methods so we can use .xargs.pipe.xargs, hopefully we can figure this out

I actually found how to make xargs chainable and more flexible, but the problem is its not 100 % user firendly because CommandBuilder extends Promise so if the type is Promise<CommandBuilder> like xargs return type, await will unwrap both the inner and the exteroir promise making it not chainable
The workaround is to introduce an inbetween type so CommandBuilder doesn't get awaited
please take a look at https://github.com/impactaky/dax_extras/compare/main...sigmaSd:dax_extras:xargs3?expand=1
I guess if we can make xargs sync somehow that would make all these problems go away

@sigmaSd And, Can I invite you to be a collaborator in this repository?
To be honest, I only learned typescript for dax, not for my work, and I don't understand it very well.
So it would be nice to have someone who is familiar with typescript as a REVIEWER!

@impactaky thanks a lot for the invite, but I prefer we keep things as is, I'll watch the repo, so I can help as much as I can
To be honest I already see from your code that my typescript foo is not far from yours xD

can we close this in favor of https://github.com/impactaky/dax_extras/compare/main...sigmaSd:dax_extras:xargs3?expand=1 I think if I give better names like {result: CommandBuilder} its not that bad
also its nice that it returns a CommandBuilder

I updated the branch https://github.com/impactaky/dax_extras/compare/main...sigmaSd:dax_extras:xargs3?expand=1 and I think it looks reasonable
we can accept xargs being weird to chain a bit but its chain-able!

I completely understand your position and it's encouraging to hear that you'll be watching the repository, thank you!
Can I merge this one first?
Since the child process will not start until spawned, there is a concern that
performance will be degraded if upstream streams are intermittent.

sure we can continue the discussion on another pr

please use squash and merge, since I'm used to use nonsense commits

oh I guess on this PR the commit msgs looks reasonable

I like squash merge, so I'll squash merge (I forgot to set it to default)


Render long code in multiple grids

For long source code with many page breaks, the alignment of line numbers can sometimes drift off and no longer match the code lines.
Right now, #sourcecode creates a grid with multiple columns.
To solve the issue, long code blocks could be split into multiple grids, to allow the alignment of line numbers to "reset" and prevent drift.
Problem with this approach:

W don't know where to split the raw code without affecting syntax highlighting and access to the highlighted code is not possible (right now).

A solution could be to use the previous approach used in v0.0.5 to set the complete code in every grid, but to clip it to show only the appropriate lines.

With Typst 0.0.9 this should not be necessary any longer.


feat(tier4_geo_pose_projector): use tier4_geo_pose_projector in eagleye

Description
Since current Eagleye implementation does not align with the /map/map_projector_info, I would like to propose the following modification

Adding a new package tier4_geo_pose_projector that, given a georeferenced pose and the projector info, converts and publishes the pose
Use this in Eagleye instead of geo_pose_converter from Eagleye repository

Note that the new package will be added to autoware.universe instead of Eagleye repository, since it is dependent on Autoware's component interface and may be used to other applications as well.

Tests performed

Confirmed that, using logging_simulator, eagleye works with sample map from shinjuku AWSIM data
Confirmed that, using logging_simulator and the following map_projector_info.yaml, eagleye works with sample map from shinjuku AWSIM data

projector_type: TransverseMercator
vertical_datum: WGS84
map_origin:
  latitude: 35.61836750154
  longitude:<PHONE_NUMBER>8243
  altitude: 2.0

Effects on system behavior

Not applicable.
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

@kminoda I think that this PR would resolve this issue? Is that correct?

Tests performed

Confirmed that, using logging_simulator, eagleye works with sample map from shinjuku AWSIM data
Confirmed that, using logging_simulator and the following map_projector_info.yaml, eagleye works with sample map from shinjuku AWSIM data

I have confirmed them in my environment. They works properly.


Possible to do a diskbacked version of this cache?

Possible to do a diskbacked version of this cache?
Ability to set maximum disk limit to use with the same concept

basically the disk backed version is about using ssd as the cache.

While this is technically possible, this is out of scope for the fastcache. I'd recommend forking it and adding support for disk-based cache on top of mmap'ed files.


fix: add CANCELLED back to the auto-retry codes for pull subscriptions, for now

Temporarily fixes: https://github.com/googleapis/nodejs-pubsub/issues/979
We're still not sure what's causing these call cancelled errors, but that is being worked on separately right now. This is to get everyone back up and running for now.

My stricter testing updates from an earlier PR are making the tests flaky. I'm just going to remove the per-test cleanup in that file for now.


React async compatible Masonry

Part of #216 followed the state mirroring paradigm talked about here https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html#updating-state-based-on-props
Did some testing on both the docs pages and the Masonry playground and both seem to work as expected.

Deploy preview for gestalt ready!

The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #228   +/-   ##
=======================================
  Coverage   61.52%   61.52%
=======================================
  Files          40       40
  Lines         798      798
  Branches      186      186
=======================================
  Hits          491      491
  Misses        217      217
  Partials       90       90

Continue to review full report at Codecov.

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


bump image versions used in trillian chart.

Description of the change

curl: 7.81.0 -> 7.83.1
netcat: 2022-01-23 -> 2022-05-23
db_server: 1.4.0 -> 1.4.1
trillian_log_server: 646d069f3cb996b6c0e66223404ddecf08822823 -> rekor v0.7.0
trillian_log_signer: 646d069f3cb996b6c0e66223404ddecf08822823 -> rekor v0.7.0

Existing or Associated Issue(s)

Additional Information

Checklist

[x] Chart version bumped in Chart.yaml according to semver. Where applicable, update and bump the versions in any associated umbrella chart
[ ] Variables are documented in the values.yaml and added to the README.md. THe helm-docs utility can be used to generate the necessary content. Use helm-docs --dry-run to preview the content
[ ] JSON Schema generated
[x] List tests pass for Chart using the Chart Testing tool and the ct lint command

@k4leung4 i will rebase, if you dont mind :)


Refine hibernate-orm database dialect hints.

What does this PR do?
Provide additional reflection hints for invoking org.hibernate.dialect.*Dialect constructors.
Also make sure to tie hints for a specific dialect to the presence of the related database driver.
Checklist before merging

[x] I have properly formatted metadata files (see CONTRIBUTING document)
[x] I have added thorough tests. (see this)

Closes: #91

Looks good to me, thanks @christophstrobl !


Export

WORK IN PROGRESS
This PR is not finished and only contains the initial work for the parser. It is intended to start the discussion on the export keyword.
It builds upon the decorators PR.

export will be implemented with help of the include statement and probably some attributes.
For example:
export type t = {myRecordField: int};
let x = 10;

will be parsed as
  include ({
      type t = {myRecordField: int};
      let x = 10;
    } : {
      type t = {myRecordField: int};
    });


configure replication,but delete a image on web, not sync to the other harbor node

I have been configured  the two harbor replication, test push image,
the image can be replicated each other.
But I delete a image on hadoop1.com web, not sync to the hadoop2.com.
The delete job log:
2017-05-05T09:09:24Z [INFO] initialization completed: repository: testproject/hello-world, tags: [latest], destination URL: https://hadoop1.com, insecure: true, destination user: admin
2017-05-05T09:09:24Z [WARNING] repository testproject/hello-world does not exist on https://hadoop1.com

[root@hadoop2 harbor]# docker pull hadoop36.jiuye/testproject/hello-world
Using default tag: latest
latest: Pulling from testproject/hello-world
983bfa07a342: Pull complete
Digest: sha256:2075ac87b043415d35bb6351b4a59df19b8ad154e578f7048335feeb02d0f759
Status: Downloaded newer image for hadoop36.jiuye/testproject/hello-world:latest
[root@hadoop2 harbor]# docker images
REPOSITORY                               TAG                 IMAGE ID            CREATED             SIZE
vmware/harbor-jobservice                 v1.1.1-rc2          ff9f04244dfb        6 days ago          163 MB
vmware/harbor-ui                         v1.1.1-rc2          3966a39f9cc6        6 days ago          183 MB
vmware/harbor-adminserver                v1.1.1-rc2          fabdeab472a3        6 days ago          142 MB
vmware/harbor-db                         v1.1.1-rc2          ca166fa6033c        6 days ago          329 MB
vmware/harbor-notary-db                  mariadb-10.1.10     64ed814665c6        4 weeks ago         324 MB
vmware/nginx                             1.11.5-patched      8ddadb143133        4 weeks ago         199 MB
vmware/notary-photon                     signer-0.5.0        b1eda7d10640        5 weeks ago         156 MB
vmware/registry                          photon-2.6.0        6cb4438d7197        6 weeks ago         146 MB
vmware/notary-photon                     server-0.5.0        6e2646682e3c        6 weeks ago         157 MB
vmware/harbor-log                        v1.1.1-rc2          9c46a7b5e517        2 months ago        192 MB
hadoop2.com/testproject/hello-world   latest              48b5124b2768        3 months ago        1.84 kB
photon                                   1.0                 e6e4e4a2ba1b        10 months ago       128 MB
[root@hadoop2 harbor]#
on hadoop2.com machine, I use docker pull from hadoop2.com/testproject/hello-world , is successful.
So hadoop2.com have exist the testproject/hello-world image.

Thanks for reporting, will provide a fix.

Fixed by #2240 .


Hugo does not fully mount multiple modules

Observation
Hugo mounts static dir for 1 module (e.g. wowchemy module) automatically.
However, when 2 modules have a static dir to mount, Hugo only mounts the static dir of one of the modules.
Possibly a Hugo bug. Hugo site doesn't yet appear to have any docs on this behaviour, so it's unclear if it's intended.
Tested with Hugo v0.78.1
Issue
This causes an issue when loading both the Wowchemy and Netlify CMS modules as Hugo only currently mounts the static dir of one of these modules, leading to sites with missing files (such as for the speaker note capability for slides).
See https://discord.com/channels/722225264733716590/742863504515793149/773908988726476810
Solution
By explicitly defining the static mount for each module, the issue appears resolved.

@gcushen Hello! I'm having the exact same problem you are describing above and can't find any solution.
I'm trying to pull in two modules that have content in similar folders (content/install), and Hugo only mounts the content/install of one of module.
When you say that you "explicitly define the static mount for each module", what do you mean exactly?
Thanks!


Error when FreeParameters are named QASM types

Describe the bug
When a user defined a FreeParameter("str") where the "str"  is a OpenQASM keyword. For example, it fails for b, q, bit, qubit, input, OPENQASM, 3.0. 1,2.
To reproduce
from braket.circuits import Circuit, FreeParameter
from braket.devices import LocalSimulator

b = FreeParameter("b")

circ = Circuit().rx(0,b)
print(circ)

device = LocalSimulator()

task = device.run(circ, shots=1_000, inputs={"b": 0})
task.result().measurement_counts

gives the error
    221     return builtin_constants[node.name]
    222 if not self.context.is_initialized(node.name):
--> 223     raise NameError(f"Identifier '{node.name}' is not initialized.")
    224 return self.context.get_value_by_identifier(node)

NameError: Identifier 'b' is not initialized.

Expected behavior
Expected the circuit to run correctly. For example, using FreeParameter("a") works correctly.

For context, here is the OpenQASM generated when an input is named b
OPENQASM 3.0;
input float b;
bit[1] b;
qubit[1] q;
rx(b) q[0];
b[0] = measure q[0];

b and q are used as variable names by the Braket SDK and will cause a collision if customers create parameters with the same names. To mitigate this, we will update these automatically created variables to __bits__ and __qubits__.
The other variable names listed conflict with OpenQASM naming standards and we will update documentation to reflect this.

I don't see on #701 the reason for reverting. Anyone know what the issue was?

I don't see on #701 the reason for reverting. Anyone know what the issue was?

I believe there was an issue with a particular OpenQASM parser not properly handling variable names beginning with __, which essentially caused it to be a breaking change when using that parser.

Any progress on this issue? @kshitijc

Hi @rmshaffer and @mbeach-aws,
I came up with two solutions, please let me know which I should proceed with.
Solution 1

We always prefix FreeParameter, e.g., FreeParameter("b") => fp_b.
If we use this, we can skip the validation of using OpenQASM language-reserved keywords as there would be no collision.
Here, users will have more flexibility in providing the name.

Solution 2

As done in #675, we can use different names for q and b:

q => sdk_total_qubits
b => sdk_total_bits

Here, we would need to document not to use OpenQASM language-reserved keywords and the above two mentioned variable names to avoid collisions.
Here, users would have less flexibility in providing the name.

@rmshaffer, is it guaranteed that SDK would only have predefined variables b or q ?
If we introduce some new predefined variable, there is a potential chance we might break existing user code if they already use the same variable.
If we prefix all the user defined variables, then there won't be collision, but we have to ensure we are not using the prefix while generating SDK predefined variables.

I don't believe there would be any reason for the SDK to introduce new predefined variables beyond b and q. If so, this would need to be accounted for at that time, but I think that is beyond the scope of this issue.

@rmshaffer , I will go with the solution where we are prefixing predefined variables and OpenQASM reserved words

Hi @rmshaffer,
I decided to output useful error messages instead of prefixing inputs because when specifying inputs in device.run, I would also need to append the prefix.
I made a list of reserved keywords from the OpenQASM grammar. I only included words like float, angle, etc., and ignored symbols like =, ;, etc., as users are more likely to enter words.
Currently, I expect the following code snippet to pass, but it unexpectedly breaks for four reserved keywords: dim, cal, void, and readonly.
QASM_RESERVED_WORDS = [
    "OPENQASM", "include", "defcalgrammar", "def", "cal", "defcal", "gate", "extern",
    "box", "let", "break", "continue", "if", "else", "end", "return", "for", "while",
    "in", "pragma", "input", "output", "const", "readonly", "mutable", "qreg", "qubit",
    "creg", "bool", "bit", "int", "uint", "float", "angle", "complex", "array", "void",
    "duration", "stretch", "gphase", "inv", "pow", "ctrl", "negctrl", "dim", "durationof",
    "delay", "reset", "measure", "barrier", "true", "false"
]

@pytest.mark.parametrize("param", QASM_RESERVED_WORDS)
def test_bug(param):
    from braket.circuits import Circuit, FreeParameter
    from braket.devices import LocalSimulator

    b = FreeParameter(param)
    circ = Circuit().rx(0, b)
    print(circ)

    with pytest.raises(Exception):
        device = LocalSimulator()
        task = device.run(circ, shots=1_000, inputs={param: 0})
        task.result().measurement_counts

Could you please help me understand why this is happening?

Hi @Tarun-Kumar07 - could you please open a draft PR with your code so that we could more easily review your changes?
I don't know what would cause those four keywords to be different than the others. When you say "it unexpectedly breaks", what does that mean? Do you get an error message of some kind? Once you open a PR, if you could please comment in the PR with those details, that would be the easiest way for us to help you out.
Thank you for your investigation into this issue!

Hi @rmshaffer,
I've submitted PR #999 to address the issue. I would appreciate your feedback.

Hi, can this issue be assigned to me after merging #999.
Thanks !!

@Tarun-Kumar07 PR #999 has been merged. Thank you for your contribution!


Use vertex input mask for creating vertex arrays

Fixes: https://github.com/godotengine/godot/issues/85053
The issue is that the calculation of skeletons became super slow after https://github.com/godotengine/godot/pull/81138. The root cause was how we cache and retrieve vertex array objects. Prior to https://github.com/godotengine/godot/pull/81138 we created a special vertex array object for skeletons which only ever contained vertices, normals, and tangents. After https://github.com/godotengine/godot/pull/81138 we used the regular mesh caching approach so we could automatically get the correct vertex array object.
However, the caching approach was subtly broken. It always returned a vertex array object with all available attributes enabled. That means, if the mesh has colors, UVs, etc. The VAO would also contain them. For skeletons, this created a huge amount of unnecessary overhead as only positions, normals, and tangents (at most) are needed.
Once I added the code to take the vertex input mask into account. I noticed it was broken as the indices were off by one.
This PR fixes the performance regression in https://github.com/godotengine/godot/issues/85053 and might also increase performance in other cases as well.
This PR is slightly too risky for RCs, so let's plan on merging for 4.3 and cherry picking to 4.2.1

I can confirm this fixes #85053.

Thanks!

Cherry-picked for 4.2.1.


Documentation on using toolchains_llvm with bzlmod

Would it be possible to add documentation to the README on how to use toolchains_llvm in a project that uses bzlmod for external dependencies? After doing some digging, the only possible documentation on this that I found is in this file: https://github.com/bazel-contrib/toolchains_llvm/blob/756b3dbe9582503e0f671188a5aa4dec3b9710bf/.github/workflows/release_notes_template.txt#L3-L26

Just realized that the release notes have this information.


[FR] Improve update sentences matching

Remove optional from bs_update_states because I suspect it can conflict with other intents and it's not really needed but state: on is hardcoded for some intents.

Summary by CodeRabbit

New Features

Enhanced French language error messages for device and entity recognition, providing clearer feedback.
Updated sentence structures for querying the availability of updates in binary sensors, improving user interaction.

Bug Fixes

Refined error handling for device classes and timer functionalities to improve user understanding.

Chores

Simplified input pattern for update availability in the configuration.

@piitaya
Or ..... Hear me out .... 😂
We simply remove these sentences...
Checking how many updates are per area ?! Who does that via voice?


add a page that shows all flags

@hamelsmu
Just added a page that shows all flags.
I was looking for this in the docs and couldn't find it. Then I notices an open issue for this.
This fixes #296
I hope I didn't miss any flags as I collected those from the scattered pieces in the docs.
Let me know if this needs any improvements

not sue what I missed here. is it the filename of the notebook?

Thanks for the corrections Hamel. All comments are addressed.

Next step is to get Jeremy to review.  @jph00 would you mind taking a look?

I see.
I'll go with "nbdev comments" then as just "comments" might be misleading.
I want to point out that the "flag" term was mistakenly used in a dozen of places to refer to comments used for things other than tests.
Here are few examples:

Remove in cells the ones with a flag #hide, #default_exp, #default_cls_lvl or #exporti (link)
for flag in ['#export', '#exports']: (link)
This concerns all the cells with #export or #hide_input flags (link)
Remove all flags from code cells (link)
Flags: nbdev uses special comments, or flags, as a markup language that allows (link)

It might worth opening an issue to unify the terminology across the library and remove confusion (for people like me😅).
Thank you @jph00 for your feedback

Thanks for noting this. If we keep using this approach in v2, then yes we should pick a name and stick to it!

Oops nevermind!

The word "flags" is only used in nbdev to refer to the comments use for optionally running tests.

I think you left that language in there on purpose!  Sorry for the confusion!

Oops nevermind!

The word "flags" is only used in nbdev to refer to the comments use for optionally running tests.

I think you left that language in there on purpose!  Sorry for the confusion!


MCP2515 bandwidth issues at 500K and 1Mbps -> SPI command optimizations

I made a few optimizations to improve the performance of the interface for the MCP2515. There are a couple of commands to reduce the overhead of the SPI to increase the data throughput to and from the MCP2515; LOAD RX BUFFER, RTS, and READ RX BUFFER. I added it endPacket() even though it doesn't matter as much since it waits for the packet to complete sending before returning (there is still an improvement), the improvement in parsePacket() is nice.
int MCP2515Class::parsePacket()
{
  int n;

  uint8_t intf = readRegister(REG_CANINTF);

  if (intf & FLAG_RXnIF(0))
  {
    n = 0;
  }
  else if (intf & FLAG_RXnIF(1))
  {
    n = 1;
  }
  else
  {
    _rxId = -1;
    _rxRtr = false;
    _rxLength = 0;
    return 0;
  }
  uint8_t SIDH = readRegister(REG_RXBnSIDH(n));
  uint8_t SIDL = readRegister(REG_RXBnSIDL(n));
  uint32_t idA = ((SIDH << 3) & 0x07f8) | ((SIDL >> 5) & 0x07);
  _rxId = idA;
  _rxRtr = (SIDL & FLAG_SRR) ? true : false;

  _rxDlc = readRegister(REG_RXBnDLC(n)) & 0x0f;
  _rxIndex = 0;

  if (_rxRtr)
  {
    _rxLength = 0;
  }
  else
  {
    _rxLength = _rxDlc;

    SPI.beginTransaction(_spiSettings);
    digitalWrite(_csPin, LOW);
    SPI.transfer(0b10010010 | (n << 2));        //Set to stream RX data from Buffer n
    for (uint8_t x = 0; x < _rxLength; x++)
      _rxData[x] = SPI.transfer(0x00);          //Stream data form RX buffer
    digitalWrite(_csPin, HIGH);                 //unsetting CS pin will reset IRQ flag
    SPI.endTransaction();
  }

  return _rxRtr ? true : _rxDlc;
}

int MCP2515Class::endPacket()
{
  if (!CANControllerClass::endPacket())
  {
    return 0;
  }

  int n = 0;

  writeRegister(REG_TXBnSIDH(n), _txId >> 3);
  writeRegister(REG_TXBnSIDL(n), _txId << 5);
  writeRegister(REG_TXBnEID8(n), 0x00);
  writeRegister(REG_TXBnEID0(n), 0x00);

  if (_txRtr)
  {
    writeRegister(REG_TXBnDLC(n), 0x40 | _txLength);
  }
  else
  {
    writeRegister(REG_TXBnDLC(n), _txLength);    //set packet length

    SPI.beginTransaction(_spiSettings);
    digitalWrite(_csPin, LOW);
    SPI.transfer(0b01000000 | (n * 2 + 1));      //set TX buffer for stream
    for (uint8_t x = 0; x < _txLength; x++)
      SPI.transfer(_txData[x]);                  //stream data to buffer
    digitalWrite(_csPin, HIGH);
    SPI.endTransaction();
  }

  SPI.beginTransaction(_spiSettings);
  digitalWrite(_csPin, LOW);
  SPI.transfer(0b10000000 | (1 << n));          //set RTS for TX Buffer n
  digitalWrite(_csPin, HIGH);
  SPI.endTransaction();

  bool aborted = false;

  while (readRegister(REG_TXBnCTRL(n)) & 0x08)
  {
    if (readRegister(REG_TXBnCTRL(n)) & 0x10)
    {
      // abort
      aborted = true;

      modifyRegister(REG_CANCTRL, 0x10, 0x10);
    }

    yield();
  }

  if (aborted) {
    // clear abort command
    modifyRegister(REG_CANCTRL, 0x10, 0x00);
  }

  modifyRegister(REG_CANINTF, FLAG_TXnIF(n), 0x00);

  return (readRegister(REG_TXBnCTRL(n)) & 0x70) ? 0 : 1;
}

Could you explain your optimizations? Possibly a Pull Request would help incorporating your changes.

Thanks for filing this!
Once I realized there is room for improvement, I've decided to take a closer look at the datasheet and this is what I came up with for parsePacket(). I'm sure something similar can be done for endPacket().

Links to PRs:
parsePacket(): https://github.com/sandeepmistry/arduino-CAN/pull/46
endPacket(): https://github.com/sandeepmistry/arduino-CAN/pull/49

Thank you @timurrrr ! With your fix I got 0% packets loss from over 30% when I tried multiple messages with the same time cycle.


Branch without Local Storage?

Local storage is required to use vue2-datatables?
I think is a good idea to have a version without local storage for server rendered projects

how about DIY according to the doc?


openssl from 3.0.0-alpha3 breaks when reading from stdin

hello
openssl from 3.0.0-alpha3 (but NOT from 3.0.0-alpha2) breaks when reading
from stdin with:
----8<----
Could not open file or uri  for loading Certificate
40D11D026C7F0000:error::system library:file_open:No such file or directory:crypto/store/loader_file.c:919:calling stat()
Unable to load Certificate
---->8----

I have attached a simple test-case that you can use to reproduce the
problem
openssl built from source on linux:
----8<----
install:260> uname -r
5.7.5
install:254> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/stow.d/versions/gcc-10.1.0/usr/lib64/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/balducci/tmp/install-us-d/gcc-9.3.0.d/gcc-10.1.0/configure --prefix=/opt/stow.d/versions/gcc-10.1.0/usr --libdir=/opt/stow.d/versions/gcc-10.1.0/usr/lib64 --libexecdir=/opt/stow.d/versions/gcc-10.1.0/usr/lib64 --enable-shared --disable-bootstrap --enable-languages=c,c++,objc,fortran --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (GCC)
---->8----

thanks
ciao
test-case.tar.gz

I believe this was fixed already by #11873 ; please confirm

I believe this was fixed already by #11873 ; please confirm

confirmed
thanks

Great - thanks. Closing.


Make use of the Redis reconnect_on_error setting

The setup_redis function was not making use of the reconnect_on_error setting as the setup_transport function does.

It is built into the Redis client.

Haven taken another look at this I do not believe that this is correct. The clients on_error callback function takes a ruby block as it's parameter. the lib/sensu/deamon.rb file passed a block however all this block does is call the stop function:
@redis.on_error do |error|
@logger.fatal("redis connection error", :error => error.to_s)
stop
end


🔨⚒ Refractored code to use global state management cont…

…ext api

Merging branch to include global state management


bug: / at the start of the path makes app unusable on Linux

Simple fix, don't prepend the /... Or just prepend ./

it seems to not be happening anymore, at least in vscode. Wonder if I was on the wrong branch...


Add Nodies as part of RPC Providers

As part of the milestones for being a recipient of SCF #30, Nodies now supports both soroban and horizon endpoints. This PR aims to add us as a RPC provider for Stellar.

Hi, there @nodiesBlade!
Thanks for the contribution! Before I can get the PR approved and merged I tried testing out the RPC endpoints, and I couldn't get a response.
The mainnet endpoint gave me a "connection refused" error and the testnet endpoint gave a DNS error, like the hostname wasn't found. Can you double-check and confirm your RPC services are up and running, and I'll give it another try.
Thanks!

Hi, there @nodiesBlade!
Thanks for the contribution! Before I can get the PR approved and merged I tried testing out the RPC endpoints, and I couldn't get a response.
The mainnet endpoint gave me a "connection refused" error and the testnet endpoint gave a DNS error, like the hostname wasn't found. Can you double-check and confirm your RPC services are up and running, and I'll give it another try.
Thanks!

Hey @ElliotFriend , I apologize. There was a small typo in the endpoints for the README. I've updated them now, can you try again


Namespace Controller to support Namespace Termination

This PR adds the ability to delete content in a Namespace as part of Namespace termination.
See #5195 for details on the design principles behind the implementation.
When coupled with #5288 it provides a complete solution for delete of a Namespace cascading to its managed content.
The general flow is as follows:

user deletes namespace X, results in namespace X.Status.Phase=Terminating
namespace controller watches for terminating namespaces, finds X
namespace controller purges all content from X
namespace controller finalizes namespace X to report it has completed its clean-up
if all finalizers for namespace X have reported status, namespace controller deletes the namespace
namespace repository allows deletion to occur if spec.finalizers == status.finalizers

The list of namespace.spec.finalizers is immutable post-creation.  The system will always ensure the "kubernetes" finalizer is present to enforce the controller being able to support deletion life-cycle.  The repository does not allow deletion of a resource if its spec.finalizers != status.finalizers.
This lets downstream components like OpenShift that add additional namespace resources to take part in termination of the namespace by deleting its content.  In that case, when OpenShift provisions a namespace it adds a namespace.spec.finalizer=openshift.com/origin that must report back in a finalize operation before the namespace is allowed to be purged.

pushed this a moment too early, will reopen tomorrow.


Freeze attribute names in the View Content tab

Feature Request
Problem
The attribute names are visible at the top of the View Content tab.  However, when I scroll down to view all entries within a table, the attribute names are not shown.
Requirements
It would be a nice addition to freeze the attribute names at the top of the screen, under the table name, so that they are visible when scrolling down to view all table entries.
OS: MacOS 11.2.3
DataJoint LabBook Version: 0.1.0
MySQL Version: Ver 15.1 Distrib 10.5.6-MariaDB (local) or Ver 14.14 Distrib 5.7.33 (remote)
MySQL Deployment Strategy: local-native or remote

Yeah that was one of the features we are looking to implement in the next round of features to add. Will update this accordingly.

Closing as this is no longer a priority for me.


Manually specified path to the default Docker registry - docker 1.10.2

Output of docker version:
Client:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        Mon Feb 22 16:22:08 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        Mon Feb 22 16:22:08 2016
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 24
 Running: 2
 Paused: 0
 Stopped: 22
Images: 308
Server Version: 1.10.2
Storage Driver: devicemapper
 Pool Name: docker-253:2-413393-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: ext4
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 10.48 GB
 Data Space Total: 107.4 GB
 Data Space Available: 26.63 GB
 Metadata Space Used: 15.14 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.132 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93 (2015-01-30)
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 4.3.4-200.fc22.x86_64
Operating System: Fedora 22 (Twenty Two)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.721 GiB
Name: tomas-dohnalek.brno.seznam.cz
ID: L3SZ:VAVV:WVWH:K37D:QTXP:A3QC:J3LU:OANJ:25A7:J2AR:OYHA:RWEF
Username: dohnto
Registry: https://index.docker.io/v1/

List the steps to reproduce the issue:

Follow the documentation: (https://docs.docker.com/engine/reference/commandline/pull/ - docker pull registry.hub.docker.com/debian or https://github.com/docker/docker/blob/master/man/docker-pull.1.md - docker pull registry.hub.docker.com/fedora:20)
Run docker pull registry.hub.docker.com/debian

Describe the results you received:
The actual output is  Error response from daemon: Error parsing HTTP response: invalid character '<' looking for beginning of value: "\n\n\n<!DOCTYPE html><!....404: The page you were looking for is not here...
Describe the results you expected:
Pull the image
Provide additional info you think is important:
When I use docker 1.9.1 everything works as expected.

I used docker 1.10.0 it can work, but warning with that
$ docker pull registry.hub.docker.com/debian
Using default tag: latest
Pulling repository registry.hub.docker.com/debian
a0e9fe2f8803: Download complete
1e58eecba27a: Download complete
Status: Downloaded newer image for registry.hub.docker.com/debian:latest
registry.hub.docker.com/debian: this image was pulled from a legacy registry.  Important: This registry version will not be supported in future versions of docker.

also master docker seems not work as the issue described, I suspect is it means that images not supported anymore in distribution or  one docker issue ?

I'm able to reproduce on docker 1.10.2, so either the documentation should be updated, or there's a regression

Looks to work in docker 1.9 indeed, so looks like a bug to me; perhaps due to "text/html" being accepted as content type? idk
ping @aaronlehmann can you take a look?

This is a mix of incorrect documentation and inconsistent server-side behavior.
docker pull registry.hub.docker.com/library/debian does work.
For some reason, the v1 registry doesn't require the library/ prefix to pull Debian. Old versions of Docker retried using the v1 protocol after almost any error. This was tightened up in 1.10 because unjustified switches to the v1 protocol were causing a lot of problems.
It's fine that registry.hub.docker.com gives a 404 for a nonexistent image. But 404s under the /v2 URL hierarchy should conform to the Docker registry protocol error schema. Producing HTML here seems like a misconfiguration.
In any case, we shouldn't be telling people to pull from registry.hub.docker.com. So let's fix the docs.

@aaronlehmann  Just one question, when you said
" Producing HTML here seems like a misconfiguration", I am not sure is it github configuration or image configuration issue?  Thansk

@HackToday: It looks like a Docker Hub misconfiguration on that subdomain.

I checked with the Docker Hub team and found out there's an unresolved issue with v2 APIs on registry.hub.docker.com. This is being fixed and should be resolved soon. However, they recommend using registry-1.docker.io for v2 APIs (this is what Docker uses by default). We should update the docs to remove the explicit hostname.

@aaronlehmann hm looks like that didn't work as well. I think that part of the docs is to show that you can specify a registry-url instead of just the repo/image name
docker pull registry-1.docker.io/debian
Using default tag: latest
Pulling repository registry-1.docker.io/debian
Error: Status 405 trying to pull repository debian: "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2 Final//EN\">\n<title>405 Method Not Allowed</title>\n
Method Not Allowed
\n
The method is not allowed for the requested URL.
\n"

@thaJeztah: I think docker.io would work for an example like this.
But it should be docker.io/library/debian.


fix: ESLint issues in botbuilder

Addresses # 4684
#minor
Description
This PR fixes the new ESLint issues after upgrading the ESLint packages in the botbuilder library.
Specific Changes

Removed botbuilder eslint.config.cjs file.
Applied the fixes needed for all the issues detected by ESLint.
Removed duplicated unit test in teamsActivityHandler.test.

Testing
The following image shows the issues fixed in the library.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>8
Details

18 of 23 (78.26%)  changed or added relevant lines in 11 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.4%) to 84.353%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

libraries/botbuilder/src/botFrameworkAdapter.ts
7
8
87.5%

libraries/botbuilder/src/skills/cloudSkillHandler.ts
0
1
0.0%

libraries/botbuilder/src/skills/skillHttpClient.ts
0
1
0.0%

libraries/botbuilder/src/cloudAdapter.ts
1
3
33.33%

Totals

Change from base Build<PHONE_NUMBER>2:
-0.4%

Covered Lines:
20435

Relevant Lines:
23067

💛  - Coveralls

Promoted /4830


CustomEvent: pass a ReadTheDocsData object as event.detail

I found a pattern that I like 👍🏼 . I think it's a clear way to communicate users what's going on, but also leaves the door open to expand checks/validations in the future. I also imagine we could even want to know "What projects are subscribing to the custom event?" in case we need to contact them due to a breaking change or similar.
Examples
Calling event.detail.initialize() without having defined the <meta ... /> HTML tag:

Calling event.detail.data() without calling .initialize() first:

Closes #279

The class structure isn't a problem, but could be easier as a function too, the class is maybe not adding much.

I also think the class is not adding too much right. However, do you think we will have the same flexibility with a function in the future in case we need to perform more validations/checks? I'm asking because my limited js knowledge 😅

However, do you think we will have the same flexibility with a function in the future in case we need to perform more validations/checks? I'm asking because my limited js knowledge

We would have plenty of flexibility to include logic that we want to hide from the maintainer user. But, if we wanted to expose and public functions/methods, the class structure would make this cleaner. I think it's fine to stick with the class based approach if we aren't sure or are leaning towards exposing public methods -- ie, maybe a event.detail.getVersions() helper method or something similar.

It seems we both agree on passing a class instead of the raw JSON data. So, I'm merging this PR into the one its based, and we can continue with the minor details there.


Better rule specification documentation

@ianshward @alulsh

@zmully made some copy edits. LGTM! :+1:
We may want to consider eventually moving this file to https://github.com/mapbox/crowsnest.


Wrong port on Linux

Spotify web server port is 4371 instead of 4370 on Linux (fresh install of Lubuntu 16.04) . Not sure whether it happens only on my machine or if it is global. Anyway problem solved by hard coding the right port in main.js line 97 let spotifyPort = 4371;

This shouldn't be necessary since the program cycles through ports 4370 through 4379 until it finds the right port. Have you tried it without the change?

My bad, it looks like the repo isn't the most recent revision with port detection.

Port detection has been implemented in v0.0.5. Let me know if there's more problems!

I will close this now since there hasn't been a response in a while. Let me know if there are still issues!


composer clear-compiled error

I am gettign the below error after doing a composer update and then clear-compiled
Fatal error:  Class 'ZooKeeper' not found in /home/vagrant/laravel/praxis/vendor/nmred/kafka-php/src/Kafka/ZooKeeper.php on line 67

make sure install php zookeeper extends


LRS_LOG_LEVEL does not seem to work

hello,
i am trying to control the logging level ,
followed instructions at https://github.com/IntelRealSense/librealsense/wiki/Troubleshooting-Q&A#q-how-do-i-enable-librealsense-logs
but setting this env variable seems to have no effect on both my code, and on the standard applications.
here's an example

export LRS_LOG_LEVEL="FATAL"
realsense-viewer
31/05 11:37:59,626 WARNING [140462828525312] (backend-v4l2.cpp:808) Empty frame has arrived.
31/05 11:37:59,626 WARNING [140462828525312] (backend-v4l2.cpp:808) Empty frame has arrived.
31/05 11:37:59,626 WARNING [140462828525312] (backend-v4l2.cpp:808) Empty frame has arrived.
31/05 11:37:59,626 WARNING [140462828525312] (backend-v4l2.cpp:808) Empty frame has arrived.

(also tried export LRS_LOG_LEVEL=FATAL , to the same effect)
please advise.
Omer.

I think realsense-viewer.cpp:214 is overriding global settings. Did you try with other examples?

managed to change the logging level using rs2::log_to_console.
:-)


adding OG data template, populate by return state query

creates OG data, we need to figure out what we want copy wise also

put some preliminary og, using the ballot bot picture as the default share and the mayor name for the last parameter

@stanzheng Have you been able to test this manually?

locally i can see the meta data, if we merge and push this up to okcandidate-staging.code4hr.org it should have the correct data.


[WFCORE-5960] Fix bug initializing Domain Base Dir for path Manager

jira issue: https://issues.redhat.com/browse/WFCORE-5960

Let's see first how it goes, it could deserve a test case to ensure this never change for any other reason

I haven't found a more simple way to test except by adding a real configuration, I was expecting something around the host path manager service, but seems to be pretty hidden for external accesses.


Check Json Encode, for characters with accents

When downloading a jed/json file foreign characters become their encoded character, something like "\u00e3".

Repeated issue #5


Add and update i18nReady: false pages

update i18nReady: false pages and include it if it doesn't exist
this applies for files within src/content/docs/en/
See #6549 for details

Hello! Thank you for opening your first PR to Astro’s Docs! 🎉
Here’s what will happen next:

Our GitHub bots will run to check your changes.
If they spot any broken links you will see some error messages on this PR.
Don’t hesitate to ask any questions if you’re not sure what these mean!

In a few minutes, you’ll be able to see a preview of your changes on Vercel 🥳

One or more of our maintainers will take a look and may ask you to make changes.
We try to be responsive, but don’t worry if this takes a few days.

Most of the pages in the cms have been translated, will this cause lunaria to mark them outdated again?

Most of the pages in the cms have been translated, will this cause lunaria to mark them outdated again? @Yan-Thomas
Not really, this PR will be marked as i18nIgnore so this doesn't happen.

Most of the pages in the cms have been translated, will this cause lunaria to mark them outdated again? @Yan-Thomas

Not really, this PR will be marked as i18nIgnore so this doesn't happen.

Sorry, but I didn't understand what you meant.

@xMohamd The i18nIgnore is a keyword we use in PR titles or commits to indicate that the changes made here should not trigger to mark any translated files as needing an update. None of the changes made are things the translators need to worry about updating on their end, so we have a keyword so that our tracking system knows that our entire i18n system and contributors can safely ignore the changes from this PR!


Hide Embulk's own dependencies from plugins

NOTE that nothing has been determined. Just pushing ideas here. Not ready for discussion.
For licensing and to hide dependency libraries from plugins, we may want to package dependency JARs as-is in the Embulk JAR, not extracting dependencies as a Fat JAR.
Focusing on hiding dependencies from plugins in this issue.
Options? :

http://one-jar.sourceforge.net/

This may solve #650 at the same time.

Relocating dependencies by Gradle shadow plugin: http://imperceptiblethoughts.com/shadow/#relocating_packages

Heard about relocating dependencies by Gradle shadow plugin. It is very very nice in terms that we don't need to use another ClassLoader, but we cannot use this because some plugins have been already depending on Embulk's own dependencies.
A possible plan is:

Use One-JAR (or else) to provide options to depend or not-depend on Embulk's own dependencies. Plugins can choose by themselves by a kind of embedded meta data.
Wait a while for (all) plugins to migrate as a deprecation period.
Drop One-JAR and switch to relocating.

An experiment (out of Embulk): https://github.com/dmikurube/clean-pluggable-example

It's mostly done through v0.10!


Use julia-downgrade-compat?

The current DocStringExtensions = "0.9.3" makes DifferentiationInterface incompatible with some packages that are still stuck on DocStringExtensions v0.8. Would it be possible to relax the version bound?

Oh yes definitely. I wonder why CompatHelper didn't pick it up. Care to open a PR?

I wonder why CompatHelper didn't pick it up

Because I wanted to extend it downwards to DocStringExtensions = "0.8, 0.9", not upwards. :-) But I can't find the package anymore that caused the trouble, maybe my dependencies are all v0.9-compatible now. I'll close this for now ...

In any case, since DifferentiationInterface wil (hopefully) be wide used, maybe we could use https://github.com/julia-actions/julia-downgrade-compat to keep the dependency version bounds wide, but in a safe manner?

Sounds like a great idea, thanks!

While a good idea in principle, downgrade compat testing is more tricky than it looks because I perform Pkg operations inside the DI test suite. The DI test suite is split into one CI workflow per AD backend, and each of those workflows activates a custom environment like DI/test/Back/Diffractor/Project.toml. This is designed to avoid instantiating an environment with all backends at once, which is very tricky due to conflicts (especially on older versions of said backends).
The trouble with this method is that compat bounds of the DI package are not enforced in the environment activated on top of the test environment, which is why I had to explicitly bound Diffractor for instance. So I'm not sure how the GitHub action you refer to will handle that.

each of those workflows activates a custom environment like DI/test/Back/Diffractor/Project.toml.

This could possibly be handled through the projects argument:
https://github.com/julia-actions/julia-downgrade-compat?tab=readme-ov-file#usage
# Comma-separated list of Julia projects to modify. The Project.toml files in all of
# these directories will be modified.
# Example: ., test, docs
# Default: .
projects: ''

I don't think so because the individual Project.toml files don't store the compatibility bounds of AD backends for DI: that's stored in the main Project.toml file. So we would need a way to enforce these bounds in the stacked environment.

https://github.com/gdalle/DifferentiationInterface.jl/blob/a0a96c7483a46cf09edbbb26a54c4262223430f1/DifferentiationInterface/test/runtests.jl#L21-L32

And a separate mechanism is at work for adding

the right version of DIT to the DI test env
the right version of DI to the DIT test env

because otherwise Pkg will try to grab it from the general registry

To the best of my understanding, the way julia-downgrade-compat works is by simply rewriting the Project.toml files at the specified projects paths.
If we first activate DI/Project.toml before activating      Pkg.activate(joinpath(@__DIR__, category, folder)), would the downgraded compat entries be enforced in the /test/BACK environments as well?

No because compat bounds of environments deeper in the LOAD_PATH stack are not necessarily enforced:

https://docs.julialang.org/en/v1/manual/code-loading/#Environment-stacks
https://discourse.julialang.org/t/compat-bound-violations-with-stacked-environements/116492

I thought it was cleaner to store this stuff in a Project.toml but maybe I can just write the list of packages explicitly. Let me open a quick PR.

See #381, if tests pass on this one you can rebase #380 on it afterwards @adrhill

#380 reveals some annoying properties of the julia-downgrade-compat action.
It looks like it rewrites the Project.toml to only keep the lowest compat entry, which often can't be properly resolved.
For example, the tests on #380 fail because SparseMatrixColorings has its DocStringExtensions compat entry set to v0.9:
ERROR: LoadError: Unsatisfiable requirements detected for package SparseMatrixColorings [0a514795]:
 SparseMatrixColorings [0a514795] log:
 ├─possible versions are: 0.1.0-0.3.5 or uninstalled
 ├─restricted to versions 0.3.0 by DifferentiationInterface [a0c0ee7d], leaving only versions 0.3.0
 │ └─DifferentiationInterface [a0c0ee7d] log:
 │   ├─possible versions are: 0.5.9 or uninstalled
 │   └─DifferentiationInterface [a0c0ee7d] is fixed to version 0.5.9
 └─restricted by compatibility requirements with DocStringExtensions [ffbed154] to versions: 0.1.0 or uninstalled — no versions left
   └─DocStringExtensions [ffbed154] log:
     ├─possible versions are: 0.4.6-0.9.3 or uninstalled
     └─restricted to versions 0.8.0 by DifferentiationInterface [a0c0ee7d], leaving only versions 0.8.0
       └─DifferentiationInterface [a0c0ee7d] log: see above

So these tests might be a headache in the future.

@adrhill can you modify #380 by

undoing #379 so that Pkg installs v0.9 of DocStringExtensions
rebasing on #381

undoing https://github.com/gdalle/DifferentiationInterface.jl/pull/379 so that Pkg installs v0.9 of DocStringExtensions

I bet that doing this will just reveal another dependency conflict.
I suggest we keep #379 (which @oschulz needs) and don't use julia-downgrade-compat until there is a way to automatically resolve an environment with lower compat bounds. We can't be the ones the manually resolve all lower bounds.  It needs to do something smarter than just pinning everything to the minimum versions.

I bet that doing this will just reveal another dependency conflict.

Or maybe not, that's my hope.
If that's the only problem, https://github.com/gdalle/SparseMatrixColorings.jl/pull/31 should be enough to fix it for good

I bet that doing this will just reveal another dependency conflict.

Or maybe not, that's my hope.

If not, then that's pure luck.
We'll encounter the same problem of having to manually resolve lower compat bounds every time we need to modify lower bounds. And that's going to happen every time we require a new feature from a new release of any dependency.

While we should test lower compat bounds, julia-downgrade-compat doesn't seem to be the answer for DI. We using it tried in #380, but it currently requires manual resolving of dependencies, which should ideally be handled by Pkg rather than a human. This problem was discussed on Discourse as well.
A proposal to add down to Pkg can be found here: https://github.com/JuliaLang/Pkg.jl/issues/1062
Until this is added, this issue will probably have to be left open.


Annotate GCE machines with project/zone/name of VM.

When creating GCE VMs, annotate the corresponding machine object with the project/zone/name of the VM so that we can find it later. Otherwise, we rely on the providerConfig in the machine spec, which can be changed at any point.

This change is

Cool - I'm wondering if we should use the "standard" labels for zone/region: https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/well_known_labels.go#L20-L23
This might also be an opportunity to make these actual fields :-)


Pod latency threshold flag for all cluste-density and node-density wo…

…rkloads
Type of change

[ ] Refactor
[x] New feature
[ ] Bug fix
[ ] Optimization
[ ] Documentation Update

Description
Adding the pod-ready-threshold flag to these workload, Im not adding it for the networkpolicy ones for now, but if you see it necessary I can add it too @mohit-sheth
cc: @paigerube14  @svetsa-rh
Related Tickets & Documents

Related Issue #
Closes #

Checklist before requesting a review

[x] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.

I've set some sane defaults for the different workloads that shouldn't trigger any error in regular tests:
node-density: 15s
node-density-heavy: 2m
node-density-cni: 1m
cluster-density and variants: 1m
As I said, these values are just default, and must be adapted to the different CPT scenarios, using the historic data we've already indexed, @afcollins @jtaleric @paigerube14

Some CPT numbers:

Benchmark
platform
Max p99 lat
Average p99 lat

Cluster-density-v2
rosa
27.8
16.3

Cluster-density-v2
self-managed aws
13.1
18.3

node-density
rosa
8.61
2.76

node-density
self-managed aws
10.1
5.13

node-density-heavy
rosa
4 mins
1.02 mins

node-density-heavy
self-managed aws
41
43.8

node-density-cni
rosa
4
3.94


Fix problem eating line ending and refactor

Problem existed on OSX where if you tried to read a password and
the user simply pressed  then that would just get ignored
since the counter==0.  That counter logic was added to fix a
problem on Windows but I think that was when we were mainly
concerned with Cygwin; the current logic works fine with cmd.exe
when I tried it out.  The reason for wanting this is so that
a program can handle the 0 length password as a special, default
case.
Also refactored based on upstream changes to centralize the logic
for getting a password, masked or not.
Lastly, introduces another fix based on upstream changes which
ignores the NUL byte.  We ran into this when using Cygwin with
the Windows calls; you just end up getting an infinite string of
0 bytes.  No harm in including this fix into our branch as it
seems the upstream repo ran into that problem in other situations
too.

@schancel @zquestz LGTY?  @zquestz  I know you put in those changes for Windows but I can't recall the exact problem.  On cmd.exe the  key just reads as key 13, so we weren't even hitting that inner if block.
We were also mixing os.Stdout.Write and fmt; I just changed it to use fmt.  Most other things just come from the upstream.

LGTM

LGTM

Soo -- it does seem like apc is leaving a newline on the buffer from the login, we may need to fix the login reading in APC.  I am running into https://apcera.atlassian.net/browse/ENGT-6198 on 504.1.8, 506 and 508.

IMO, we should update to the latest upstream. This library was the first external dependency, and it was initially only forked because it changed to use a library that needed mercurial, which none of the build systems has. This we before we had any kind of third party dependency management stuff.

We've basically rewritten this library at this point.   I don't think we should do anything with the upstream library at this point.  I looked at updating it awhile back, and since then we've fixed a lot of other issues.  In particular we have fixes in to allow this to pipe files as input into apc/apcera-setup on windows.

So I didn't even know you guys were talking about this here; @tw4dl had me start looking into updating the upstream...so I did.
So I submitted the fix for accepting input from pipes which they already took; I just submitted another for adding some testing but its not really vital.
I would be in support of moving to the upstream because they do have some little fixes that we still dont have: apparently the masking of the Windows console mode was done incorrectly, in some cases (in multiple OSs I think) you'd get the 0x03 byte rather than an actual interrupt so they added a case for that too.
In my update to their readFile routine I also expanded the error handling to actually look at the return value from Windows in case there was a problem.
I think they (and us) still suffer from a problem if CTRL-C is hit during the password entry (console mode isn't reset) but it is a known issue in both of them which we can resolve pretty easily by just listening for the interrupt signal.

We had basically rewritten it, then when we had problems we found that they were doing nearly the same things now (since I'm sure they hit the same problems like null bytes etc).  So we ended up taking large sections of code back from the upstream with little edits.
Also, not sure if this is a taboo but since I was on a mission to get the upstream more like ours it seemed easiest to fork it myself and add those changes gradually.  If thats a no-no due to authorship and such, please let me know, I didn't mean to offend or take credit for every line of changes.

I'd love for us to contribute back to the community. It is not a short term mandate, but we can do it with a schedule we are comfortable and with low impact/risk. Great one PR is already accepted by the upstream.


ConsumerGroup reconciler

Part of #1537

Proposed Changes

Add ConsumerGroup reconciler

Release Note

None

Docs

None

/assign

Friendly ping @devguyio

/lgtm


panda-client 1.5.33 github action

automatic pull request

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


Attributes syntax change

As discussed at length in https://github.com/twinbasic/twinbasic/issues/835, the following syntax change has been agreed and due to come into force.
Old attribute syntax:
[ AttributeName (args) ]
New attribute syntax:
@AttributeName(args)

for boolean attributes, "(args)" are optional (as they are right now)
whitespace between the attribute name and the opening argument parenthesis will be removed by the prettifier
multiple attributes on the same line are allowed, immediately following each other, or seperated by a line splitter character ":"
attributes must appear BEFORE the intended target in ALL cases

Examples...
@Enumerator
Public Function NewEnum() As stdole.IUnknown
   ' ...
End Function

@PredeclaredId : @ClassId("00000000-0000-0000-0000-0000000")
Class MyForm
   ' ...
End Class

@Serialize(True, "FriendlyName")
Public UnfriendlyName As String

Public Declare Sub MySub(@MarshalAs(LPWSTR)  ByVal A As String, _
			 @MarshalAs(Byte)    ByVal B As MyEnumeration)

NB. MarshalAs() is not a currently available attribute... this is just to show how we might possibly support inline attributes in future.

Question:
Given this rule:

multiple attributes on the same line are allowed, immediately following each other, or seperated by a line splitter character ":"

and This example above:
Public Declare Sub MySub(@MarshalAs(LPWSTR)  ByVal A As String, _ 			 @MarshalAs(Byte)    ByVal B As MyEnumeration) ' Would this be valid syntax?
Public Declare Sub MySub(@MarshalAs(LPWSTR) : ByVal A As String, _
@MarshalAs(Byte)  :  ByVal B As MyEnumeration)
'
...or would that confuse the parser?
...and if not, then how will we eventually do this:
`
Public Declare Sub MySub(@MarshalAs(LPWSTR) : @ObsoleteAsOf("Version 3.0")  ByVal A As String, _
@MarshalAs(Byte)  : @ObsoleteAsOf("Version 3.0")  ByVal B As MyEnumeration)
'
?
...assuming we eventually get Custom Attributes?

v1 blocker
Presumably we don't want to keep the old attributes around if we do the new syntax, since that will just be confusing to have 2 ways to do the same thing, and we may want to reuse those [square brackets] down the line for something else. Will break existing tB code to remove old attribute syntax therefore must come before v1

Is it only enum item descriptions prompting this syntax change? Because I've thought up several alternatives that while a little clunky just for enums would avoid this syntax change for all attributes. I much prefer the brackets.

I think at this stage we need to also (re-) consider the effort required to change this now.  Let's just sound out alternatives, although bear in mind we probably don't want to re-open the whole debate 😭

Ok, some proposals for enums:

New attribute: [ ItemDescription(index, string) ]. Multiple attributes are allowed, they can be one per line:

[ Desciption("Description of enum itself)" ]
[ ItemDescription(0, "First item") ]
...
Enum foo
   Item0
...
End Enum

Detect [ Description() ] is used on enum, and parse as quoted list: [ Description("Item0", "Item1", ... ]

New Attribute [ EnumDescriptionUseComments(Position) ]. Just use comments in existing enum as descriptions. Position would inform it which to use:

Enum foo
    'Above
    Item0 'Adjacent
    'Below

Bonus here is VB programmers already have a lot of enums commented this way, so would have a much easier time adding them. Downside is this would be more difficult to transition to external sources for localization. The other two would use whatever method is implemented for regular [ Description() ]
Could probably think of more, and of course maybe these could be better named.

I guess the question on my mind is, is it likely that we will ever want any other attribute than Description for an enum member?  If it likely that there isn't any other use case for it, then that does simplify the problem somewhat.

Even if we did, option 1 would be available; any attribute could be organized per item. Can we think of any possibilities for others?
If we can, what about a generic?
[ ItemAttribute(Name, Value) ]
Though since the only additional modification we've ever considered is type, and that would use As syntax, and I can't think of any, I'm not sure it should be a concern at this point.

If we did just want to enable it per item like in Type... what if we required an affirmation? Only parse that way if [ EnableAttributes ] was specified for the enum? Then the documentation for that attribute would make it clear you either couldn't have members using [ ], or that any [ ] item matching an attribute would be interpreted that way.
You know, I bet this is pretty similar to the conversation that led to PtrSafe... when tB is dominant 20 years from now, "Why do we need this useless thing?" "Because in ancient times..."

I never liked the "[ " I mean the spaces after the opening and before the closing of the square brackets, but it seems very established already, and perhaps there is a reason for that.

I think it needs to be consistent with the rest of the language attributes ideally, so keeping it as [ Description("")] would be ideal.  Did you see my edited proposal about detection of parenthesis to determine attribute vs enumeration member?
Having an [ EnableAttributes]  on the parent enum could indeed work too.

I never liked the "[ " I mean the spaces after the opening and before the closing of the square brackets, but it seems very established already, and perhaps there is a reason for that.

This is due to parser auto-correction where it adds spaces for some syntax.  The extra spaces were never actually intended, and I should probably fix it so they get auto removed.

@EduardoVB -- the spaces are just formatting. The prettifier often misses closing ones for me but it still works fine.
Re: Detection of parenthesis... I'm having the same thoughts about consistency with how things currently work-- does putting [ Hidden ] without parenthesis not enable it being hidden? It might be confusing to have () required, only in enums.

Yeah the True argument is optional in other contexts, so if we want to keep consistency the extra attribute on the parent Enum sounds like the most valid option.

I like the idea of only allowing Description attributes in Enums (if I understood that correctly).

Putting member attributes at the top level seems like a compromise too far IMO. In every other application, an attribute appears immediately before the thing it's attributing. I think its valuable to keep this paradigm.
Is it worth revisiting earlier ideas:

Using < and >

Using an "escape character

Has the advantage that those characters are almost unused in VBx outside of expressions, so shouldn't clash. And a further advantage that its the path VB.Net chose, so may be more natural to that target audience.

As an example, in C#, you can't use event as a parameter name, as it's a language keyword. But its also quite a common word that you might want to use. So they allow you to prefix it, so that @event is allowed.

FWIW, this is a compile error in VBA:
Public Enum foo
    [Description("")] [Description("")]
End Enum

Therefore, if we say that an enum member can be only decorated with an attribute on the same line, that would avoid backcompat issues and avoid locking us into a set of attributes allowed for enum members.

That could be genius, would also solve how to handle parameter attributes later on - they have to be on the same logical line,

Although I'm still kinda fond of option 1... < and > seem under-used at the moment, and VB.Net already chose them for this.
Just thinking about conversions here - if a VB.Net developer saw attributes like <Hidden>, they might be more tempted to look further...

VB.NET developers would see [Hidden] and feel uncomfortable, but <Hidden> is comfortable?
C# uses brackets. How many .NET people are so isolated on the VB.NET side they'd be put off by brackets?
But requiring it on the same line is also breaking consistency. Everywhere else, you can put it on the line before.
I know none of these solutions for enums are perfect, but again, it's preferable to changing them for everything just to accommodate not having a special rule for enums.

But requiring it on the same line is also breaking consistency. Everywhere else, you can put it on the line before.

Keep in mind that currently there are no inline attributes but it doesn't mean there won't be. We may want inline attributes for parameters which would not be able to adhere to the line above convention. At that point, the inline enum member attributes would be consistent.

Isn't [TypeHint()] inline? But that makes sense; because it's not a one-element-per-line situation.
[Description()] is meanwhile allowed on types:
Type foo
    [Description("Member 1")] Member1 As Long
    [ Description("Member 2")]
    Member2 As Long
End Type

VB.NET developers would see [Hidden] and feel uncomfortable, but <Hidden> is comfortable?

Well not uncomfortable, but using their native syntax just makes things feel a bit more homely.
The main reason I suggest < and > though is that it seems likely to work for all places we'd want to use attributes, without using unpleasantries like escape characters. I can't see much downside, unless I'm missing something.

If I have to be honest overloading square brackets for "quoted literals" and attributes is a poor decision with unneeded consequences provided that there already are attributes in VB.Net as prior art and these use < and > with no apparent down-sides.

As an example, in C#, you can't use event as a parameter name, as it's a language keyword. But its also quite a common word that you might want to use.

In TB you are supposed to use [event] and always get a token of type identifier from the parser i.e. disambiguate on keywords with the same name which a very good and straightforward idea. I might like to call my vars [if] and [then] for some fun reason.

I'm confused the consensus or final decision at the top of this post after lengthy discussion was to use the @ symbol
Surely the question here should be between do nothing and stick to square brackets as that is easier, or justify the swap to @ symbol which will be disruptive but valuable, as described at the top of this issue post? Why reopen the discussion on angle brackets

Apologies, I know this has dragged on. But it's important to get this right before v1, as it would be breaking to change it afterwards.
I strongly believe a @ prefix, with no suffix, is not the best choice. Let's look at some examples:
@Hidden
@Description("Gets the count of collection items")
vs
<Hidden>
<Description("Gets the count of collection items")>
Both would work, so this is a cosmetic choice. But braces (in this case angled) have the advantage of delineating both the start and end, rather than relying on an implicit end of token (here, a line break, potentially any whitespace for inlines in future).
Neither has any prior art in VBx. But < and > at least have prior art in other BASIC dialects, whilst @ only has prior art in Java (and derivatives).

I just don't think < > offers enough advantages over [ ] to be worth the disruption. VB.NET uses them (C# uses [ ] ) and it makes things very slightly less awkward for adding descriptions and maybe hidden one day to individual enum items. In exchange every tB project written over the last 3 years has to be fixed (unless we're keeping both, which, please no).
I vote just go with one of the slightly more awkward options for enums alone and keep the [ ]. Is [EnableAttributes] that bad for what isn't exactly a common use and not exactly something beginners will be doing? I'd even prefer requiring they be inline or requiring () for enums only over changing at this point; tB could even pop up a note about it when it detects [] and " on the same line in an enum.

If there is ever a time to be disruptive, it's now. Before v1.
[ and ] were poorly chosen, as wqweto says, because they clash with existing VBx syntax. We should change this before v1, either for @ as in the OP, or < and >.
I appreciate this may be disruptive for existing users, but that's the nature of beta software, nothing is set in stone. Far better to finalise it now than to break a shipped release.

We've had extensive discussions over many threads about this. V1 is near, so a decision will need to be made.
@WaynePhillipsEA

They clash in exactly one scenario, providing individual attributes for enum members. There won't need to be a break after v1 because there's solutions that don't involve changing it for everything besides enums.
If it was just the disruption and the change brought a substantial benefit overall, yeah you can chalk it up to beta. But it's not; it's a very slight benefit for one specific, unusual usage, in exchange for an overall system that's anywhere from no benefit to worse for the other 99.99% of usages, depending on preference.
But yes this does need to be settled now.

They clash in exactly one scenario, providing individual attributes for enum members.

The syntax in ambiguous for UDT members too and for something as simple as procedure parameters. Using square brackets for attributes prevents these to appear before regular identifiers like enum entry name, UDT entry names, parameters and every other language construct which does not have a dedicate "introductory" keyword (like "function", "type", "module", etc.)
It's not possible to overload square brackets here unless attributes use some other symbol inside the square brackets to disambiguate e.g. prefix with @ like [@attrib] or suffix with parens like [attrib()]. Overall too much hassle for something which has already been dealt with in VB.Net. It's like coming up with new syntax for generics instead of using (Of Type) or whatever VB.Net is using. Why?

How is it ambiguous for UDT members? [ ] isn't allowed in variable names; [Description()] is already available for them and works fine.
Procedure parameters too; [TypeHint()] works fine so I'd imagine Description would too; can you give an example of VB6 legal syntax that can't be used with the current attributes or ones without () in the future? If you can it's a very strong argument, but I'm struggling to think of anything besides individual enum members.
Also again my reply to VB.NET is C#. C# uses [ ] for attributes.

Just to note: there's also the matter of external names. I don't think they are featured regularly in VB6 but they are common in VBA projects especially with Excel or to less extent Access as the host.  See this and that.
As long as the attributes are only defined on the signatures and not within the procedure body, there'll be no clash because external names can be only used within the body. But if we one day end up with local or anonymous procedures, that might make it possible to need attributes in the body, and that would limit the language's flexibility.

How is it ambiguous for UDT members?

It is but Wayne get away with it by "anchoring" on As keyword probably and for parameter attributes even more shenanigans will be needed (counting consequtive identifiers, etc.) which might work for enum entries too if attribs are required to always end with parens. This way closing parenthesis (plus optional space) before closing square bracket can be used as a distinguisher between an attribute and a quoted identifier provided that closing parenthesis is not allowed to end quoted identifiers which is not a big deal.
Yes, this is possible and not very disruptive for the language IMO. Limiting quoted identifiers, requiring parentheses on (ambiguous) attributes and so all this will allow keeping existing code intact.

Yes, this is possible and not very disruptive for the language IMO. Limiting quoted identifiers, requiring parentheses on (ambiguous) attributes and so all this will allow keeping existing code intact.

I'm worried that we're talking about language disruption whilst we're still in beta. At this point, we should be thinking about how best to lay the foundations for the language going forward.
I appreciate that a lot of code may have been built on the beta release, but is it really worth compromising the base design to avoid rework? Perhaps a regex search/replace could fix up any breaking changes?
The key question should be: is [ and ] the best choice for the language? If not, we should change it.
The follow on question is then: What is the best replacement?

Again, if it was only the disruption that would be one thing. It's not though. I think [ ] is the best option.

@fafalone, I'm not following. Why do you think that [ and ] are the best choice for the future, given that they clash with existing syntax whilst other proposals don't?

Both [ ] and < > are better than @ because they more clearly delineate the start and end. Combining more than one is really not good, Function foo(@TypeHint(x)@MarshalAs(LPWSTR) x As LongPtr) or Function foo(@TypeHint(x), MarshalAs(LPWSTR) x As LongPtr)`?
Between the two of those, I think aesthetics have a nonzero value (if you're interesting in a lengthy pontification on why I think [ ] wins here, let me know lol) and just don't give such high importance to one single, unusual scenario where a special rule has to apply because of a conflict. So that's how I'd have resolve a day-0 conflict. Then with the disruption, it takes it from mostly preference to strong argument. Again, it's not that nothing can be broken now, it's just that invalidating all existing code in dozens of places is no small change you can just chalk up to 'it's beta'. For a change this big, < > would have to offer substantial  benefits, not make one rare niche usage not even possible in VBx not require slightly special handling like attestation or requiring ( ) if we ever want to, for some reason, support [Hidden] or [Restricted] or some other default value-having attr on individual enum members, something that's not exactly on any wishlist I've seen.

I guess it boils down to priorities. This syntax is new to twinBASIC, and has only just begun to find application. What happens when we want to apply attributes to parameters? Or lambda? Or...
We've already seen an example of it not working in existing code, what happens when the language wants to expand?
[ and ] are poor choices because they already have semantic meaning in VBx, which has to be respected. < and > don't.
This is what betas are for - to try things out, find what works and what doesn't, and fix things before release.

Let me put it this way... If Wayne had chosen < and > and code had been written for it, would you be advocating for [ ]?

If you're hypothesizing about conflicts with syntax that doesn't yet exist, how can you suggest < > wouldn't be a conflict too? New syntax is just that-- new. It's designed to work with the existing ruleset. C# uses [ ] for attributes and has the features you describe, so it's not some global standard we'd be in conflict with. Lambas or whatever new feature would be designed to not conflict with existing syntax.
IMO you're still making way, way, way too much out of a conflict in a single scenario, that's also a potential new feature, but not in conflict with VBx compatibility, and I don't think there's any reasonable argument people will be inordinately confused or upset if they have to use [Hidden(True)] instead of just hidden in the single spot where it conflicts, attributes for individual enum members.

Let me put it this way... If Wayne had chosen < and > and code had been written for it, would you be advocating for [ ]?

Day one? Yes. Year 4? No, I wouldn't think the benefit outweighs the disruption.

Btw, in rust they use #[Attrib()] with explicit # for no apparent reason but probably to make parsing easier.
Main benefit of < and > is easy of parsing, second one is prior art in .Net.

If you're hypothesizing about conflicts with syntax that doesn't yet exist, how can you suggest < > wouldn't be a conflict too? New syntax is just that-- new. It's designed to work with the existing ruleset. C# uses [ ] for attributes and has the features you describe, so it's not some global standard we'd be in conflict with.

C# used [ and ] for attributes from v1, and C# was entirely greenfield (other than a general idea of "make it C-like"). So they knew they couldn't conflict even though C# uses those symbols for indexers.
VB.Net didn't have the same luxury - one of its main design goals was to keep to familiar VB6 syntax, and thus not repurpose symbols. And they chose < and >, presumably so as not to clash. So far, it seems to have worked well.

Day one? Yes. Year 4? No, I wouldn't think the benefit outweighs the disruption.

I thought this might be an exaggeration, but I just checked and twinBASIC went public 1st March 2021, so yes we're about to enter year 4. Wow, time flies...
My point stands though - I appreciate (in both senses) that you've built a lot of code on the beta. But all being well, once twinBASIC goes live there will be vastly more code written and published on the internet. If there's a problem with the syntax, surely it's better to fix it now than post-v1?
Is it really that onerous to do a regex search/replace for [whatever] to <whatever> and ship a new version? I feel like I'm missing something here.

VB.Net didn't have the same luxury - one of its main design goals was to keep to familiar VB6 syntax, and thus not repurpose symbols. And they chose < and >, presumably so as not to clash. So far, it seems to have worked well.

It did have that luxury. The syntax is in no way compatible with VB6. The complete lack of familiarity was and still is the primary complaint against it as a "successor" to VB. It's VB in name only.
You know, I'd wager more people are familiar with [ ] as an attribute-like notation of optional arguments in Intellisense/Object Browser than are even aware you can use it in the names of enum values.

Is it really that onerous to do a regex search/replace for [whatever] to  and ship a new version? I feel like I'm missing something here.

Is it really that onerous to have a single, rare, scenario where you need to use () in your attribute? Once again, I feel like you're making a mountain out of the molehill of a the one single, very uncommon, still theoretical, situation of attributes for individual enum items without ( ). If it wasn't for this one single isolated situation where there's an incompatibility, would you still be arguing for < >, and on what grounds?

JFYI, VB.NET does not accept weird names for either the enum or enum members. It won't allow you to bracket the weird names even though you can bracket the normal name, so VB.NET already breaks the compatibility in this area.
This can be verified via .NET Fiddler:
Imports System

Public Module Module1
	Public Enum FooBar
		Foo
		[Bar]
		_Bizz
		[_Bazz]
		'[Fizz$] 'Won't compile
		'[Fizz Buzz] 'Won't compile, either
	End Enum

	Public Sub Main()
		Dim fb As FooBar
		For Each fb In System.Enum.GetValues(GetType(FooBar))
			Console.WriteLine(fb)
		Next
	End Sub
End Module

Thus, those wanting to migrate their VB6 to VB.NET with their funny enums are out of luck (not that they'd have far more problems beside this case). But more importantly, the example invalidates the rationale that they chose < > because of compatiblity.

The syntax is in no way compatible with VB6. The complete lack of familiarity was and still is the primary complaint against it as a "successor" to VB. It's VB in name only.

I wasn't claiming that the two languages are equivalent, they're clearly vastly different beasts. Just that the operators (in fact most of the keywords) have similar (identical?) semantics in both, and that was by design.
Anyway, I think we've raised all relevant discussion points, over to Wayne to make a call.

@bclothier I'm wondering if there's some underlying limitation of the CLR that causes that, or maybe it's just so that VB.Net can interop with other CLR languages.

One last point to note I want to clarify, when I say "disruption"... I don't mean just the need to find/replace the user code from me and others (if you're inexperienced with RegEx it's a little more complicated because there's no simple way to catch all the endings), I also mean, how much is this going to delay v1 for Wayne to recode everything to use a different symbol, run the tests on it, update all the tB internal code... how many bugs/regressions will be introduced, how long will it take to fix those... I really doubt it's a simple regex for him. So that's part of what I mean by disruption; with that plus the user code; I just can't see resolving such a small, obscure potential future issue as worth it.

Good point.

I'm not so much worried about this particular obscure case, I'm sure we can find a way to work around it. I'm mainly concerned that other cases will emerge as attributes get enabled for use in more places. My hunch (and it is just a hunch) is that square brackets are a lot less likely to cause problems in the future, purely because they are valid in fewer settings in VBx (only in expressions?)

Also, I'd like to apologise if I overheated this discussion, I meant no offence. I know everyone wants to make twinBASIC the best product possible

@bclothier I'm wondering if there's some underlying limitation of the CLR that causes that, or maybe it's just so that VB.Net can interop with other CLR languages.

Possibly but it doesn't matter if that was the reason, given that the sample code disprove that the compatibility was a factor in choosing the < > syntax for VB.NET. This section on escaped name seems to support the theory that compatibility wasn't the primary factor. Thus, I think that's enough to demonstrate that's not the primary reason VB.NET went with the < > for the attributes. The actual reason they chose the < > syntax is moot now that we've established it wasn't because of compatibility.

I'd like to apologise

Hey, we're professional dead horse beaters here! This is what we do! No apologies needed.

I'm not so much worried about this particular obscure case, I'm sure we can find a way to work around it. I'm mainly concerned that other cases will emerge as attributes get enabled for use in more places after v1. My hunch (and it is just a hunch) is that angle brackets are a lot less likely to cause problems in the future, purely because they are valid in fewer settings in VBx (only in expressions?)

The big concern with that is inline attributes... right now we only have one, [TypeHint()]; is there a possible conflict if inline attributes are introduced to arg lists without ()? That would be a more significant issue as I definitely see the need to add [Out] in the future. But if it's just conflicts with new syntax-- again it wouldn't be a concern because any new syntax would be designed to work with the existing rules for the language.

Also, I'd like to apologise if I overheated this discussion, I meant no offence. I know everyone wants to make twinBASIC the best product possible.

I was worried about coming across that way too, but I think we've kept this entirely civil and issue focused... great debates like this where we explore  all the issues in depth between people who want what's best for the language is how you get great solutions. So also sorry if I've come across that way, I just enjoy a good debate, you've raised a lot of good points too and I know you're also thinking about what's best for tB.

Agree, I think this has been a lively but civil debate.

I think I'm just paranoid about v1, that we'll make a wrong turn and regret it later. Maybe for this, maybe for something else. Maybe it'll all be fine. Certainly Wayne has the best view on that...
Maybe I just need to chill out :-)


[Feature Request] Operate color temp and brightness separately

AFAIK, right now, the changes in brightness and color temp take place at the same time. But the problem is that with MQTT lights, both the attributes are set to change at the same time. Some MQTT smart bulbs can take only one attribute change at a time. So, for me only the color temp changes or the brightness. Both attributes never change. If you could add an option to change the attributes separately, it would be great.

Is this true for all MQTT lights?

@psbankar could you try the latest commit, I've added a separate_turn_on_commands option.

This is a duplicate of https://github.com/basnijholt/adaptive-lighting/issues/16.

I think psbankar means for his light, when adaptive-lighting sends the command to the lights [60% brightness, 1000k], it only picks up the 60% brightness and the 1000k does not get set. It may fix the issue to have send the [60% brightness] setting and THEN [1000k] setting which will allow the lights to react to each new setting seperatly

@nickg90, a right, I misremembered what you were asking.

Yes, @nickg90 got it right. In the latest commit, the light on command is triggering before the usual color temp and brightness command so it didn't work for me.

Could you tell me the exact sequence of commands that you need?

As @nickg90 said, I need the brightness and color_temp/RGB commands split up. i.e you could use a separate command for setting the brightness and separate for color_temp/RGB.

Yes, that is exactly what I implemented.
Could you try it?

Ok, I figured out what was going wrong for me. Because of transition, color_temp, and brightness attributes, three separate commands were being sent. And because of the transition command, the light was turning on at full brightness again. I have fixed the issue for me by adding a condition to ignore the transition command.

That shouldn't be needed, I can fix it.
Are you able to do?
- service: light.turn_on
  data:
    color_temp: ...
    entity_id: light.yolo]
    transition: ...
- service: light.turn_on
  data:
    brightness: ...
    entity_id: light.yolo
    transition: ...

Yes those commands work

OK then I should change the implementation.
The only thing you need to do separately is the color and brightness?

Yes, that's right. You can combine transition with color and brightness so only two commands are sent.

I've made the changes accordingly, now it sends one light.turn_on for

brightness (and optionally white_value) + transition
color + transition

I consider this solved. Please ping me here if this is not the case.


Allow client to get team member details

Issue that this pull request solves
Closes: #723
Proposed changes

Allow getting team member details.
Add test for getting team member details.

Types of changes
Put an x in the boxes that apply

[ ] Bugfix (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 not work as expected)
[ ] Documentation update (Documentation content changed)
[ ] Other (please describe):

Checklist
Put an x in the boxes that apply

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] My changes does not break the current system and it passes all the current test cases.

@kushal98 It's done.

@Kajol-Kumari It's done.

@Kajol-Kumari Sorry I tried to rename the feature branch. It deleted it and created a new one with the new name.
I will make a new PR.