Fix ros2 control xacro

@destogl Would you have time to have a look at this? Thanks!

@destogl I rebase it which fixed the formatting check. Iit is ready to be merged.
@galou Thanks for the improvement!


Make shebang detection cheaper

String#lines can potentially allocate many strings depending on the
number of newlines in the string.  That might be OK if the file we're
looking at is actually a file with a shebang in it (because we might
eventually use every line).  But it is not OK when the file isn't a
shebang file because we end up allocating many objects for no reason.
This commit reduces the number of allocations it takes to determine
whether or not the string is interesting to the Shebang class.
Here is a benchmark:
require "linguist/shebang"

def allocs
  x = GC.stat(:total_allocated_objects)
  yield
  GC.stat(:total_allocated_objects) - x
end

file = "foo\n" * 1000

p allocs {
  Linguist::Shebang.interpreter(file)
}

Before this commit:
$ bundle _1.17.2_ exec ruby -I lib:test thing.rb
1003

After this commit:
$ bundle _1.17.2_ exec ruby -I lib:test thing.rb
2

It's now at 0 allocations on a "miss".


Discussion: TV remote events order (question)

Description
Consider the code bellow. In the tvOS when navigating up and down with the remote I'm getting the following order of events:
LOG      focus
LOG      blur
LOG      blur
LOG      blur
LOG      blur
LOG      down

Shouldn't it be the other way arround? Fire the remote tap first, then fire the blur event and finally the focus?
React Native version:
info Fetching system and libraries information...
System:
    OS: macOS 11.2
    CPU: (8) x64 Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
    Memory: 69.52 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.15.5 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.11 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.10.0 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 14.4, DriverKit 20.2, macOS 11.1, tvOS 14.3, watchOS 7.2
    Android SDK: Not Found
  IDEs:
    Android Studio: Not Found
    Xcode: 12.4/12D4e - /usr/bin/xcodebuild
  Languages:
    Java: Not Found
    Python: 2.7.16 - /usr/bin/python
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.13.1 => 16.13.1
    react-native: Not Found
    react-native-macos: Not Found
    react-native-tvos:  0.63.4-0
  npmGlobalPackages:
    *react-native*: Not Found

Code example:
const App = () => {
  const myTVEventHandler = (evt) => {
    console.log(evt.eventType);
  };

  useTVEventHandler(myTVEventHandler);

  return (
    <View>
      <Button label="Button 1" />
      <Button label="Button 2" />
    </View>
  );
};

The different blur events are actually coming from different views.  Try the following:
import React from 'react';
import {
  View,
  Button,
  useTVEventHandler
} from 'react-native';

const App = () => {
  const myTVEventHandler = (evt) => {
    console.log("Type: " + evt.eventType + ", Tag = " + evt.tag);
  };

  useTVEventHandler(myTVEventHandler);

  return (
    <View>
      <Button title="Button 1" />
      <Button title="Button 2" />
    </View>
  );
};

export default App;

This will show you the React tags for the views that are firing the focus and blur events:
[Thu Feb 25 2021 16:46:28.719]  LOG      Type: down, Tag = undefined
[Thu Feb 25 2021 16:46:29.920]  LOG      Type: focus, Tag = 9
[Thu Feb 25 2021 16:46:29.920]  LOG      Type: blur, Tag = 23
[Thu Feb 25 2021 16:46:29.930]  LOG      Type: blur, Tag = 25
[Thu Feb 25 2021 16:46:29.930]  LOG      Type: blur, Tag = 27
[Thu Feb 25 2021 16:46:29.940]  LOG      Type: blur, Tag = 19
[Thu Feb 25 2021 16:46:29.180]  LOG      Type: up, Tag = undefined
[Thu Feb 25 2021 16:46:31.622]  LOG      Type: focus, Tag = 19
[Thu Feb 25 2021 16:46:31.623]  LOG      Type: blur, Tag = 23
[Thu Feb 25 2021 16:46:31.623]  LOG      Type: blur, Tag = 25
[Thu Feb 25 2021 16:46:31.624]  LOG      Type: blur, Tag = 27
[Thu Feb 25 2021 16:46:31.625]  LOG      Type: blur, Tag = 9
[Thu Feb 25 2021 16:46:31.687]  LOG      Type: down, Tag = undefined
[Thu Feb 25 2021 16:46:58.162]  LOG      Type: focus, Tag = 9
[Thu Feb 25 2021 16:46:58.163]  LOG      Type: blur, Tag = 23
[Thu Feb 25 2021 16:46:58.163]  LOG      Type: blur, Tag = 25
[Thu Feb 25 2021 16:46:58.164]  LOG      Type: blur, Tag = 27
[Thu Feb 25 2021 16:46:58.164]  LOG      Type: blur, Tag = 19
[Thu Feb 25 2021 16:46:58.228]  LOG      Type: up, Tag = undefined

Hi @dlowder-salesforce, thanks for the response. My question here is really about the event order.
Let's say we want to know when the user pressed a direction key when on a button.
Since the focus event fires before the tv remote key, in the example below if we enter the app an press 3 times down we're going to get
LOG      You've pressed down on button 2
LOG      You've pressed down on button 3
LOG      You've pressed down on button 3

instead of
LOG      You've pressed down on button 1
LOG      You've pressed down on button 2
LOG      You've pressed down on button 3

or there is another way to accomplish this?
Code example:
import React, { useState } from "react";
import { View, useTVEventHandler, Text, TouchableOpacity } from "react-native";
import "react-native/tvos-types.d";

class Button extends React.Component<any> {
  render() {
    return (
      <TouchableOpacity
        activeOpacity={0.7}
        onPress={this.props.onPress}
        onFocus={this.props.onFocus}
      >
        <Text>{this.props.title}</Text>
      </TouchableOpacity>
    );
  }
}

const App = () => {
  const [state, setState] = useState(0);

  const myTVEventHandler = (evt) => {
    if (evt.eventType === "down") {
      console.log("You've pressed down on button " + state);
    }
    if (evt.eventType === "up") {
      console.log("You've pressed up on button " + state);
    }
  };

  useTVEventHandler(myTVEventHandler);

  return (
    <View>
      <Button onFocus={() => setState(1)} onPress={() => {}} title="Button 1" />
      <Button onFocus={() => setState(2)} onPress={() => {}} title="Button 2" />
      <Button onFocus={() => setState(3)} onPress={() => {}} title="Button 3" />
    </View>
  );
};

export default App;

I do see the problem with event ordering.  In order to accomplish what you want, I think we would want to make some changes in the iOS/tvOS native code to include the direction information in the focus event.  We are already using this direction information in the implementation of nextFocusUp, nextFocusDown, etc.  See this code in React/Views/RCTTVView.m, which uses the focusHeading property of the focus event context:
- (BOOL) shouldUpdateFocusInContext:(UIFocusUpdateContext *)context {
  if (self.isFocused) {
    if (_nextFocusUp != nil && context.focusHeading == UIFocusHeadingUp) {
      self->_nextFocusActiveTarget = _nextFocusUp;
      [self setNeedsFocusUpdate];
      return false;
    }
    if (_nextFocusDown != nil && context.focusHeading == UIFocusHeadingDown) {
      self->_nextFocusActiveTarget = _nextFocusDown;
      [self setNeedsFocusUpdate];
      return false;
    }
    if (_nextFocusLeft != nil && context.focusHeading == UIFocusHeadingLeft) {
      self->_nextFocusActiveTarget = _nextFocusLeft;
      [self setNeedsFocusUpdate];
      return false;
    }
    if (_nextFocusRight != nil && context.focusHeading == UIFocusHeadingRight) {
      self->_nextFocusActiveTarget = _nextFocusRight;
      [self setNeedsFocusUpdate];
      return false;
    }
    self->_nextFocusActiveTarget = nil;
    return true;
  }
  self->_nextFocusActiveTarget = nil;
  return true;
}

I made the changes needed to propagate the context.focusHeading value up to the JS app layer... see branch https://github.com/react-native-tvos/react-native-tvos/tree/focusdirection-test
With this branch, I ran this example:
import React from 'react';
import {
  View,
  Button,
  useTVEventHandler
} from 'react-native';

const App = () => {

  const myTVEventHandler = (event) => {
    console.log('' + event.eventType + ' ' + event.direction + ' ' + event.tag);
  };

  useTVEventHandler(myTVEventHandler);

  return (
    <View>
      <Button
        title="Button 1" />
      <Button
        title="Button 2" />
    </View>
  );
};

export default App;

and see that focus and blur events now have the direction (down, up, etc.) of the gesture that caused the change.
Will this work for your use case?

Thanks for the reply and the test branch!
I've done some experiments with that branch and seems we still cannot identify when there was a down tap in the last button.
With the example you've provided, this is the logs it generates hen entering the app and tap down twice.
focus down 19
blur down 23
blur down 25
blur down 27
blur down 9
down undefined undefined
down undefined undefined

the first down generates the first 6 log lines, and the second generates the last line. Now we know when down was tapped while on 1st button by listening to its blur event ( blur down 9 ) but for the second button since there is no element bellow, there is no blur event, and no way to know if down was tapped in this button.
Probably a way to workaround this will be register when the button was focused and add a counter of the times down is tapped and discard the first 'down' event. When the button is blurred, reset the counter. But it will not work if the button received focus from other way than the remote. Have to think a bit more how to workaround this.
The onFocus and onBlur events on the Button component are a nice addiction.

When you are on the second button, there is nothing focusable below it, so no focus events are received when you swipe down from there.  The down event is not associated with any view -- it is generated from a gesture handler in the root view, and just tells you that the down gesture happened, and nothing else. So yes if you need to know that, a workaround would be needed.

when I use useTvEventHandler or even TVEventHandler it is throwing an error
(0, _reactNative.useTVEventHandler) is not a function. (In '(0, _reactNative.useTVEventHandler)(myTVEventHandler)', '(0, _reactNative.useTVEventHandler)' is undefined)
what would I do

when I use useTvEventHandler or even TVEventHandler it is throwing an error (0, _reactNative.useTVEventHandler) is not a function. (In '(0, _reactNative.useTVEventHandler)(myTVEventHandler)', '(0, _reactNative.useTVEventHandler)' is undefined)
what would I do

Most of TV OS code as been removed on RN 0.64 release (https://github.com/facebook/react-native/pull/29407). But actual doc is not clear...


Refactor new table creation and add setting options on location & naming format

Things in this PR:

Refactored new table creation with Obsidian's native way of avoiding file collision.
Add new setting options to allow:

Creating new table at Obsidian's attachments folder (specified in Obsidian's settings)
Creating new table under a custom folder
Creating new table with name ${currentNoteName}-${stamp}

Tests
Settings Page

Using obsidian's attachments folder - "Same folder as current file"
https://user-images.githubusercontent.com/11176415/231295730-432102ba-f7a0-4e44-b650-57d14e415a28.mov
Using custom folder (and the folder does not exist yet, will be created at runtime)
https://user-images.githubusercontent.com/11176415/231295795-545fae8a-cc36-47ae-bf59-f76af8365ec9.mov
Using the timestamp naming
Note that the current location setting is Use Obsidian's attachments folder - Same folder as current file.

When no file has been opened yet, go with the default naming and root vault folder

https://user-images.githubusercontent.com/11176415/231297022-4b112ac2-2958-42a0-b9a1-8bf61a382e98.mov

When current file is not a note (i.e., markdown file), still go with the default naming and root vault folder

https://user-images.githubusercontent.com/11176415/231297232-5747a05a-9659-46af-81c5-1011161081f5.mov

When current file is a note, use the timestamp naming style and same folder

https://user-images.githubusercontent.com/11176415/231297381-32e51270-be71-479b-9eda-5c648d92289a.mov

And for the ease of cherry-picking, I squashed all commits into one (also intended for a clean commit history, cuz it was full of reverts/nit clean-ups)

Great! I'll merge it in


Add rotate image option to iss.py

Add option to rotate the map 180°.
To enable it, edit the file iss.py, locate and remove comments from the following lines:
    # Rotate image 180
    #  imageRed = imageRed.transpose(Image.ROTATE_180)
    #  imageBlack = imageBlack.transpose(Image.ROTATE_180)

Looks great, thanks!


lib: deprecation, warnRenamed, release constants

Introduce the concept of attribute deprecation.
A new library contains deprecation functions (for now only
renamedWarning) that annotate functions and print a deprecation
warning.
In order to manage time until a symbol is removed, we introduce release
constants that are used in the warning messages and contain release
names and dates.
The printed warning only uses a trace message at the moment, this should
be improved.
As an example, opusTools is renamed to opus-tools, with the
reasoning that the related vorbis-tools uses a different naming
scheme. Users on master will immediately get a warning, users of stable
channels can find out about the changed attribute from the changelog
when they update to a new release.
cc @edolstra @aszlig @vcunat

(bikeshedding) I'd prefer changing renamedWarning to warnRenamed.
Additionally using lib.warn adds a "WARNING: " prefix if you use it instead of builtins.trace.

(bikeshedding) I'd prefer changing renamedWarning to warnRenamed.

Thanks, I was dissatisfied with the name myself.

I remember seeing a checklist for releases somewhere. We should add “search and delete all that is deprecated in this version, add each item to the release notes; do it in one commit”.

This has been tried before, but the problem is that it makes nix-env -qa print out lots of warnings (because it evaluates deprecated attributes).

@Profpatsch just landed in master at https://github.com/NixOS/nixpkgs/commit/ed6ea7416aafdf96aa6cc87e165569bb79c42be0

I’m not sure, I haven’t used nix-env for over a year I think. I hear it does … strange things. :)
Can we add some metadata it can use to find out about deprecations? I’d like to get rid of the special “skipping abort and error from nix-env sooner or later, it makes a lot of things very awkward.

Still to do would be

warnRemoved
warnSemanticChange (new package behind the name etc.

Ref. about problems with nix-env: https://github.com/NixOS/nixpkgs/commit/8e8e23de33

At the moment we only have trace as a way of putting stuff on stderr while evaluating. trace was originally designed to enable debugging, but has been abused a lot for warnings.
What do you think about introducing a warning <msg> builtin, which prints a yellow Warning:  to stderr? Those can then be ignored by tools that want to strictly evaluate as much of nixpkgs as possible, and we get trace back for debugging, as was originally intended.
cc @edolstra @vcunat.

Yeah, perhaps. Tools can filter those lines easily enough now (e.g. by a simple grep), though it's not perfectly reliable in principle.

@vcunat With your changes to mkDerivation recently, do you think the things in this PR could work now?

It's probably a bit late to get this together for 18.09, but I really think either this or something doing the same job is in need.
There were a couple sparks flying around lately with regards to deprecation of attributes;
We had a chat about something similar recently on #nixos. One main thing differed from your approach in the idea thrown around: instead of approaching the deprecation in two stages (deprecate, remove), add an additional step (pre-deprecate, deprecate, remove). The pre-deprecation step would allow through an opt-in configuration to get the warnings during the pre-deprecation period.
The three-step approach allows users not to worry with a deprecation warning stemming from some tooling they use. Imagine tool "A" using nix, and using the attribute foo which has just been deprecated for the next NixOS release cycle. The author of "A" may not be able to fix their tool in time with the release, and the now-deprecated option shows up in their user systems, somehow confusing them. Not the most amount of value for use inside nixpkgs, but probably much more for third-parties building solutions around nix and nixpkgs. (I know my users at $client would all let me know about a new deprecation warning!)
Let me know your thoughts about that additional step.

TLDR: 👍 want to see this or something doing the same job hit 19.03.

instead of approaching the deprecation in two stages (deprecate, remove), add an additional step (pre-deprecate, deprecate, remove)

I wouldn’t overcomplicate it, someone has to remember to change these after all. I haven’t seen systems that do it like this so far. I imagine the overhead is not worth the gains in practice..

What really is the need for removing compability aliases? It doesn't really cost us anything to keep an alias like opusTools = opus-tools around.
Also, removedAt = lib.releases.next is inherently stateful - if people actually write that, it would mean the package would never be removed since its removal is always in the future. (Or you would have to consult the Git history to see when the removedAt line was first added.)

I am operating only under the assumption that there is a need or want to remove compatibility aliases.
Though, something similar would be needed if something is going to be dropped, right? Dropping something from Nixpkgs will cause issues to the end-users (we can easily manage the change inside Nixpkgs).

About complicating with pre-deprecation:
This is for end-user user-friendliness. The warnings will cause headaches to the end-user using additional tools built on top of nixpkgs. The integrator (a nixpkgs user that built the tool built on top of nixpkgs) would be expected to follow up with the news (reading the release notes, hoping it made it in) or better with the option, using the the option opting-in for the warning one release beforehand. This is not for the simple "nixpkgs and nixpkgs users" situation, but one that has to be thought of, users using tools built by other users of nixpkgs.

I will add a bit, and maybe be a bit harsh:
Let's not stop or stall the discussion about the deprecation feature because there is no need since we can keep compatibility aliases. Please either review under the assumption the feature being implemented in whole is required and needed, or reject the feature as a whole if undesirable. Right now the half-rejection-because-we-keep-everything makes this a less desirable feature to look at and work on since there's a heavyweight decision maker casting a negative cloud over the future of the feature.
In the event the feature is desirable only or some uses, and a technical solution does not exist restricting its use (e.g. dropping aliases for renamed attributes), it'll have to be documented and rely on the committers/members to review appropriately.

Any updates on this pull request, please?

Don’t think this will ever happen. Thanks for triaging.


Double hyphen not handled correctly in some situations

Try
_usage () { echo "usage" 1>&2; exit ${1:-0}; }
_die () { printf "\n$1\n" 1>&2; _usage ${2:-1}; }
while read args ; do
  OPTIND=1
  while getopts_long ":hvab: alpha bravo: charlie" OPT  $args ; do
    case "$OPT" in
      h|help   ) _usage          ;; # E.g., help option
      v|verbose) ((++verbose))   ;; # E.g., an incrementing option
      a|alpha  ) alpha=1         ;; # E.g., non-arg-requiring option
      b|bravo  ) bravo="$OPTARG" ;; # E.g., argument-requiring option
      charlie  ) charlie=1       ;; # E.g., long-option-only
      ':') _die "OPTION '${OPTARG}': MISSING ARGUMENT" 1;;
      '?') _die "UNKNOWN OPTION: '${OPTARG}'"          2;;
    esac
    echo "OPT=$OPT, OPTIND=$OPTIND, OPTARG=$OPTARG"
  done
done < <( cat <<EOF
-a-- param
EOF
)

and compare with the behavior of getopts. getopts is correctly able to stop parsing when the double-hyphen is grouped with the non-argument-requiring option, whether or not it is space separated, and whether or not '-:' is included in the shortopt spec.

This is a strange edge case where it's not so clear what the correct behaviour is, IMO, but it does make sense to do the same as getopts.

Thanks for reporting this guys! It took me a while, but I finally had a chance to look into it, and it turns out the issue isn’t just with "--" alone.
The root cause is that Bash’s built-in getopts supports adjacent variable-value syntax, like what you often see when compiling C: gcc -Llib -o example example.c -lmylib. Unfortunately, getopts_long can’t handle that properly.
The good news is the fix is fairly straightforward – #f263a9c – and will be available in getopts_long v1.2.3, as soon as I merge #20.


collect requirements for API documentation widgets

this issue is to collect all usecases for mdx widgets which are needed for the API docs.

An icon next to the created URL of a widget to copy the link address into the clipboard, so that I can paste it easily.

done


SliceBox: allow Deref into &[T]

Allows more convenient use of SliceBox where one doesn't care whether
it represents a Vec or &[T] and can handle using a &[T].

How are you using this in your code?  The reason that I didn't add this impl is because slicebox should be used only for immediate encoding / decoding and shouldn't really be used outside of that, so there shouldn't be a case where you aren't 100% certain that it represents a Vec or &[T].

I'm using structs I encode/decode directly for things in my programs other than encoding and decoding.
Rather than create duplicates of all my encoded/decoded structs just to push the same data around, doing this was more convenient.
Note that there is already a (nearly identical) implementation of Deref for RefBox (which this code was based on) which, as far as I can see, is provided for similar uses.

Fair enough; thanks for the pull request!


Configuration Document is Incorrect

The installation method in this document is wrong. The install.bat method displays a command prompt to the user during installation and the detection method fails should the product be updated to a newer version.
A better detection method is required to cope with the frequent version updates.
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: ffd521ea-089c-001c-ad4f-e1bfc6f94285
Version Independent ID: e3d308c4-f527-a202-55ea-249d9ede8e99
Content: Install the Remote Desktop client for Windows on a per-user basis with Intune or Configuration Manager - Azure
Content Source: articles/virtual-desktop/install-client-per-user.md
Service: virtual-desktop
GitHub Login: @Heidilohr
Microsoft Alias: helohr

@Heidilohr
Can you please check and add your comments on this doc update request as applicable.

Hi @marshalexander99 - thanks for the feedback. I agree with you on all those points, so I've rewritten the processes to use a PowerShell script, detection using the presence of the .exe file, and changed the uninstall command to be universal, regardless of the version.  The changes should be visible later today.
#please-close


Test failure: ResponseBody_SyncWriteEnabledByDefault_ThrowsWhenDisabled

This issue was made automatically. If there is a problem contact ryanbrandenburg.
This test failed with the following error:
System.Net.Http.HttpRequestException : Error while copying content to a stream.
---- System.IO.IOException : The read operation failed, see inner exception.
-------- System.Net.WebException : The request was aborted: The request was canceled.
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at Microsoft.AspNetCore.Server.HttpSys.Listener.ResponseBodyTests.<ResponseBody_SyncWriteEnabledByDefault_ThrowsWhenDisabled>d__0.MoveNext() in /_/test/Microsoft.AspNetCore.Server.HttpSys.FunctionalTests/Listener/ResponseBodyTests.cs:line 50
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
----- Inner Stack Trace -----
   at System.Net.Http.HttpClientHandler.WebExceptionWrapperStream.BeginRead(Byte[] buffer, Int32 offset, Int32 count, AsyncCallback callback, Object state)
   at System.Net.Http.StreamToStreamCopy.StartRead()
----- Inner Stack Trace -----
   at System.Net.ConnectStream.BeginRead(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
   at System.Net.Http.HttpClientHandler.WebExceptionWrapperStream.BeginRead(Byte[] buffer, Int32 offset, Int32 count, AsyncCallback callback, Object state)

Other tests within that build may have failed with a similar message, but they are not listed here. Check the link above for more info.
This test failed on 2.2.
CC Eilon

This comment was made automatically. If there is a problem contact ryanbrandenburg.
Please use this workflow to address this flaky test issue, including checking applicable checkboxes and filling in the applicable "TODO" entries:

Is this actually a flaky test?

No, this is a regular test failure, fix the test/product (TODO: Link to commit/PR)
Yes, proceed below...

Is this test failure caused by product code flakiness? (Either this product, or another product this test depends on.)

[ ] File a bug against the product (TODO: Link to other bug)
Is it possible to change the test to avoid the flakiness?

Yes? Go to the "Change the test!" section.
No?

[ ] Disable the test (TODO: Link to PR/commit)
[ ] Wait for other bug to be resolved
[ ] Wait for us to get build that has the fix
[ ] Re-enable our test (TODO: Link to PR/commit)
[ ] Close this bug

Is it that the test itself is flaky? This includes external transient problems (e.g. remote server problems, file system race condition, etc.)

Is there is a way to change our test to avoid this flakiness?

Yes? Change the test!

[ ] Change the test to avoid the flakiness, for example by using a different test strategy, or by adding retries w/ timeouts (TODO: Link to PR/commit)
[ ] Run the test 100 times locally as a sanity check.
[ ] Close this bug

No?

Is there any logging or extra information that we could add to make this more diagnosable when it happens again?

Yes?

[ ] Add the logging (TODO: Link to PR/commit)

No?

[ ] Delete the test because flaky tests are not useful (TODO: Link to PR/commit)

Full test name: Microsoft.AspNetCore.Server.HttpSys.Listener.ResponseBodyTests.ResponseBody_SyncWriteEnabledByDefault_ThrowsWhenDisabled
@muratg - please assign.


Package request: volare

Project description
It would be nice to package volare, which is a kind of 'remix' of sway. Ideally it should be possible to re-use most of the existing sway packaging/infrastructure, and 'just' replace the sway compositor with volare. I'm the volare upstream, so I'm definitely happy to make any changes there if/when helpful :).
/cc @primeos @Synthetica9 @colemickens
Metadata

homepage URL: https://codeberg.org/raboof/volare
source URL: https://codeberg.org/raboof/volare
license: mit
platforms: linux

Indeed this issue can now be closed, the flake works great!


acces a song by typing a word

Describe your problem here.
I want to make so when you type a secret word on you're keyboard, it opens a secret song, but, I'm not a coder, neither a lua guy, so, can someone pass me a script to do that?
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
No

don't ask people to code for you, learn to do it yourself

alright then, i'll find a guide

don't ask people to code for you, learn to do it yourself

no cap tho

don't ask people to code for you, learn to do it yourself

no cap tho

probably me too 💀


Added Leetcode-1773 Count Items Matching a Rule

Added python solution for sum Leetcode-1773 Count Items Matching a Rule-
You are given an array items, where each items[i] = [typei, colori, namei] describes the type, color, and name of the ith item. You are also given a rule represented by two strings, ruleKey and ruleValue.
The ith item is said to match the rule if one of the following is true:
ruleKey == "type" and ruleValue == typei.
ruleKey == "color" and ruleValue == colori.
ruleKey == "name" and ruleValue == namei.
Return the number of items that match the given rule.

Can you also like the repo @Shifa2505


Fedora 39 packit jobs fail

Which jobs are failing?
All fedora 39 pack RPM jobs, like: https://dashboard.packit.dev/jobs/copr/1883601
Which tests are failing?
The package builds.
Since when has it been failing?
Since the beginning of this week.
Reason for failure (if possible)
Additional repo copr_rhcontainerbot_podman_next 2.7 kB/s | 341  B     00:00
Errors during downloading metadata for repository 'copr_rhcontainerbot_podman_next':
  - Status code: 404 for https://download.copr.fedorainfracloud.org/results/rhcontainerbot/podman-next/fedora-39-x86_64/repodata/repomd.xml (IP: 2600:9000:2509:4400:4:bbc1:1840:93a1)
Error: Failed to download metadata for repo 'copr_rhcontainerbot_podman_next': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

Anything else we need to know?
Nothing so far.

@lsm5 is there anything we can do to fixup the failing package builds? :pray:


Update tutorial.json

Related Issues

issue goes here

Proposed Changes

Change 1
Change 2

Additional Information

Any additional information or context

Checklist

[ ] Tests
[ ] Translations
[ ] Documentations

Screenshots

Original
Updated

** Original Screenshot **
** Updated Screenshot **

solve merge conflicts @B2prakash


fixed footnotes formatting

@arielsaghiv : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

Hi @arielsaghiv - this PR has merge conflicts so we can't merge it.
Please set up access to the private repo as per https://review.docs.microsoft.com/en-us/help/contribute/contribute-get-started-setup-github?branch=main, and make this change again in the private repo.
You'll get a build validation and a staging site where you can verify your change before signing off - this is totally in the scope of things you should be able to sign off on yourself.


Add additional tests for icmp-i128. Fixes #1136.

Tests added:

eq with nonzero values
gt with nonzero values
ge with nonzero values

The b1 legalization issues referenced in the discussion of #1136 appear to be resolved.
closes #1136

Hi Chris, thank you for the review!
Added the test to the x64 backend and tried to follow the naming scheme in that directory,
I noticed that the existing i128 compile test also covers these features, is it desirable to have overlapped compile and run tests?
The failing checks are due to a security advisory for the raw-cpuid crate.
Lastly, for my edification: is the x64 backed the lowering framework, as opposed to the older legalizing one?

Hi Chris, thank you for the review!
Added the test to the x64 backend and tried to follow the naming scheme in that directory,
I noticed that the existing i128 compile test also covers these features, is it desirable to have overlapped compile and run tests?
The failing checks are due to a security advisory for the raw-cpuid crate.
Lastly, for my edification: is the x64 backed the lowering framework, as opposed to the older legalizing one?

Thanks!

is it desirable to have overlapped compile and run tests?

Yes, it's fine; nominally at least, they're testing different things (requiring a specific lowering, vs. ensuring that the lowering actually executes to produce desired results). IMHO we should flesh this out a bit more in the future and add run tests for everything that's required by CLIF semantics, but that's for a later time!

failing checks are due to a security advisory

I'll go ahead and do a quick PR to bump the version, then we should be able to merge main into this branch to make cargo-deny happy.

Lastly, for my edification: is the x64 backed the lowering framework, as opposed to the older legalizing one?

Yes, exactly. We sometimes call it a Machinst backend or "new-style backend" and it's based on lowering to VCode.

Thanks!

is it desirable to have overlapped compile and run tests?

Yes, it's fine; nominally at least, they're testing different things (requiring a specific lowering, vs. ensuring that the lowering actually executes to produce desired results). IMHO we should flesh this out a bit more in the future and add run tests for everything that's required by CLIF semantics, but that's for a later time!

failing checks are due to a security advisory

I'll go ahead and do a quick PR to bump the version, then we should be able to merge main into this branch to make cargo-deny happy.

Lastly, for my edification: is the x64 backed the lowering framework, as opposed to the older legalizing one?

Yes, exactly. We sometimes call it a Machinst backend or "new-style backend" and it's based on lowering to VCode.

@kaseyc I've fixed the cargo-deny issue in #2603; you should be able to merge in main now to get a green CI.

@kaseyc I've fixed the cargo-deny issue in #2603; you should be able to merge in main now to get a green CI.

Rebased into head.

Rebased into head.

Thanks!

Thanks!


added missing CustomerType optional param

Missing

Query
CustomerType  optional
Indicates whether to request pricing information from the point of view of Consumer or Business buyers. Default is Consumer.
enum (CustomerType)

Query	CustomerType
optional	Indicates whether to request pricing information from the point of view of Consumer or Business buyers. Default is Consumer.	enum (CustomerType)
Example:
    try:

        res = Products(account=store, marketplace=marketplace).get_competitive_pricing_for_skus(
            marketplaceIds=marketplace_id,
            seller_sku_list=sku_list,
            CustomerType='Business'
        )

        logging.info(res)
        result = res.payload
        # logging.info(result)

    except SellingApiException as ex:
        logging.info(ex)

@denisneuf Hey Daniel, should we add a link to each of our repos? Something like:
The client is also available for the advertising/selling API
??

Yes, I think so, as your client has the same way of use, even the credentials is a little bit different the user if get familiar with one could use both with no learning.
In fact I use both at the same time to cross data between advertising and selling : )
Just post your link in your repo and I'll add in the advertising too.
Thanks!

Yeah, that's what I thought. I'll add it later.


Not able to group checkbox groups

Hi,
First of all thanks for this awesome library. I am using this in my application where I have to use it like Checkbox in some cases and radio buttons in some cases. Here when I am trying to group checkboxes that are created in for loop it is not working. Here is my code.
int xVal = 10;
            NSMutableArray *checkBoxArray = [[NSMutableArray alloc] init];
            for (int i=0; i<3; i++) {
                BEMCheckBox *myCheckBox = [[BEMCheckBox alloc] initWithFrame:CGRectMake(xVal, 0, 50, 50)];
                myCheckBox.tag = 100+i;
                myCheckBox.delegate = self;
                [cell addSubview:myCheckBox];
                [checkBoxArray addObject:myCheckBox];
                xVal += 60;
            }
            BEMCheckBoxGroup *boxGroup = [BEMCheckBoxGroup groupWithCheckBoxes:checkBoxArray];
            boxGroup.selectedCheckBox = checkBoxArray[0];
            boxGroup.mustHaveSelection = YES;

Please let me know if this implementation is wrong.

Thanks for the kind words @upendrasiripurapu!
What precisely isn't working for you?
Your implementation looks fine to me.

When I am adding myCheckBox to BEMCheckBoxGroup then it should work like radio buttons right, like anytime only one button should be selected and others should be deselected. But here it is now working like that.
Regards

This is indeed a bug on our side of things. Good catch! I submitted a PR (#55) that should fix the issue. Feel free to review it =)

This is fixed with the release of 1.4.1. Thank you for your contribution @upendrasiripurapu!


format ExprJoinedStr

wip to check direction
currently generates invalid python because it doesn't know to switch quote style when the nesting is inside a formatted value like in f"MOAR {' '.join([])}" so it makes the inner quotes double as well
hopefully eventually fixes #5913

oh. not sure how i managed to miss this, but black doesn't (yet) format expressions inside f-strings

so this approach works.. not sure what we think of it though
note that FormattedValue isn't used at all with this impl and none of my related refactorings are needed (though i think we still want them). That will all be needed when we decide to start formatting things inside formatted values

hey @konstin did your recent ecosystem test pr also change (fix) it failing on errors? it looks like the most recently merged pr after that https://github.com/astral-sh/ruff/pull/6152 fails the checks (i was trying to figure out why i'm failing after rebasing onto main)

yes, sorry, fixed in https://github.com/astral-sh/ruff/pull/6202. Part of the problem is that i forgot to make the formatter ecosystem checks required for merging (but i don't think github properly shows in the PR UI that we could still merge your PR even with that check failing).

This is awesome. Are you interested in looking into "proper" f-string formatting? It isn't as high a priority to us as increasing coverage on other nodes but it would be a real differentiator to black

looking into "proper" f-string formatting

sure. do we need some mechanism to opt out of this behaviour for all the tests that are comparing to black?

looking into "proper" f-string formatting

sure. do we need some mechanism to opt out of this behaviour for all the tests that are comparing to black?

Are you expecting many differences? If not, then I don't think it's worth bothering. We can otherwise make it an option on PyFormatOptions which we already support loading for tests.

i thought i'd seen a bunch but maybe i'm misremembering
i started looking (maybe we can make an issue to have these discussions there instead) and came across something to run by you:
currently f"{{" is parsed as
ExprJoinedStr {values: [Constant(ExprConstant {
    value: Str(
        "{",

ie the escaped curly is rendered into the constant. is that what we want? if so i guess we need special handling when rendering to reproduce the escaping. or do we want to parse as something closer to the source and store the string "{{" instead?
do we do anything corresponding for regular string escapes like '\"'?

A discussion would be good because I tend to not look at merged PRs and the discussion also goes beyond of what this PR addressed.
Generally, it is very common for ASTs to undo string escapes, because the goal is to represent the semantic of the program and not the representation of the program in the source (this is different to a CST that preserves the code as is).
You can see that Ruff's parser removes the escape sequences of quotes too: Playground. I assume this happens inside of parse_string because the lexer isn't performing this operation (But I think it would be more appropriate for the lexer to perform this, but that requires Python's 3.12 f string parsing)


Update README.rst

replaced the irc channel with the current proper irc channel

Thank you for contributing to openstack/kolla!
openstack/kolla uses Gerrit for code review.
If you have never contributed to OpenStack before make sure you have read the
getting started documentation:
http://docs.openstack.org/infra/manual/developers.html#getting-started
Otherwise please visit
http://docs.openstack.org/infra/manual/developers.html#development-workflow
and follow the instructions there to upload your change to Gerrit.


Precompiles can emit logs.

This changes allows VM developers to emit logs from precompiles. This is particularly useful in the case we need to delay the execution of a task until the end of a transaction. In this case, we can emit a log, and in the end, if the whole tx succeeded/failed, watch logs and check if they trigger any specific behaviour.

I think if we want this to be accepted in the main repo, we need to enable this functionality using the feature flag.

You know, I'm unsure if this change makes sense in the main repo as its API breaking, but that would need to be up to the main repo owners, of course. I get for our intents and purposes it makes sense and solves one of our issues. Typically precompiles don't have logs though.
There is nothing wrong of having it a key component of our fork though, as long as we take great care and attention to keeping up to date with upstream.

This was merged upstream already


ImportError: No module named arbitrer

Hi team,
We couldn't run below comments.  PFA.
python3 -m arbitrage -m Paymium get-balance
python3 -m arbitrage -m Paymium,BitstampUSD get-balance

Then we have checked test commend (  nosetests arbitrage/ ). This is also got some error. PFA.

Kindly check and help to us ASAP.

the worst and dishonest trading company that I ever have had the misfortune of dealing with. They are, in my mind, criminals. I requested a withdrawal of £100,000 from my account. Within about 4 hours, the withdrawal had been put back into my account. Then my account was traded illegally with 11 trades taken and losing all the money. I complained to this company and they couldn't give a damn. I had to reach out to  oliviatrader 44 @ gmail. com to assist me in getting back my money. Glad I have all my money back now.
WhatApp +1 (423) 248 - 2140

Paymium module needs to be updated. Actually most of the market modules need an update.
Bitstamp, Kraken, Bitflyer seems to work fine though:
$ python3 -m arbitrage -m Bitstamp,Kraken,Bitflyer
2023-11-03 12:20:48,818 [INFO] profit: 1.440809 USD with volume: 0.197179 BTC - buy from BitFlyerUSD sell to BitFlyerEUR ~0.02%
2023-11-03 12:20:48,818 [INFO] profit: 0.004589 USD with volume: 0.000311 BTC - buy from BitFlyerUSD sell to PaymiumEUR ~0.04%

I've been exploring different options for managing my BTC transactions and came across an interesting alternative: flash BTC software. I've found that using a reliable flash BTC software can provide a more efficient and secure way to handle transactions. If anyone is interested in learning more, look at that repository (https://github.com/CrypToprexofficial/Free-flash-btc-sender) that provides more information and resources on the topic. Please keep in mind that it's essential to do your own research and due diligence when exploring new tools and methods.

THNEMANS ENMDKFMEARKTAKII SKDLME EMENAJA MSNDKKELLR;M EMMWJKSMAJKWKE!!!


ci: bump the version of esbuild to support decorator metadata

close https://github.com/privatenumber/tsx/issues/287 since https://github.com/evanw/esbuild/issues/104 esbuild upgraded to support decorator metadata recently.
Not sure if this change needs more testing or adding a testcase.. for now both pnpm test and CI=1 pnpm test passed.

btw, the lockfile change looks weird (pnpm version already lock to 9.1.1).  It's OK to close this PR and do this version bump through other quick change.

This is already upgraded in the development version of tsx (sponsors only).
I haven't released it yet because of the confidence level:

Probably at least half of the work for this feature went into creating a test suite that exercises many of the proposal's edge cases: https://github.com/evanw/decorator-tests. It has given me a reasonable level of confidence that esbuild's initial implementation is acceptable. However, I don't have access to a significant sample of real code that uses JavaScript decorators. If you're currently using JavaScript decorators in a real code base, please try out esbuild's implementation and let me know if anything seems off.

Feel free to test it out.

Released in https://github.com/privatenumber/tsx/releases/tag/v4.15.0


Multiple object tracking

Hi,
With respect to this video of walking people, could you use this model for tracking multiple people?
If yes, how can you do the same?

Hi, when l run this code 'run_tracker.m' just  in CPU.
An error occurred：“img=imResample(img, net.meta.normalization.imageSize(1:2)) , net have non-exitent field meta  ”
please this  is  the reason why ? Just  can be run in GPU?

Hi,when i run this code'tracker_ensemble.m'.An error occurred:When tap 'tracker_ensemble.m',output parameter positions not assigned.Please tell me the reason.Thank you.

As I am not exploring this thread, I am closing the issue.


added ability to format response with json header

#2
:100: ?

:pray:

Just deployed it to the server:
http://metaphorpsum.com/sentences/4?format=json

:+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1:


Bubble code is not in m_rhs?

This code used to be in the m_bubbles modules, but now it's also in s_compute_rhs? Also, s_compute_rhs is 1863 lines long.
https://github.com/MFlowCode/MFC/blob/ecbcb72cc93563bb071118c447e84c3dabdf6341/src/simulation/m_rhs.f90#L1113-L1321

@anandrdbz reminder of this issue


No longer works since 2 may

Apilib constantly errors out on HA 0.68.1
I use it with python 3.6.
Below is error trace
Log Details (ERROR)
Fri May 04 2018 23:51:59 GMT+0200 (CEST)
Error during setup of component toonTraceback (most recent call last): File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/setup.py", line 145, in _async_setup_component component.setup, hass, processed_config) File "/usr/local/lib/python3.6/asyncio/futures.py", line 331, in iter yield self # This tells Task to wait for completion. File "/usr/local/lib/python3.6/asyncio/tasks.py", line 244, in _wakeup future.result() File "/usr/local/lib/python3.6/asyncio/futures.py", line 244, in result raise self._exception File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 55, in run result = self.fn(*self.args, **self.kwargs) File "/home/homeassistant/.homeassistant/custom_components/toon.py", line 69, in setup config['toon'][CONF_NAME]) File "/home/homeassistant/.homeassistant/custom_components/toon.py", line 107, in init display_common_name=name) File "/srv/homeassistant/lib/python3.6/site-packages/toonapilib/toonapilib.py", line 100, in init self._authenticate() File "/srv/homeassistant/lib/python3.6/site-packages/toonapilib/toonapilib.py", line 147, in _authenticate self._get_agreements() File "/srv/homeassistant/lib/python3.6/site-packages/toonapilib/toonapilib.py", line 168, in _get_agreements for agreement in agreements] File "/srv/homeassistant/lib/python3.6/site-packages/toonapilib/toonapilib.py", line 168, in  for agreement in agreements] AttributeError: 'str' object has no attribute 'get'

I am sorry, I cannot reproduce this. Is there any chance your subscription to eneco has expired?

Could you please try out this branch https://github.com/costastf/toonapilib/tree/b-no-agreement that handles that so we can troubleshoot and maybe fix this for you? Please be careful what you paste though in case there is any sensitive information there. Thanks!

i have no experience using github, i dont know how to install from this
repository on a hassbian setup
2018-05-05 13:07 GMT+02:00 Costas<EMAIL_ADDRESS>
Could you please try out this branch https://github.com/costastf/
toonapilib/tree/b-no-agreement that handles that so we can troubleshoot
and maybe fix this for you? Please be careful what you paste though in case
there is any sensitive information there. Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/costastf/toonapilib/issues/11#issuecomment-386797734,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AlL7yjxFb66MjCEA7dI8PNjLrMEoPbKRks5tvYgEgaJpZM4TzU-1
.

i installed the new version, everything seems to be working again as it
should!
2018-05-24 22:00 GMT+02:00 Costas<EMAIL_ADDRESS>
I have created a new 3.0.2 version with a handle of your error so we can
debug further. Please update the version of the library in the HA component
and report back when you have something new.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/costastf/toonapilib/issues/11#issuecomment-391840560,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AlL7yrPhxllpvLHeIqq38OpRLN-SmJM0ks5t1xFegaJpZM4TzU-1
.

it seems i was too early, none of the controls that should be controlling
the thermostat temperature or the selector that changes the programs the
thermostat runs, are working, the call gets sent fron hassbian but nothing
happens on the device
2018-05-24 23:05 GMT+02:00 luuk neele<EMAIL_ADDRESS>
i installed the new version, everything seems to be working again as it
should!
2018-05-24 22:00 GMT+02:00 Costas<EMAIL_ADDRESS>
I have created a new 3.0.2 version with a handle of your error so we can
debug further. Please update the version of the library in the HA component
and report back when you have something new.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/costastf/toonapilib/issues/11#issuecomment-391840560,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AlL7yrPhxllpvLHeIqq38OpRLN-SmJM0ks5t1xFegaJpZM4TzU-1
.

The latest version does not have any fix for any issue, it just extends the error handling in order to see why you are getting that exception. Please try out the library outside of the context of Home Assistant and let me know if you have any issue using it independently.

Reading the state works, but setting it doesn't.
I try:
toon.thermostat = 25

and that doesn't work. Any idea how come?

Could you please try with debugging enabled and report back? That should shed some light.
To enable debugging please
import logging
Iogging.basicConfig(level= logging.DEBUG)

Thanks for the reply!
Here it is:
DEBUG:toonapilib.Toon:Using patched request for url https://api.toon.eu//toon/v3/494995/thermostat
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.toon.eu
DEBUG:urllib3.connectionpool:https://api.toon.eu:443 "GET //toon/v3/494995/thermostat HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.toon.eu
DEBUG:urllib3.connectionpool:https://api.toon.eu:443 "PUT //toon/v3/494995/thermostat HTTP/1.1" 200 None
DEBUG:toonapilib.Toon:Response received b'{\n  "currentSetpoint" : 2500,\n  "currentDisplayTemp" : 2700,\n  "programState" : 1,\n  "activeState" : -1,\n  "nextProgram" : 1,\n  "nextState" : 2,\n  "nextTime" :<PHONE_NUMBER>,\n  "nextSetpoint" : 1500,\n  "errorFound" : 255,\n  "boilerModuleConnected" : 1,\n  "realSetpoint" : 2000,\n  "burnerInfo" : "0",\n  "otCommError" : "0",\n  "currentModulationLevel" : 0,\n  "haveOTBoiler" : 1\n}'
DEBUG:toonapilib.Toon:Clearing state cache.
DEBUG:toonapilib.Toon:Using patched request for url https://api.toon.eu//toon/v3/494995/status
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.toon.eu
DEBUG:urllib3.connectionpool:https://api.toon.eu:443 "GET //toon/v3/494995/status HTTP/1.1" 200 None
DEBUG:toonapilib.Toon:Using patched request for url https://api.toon.eu//toon/v3/494995/status
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.toon.eu
DEBUG:urllib3.connectionpool:https://api.toon.eu:443 "GET //toon/v3/494995/status HTTP/1.1" 200 None

After all those (regardless how long I wait):
print(toon.thermostat)
20.0

Well,I don't see any issue sadly. The response is ok and there is no error raised. There is a "errorFound" flag on the response which means that server side something went wrong but there is not much we can do with the data we

In your other thread the same problem was raised.
When you look online you can indeed see that realSetpoint is the one that should be changed. The package currently is only setting currentSetpoint. Also, the page shows that error code 255 means "OK" (strange code, but it is not a server side error).

http://developer.toon.eu/toonapi/apis/put/{agreementId}/thermostat has no mention of realSetpoint

Yea, it is weird right? Well, I don't have any API running. But I do have the Toon app installed. It is not using the same credentials. Do you think that one is conflicting? I doubt that uninstall the app would have an effect. Preferably, I would have both working.

Nah, the app should be fine.

hi,
how do i use the toonapilib outside of homeassistant?
i think id need a piece of software capable of making api calls? (which
home assistant is)
i am not a developer, i have no idea how to replicate what you're asking me
to do.
i receive no more errors, and all states are again read correctly, i can
also switch on/off my fibaro plugs connected to toon.
i can however, not set the thermostat. this does not work at all, i can set
it, but it does not change on the device.
2018-05-26 12:40 GMT+02:00 Costas<EMAIL_ADDRESS>
The latest version does not have any fix for any issue, it just extends
the error handling in order to see why you are getting that exception.
Please try out the library outside of the context of Home Assistant and let
me know if you have any issue using it independently.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/costastf/toonapilib/issues/11#issuecomment-392252977,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AlL7yhoRv1LpjXNE7cjY7apmu9ab6bS-ks5t2TEbgaJpZM4TzU-1
.

I have sent an email to the developers, I'll update when I hear from them.

@Lucus123 please follow the installation and usage pages of the documentation at http://toonapilib.readthedocs.io/en/latest/

Does not work for me, i get all data, can controle fibaro switches etc but
cannot set thermostat. Data Just does not seem te pass to the device
On Tue, May 29, 2018, 18:09 scheric<EMAIL_ADDRESS>wrote:

It works again. 🎉 Using HA 0.70.
I can change the temperature of the thermostat and i am getting data of
power usage.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/costastf/toonapilib/issues/11#issuecomment-392835465,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AlL7yibFESTK7_u_9Bv9QRAv_cOvRP05ks5t3XLVgaJpZM4TzU-1
.

@Lucus123 have you tried working directly with the library?

Is there any way that you have two eneco subscriptions?

I don't think so?
I was able to make a change once from the swagger, not exactly sure what I filled in, but the realSetpoint did change. I think I submitted the returned data of toonapilib with a change to it (don't remember if it was realSetpoint or currentSetpoint), and then it did change. I think that's the only time I was able to make a change.

Please try to reboot your toon, I can't think of anything else that might be of an issue.

Hi,
I think I found something. It appears that toonapilib has a problem with
the toon thermostat being in Dutch. See below error:
Log Details (ERROR)
Tue Jun 05 2018 22:38:24 GMT+0200 (CEST)
Error executing service <ServiceCall climate.set_operation_mode:
operation_mode=eco, entity_id=['climate.toon']>
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/core.py",
line 1007, in _event_to_service_call
await service_handler.func(service_call)
File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/climate/init.py",
line 393, in async_operation_set_service
await climate.async_set_operation_mode(operation_mode)
File "/usr/local/lib/python3.6/asyncio/futures.py", line 331, in iter
yield self  # This tells Task to wait for completion.
File "/usr/local/lib/python3.6/asyncio/tasks.py", line 244, in _wakeup
future.result()
File "/usr/local/lib/python3.6/asyncio/futures.py", line 244, in result
raise self._exception
File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "/home/homeassistant/.homeassistant/custom_components/climate/toon.py",
line 107, in set_operation_mode
self.thermos.set_state(toonlib_values[operation_mode])
File "/home/homeassistant/.homeassistant/custom_components/toon.py",
line 174, in set_state
self.toon.thermostat_state = state
File "/srv/homeassistant/lib/python3.6/site-packages/toonapilib/toonapilib.py",
line 446, in thermostat_state
self._validate_thermostat_state_name(name)
File "/srv/homeassistant/lib/python3.6/site-packages/toonapilib/toonapilib.py",
line 425, in _validate_thermostat_state_name
raise InvalidThermostatState(name)
toonapilib.toonapilibexceptions.InvalidThermostatState: Weg
Op vr 1 jun. 2018 13:02 schreef Costas<EMAIL_ADDRESS>
Please try to reboot your toon, I can't think of anything else that might
be of an issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/costastf/toonapilib/issues/11#issuecomment-393847584,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AlL7ym4GgBs1GD7wv7Qjn3qWc2rb5iwXks5t4R8wgaJpZM4TzU-1
.

Do you know if you changed anything in the toonapilib.
When I changed something in the toonapilib and I break some stuff i found an easy fix to get everything back to normal.
Make a copy of the toonapilib folder to be safe!
Try deleting folder /srv/homeassistant/lib/python3.6/site-packages/toonapilib/ to get a fresh install of toonapilib.
*You have to reboot after deletion of the toonapilib folder.
After the reboot you can check if the folder is back. *

Not changed anything.
Completely original.
Op di 5 jun. 2018 23:15 schreef scheric<EMAIL_ADDRESS>
Do you know if you changed anything in the toonapilib.
When I changed something in the toonapilib and I break some stuff i found
an easy fix to get everything back to normal.
Make a copy of the toonapilib folder to be safe!
Try deleting folder
/srv/homeassistant/lib/python3.6/site-packages/toonapilib/ to get a fresh
install of toonapilib.
*You have to reboot after deletion of the toonapilib folder.
After the reboot you can check if the folder is back. *
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/costastf/toonapilib/issues/11#issuecomment-394862768,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AlL7ypo-po9UMP2WjAtliewaAV8Rss8Mks5t5vTWgaJpZM4TzU-1
.

@Lucus123
Did you change something in the custom_components folder?
Have you tried to refresh the toonapilib as described?

@Lucus123
Ore you can turn the debugging mode on by replacing all logger.debug to logger.warning in toonapilib.py

I did this myself and saw Manually set temperature, no Thermostat State chosen!

If this happens everything should be fine but report if you see something different.
look for Response received and check if activeState" : X, changes.

Hi @Lucus123. Sorry it took so long for me to answer, but I was on vacation and I needed some time away :) . The exception that you mention happens because the state that is sent to the library to be set on the service is not valid. If you look into the configuration.py of the project you will notice the states mentioned being :
          1: 'Home',
          2: 'Sleep',
          3: 'Away',
          4: 'Unknown',
          5: 'Unknown'}```

That means that you have some setting on HA that sends over states in dutch which does not work according to the above mentioned setting. Seeing as that you are the only one affected by this I would guess that this is a setting that you have set and it is not HA specific. Could you please look into your configuration better? Could you also  test the library independent of HA and report back if it works?

Since this is caused by some custom change I am closing this. If there is more feedback and we can troubleshoot further, lets reopen.


Save current settings to LocalStorage?

What do you think of storing the chart settings in LocalStorage to protect against refreshing / closing the browser inadvertently and losing the project? To protect against always being confronted by your last chart, you could have a "Load previous" button.

This is already implemented. There is a localStorage timer that starts on page load, and the "Load previous" button persists for some time (currently 30sec), after which it starts saving the current chart to localStorage on change.
Here's the component that controls that button:
https://github.com/Quartz/Chartbuilder/blob/master/src/js/components/LocalStorageTimer.jsx
The timer is controlled via the Session flux store:
https://github.com/Quartz/Chartbuilder/blob/master/src/js/stores/SessionStore.js

I must have changed something else then. Thanks!


Update netty-codec-http, ... to 4.1.113.Final

About this PR
📦 Updates

io.netty:netty-codec-http
io.netty:netty-handler-proxy
io.netty:netty-transport-native-epoll
io.netty:netty-transport-native-kqueue

from 4.1.87.Final to 4.1.113.Final
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.netty" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "io.netty" }
}]

labels: library-update, commit-count:1

Superseded by #156.


Add lot of French translations

I added a lot of the French missing translations.

Merci beaucoup.
Unfortunately, this seems not parse as valid YAML. It's confusing; it looks fine to me.

did not find expected key while parsing a block mapping at line 691 column 7

Looks fine to me too ^^

There were a few issues. Here's what I needed to change https://github.com/jhawthorn/solidus_i18n/commit/9eca053f3872103e9bd6edd715431f95b71de521

Merged as cf3c7080ff2d6583c090c839a0b856f2ff9e44ae :tada:

Thanks a ton !!


Decouple AppTP and VPN enable/disable states

Task/Issue URL: https://app.asana.com/0/1202279501986195/1202551193613496/f
Description
See context in asana task
Steps to test this PR
Fresh install

[ ] fresh install from this branch
[ ] enable AppTP when going through onboarding
[ ] go to Settings -> App tracking protection screen
[ ] verify AppTP is enabled
[ ] Toggle AppTP OFF
[ ] verify AppTP is disabled
[ ] go back to Settings
[ ] verify AppTP appears as disabled
[ ] in the browser, open new tabs until the AppTP banner apperas in new tab
[ ] verify AppTP is disabled
[ ] tab on the banner to go to App tracking protection screen
[ ] enable AppTP
[ ] go back to new tab and verify the banner shows AppTP enabled
[ ] install another VPN app and enabled it
[ ] back to our browser, verify AppTP is disabled and the reason in both new tab and AppTP screen is A VPN app on your device disabled App Tracking Protection
[ ] in App tracking protection screen, enable AppTP
[ ] verify AppTP is enabled
[ ] kill the VPN process (this can be done from IDE logcat)
[ ] verify AppTP is is re-enabled

App update

[ ] fresh install from develop branch
[ ] enable AppTP and update from this branch
[ ] launch AppTP and verify is enabled
[ ] repeat tests in previous section

Current dependencies on/for this PR:

develop

PR #2066   👈

This comment was auto-generated by Graphite.


extract sound to bundle mp3 files

all sounds will be placed inside .bundle/sounds/*.mp3 where the file basename will equal the linkage class name (assumes all sounds have linkage names; technically may not be always true but has been so far; can't imagine a scenario where sound is used without linkage name; could provide character id as fallback for that scenario if proven possible)
sounds exported will also be listed inside .bundle/library.json assets:Asset[] with their name containing  a relative path from the .bundle/ folder
.mp3 files just work!
.wav files need testing. may need their header bytes prefixed when writing to disk. notice that code is there but commented until we get a chance to test further.
other sound formats are possible but were not used by our codebase so we are skipping implementation for now.
ideally sounds should all be translated to .mp3 and/or .ogg regardless of what format they were in. perhaps some .exe tool can be provided similar to how webfonts are processed. (ffmpeg is ideal but a HUGE project)

🚧 👷 CAUTION! This branch is still experimental and should be thoroughly tested. 🏗
TODO: currently adding support to read and cache the sounds before .bundle is finished loading at runtime. all sounds should be preloaded before the .bundle/ is considered done loading, and able to be referred to and run from anywhere (globally) by their library + ":" + linkageName, similar to the way MovieClips are.
NOTICE: Depends on PR #1636 being merged first.

this guy's project can convert SWF ADPCM format (currently mistakenly called .WAV by me) to RAW then normal software can convert it from RAW to WAV or MP3
https://github.com/alexgirao/adpcm_swf

nvm jpexs.jar is already cross-platform and does it better
java -jar "${JPEXS}" -format sound:mp3_wav -export sound "out/jpexs/${FILE}/sounds/" "out/swf/${FILE}.swf"
https://www.free-decompiler.com/flash/features/commandline/
we could package this in?
would still need something to transcode .wav to .mp3 tho

This has been merged, thank you :smile:


bug: wrong CWD when using Dev Containers (extensionKind = "ui")

Check the following:

[X] I have tried setting vscode-neovim.neovimClean in VSCode settings and restarting VSCode.
[X] I have read the vscode-neovim docs.
[X] I have searched existing (closed!) issues.

Neovim version (nvim -v)
v0.10.1
Operating system/version
Mac 14.4.1
Problem (including log messages)
On a fresh setup with a Dev Container Neovim sets the CWD to /. This prevents e.g. tab path completion working when opening new files.
Steps To Reproduce

Open a project with Neovim and Dev Container Extensions
: followed by lua print(vim.fn.getcwd())
Output is /

Expected Behavior
I expect the reported working directory to be the root of the project I am working in.

Is vscode-neovim installed in a remote environment? (I mean the vscode-neovim extension, not neovim itself.)

No, it's installed locally.
On Sun, Sep 22, 2024, 8:54 PM wongxy @.***> wrote:

Is vscode-neovim installed in a remote environment? (I mean the
vscode-neovim extension, not neovim itself.)
—
Reply to this email directly, view it on GitHub
https://github.com/vscode-neovim/vscode-neovim/issues/2258#issuecomment-2367071557,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACLHDD7USEDNVBCIVE6OPLZX5RFVAVCNFSM6AAAAABOU4V6D2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRXGA3TCNJVG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

https://github.com/vscode-neovim/vscode-neovim?tab=readme-ov-file#remote-development

I'm trying to understand your response. I want to use vscode-neovim as a
local UI extension, so it is installed locally, and should "work out of the
box", as the docs you linked states. Is your reply intended to imply this
is broken and I should use remote Neovim?
On Sun, Sep 22, 2024, 10:32 PM wongxy @.***> wrote:

https://github.com/vscode-neovim/vscode-neovim?tab=readme-ov-file#remote-development
—
Reply to this email directly, view it on GitHub
https://github.com/vscode-neovim/vscode-neovim/issues/2258#issuecomment-2367132644,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACLHDCTV2QAYQABHBHKFXLZX54S3AVCNFSM6AAAAABOU4V6D2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRXGEZTENRUGQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

How could the CWD be a remote location if the extension runs locally?

The CWD is just the diagnosable issue. All I want is tabbed path completion
to work properly. Presumably using the local CWD over a random path would
be part of a solutiomn.
At a minimium if it's not possible for this UI extension to support the
standard vim/neovim methods for opening files when used as a front-end
extension I think that would be a good thing to document. Presumably
opening files is a commonly-used feature.
On Mon, Sep 23, 2024, 2:40 AM wongxy @.***> wrote:

How could the CWD be a remote location if the extension runs locally?
—
Reply to this email directly, view it on GitHub
https://github.com/vscode-neovim/vscode-neovim/issues/2258#issuecomment-2367341982,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACLHDFKVOESQAREQLGDA63ZX6ZVPAVCNFSM6AAAAABOU4V6D2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRXGM2DCOJYGI
.
You are receiving this because you authored the thread.Message ID:
@.***>

We definitely should try to set a useful CWD. Is there a reason we can't?

All I want is tabbed path completion to work properly

Are you hitting <tab> in Nvim? Describe the steps.
If Nvim is running locally in a remote vscode session, then setting CWD won't help with tab-completion, because Nvim doesn't know about the vscode VFS. But depending on the steps you describe, there may be other things that can work.

Open a project with a Dev Container. Presume it has a.txt and b.txt in its root.
Open the a.txt file
Type :tabe b

Expectation: Presented with auto complete menu including b.txt
Result: Presented with files starting with b in my machine root directory.
This does work as expected when not using devcontainers.
It's a workflow of particular interest to me because I'm only using VSCode in the first place to experiment with using Dev Containers while maintaining NeoVim ergonomics.
Maybe this is just not possible in this configuration, but hypothetically it seems possible to set CWD to the local project and then intercept resulting fopen etc. commands and redirect them to whatever remote equivalent VSCode expects. That's assuming there's not already some 'virtual directory structure' VSCode creates locally that could be used directly.

but hypothetically it seems possible to set CWD to the local project and then intercept resulting fopen etc. commands and redirect them to whatever remote equivalent VSCode expects

That would be the VFS concept I mentioned. Nvim currently doesn't have a VFS interface (indirectly discussed in https://github.com/neovim/neovim/issues/21635 , just vaporware currently), but that would be something that Nvim should provide.
Meanwhile, if nvim is running on the remote then yes, we should ensure that vscode-neovim sets a useful CWD there. If it's running locally, then no, it can't work without a VFS layer.

Thank you, that makes sense. I will try running as a remote extension as a work-around.
I think I'm suggesting something slightly different than a VFS interface for Nvim. Rather, let Nvim use the local project CWD. Path completion should work reasonably in that case. Then when translating open-file calls to VSCode APIs change the paths to refer to remote URIs corresponding to the open remote workspace. The API calls vscode-neovim uses now take URIs, and it appears those URIs can reference the remote filesystem (e.g. https://stackoverflow.com/questions/77801691/how-to-open-vscode-with-vscode-vscode-remote-with-devcontainers).

I think I'm suggesting something slightly different than a VFS interface for Nvim. Rather, let Nvim use the local project CWD. Path completion should work reasonably in that case.

But that would only work in the rather special case where the local nvim CWD happens to point to a project that "looks like" whatever workspace is on the remote?

I also think an approach like I describe would resolve a variety of similar issues WSL users have.
If PRs in this direction would be welcome please let me know.

If PRs in this direction would be welcome please let me know.

Sure, it would help! Start with a quick hack/prototype for discussion purposes.

@mharradon I think your suggested approach is impossible without a VFS. If your code "lives" in a remote container, but nvim is running on your local machine... then nvim has NO access to the real files on the remote, and instead only sees buffer contents (opened from vscode).
Yes, we can translate open/save URIs so that :e remote_file.txt works, but we cannot do anything about tab completion, because this is done internally within nvim (ie there is no vim.fs.ls() or autocommand we can stub).
TLDR the only way nvim can have any understanding of the remote file tree for the purposes of tab completion, netrw, etc, is by integrating nvim<->vscode through a VFS.
If I'm not missing anything I suggest we close this issue until nvim comes up with a new API.

This issue has good info though so we can mark it as blocked and keep it open?


Replace the Mocha injected CSS with CSS variables to be matched as Vuetify classes

do we still need this?

We can disregard this one as we now have multiple solutions:

@ehab-hassan adjusted the colors to work seamlessly in both dark and light modes.
@MohamedElmdary developed a new toast package, which we can integrate at a later stage.

Considering the available alternatives, I will proceed to close this issue for the time being.


Session ID is coming as null ,

Set the parallel to false for single thread execution
public class WeatherRunnerTest extends AbstractTestNGCucumberTests {
@Override
@DataProvider(parallel = false)
public Object[][] scenarios() {
return super.scenarios();
}
[INFO]   Run 1: PASS
[ERROR]   Run 2: WikipediaParallelRunnerTest.runScenario » NoSuchSession Session ID is null. Us...
[ERROR]   Run 3: WikipediaParallelRunnerTest.runScenario » NoSuchSession Session ID is null. Us...
how to limit the number of threads, please let me know.
Thanks for the greater work

WebDriverRunner is closing the drivers session after each test when run concurrently. This is a good candidate for a Pull Request if you'd like to fix it.


USA Hyundai force refresh

I recently got a new Hyundai (in the US) and found this library via the kia_uvo Home Assistant integration. I found that the BlueLink data was often very stale, which makes sense given the lack of a force-refresh implementation. I've taken a shot at adding that to the HyundaiBlueLinkAPIUSA file. I incorporated some of the changes from #244 as part of a bit of refactoring of the various internal API call methods.
Fixes #31
I tested this by:

Setting up a Home Assistant dev environment
Manually installing the kia_uvo integration
Manually installing this library in the HA virtualenv with pip3 install -e ../hyundai_kia_connect_api
Starting HA with pip skipping this library with hass --skip-pip-packages hyundai-kia-connect-api -c config
Enabling debug logging per the docs in this repo

I was able to see that the integration was successfully refreshing the data at the configured interval, whereas before it would sit stale:

As far as tests go, I tried running flake8 and it found a ton of existing warnings - I addressed some of the ones that this change touches, but fixing all of them seemed out of scope. I also ran the existing tests, some of which passed and others did not. :man_shrugging: I'm not primarily a Python developer, so if you'd like additional testing, I could use some pointers.
Hoping this looks good and I can start using it in my main Home Assistant instance soon!

Amazing work! Thank you for doing this.  I will merge and release this into HA.  Could I ping you if we see user issues afterward for this region?

Could I ping you if we see user issues afterward for this region?

Sure thing, I'm using this code now in my Home Assistant install so I'm certainly motivated to keep it working. :wink: Hopefully I'll have some time to look into the other features missing in the US region as well.


new contact me form

want to add new contact form which is responsive .kindly assign this issue under swoc to me.
Can you complete this feature request by yourself?

[x ] YES
[ ] NO

I am thinking to make this kind of form.


Disable bracket pair colorization via color theme

I know this can be disabled via settings.json with "editor.bracketPairColorization.enabled": false,, but I need to disable it via my color theme such that it is only disabled when my theme is active.
The only solution I can find for now is to explicitly set colors for
editorBracketHighlight.foreground1
editorBracketHighlight.foreground2
editorBracketHighlight.foreground3
editorBracketHighlight.foreground4
editorBracketHighlight.foreground5
editorBracketHighlight.foreground6

but this is cumbersome...

P.S. I hope this feature is just an experiment... it really ought to be disabled by default.

P.S. I hope this new feature is just an experiment... it really ought to be disabled by default.

Thank you, i was able to "fix" my vscode. It was really troublesome. I can see how this feature could help people but it should be disabled by default. Made me think that my theme was broken.

P.S. I hope this new feature is just an experiment... it really ought to be disabled by default.

I was looking to see if anyone else was saying the same thing. SystemVerilog (which "brackets" with class endclass function endfunction) with this on looks like an ugly christmas tree. Plus, words like interface endinterface sometimes don't have the end pair but are still valid syntax. Doesn't stop this bracket highlighter from marking them red. Not to mention, the default dark theme's gold looks hideous.

Agree that. The default bracket color looks really bad when using certain themes.
There should be options for theme makers to disable this feature or specific tokens to customize it.

Maybe we can check if a theme sets all bracket colors to #000000 and disable the feature automatically if that is the case.

P.S. I hope this new feature is just an experiment... it really ought to be disabled by default.

See the release notes for 1.67:

Given the positive feedback of the new bracket pair colorization feature introduced in the 1.60 release, we enabled bracket pair colorization by default.

Maybe we can check if a theme sets all bracket colors to #000000 and disable the feature automatically if that is the case.

But it wouldn't be obvious to someone reading the code that it disables the feature.
Setting all bracket highlight colors to transparent works so actually maybe this is the best solution and nothing needs to be fixed. Though it still requires 6 lines of code, but I'm not sure introducing a new property to disable is any better either.

P.S. I hope this new feature is just an experiment... it really ought to be disabled by default.

See the release notes for 1.67:

Given the positive feedback of the new bracket pair colorization feature introduced in the 1.60 release, we enabled bracket pair colorization by default.
Perhaps this merits a new issue, but there should at least be an easier way to disable it then if it's going to be on by default. I doubt there was much negative feedback when it was default disabled.

Closing this issue because it seems the real issue is whether this feature should even be enabled by default to begin with.

I actually think this feature request is reasonable and might be a good compromise between enabling the feature by default and not ruining themes.

I'm still in strong favor of disabling this feature by default, but if it's going to be enabled by default (or disabled by default but enabled by user) then maybe a good way to not ruin themes or require preexisting themes to be updated is:
For the bracket highlight properties:
editorBracketHighlight.foreground1
editorBracketHighlight.foreground2
editorBracketHighlight.foreground3
editorBracketHighlight.foreground4
editorBracketHighlight.foreground5
editorBracketHighlight.foreground6

if a theme has not explicitly set the property, then don't inherit the default vscode color for it.
This way you can have bracket pair colorization enabled by default, but the theme would have to support it by explicitly setting these properties or else there's no effect. And if the theme doesn't support it but the user still wants it, then there could be another setting to inherit vscode's default colors for it, but this setting would be disabled by default to not affect prexisting themes or themes that don't support it.

I'm still in strong favor of disabling this feature by default, but if it's going to be enabled by default (or disabled by default but enabled by user) then maybe a good way to not ruin themes or require preexisting themes to be updated is:
For the bracket highlight properties:
editorBracketHighlight.foreground1
editorBracketHighlight.foreground2
editorBracketHighlight.foreground3
editorBracketHighlight.foreground4
editorBracketHighlight.foreground5
editorBracketHighlight.foreground6
if a theme has not explicitly set the property, then don't inherit the default vscode color for it.
This way you can have bracket pair colorization enabled by default, but the theme would have to support it by explicitly setting these properties or else there's no effect. And if the theme doesn't support it but the user still wants it, then there could be another setting to inherit vscode's default colors for it, but this setting would be disabled by default to not affect preexisting themes or themes that don't support it.

I'm still in strong favor of disabling this feature by default, but if it's going to be enabled by default (or disabled by default but enabled by user) then maybe a good way to not ruin themes or require preexisting themes to be updated is:
For the bracket highlight properties:
editorBracketHighlight.foreground1
editorBracketHighlight.foreground2
editorBracketHighlight.foreground3
editorBracketHighlight.foreground4
editorBracketHighlight.foreground5
editorBracketHighlight.foreground6

if a theme has not explicitly set the property, then don't inherit the default vscode color for it.
This way you can have bracket pair colorization enabled by default, but the theme would have to support it by explicitly setting these properties or else there's no effect. And if the theme doesn't support it but the user still wants it, then there could be another setting to inherit vscode's default colors for it, but this setting would be disabled by default to not affect preexisting themes or themes that don't support it.

The Default Activation of the bracketPairColorization Feature did not Fuel the Negative Response Alone

The link below is an answer that I authored on Stack Overflow. I was completely unaware of the response it would get at the time. VS Code had activated the bracketPairColorization by default, and before I even installed the new release (which I always do within 1-12 hours of each release) this question was asked. I was surprised to see the first few people shrug the question of as not being important enough to answer with anything more than a brief comment. Because I was a fan of the new feature (though I don't use it in its fullness) I thought I would answer the question with the sort of answer it deserved. The answer I authored took me nearly 2 hours. Shortly after, it started getting up-votes. Since then it has gotten at-least one, sometimes 4 or 5, up-votes a day. For stack overflow, that is really good.
Disabling bracketPairColorization
I soon noticed that my answer wasn't the only one floating around, there were 2 others, however, the response they got was not nearly as warm. One of them sat at -1 before the author deleted it. After a short while I realized why people were up-voting the answer I gave.

In the answer, I suggested turning of the colorization of the bracket-pairs via "editor.bracketPairColorization.enabled": false, however; I continued to denounce the following:

After the editor.bracketPairColorization feature was released, two other features, that were part of the same group, were released. All of the settings for that group is as follows:

"editor.bracketPairColorization.enabled"
"editor.guides.bracketPairsHorizontal": false
"editor.guides.highlightActiveBracketPair": false

This is not the end of the story though. Before the three features released, the following two settings already existed.

"editor.guides.indentation": false
"editor.guides.highlightActiveIndentation": false

If you fail to disable them all, it may seem like parts of the bracketPairColorization feature are remaining on, despite disabling them, therefore, I suggest the following configuration for those who want the feature completely disabled.
  {
      // Bracket-pair colorization
      "editor.bracketPairColorization.enabled": false,

      // Bracket-pair guides
      "editor.guides.bracketPairsHorizontal": false,
      "editor.guides.highlightActiveBracketPair": false,

       // Indentation guides
      "editor.guides.indentation": false,
      "editor.guides.highlightActiveIndentation": false
  }

### The Purpose for Authoring this...

...is because, I feel that the negative reaction was magnified by how hard it was to configure the editor back to its normal state. The fact that there are 4 different settings for activating `editor.guides`, that there are `editor.guides.indentation` and `editor.guides.BracketPairs`, and that the bracket-pair guides were activated by default along-side the `bracketPairColorization` feature was what frustrated people.

When it was just activated by default, people looked for a single setting to disable the feature. When they set `"editor.bracketPairColorization.enabled"` to false, many were confused why there were lines still being highlighted in the editor.

Another thing that was not good, happened to people like myself. I knew about the feature, I read about it in all of the new release   statements, and any documentation added to the docs, therefore; I new what settings to enable, which settings had values that could be set to something other than `true` or `false`, and had the features all set in my user `settings.json` such that the feature rendered as I desired. Then the feature was enabled by default, consequently; the settings that I wanted to be set to there default value, were not in my `settings.json` file. They were not there, not because I removed them, but because VS Code removed them by default.  I had to stop working to figure out how to fix it, because in truth, when the feature isn't  what you want, it can feel very invasive, which is another problem.

This would also lead me to argue that if I use the VS Code settings explorer (rather than manually authoring my user `settings.json` file to configure vscode), it should not remove any settings that I manually added  to the settings.json file. My justification for this is that the default changes you guys made, would not have affected me if that were the case.

Anyways, that's how I feel about the issue.

<br>

Maybe it's just not easy to choose appropriate bracket pair color easily based on theme.  I think it should at least be off and at least ask me if I want it on.
When I upgraded and this feature was automatically on, I thought MS had just broken the default dark theme by choosing insane colorization for my brackets.
Against the dark background the choice of neon magentas and oranges not only did not help me find my bracket pairs, it was an absolute assault on the eyes.
I think a much better solution would just to be to highlight the region which corresponds to a closure in an overlay box.

as a theme creator, I would welcome an option to enable/disable/customize bracket colorization for specific languages.

There is already a mechanism for removing bracket pair colorization via color theme without disabling the setting (just set all the editorBracketHighlight.foreground properties to transparent). I don't see the benefit of adding a further mechanism for disabling the setting, so I think this issue can be closed if you agree.
Otherwise, for preexisting themes that are negatively affected by this feature, I believe the best solution that doesn't require them to be updated is to have bracket pair colorization enabled by default but have the six editorBracketHighlight.foreground properties and editorBracketHighlight.unexpectedBracket.foreground be transparent by default. Themes would need to set these properties explicitly or else inherit the transparent values. The description for the bracket pair colorization setting could be updated to state that the active theme must support it to show effect.


Add draft of Svukte extension

Svkt provides a means to make user-mode accesses to supervisor memory raise page faults in constant time, mitigating attacks that attempt to discover the supervisor software's address-space layout.
I plan to submit this as a fast-track soon.

OK, what happens if the extension is enabled, the Ubit in the PTE is set ( so the access would be valid if the extension was disabled). Does that override the U-bit? Implicitly, it does, but I'd like to see that explicit (possibly in this extension spec, and/or in the the description of the U-bit in the spec section on the definition of the U-bit

OK, what happens if the extension is enabled, the Ubit in the PTE is set ( so the access would be valid if the extension was disabled). Does that override the U-bit? Implicitly, it does, but I'd like to see that explicit (possibly in this extension spec, and/or in the the description of the U-bit in the spec section on the definition of the U-bit

The basic premise of Svukte is to take advantage of the convention in all 64-bit OS that user mappings are in positive address space and supervisor mappings are in negative address space. An OS that create user mappings in negative address space - even a single mapping - cannot turn on Svukte or the OS has to provide an emulation. For instance, for x86 based Linux legacy vDSO were located in negative address space and when LASS was introduced the OS provided emulation for such legacy vDSO. Non legacy vDSO on x86 and vDSO on RISC-V are located in positive address space. The point of Svukte is to fault on user access to negative addresses without consulting the address translation caches or doing implicit accesses to the page tables.
So I think the state of the U bit is a don't care for this extension. For that matter the PTE itself may not be valid at all.

I understand that convention of supervisor mappings in negative VA space.
I agree that implicitly the state of the U-bit ( or the validity of the
PTE entry) is a don't care.
I am just saying that it should be explicit, and not require a careful
reading.
There is nothing in the spec that says that PTE entries must not be
fetched - just that, if they are accessed, the amount of time to get to the
leaf PTE should be constant
(it isn't clear how time is measured: realtime, #cycles, etc - but my
assumption is however SW could measure it).
There is nothing in the spec that says an OS that allows U-mode mappings in
negative address space cannot  (or must-not) turn on Svukte.
Bad things may (or may not) happen if it does (as Ved points out), but
certainly there is no HW enforcement.
There is nothing that prevents describing the obvious  implementation
(short circuiting the translation process) into the spec
( or even making it a requirement if it is that obvious and simple).
instead of making all implementors puzzle it out / re-invent it from first
principles.
On Wed, Oct 9, 2024 at 11:44 AM Ved Shanbhogue @.***>
wrote:

OK, what happens if the extension is enabled, the Ubit in the PTE is set (
so the access would be valid if the extension was disabled). Does that
override the U-bit? Implicitly, it does, but I'd like to see that explicit
(possibly in this extension spec, and/or in the the description of the
U-bit in the spec section on the definition of the U-bit
The basic premise of Svukte is to take advantage of the convention in all
64-bit OS that user mappings are in positive address space and supervisor
mappings are in negative address space. An OS that create user mappings in
negative address space - even a single mapping - cannot turn on Svukte or
the OS has to provide an emulation. For instance, for x86 based Linux
legacy vDSO were located in negative address space and when LASS was
introduced the OS provided emulation for such legacy vDSO. Non legacy vDSO
on x86 and vDSO on RISC-V are located in positive address space. The point
of Svukte is to fault on user access to negative addresses without
consulting the address translation caches or doing implicit accesses to the
page tables.
So I think the state of the U bit is a don't care for this extension. For
that matter the PTE itself may not be valid at all.
—
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/pull/1564#issuecomment-2403058486,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJVI46WBNAB3PIF7OJDZ2V2RXAVCNFSM6AAAAABLNSDROGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBTGA2TQNBYGY
.
You are receiving this because you commented.Message ID:
@.***>

OK, I'll make it explicit.

I would interpret "user-mode accesses to supervisor memory" to mean "where
the U-bit is zero".
"supervisor memory" is not a RISC-V architectural definition, except for
the above.
If there is an obvious implementation of this, why not just come right out
and describe it in a non-normative note?
I guarantee no one will firebomb your hourse if you do that (but if you
don't - no guarantees)
On Wed, Oct 9, 2024 at 2:26 PM Andrew Waterman @.***>
wrote:

@.**** commented on this pull request.
In src/supervisor.adoc
https://github.com/riscv/riscv-isa-manual/pull/1564#discussion_r1794248591
:

@@ -2270,6 +2279,45 @@ Invalid PTEs using a bounded timer, or making address-translation caches
coherent with store instructions that modify PTEs.
====

+[[sec:svukte]]
+== "Svukte" Extension for Address-Independent Latency of User-Mode Faults to Supervisor Addresses, Version 0.3
+
+The Svukte extension provides a means to make user-mode accesses to supervisor
+memory raise page faults in constant time, mitigating attacks that attempt to
I went with my version, but we can revisit this later if need be.
—
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/pull/1564#discussion_r1794248591,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJUV2XRYORWADJ75SYTZ2WNRNAVCNFSM6AAAAABLNSDROGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGNJYGM2DMNJXGE
.
You are receiving this because you commented.Message ID:
@.***>

I don’t understand what you’re complaining about at this point. The note I added, that the PTE contents don’t matter, is even stronger than the thing you asked for!

Hey everyone, just to piggy back on @allenjbaum comment, as I share the same opinion. I also misinterpreted the text on my first reading, and thought the hart would have to check the U bit on the PTE on every U-mode access and deliver an exception in constant-time (even though an implementation like this would be possible). However, after the presentation at the Security HC meeting, I now understand the extension much better. The desired final implementation is to AND three bits: vaddr[2^SXLEN-1], priv == u-mode, and senvcfg.UKTE (or the equivalent for the guest). I think it would be immensely helpful to add this short sentence as an implementation hint to the reader.

@lfiolhais after discussing offline with Allen, I did add another sentence to the NOTE that directly addresses the matter.  (No TLBs or page-table walks occur => U-bit isn't relevant)

@aswaterman Thanks! I think it's better now.


Unexpected and very long error message when saving custom rpc

When the RPC URL field in a CustomRPC is a valid URL but does not point to any actual location, the following error message is given. An example of such a url is https://node.expanse.tect.

A better error message should be used.

Seems like it should appear as how errors look like when filing in the form


Update supabase.py - change def query argument name

change to data. Seems working now.
Description
unknown argument query_vector. Now is changed for data and works fine
Fixes # (issue)
Type of Change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Added new unit/integration tests
[ ] Added new notebook (that tests end-to-end)
[ ] I stared at the code and made sure it makes sense

Suggested Checklist:

[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

closing in favor of https://github.com/jerryjliu/llama_index/pull/7103