feat: Add a Hedgey position hook

Codecov Report

Merging #175 (586b2f0) into main (286ba1f) will decrease coverage by 0.18%.
The diff coverage is 88.88%.

@@            Coverage Diff             @@
##             main     #175      +/-   ##
==========================================
- Coverage   91.37%   91.19%   -0.18%
==========================================
  Files          29       31       +2
  Lines         591      636      +45
  Branches       59       61       +2
==========================================
+ Hits          540      580      +40
- Misses         47       52       +5
  Partials        4        4

Files Changed
Coverage Δ

src/apps/hedgey/positions.ts
88.63% <88.63%> (ø)

src/apps/hedgey/abis/token-vesting-plans.ts
100.00% <100.00%> (ø)

Continue to review full report in Codecov by Sentry.

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


Windows gRPC C core memory leak

Should this be an issue in the gRPC issue tracker?
Yes, I believe so
What version of gRPC and what language are you using?
C++ master branch and also v1.6.x (current https://grpc.io/release)
What operating system (Linux, Windows, …) and version?
Windows 10 version 1709 OS Build 16299.19
What runtime / compiler are you using (e.g. python version or version of gcc)
MSVC 2017 (15.4.1)
What did you do?
Run standard helloworld sample server and client on same machine.
Modified helloworld client so it opens 100 connections and does 100 requests (one per connection), run more instances of modified helloworld client (in order to open and close "large" amount of tcp connections)
What did you expect to see?
helloworld server & client doing their thing.
helloworld server's process ram should not increase constantly
What did you see instead?
helloworld server process ram was growing slowly with each open tcp connection. When all connections were closed ram was not reclaimed.
Memory was also not freed after calling  server->Shutdown();
Anything else we should know about your project / environment?
When trying find out why this is happening I found out that the memory which is not freed is getting allocated in grpc_resource_quota_create called by grpc_tcp_create
By tracing the execution of the function and also tracing the related tcp_free i noticed that in grpc_tcp_create resource_quota->refs.count is set to 1 when resource_quota is created. This refcount is then increased when tcp->resource_user = grpc_resource_user_create(resource_quota, peer_string); is called near the end of the function. Since this looked a bit suspicious I checked how grpc_tcp_create is implemented in tcp_posix.cc and I saw that grpc_resource_quota_unref_internal(exec_ctx, resource_quota); is called before returning. This call is not present in tcp_windows.cc
Adding that line fixed the leak problem. I tested it with master and v1.6.x branch
I did not do run any gRPC tests
Then looking at the function as a whole I could see that there is some refcount increasing and decreasing going on if resource_quota is received from grpc_channel_args *channel_args, but tcp_posix.cc does the same thing.
So the patch is (no Pull request since I just started playing with gRPC today):
diff --git a/src/core/lib/iomgr/tcp_windows.cc b/src/core/lib/iomgr/tcp_windows.cc
index dc84e564a9..ad939d3b50 100644
--- a/src/core/lib/iomgr/tcp_windows.cc
+++ b/src/core/lib/iomgr/tcp_windows.cc
@@ -442,6 +442,7 @@ grpc_endpoint *grpc_tcp_create(grpc_exec_ctx *exec_ctx, grpc_winsocket *socket,
   tcp->resource_user = grpc_resource_user_create(resource_quota, peer_string);
   /* Tell network status tracking code about the new endpoint */
   grpc_network_status_register_endpoint(&tcp->base);
+  grpc_resource_quota_unref_internal(exec_ctx, resource_quota);

   return &tcp->base;
 }

the grpc server and client i write in .net consumes 10mb more momery every day

@JakaBac thanks for the detailed analysis. We'll look into that!

The patch also fixes csharp memory leak on Windows (also uses grpc_tcp_create). I built the csharp debug bits and tested with/without the patch and confirmed behaviour using native heap profiling in VS.
This probably affects all gRPC servers on Windows which use the C low level OS abstraction library.

Thanks! 'fraid I am seeing the leak too (64-bit windows C++ server, gRPC built off the tag v1.6.6).

I believe that everything that is based on C core starting with v1.3.0 is affected (did not test, just had a quick look)

Still have memory leak in 1.7.0 both in client and server

@luchunminglu, a fix for another leak https://github.com/grpc/grpc/pull/13169 will be in 1.7.1, would that resolve the problem you are seeing? If not, please file an issue with details about what you're experiencing.

@luchunminglu: Could you please do the following test? Set environment variables GRPC_VERBOSITY and GRPC_TRACE to an empty value (empty value for each won't change the behavior) and then see if you still have the leak you are mentioning in your last comment? The memory leak that @jtattermusch mentions happens only when either of these environment variables does not exist. If setting the variables resolves it for you, then you are seeing the issue that is fixed in the upcoming 1.7.1. If not, then we have more leaks to hunt for. Thanks!

@luchunminglu,@kkm000  with the patch for this issue and PR #13169 pulled into v1.6.7 I don't see any obvious leaks when running a C++ server and a C++/C# client.

@JakaBac: Thanks for checking. So let's assume this was it!


Nest Displaying Wrong Unit

Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
Home Assistant release (hass --version): 0.28.2
Python release (python3 --version): 3.4.2
Component/platform: Climate/Nest
Description of problem: I have set up my Nest thermostat and it is displaying the temp in Fahrenheit but the units is C. I have the unit_system set to imperial in my configuration.yaml.
Expected: Unit should match the temperature.
Problem-relevant configuration.yaml entries and steps to reproduce:
From configuration.yaml:
# Nest Thermostat
nest:
  username: REDACTED
  password: REDACTED

climate:
  platform: nest

Fix provided in #3394


navigateAfterFuture called multiple times

First of all thank you for your great package.
The issue
The function assigned to navigateAfterFuture  is called multiple times  (2 or 3 times in my case).
The code
class MyApp extends StatefulWidget {
  @override
  _MyAppState createState() => new _MyAppState();
}

class _MyAppState extends State<MyApp> {
  MainSingleton mainSingleton = MainSingleton();

  @override
  Widget build(BuildContext context) {
    return SplashScreen(
        routeName: "/",
        navigateAfterFuture: loadFromFuture(),
        title: new Text(
          APP_NAME,
          style: new TextStyle(fontWeight: FontWeight.bold, fontSize: 30.0, color: Colors.green, fontFamily: "Roboto"),
        ),
        image: Image(image: AssetImage('assets/images/logo.png')),
    );
  }

  Future<Widget> loadFromFuture() async {
    await Firebase.initializeApp();
    // To catch background messages
    FirebaseMessaging.onBackgroundMessage(firebaseMessagingBackgroundHandler);
    FirebaseMessaging.onMessage.listen(firebaseMessagingForegroundHandler);
    String token = await FirebaseMessaging.instance.getToken();
    print("FirebaseMessaging token: $token");

    // These func only call my API to retreive some data.
    bool authorsLoaded = await loadAuthors();
    bool translatorsLoaded = await loadTranslators();
    bool tagsLoaded = await loadTags();
    bool captionsLoaded = await loadCaptions();

    return buildHomePage(authorsLoaded && translatorsLoaded && tagsLoaded && captionsLoaded);
  }

  Widget buildHomePage(bool everythingLoaded) {
    return MaterialApp(
      debugShowCheckedModeBanner: false,
      title: APP_NAME,
      theme: ThemeData(
        primarySwatch: Colors.green,
        visualDensity: VisualDensity.adaptivePlatformDensity,
      ),
      home: (everythingLoaded) ? HomePage() : buildRetryPage(),
    );
  }

Widget buildRetryPage() {
    return Scaffold(
      appBar: AppBar(title: Text(APP_NAME)),
      body: Container(
        child: Column(
          children: <Widget>[
            Text('PROBLEM, PLEASE RETRY'),
            Padding(padding: EdgeInsets.only(bottom: 20.0)),
            GFButton(
                text: "RETRY",
                onPressed: () async {
                  Navigator.of(context).pushReplacement(MaterialPageRoute(builder: (BuildContext context) => MyApp()));
                }),
          ],
        ),
      ),
    );
  }

Expected behavior
It should call my callback only one time, or I done something wrong.
Thanks for your help 👍

I am also experiencing the same

That's weird
I can't reproduce it, temporarly you can make a variable that becomes true if the function ran and prevent the function from running again,  but I will try to investigate it also
Thanks for reporting

Yes this is what I use to avoid multiple calls 👍

I am also experiencing the same behaviour.
This is how it happens for me:
  Future<Widget> loadApplicationWithScreenToNavigate() async {
    printError(info: "Called");
    return Future.value(Home());
  }

  @override
  Widget build(BuildContext context) {
    return GetMaterialApp(
      title: 'Some title',
      debugShowCheckedModeBanner: false,
      theme: buildThemeData(),
      home: SplashScreen(
        navigateAfterFuture: loadApplicationWithScreenToNavigate(),
        backgroundColor: Colors.white,
    );

And in console I can see sometimes it's being called 2 times, sometimes 3 times.
P.S. Code above is pseudo code just to demonstrate the reproduction of this issue,

I am also experiencing the same behaviour.
This is how it happens for me:
  Future<Widget> loadApplicationWithScreenToNavigate() async {
    printError(info: "Called");
    return Future.value(Home());
  }

  @override
  Widget build(BuildContext context) {
    return GetMaterialApp(
      title: 'Some title',
      debugShowCheckedModeBanner: false,
      theme: buildThemeData(),
      home: SplashScreen(
        navigateAfterFuture: loadApplicationWithScreenToNavigate(),
        backgroundColor: Colors.white,
    );

And in console I can see sometimes it's being called 2 times, sometimes 3 times.
P.S. Code above is pseudo code just to demonstrate the reproduction of this issue,

Probably that the state changes and redraws the widget thus calling your Future again 🤔

I agree with @kuromukira , it should be a State issue.
A quick workaround worked for me : Setting a boolean to true as soon as the Future is called, and not calling the Future if the boolean is true :
`class _SplashScreenPageState extends State {
bool credentialsCalled = false ;
Future _retrieveCredentials() async {
if (!credentialsCalled) {
await Requests().getCredentials();
credentialsCalled = true;
}
return SearchPage();
}
@override
Widget build(BuildContext context) {
return SplashScreen(
  navigateAfterFuture: _retrieveCredentials(),
  // [...]
);

}
}`


add missing tests for Word

https://app.codecov.io/github/cieslarmichal/faker-cxx/blob/main/src%2Fmodules%2Fword%2FWord.cpp

I can try to fix this, @cieslarmichal  could you please assign this to me?

Yup, assigned


[Bug] [dolphinscheduler master] After the workflow contains a sub-process and performs the "Stop" operation, the workflow instance will always display "Ready to Stop"

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
After stopping a workflow with sub-processes, the workflow status in the workflow instance list always displays "Ready to Stop" and the workflow instance cannot be ended.
Create a workflow with sub-processes.
Submit workflow
Workflow instance list execution "Stop"
The workflow instance cannot be ended and "Ready to Stop" is always displayed.
对一个带子流程的工作流执行停止操作后，工作流流实例列表的工作流状态一直显示“准备停止”，该工作流实例无法结束。
dolphinscheduler 版本：3.1.8
1、创建一个带子流程的工作流。
2、提交工作流
3、工作流实例列表执行“停止”
4、查看工作流实例无法结束，一直显示“准备停止”
What you expected to happen
Problem description: After stopping a workflow with sub-processes, the workflow status in the workflow instance list always displays "Ready to Stop", and the workflow instance cannot be ended.
Expected results: The workflow instance ends normally with a status of Stopped.
问题描述：对一个带子流程的工作流执行停止操作后，工作流流实例列表的工作流状态一直显示“准备停止”，该工作流实例无法结束。
预期结果：该工作流实例正常结束，并且状态为“停止”。
How to reproduce
After stopping a workflow with sub-processes, the workflow status in the workflow instance list always displays "Ready to Stop" and the workflow instance cannot be ended.
Create a workflow with sub-processes.
Submit workflow
Workflow instance list execution "Stop"
The workflow instance cannot be ended and "Ready to Stop" is always displayed.
对一个带子流程的工作流执行停止操作后，工作流流实例列表的工作流状态一直显示“准备停止”，该工作流实例无法结束。
1、创建一个带子流程的工作流。
2、提交工作流
3、工作流实例列表执行“停止”
4、查看工作流实例无法结束，一直显示“准备停止”
Anything else
No response
Version
3.1.x
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Please use english to describe your issue.

请用英语描述您的问题。

Please use english to describe your issue.

Click the "Stop" button of a certain workflow in the workflow list, and the workflow status is always displayed as "Ready Stop"

Please use english to describe your issue.

Click the "Stop" button of a certain workflow in the workflow list, and the workflow status is always displayed as "Ready Stop"

Please use english to describe your issue.

Click the "Stop" button of a certain workflow in the workflow list, and the workflow status is always displayed as "Ready Stop"

hi,bro,Has the problem been solved?

3.1.7版本还是有这个问题，请问怎么解决呢


#48in24: Sync protein-translation

[x] Run bin/configlet sync -u -e protein-translation --yes --docs --filepaths --metadata --tests include (updates the Markdown files and maybe tests.toml)

docs: instructions unsynced: protein-translation
metadata: unsynced: protein-translation

[x] Drop strict types comments from test file and example code (these are useless)
[x] Add and sync test meta data to tests (uuid / @testdox in DocBlocks)
[x] Decide on adding / adjusting / ordering test cases to match current problem specs

protein-translation: missing 30 test cases
Missing tests.toml file!

Do not redesign the student's interface or add test cases that would invalidate existing community solutions. These are extra tasks, which should be discussed in advance.

No new tests, but data provider spread out into single test methods.


1brc contribution from mattiz (first attempt)

Check List:

[X] Tests pass (./test.sh <username> shows no differences between expected and actual outputs)
[X] All formatting changes by the build are committed
[X] Your launch script is named calculate_average_<username>.sh (make sure to match casing of your GH user name) and is executable
[X] Output matches that of calculate_average_baseline.sh
[X] For new entries, or after substantial changes: When implementing custom hash structures, please point to where you deal with hash collisions (line number)

Execution time: 6.5 seconds (when running on 8 cores)
Execution time of reference implementation: 2 minutes 15 seconds (when running on 8 cores)

Name: Mathias Bjerke
Github username: mattiz
Implementation class: dev.morling.onebrc.CalculateAverage_mattiz
Tested on laptop with: 13th Gen Intel(R) Core(TM) i7-1355U with 12 cores and 32GB RAM
Hash collisions is handled on: line 171

00:08.255.


Problem with targetNames with retainTargets()

ds = prtDataSetClass('X',0,'Y',[0,0],'targetNames',{'first','second'});
ds1 = ds.retainTargets(1);
ds2 = ds.retainTargets(2);
ds1.targetNames
ds2.targetNames

retainTargets() seems to be doing the right thing, but prtDataSetInMem.getTargetNames() looks for a target name associated with index 1 and, not finding it, yields a default target name.

Should be fixed in
https://github.com/covartech/PRT/commit/eb161c7c5bc64eb93fd4d3003cbb52d8faf19d58

ds = prtDataSetClass('X',0,'Y',[0,0],'targetNames',{'first','second'});
ds1 = ds.retainTargets(1);
ds2 = ds.retainTargets(2);
ds1.targetNames
ds2.targetNames

Should output:

ans =
  cell
    'first'
ans =
  cell
    'second'


how to solve the problem"has no field named "scale_param""

when I use the deploy to do get the feature,it has the problem like this?if I have a wrong version caffe?

the matter is that i can train the model successful,but when i use the deploy to get the feature,it falied.is there somebody can help me?


It seems to mess up my default maya shortcuts a bit

This one I am actually not very sure, but that's the only suspection I have, cause it happen after I start using the picker. My "f" button, and ctrl -z button is not quite working as before, the f button works on the picker's window, but not working for my perspective view anymore.

I need more information for this:

Os: Win10/11, MacOs, Linux
Maya version
Picker window is docked of floating.
It seems to work properly with Win10/11 maya 2018, maya 2020, maya 2022.

By the way, a similar issue (#23) as been solved on march 10th. May you just have to update your picker.

I actually just found that it occupied all my shortcuts from maya, for example right now when I click ctrl-s, even I click on the pesp window for many time, it still
call out the window for saving the picker file, instead of saving my maya file.

From: Ann ZHAO @.>
Sent: March 17, 2022 9:58
To: DreamWall-Animation/dwpicker @.>; DreamWall-Animation/dwpicker @.>
Cc: Author @.>
Subject: Re: [DreamWall-Animation/dwpicker] It seems to mess up my default maya shortcuts a bit (Issue #32)
win10, maya 2017 Update4, picker window is docked.

From: Lionel Brouyère @.>
Sent: March 17, 2022 5:05
To: DreamWall-Animation/dwpicker @.>
Cc: ann40 @.>; Author @.>
Subject: Re: [DreamWall-Animation/dwpicker] It seems to mess up my default maya shortcuts a bit (Issue #32)
I need more information for this:

Os: Win10/11, MacOs, Linux
Maya version
Picker window is docked of floating.
It seems to work properly with Win10/11 maya 2018, maya 2020, maya 2022.

By the way, a similar issue (#23https://github.com/DreamWall-Animation/dwpicker/issues/23) as been solved on march 10th. May you just have to update your picker.
—
Reply to this email directly, view it on GitHubhttps://github.com/DreamWall-Animation/dwpicker/issues/32#issuecomment-1070576181, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AH57WKL34FJI22THRSYN6LDVALYUFANCNFSM5Q5DNI4Q.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>

can you confirm it is still with the latest version of picker

no it's not the latest one, guess from 2021?

From: Lionel Brouyère @.>
Sent: March 17, 2022 16:37
To: DreamWall-Animation/dwpicker @.>
Cc: ann40 @.>; Author @.>
Subject: Re: [DreamWall-Animation/dwpicker] It seems to mess up my default maya shortcuts a bit (Issue #32)
can you confirm it is still with the latest version of picker
—
Reply to this email directly, view it on GitHubhttps://github.com/DreamWall-Animation/dwpicker/issues/32#issuecomment-1071406250, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AH57WKNCPBJLOIRJIPEFO4DVAOJYPANCNFSM5Q5DNI4Q.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>

Can you try to install the last commit firt and tell me if the issue persist.

do you know how I can uninstall this version completely? or I just directly install the latest one??

From: Lionel Brouyère @.>
Sent: March 17, 2022 18:13
To: DreamWall-Animation/dwpicker @.>
Cc: ann40 @.>; Author @.>
Subject: Re: [DreamWall-Animation/dwpicker] It seems to mess up my default maya shortcuts a bit (Issue #32)
Can you try to install the last commit firt and tell me if the issue persist.
—
Reply to this email directly, view it on GitHubhttps://github.com/DreamWall-Animation/dwpicker/issues/32#issuecomment-1071621838, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AH57WKOQ3K7WA3KWHANKVATVAOVBZANCNFSM5Q5DNI4Q.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>

Hey, I haven't uninstall yet, cause I am not sure how to completely uninstall. But I've just tried to undock it, and seems like in that
way the f key and other keys is working in maya.

From: Lionel Brouyère @.>
Sent: March 17, 2022 18:13
To: DreamWall-Animation/dwpicker @.>
Cc: ann40 @.>; Author @.>
Subject: Re: [DreamWall-Animation/dwpicker] It seems to mess up my default maya shortcuts a bit (Issue #32)
Can you try to install the last commit firt and tell me if the issue persist.
—
Reply to this email directly, view it on GitHubhttps://github.com/DreamWall-Animation/dwpicker/issues/32#issuecomment-1071621838, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AH57WKOQ3K7WA3KWHANKVATVAOVBZANCNFSM5Q5DNI4Q.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>

Hey, just go to the script folder:

and delete the dwpicker folder.

yeah  I tried, but the script can still be run by my maya haha.
btw, I got another question about the prop, are we not able to create a button for prop in character's picker file? we have to create another file for
prop to create seperate picker right?

From: Lionel Brouyère @.>
Sent: March 18, 2022 5:27
To: DreamWall-Animation/dwpicker @.>
Cc: ann40 @.>; Author @.>
Subject: Re: [DreamWall-Animation/dwpicker] It seems to mess up my default maya shortcuts a bit (Issue #32)
Hey, just go to the script folder:
[image]https://user-images.githubusercontent.com/25019043/158976635-77d67c8f-e1e8-45f2-a64c-1c2f6efdcc21.png
and delete the dwpicker folder.
—
Reply to this email directly, view it on GitHubhttps://github.com/DreamWall-Animation/dwpicker/issues/32#issuecomment-1072229575, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AH57WKIX42622ZW6TUSYCU3VARD7JANCNFSM5Q5DNI4Q.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>

it should work. The only thing is, that can lead issue if they have different namespaces and you want to switch it.
By the way, the data are saved inside the maya scenes. Then you can do edit scene per scene without erasing the file.
I will close the ticket as I it is a duplicate or #23 and I think it is solved.
Do not hesitate to reopen it or create new one if you encounter other issue.


Xpath select returns only first element when it should return set

When having this XML sample
<c>
  node1
  node2
</c>

and the query /c/b/a[1] the library returns only the first
node1

It should return the first a child of all /c/b nodes, therefore, expected output is
node1node2

Code:
const dom = require('xmldom').DOMParser;
const xpath = require('xpath');
const doc = new dom().parseFromString("<c>node1node2</c>");
console.log(xpath.select("/c/b/a[1]",doc).toString());

There is already a case #45 on this, which contains a workaround (albeit not a terrific one).


Added name to list of contributors

What changes does this PR do?
It adds my name to the README file

closing due to inactivity


404 redirects appending /index.html

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

App Id
No response
Region
No response
Amplify Console feature
No response
Describe the bug
Description of the issue:
Setup:
suba.domain.com - amplify react application
subb.domain.com - application hosted on EC2
Replication:
With below 404 redirect rule we are trying to redirect to a resource path/page "test" from suba to subb in case the "test" is not present in suba.domain.com.

Source address*: /<*>
Target address*:  subb.domain.com/<*>
Type*: 404 redirect
For a "/test" page we are redirected to subb.domain.com/test/index.html, however expected behaviour should be "subb.domain.com/test"
On using below 301 permanent redirect, the redirections works as expected from suba.domain.com/test, to subb.domain.com/test/,

Source address*: /test
Target address*:  subb.domain.com/test
Type*: 301 permanent redirect
But use-case requirement is to be it working the same for 404 redirects.
Expected behavior
For a "/test" page we are redirected to subb.domain.com/test/index.html, however expected behaviour should be "subb.domain.com/test"
Reproduction steps
Source address*: /<*>
Target address*:  subb.domain.com/<*>
Type*: 404 redirect
For a "/test" page we are redirected to subb.domain.com/test/index.html, however expected behaviour should be "subb.domain.com/test"
Build Settings
No response
Additional information
No response

Any update or workaround for this? I am having the same issue.


Spurious test-case failures related to string merging

Pretty rarely, but surely, I hit the following issue for various test-cases:
$ cargo clean
$ cargo test --release
Error: Failed copying from /usr/lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crt1.o (256 (1/0)) to output file

Caused by:
    0: Failed to apply relocations in section `.debug_info` of /usr/lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crt1.o
    1: Failed to apply relocation of type R_X86_64_32 to section `.debug_str` (23 local=13) in file #256 (1/0) (/usr/lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crt1.o) (ADDRESS | CAN_BYPASS_GOT) at offset 0x1a
    2: Failed to find merge-string at offset 0
test integration_test::program_name_31___input_does_not_exist_c__ ... ok
collect2: error: ld returned 255 exit status
test integration_test::program_name_02___trivial_main_c__ ... FAILED

I also hit the same issue in dev mode sometimes:
Error: Failed copying from /usr/lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crt1.o (256 (1/0)) to output file

Caused by:
    0: Failed to apply relocations in section `.debug_info` of /usr/lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crt1.o
    1: Failed to apply relocation of type R_X86_64_32 to section `.debug_line_str` (24 local=14) in file #256 (1/0) (/usr/lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crt1.o) (ADDRESS | CAN_BYPASS_GOT) at offset 0x4b
    2: Failed to find merge-string at offset 112
collect2: error: ld returned 255 exit status
test integration_test::program_name_29___cpp_integration_cc__ ... FAILED

Typically happens if I run cargo clean and then completely rebuild the wild linker. This might be related to: #249.

Pretty common in the debug mode as well:
❯ for t in {0..30} ; do echo $t ; cargo t 2>&1 | grep -B5 -A5 merge-string ; done
0
1
2
3
4
5
6
7
8
9
Make sure unwinding works
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at /home/marxin/Programming/wild/wild/tests/sources/rust-integration.rs:21:5:
Make sure unwinding works
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: Failed to find merge-string at offset 16640
collect2: error: ld returned 255 exit status
test integration_test::program_name_26___libc_integration_c__ ... FAILED
test integration_test::program_name_28___rust_integration_dynamic_rs__ ... ok
thread 'main' panicked at /home/marxin/Programming/wild/wild/tests/sources/rust-integration.rs:21:5:
Make sure unwinding works
10
11
12
13
14
15
16
17
18
19
Error: Failed copying from /usr/lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crt1.o (256 (1/0)) to output file

Caused by:
    0: Failed to apply relocations in section `.debug_info` of /usr/lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crt1.o
    1: Failed to apply relocation of type R_X86_64_32 to section `.debug_line_str` (24 local=14) in file #256 (1/0) (/usr/lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crt1.o) (ADDRESS | CAN_BYPASS_GOT) at offset 0x4b
    2: Failed to find merge-string at offset 112
collect2: error: ld returned 255 exit status
test integration_test::program_name_29___cpp_integration_cc__ ... FAILED
thread 'main' panicked at /home/marxin/Programming/wild/wild/tests/sources/rust-integration.rs:21:5:
Make sure unwinding works
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
20
21
22
23
24
25
26
27
Error: Failed copying from /usr/lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crt1.o (256 (1/0)) to output file

Caused by:
    0: Failed to apply relocations in section `.debug_info` of /usr/lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crt1.o
    1: Failed to apply relocation of type R_X86_64_32 to section `.debug_str` (23 local=13) in file #256 (1/0) (/usr/lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crt1.o) (ADDRESS | CAN_BYPASS_GOT) at offset 0x1a
    2: Failed to find merge-string at offset 0
collect2: error: ld returned 255 exit status
test integration_test::program_name_29___cpp_integration_cc__ ... FAILED
thread 'main' panicked at /home/marxin/Programming/wild/wild/tests/sources/rust-integration.rs:21:5:
Make sure unwinding works
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
28
29
30

I assume this has only started happening since I changed the string merge algorithm - i.e in the last day?

Yes, started with 190bec9.

Got fixed with the just landed changes related to string merging.


fix(forseti-security): fix Helm error

Proposal to fix an error in the Helm chart.
For more info : https://github.com/helm/helm/issues/8311

@googlebot I signed it!

Thanks for this @ThibaultLengagne, can you clarify what versions of Helm this is fixing and what version you are using? Just want to make sure this is compatible with the existing Terraform module, which I believe most people are using 0.10.4.

Hi @gkowalski-google,

It is fixing version the Helm version helm-v2.16.8, which uses the Go version 1.14. In this version of Go, there is a new checker that reports errors when a parenthesized argument is used as a function : commit
I am using this version of Helm : version.BuildInfo{Version:"v3.5.0", GitCommit:"32c22239423b3b4ba6706d450bd044baffdcf9e6", GitTreeState:"clean", GoVersion:"go1.15.6"}
It should not break previous version of Helm, as the syntax is valid for any Helm version :)

Can we get a release with this fix?

Seconding @tony-mw 's comment. Any news on this getting released?

To confirm, you just need us to publish a new chart to Helm Hub, correct?

Hi @gkowalski-google, apologies for the delay your response got buried in my Junk. But yes please, now this has been merged into master it would be great if this could get published.


Renamed otel-metrics-service folder and updated values file for how to use Grafana Agent with OTEL

Renamed the otel-metrics-service folder to Otel-service
Updated values.yaml file
Updated README.md

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I just had someone else with the same annotation issue. What version of the Helm CLI are you using? Try upgrading to the latest and trying again?

I just had someone else with the same annotation issue. What version of the Helm CLI are you using? Try upgrading to the latest and trying again?

version.BuildInfo{Version:"v3.9.0", GitCommit:"7ceeda6c585217a19a1131663d8cd1f7d641b2a7", GitTreeState:"clean", GoVersion:"go1.18.2"}

I just had someone else with the same annotation issue. What version of the Helm CLI are you using? Try upgrading to the latest and trying again?

version.BuildInfo{Version:"v3.9.0", GitCommit:"7ceeda6c585217a19a1131663d8cd1f7d641b2a7", GitTreeState:"clean", GoVersion:"go1.18.2"}

Gotcha! Yeah, there's an issue in helm 3.9 where it doesn't respect removing fields in values by setting them to null. That's why the node exporter annotation keeps coming back. Try upgrading your helm cli and try again. I'm really looking forward to getting this example updated!

I just had someone else with the same annotation issue. What version of the Helm CLI are you using? Try upgrading to the latest and trying again?

version.BuildInfo{Version:"v3.9.0", GitCommit:"7ceeda6c585217a19a1131663d8cd1f7d641b2a7", GitTreeState:"clean", GoVersion:"go1.18.2"}

Gotcha! Yeah, there's an issue in helm 3.9 where it doesn't respect removing fields in values by setting them to null. That's why the node exporter annotation keeps coming back. Try upgrading your helm cli and try again. I'm really looking forward to getting this example updated!

My system got a bit messed up, I think it would be easier for me to close this PR and create a new one.


xliffmerge does not merge the new source references

Starting with ng 4.0 there is a reference to the source of a message in the xlf or xmb file.
xliffmerge should transport this information from the master to the merged files.
This should happen too when the merged file contains already completed translations.

fixed with 0.6


Failed to run config using default config

{
"saghen/blink.cmp",
opts = {
highlight = {
use_nvim_cmp_as_default = true,
},
-- experimental auto-brackets support
accept = { auto_brackets = { enabled = true } },
  -- experimental signature help support
  trigger = { signature_help = { enabled = true } },
},

},

you need to add version = 'v0.*', since only the tagged versions contain the binary needed for blink.cmp. If you leave it out, you will have to build the binary itself, as documented in the readme

Chris's comment is correct as well but this specific error seems to come from running an unsupported neovim version. Try running nvim --version to confirm that you're on v0.10.0+

Closing as not planned since it seems like an issue with your environment but don't hesitate to comment if you're still having trouble!


Region copy fix

*New PR due to incorrect branching resulting in conflicting commit history
Minor changes for 0.1.1

Region bug fix where 'repair create' failed when the resource group region and disk region was different.

Typo fixes

If this PR is for a new extension or change to an existing extension, use the following to try out the changes in this PR:
docker run -it microsoft/azure-cli:latest
export EXT=<NAME>
pip install --upgrade --target ~/.azure/cliextensions/$EXT "git+https://github.com/swbae31/azure-cli-extensions.git@region_copy_fix#subdirectory=src/$EXT&egg=$EXT"


Integration startet nicht

Hallo ich habe es über die HACS repo instaliert. Ich bekomme aber immer die Meldung:
Logger: homeassistant.setup
Source: setup.py:251
First occurred: 19:43:04 (1 occurrences)
Last logged: 19:43:04
Setup failed for custom integration victron: No setup or config entry setup function defined.
Was mache ich falsch?

2023-03-06 20:26:19.755 WARNING (SyncWorker_1) [homeassistant.loader] We found a custom integration victron which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-03-06 20:26:19.755 WARNING (SyncWorker_1) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-03-06 20:26:28.947 ERROR (MainThread) [homeassistant.setup] Setup failed for custom integration victron: No setup or config entry setup function defined.

Versions:
Cerbo 2.92
Core 2023.3.1
Victron Cerbo GX 0.0.8 und 0.0.9 tested. Same failure


can't find moudle "chokidar"

here are two issue, one about gulp and the other one is about postcss
please have look the one about gulp,  can't find moudle "chokidar"
What were you expecting to happen?
no error
What actually happened?

Please post a sample of your gulpfile (preferably reduced to just the bit that's not working)
import * as  gulp from "gulp"
import * as rename from "gulp-rename"
import * as stylus from "gulp-stylus"
import * as plumber from "gulp-plumber"

import * as autoprefixer from "autoprefixer"
import * as postcss from "gulp-postcss"

import * as ts from "gulp-typescript"
import { FSWatcher } from "fs";

let tsProject = ts.createProject("tsconfig.json");

function acss(done) {
    gulp.src(`pages/**/*.styl`)
        .pipe(plumber())
        .pipe(stylus())
        .pipe(postcss([autoprefixer()]))
        .pipe(rename({
            extname: '.acss',
        }))
        .pipe(gulp.dest("./"));
    done();
}

function tsc(done) {
    gulp.src(`./**/*.ts`)
        .pipe(tsProject())
        .js
        .pipe(gulp.dest("./"));
    done();
}

console.log("starting gulp task...")
gulp.task("default", gulp.parallel(acss, tsc))

console.log("starting watching...")

let watcher = <FSWatcher[]>[]

watcher.push(gulp.watch(`./**/*.styl`, acss))
watcher.push(gulp.watch(`./**/*.ts`, tsc))

watcher.forEach((ele) => {
    ele.on("change", (fileName, eventType) => {
        console.log(`${fileName} changed...`)
    })
})

What version of gulp are you using?
4.0.2
What versions of npm and node are you using?
node 15.3 npm 6.4.1 yarn 1.5.2

This looks like an issue in your package.json or tsconfig.json file. Make sure that you use<EMAIL_ADDRESS>or higher.
This is a Typescript error caused by the types defined in DefinitelyTyped. We don't control these types. [Report the issue on DefinitelyTyped] if it persists.

@demurgos yeah, I use<EMAIL_ADDRESS>now. and it has some relation with tsconfig.json file, the issue come out wiht target option above es5.


[MeshModel] Add new Peer Relationship definitions

Notes for Reviewers
This PR adds Controller and Configurational relationship definitions.
Signed commits

[x] Yes, I signed my commits.

🚀 Preview for commit 7eb5cc6d658d06c5c57f1421ef5446508b905bbb at: https://64bf988031e2ef46dc8bb6ab--meshery-docs-preview.netlify.app


feat: add random pivot quick sort algorithm

Description of Change

Checklist

[x] Added description of change
[x] Added file name matches File name guidelines
[x] Added tests and example, test must pass
[x] Added documentation so that the program is self-explanatory and educational - Doxygen guidelines
[x] Relevant documentation/comments is changed or added
[x] PR title follows semantic commit guidelines
[x] Search previous suggestions before making a new one, as yours may be a duplicate.
[x] I acknowledge that all my contributions will be made under the project's license.

Notes:

I saw another file with c-style declarations of arrays, so I reverted my code, but now linter complains, so I used  now.

saw another file with c-style declarations of arrays

Those are old files with C-style code, but now we ask to use pure C++11 only.

Ohh... make sense.

pushing suggestions in 10 mins, sorry for the delay
On Mon, Jun 21, 2021 at 10:36 AM David Leal @.***>
wrote:

@Panquesito7 requested changes on this pull request.
The suggestions and reviews above must be accepted. Thanks.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/TheAlgorithms/C-Plus-Plus/pull/1510#pullrequestreview-688031731,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHXAYJDJU4K3SU7QJF3XBWTTT3CENANCNFSM465Z2XYA
.

Done :)

It's done! Thanks for the suggestions :)

Hi @Panquesito7, sorry for the ping, Can you check once.

Does this need further improvements?

completed

@Panquesito7 can u take a look


Add support for PATCH to partially replace an entity

~This PR adds support for PUT requests to fully replace an entity in one transaction. Note that you'll need to supply the full object. Non-supplied checks or linked users for example will be removed.~
This PR adds support for PATCH requests to partially replace an entity in one transaction. You'll need to pass the properties you want to replace. If you want to replace the full object, specify all properties.
See https://github.com/angely-dev/freeradius-api/issues/5

I'll update this PR to add support for PATCH requests also, since I can refactor this a bit.

I've added support for PATCH.
I could refactor to create a BaseUser and have a UserCreate and UserUpdate inherit from this BaseUser. The username could then be in the UserCreate class (since UpdateUser doesn't need to username in the body), and the UserUpdate would just extend from BaseUser with only an updated model_config.
I think this might make the code more complicated though, so I leave it up to you to indicate if you want to have some changes.

Thanks for the work and your interest in the project. I do appreciate!
I reviewed the commit for the PUT and couldn't have done it better, except for the status code that should be 200 instead of 201. Theoretically, it may also create the object if it does not exist already (and in this case, a 201 is returned, yes) as per RFC 9110.
What you implemented in the PATCH is precisely the JSON Merge Patch strategy from RFC 7386 (e.g., if an attribute is not given, we don't modify it). For reference, FastAPI did document it in Partial updates with PATCH and it makes use of Pydantic exclude_unset feature.
I'm okay with this implementation and I agree: at this point, we might as well refactor the classes with inheritance. For reference again, FastAPI did suggest a similar pattern, especially about the naming convention (UserBase, UserCreate and so UserUpdate). Feel free to refactor this if you wish. Otherwise, I'll probably do it myself later.
I can either accept the PR as is or wait for the refactor.

Thanks for your review and comment!

I reviewed the commit for the PUT and couldn't have done it better, except for the status code that should be 200 instead of 201. Theoretically, it may also create the object if it does not exist already (and in this case, a 201 is returned, yes) as per RFC 9110.

Note that I removed the PUT requests, since the same could be achieved by using the PATCH requests and just passing all the attributes with [].
I think for this merge request, the PATCH implementation is fine and the refactoring can be done later if needed. I don't think the PUT request is needed.

I'll update the PATCH implementations so it returns a 200 instead of a 201.

So I ran your PR in my local environment and all seems good.
Would you mind, however, add a bit more unit tests to get 100% code coverage of pyfreeadius as it is the case at the moment?
$ pip install coverage
$ coverage run -m unittest test.py
.....
----------------------------------------------------------------------
Ran 5 tests in 0.126s

OK

$ coverage report
Name              Stmts   Miss  Cover
-------------------------------------
database.py           5      0   100%
pyfreeradius.py     333     16    95%
test.py             102      0   100%
-------------------------------------
TOTAL               440     16    96%

You can see details and missing lines using the HTML report:
$ coverage html
Wrote HTML report to htmlcov/index.html

Also, could you sync your fork to get the last commit that removed the extra commit from NasRepository.add?
Thanks!

I was trying to add the missing unit tests and got some failures. Here are the problems I observed:

patch_user endpoints does not check groups (if given) existence (like this)—so we can add a non-existing group to a user
patch_group endpoints does not check users (if given) existence (like this)—so we can add a non-existing user to a group
We cannot update just the group users, e.g., GroupUpdate('my-existing-group', users=[gu, gu2]) will trigger a ValidationError because of these lines

So the code is actually missing some semantic checks.

My bad, I forgot to add those. I think I addressed these changes in my last commit.

Thanks for the changes.
One last concern: the patch_group endpoint now allows to remove all group attributes (checks and replies). And this I explicitly forbid during the conceptual stage. It will also trigger a ValidationError when returning the group because of these lines.
Example:
{
    "checks": [],
    "replies": [],
    "users": [{"username": "a", "priority": 1}, {"username":"b", "priority": 1}]
}

So the patch_group endpoint needs extra logic to compare the given attributes with the current ones.
Conceptually, having a group without any attributes (while permitted by the FreeRADIUS data model) is strange from the REST API point of view. It would mean that a user can belong to a non-existing group. The group will start to exist because a user has been bound to him, and will cease to exist once its last user has been deleted.

Hmm, I do have the use-case for a group without any attributes or checks. This is to make it easier later on to just add attribute to that group without having to link all users to that group. I prefer to link the users to their group during creation instead of later on when a parameter is added, since this information isn't easily available at that point.

So this is more of a conceptual change I prefer not to accept. I get your point, but this API is mainly made for automation purposes where users get created and updated (deleted and re-created) using a Source of Truth. It could be the same for groups (e.g., L3VPN groups shared among users of the same L3VPN). I don't see a practical need where an automatized tool will first create an empty group with users and then add the attributes later.
At this point, either we add more logic to prevent empty groups or we implement attributes overwriting as I suggested in https://github.com/angely-dev/freeradius-api/issues/5#issuecomment-2143377592.
You may disagree on the conceptual approach and I'd understand if you prefer to work on a separate fork with that enhancement.

I'll try to describe my use-case, and leave it up to you what you want to do with it :)
We will be using the API to push Radius users that is used for PPPoE sessions. We use a radius group to combine users that belong to the same Organisation. They can have multiple users if they have multiple connections on multiple locations.
Usually, we specify on a group level if the user needs to be terminated in a specific VRF but we can also provide different DNS servers here for example.
On occasion, these settings can change, or some other group level setting needs to be modified. (This is why I want to be able to PATCH them instead of deleting and recreating).
Now, while writing this, I noticed that we always have at least one attribute in the group (to specify the VRF) so the restriction on having at least one attribute might be okay for us.

Yes, the use case you described is a typical scenario for VRF-based users belonging to the same L3VPN and RADIUS groups are well suited for this. I'm okay with the PR but the extra logic in patch_group endpoint to ensure groups always have at least one attribute is needed. I could add it myself after accepting the PR, or you could implement it if you are willing to.

I can look at this next week :)

@angely-dev I've added the check to the patch_group(). I still have some doubts about this, since we need to do 3 extra queries now when updating a group, but this does allow for the business rules to be consistent, so I suppose it's worth it :)
I also noticed that I had to check for the checks, replies or groups to be actually None instead of falsy, to know the difference between an update with no values ([]), or not updating something.
I wanted to add a test for this, but this would require a rewrite of the tests, since they now test the repository itself, instead of the api methods where the additional business logic resides.

I reran the PR in my local environment and got errors:

When patching an object, lines 118, 131 and 148 throw an AttributeError since the name is not part the Update models, e.g.:

    raise AttributeError(f'{type(self).__name__!r} object has no attribute {item!r}')
AttributeError: 'GroupUpdate' object has no attribute 'groupname'

I fixed it and got another error after patching my group which only has reply attributes:

fastapi.exceptions.ResponseValidationError: 3 validation errors:
  {'type': 'missing', 'loc': ('response', 'groupname'), 'msg': 'Field required', 'input': GroupUpdate(checks=None, replies=[AttributeOpValue(attribute='Filter-Id', op=':=', value='10m')], users=None)}
  {'type': 'list_type', 'loc': ('response', 'checks'), 'msg': 'Input should be a valid list', 'input': None}
  {'type': 'list_type', 'loc': ('response', 'users'), 'msg': 'Input should be a valid list', 'input': None}

That is because there is a mismatch between the response_model which is set to Group and the object you returning which is a GroupUpdate. The same applies for User and Nas. And in the current code, I work with empty list rather than None.

Unit tests still not cover all the pyfreeradius module:

$ coverage run -m unittest test.py
.....
----------------------------------------------------------------------
Ran 5 tests in 0.143s

OK

$ coverage report
Name              Stmts   Miss  Cover
-------------------------------------
database.py           5      0   100%
pyfreeradius.py     333     16    95%
test.py             102      0   100%
-------------------------------------
TOTAL               440     16    96%

Note that I am working on the unit tests of the API itself as per Testing.

I reran the PR in my local environment and got errors:
* When patching an object, lines [118](https://github.com/michaelarnauts/freeradius-api/blob/allow-updates/src/api.py#L118), [131](https://github.com/michaelarnauts/freeradius-api/blob/allow-updates/src/api.py#L131) and [148](https://github.com/michaelarnauts/freeradius-api/blob/allow-updates/src/api.py#L148) throw an `AttributeError` since the `name` is not part the `Update` models, e.g.:

    raise AttributeError(f'{type(self).__name__!r} object has no attribute {item!r}')
AttributeError: 'GroupUpdate' object has no attribute 'groupname'

* I fixed it and got another error after patching my group which only has reply attributes:

fastapi.exceptions.ResponseValidationError: 3 validation errors:
  {'type': 'missing', 'loc': ('response', 'groupname'), 'msg': 'Field required', 'input': GroupUpdate(checks=None, replies=[AttributeOpValue(attribute='Filter-Id', op=':=', value='10m')], users=None)}
  {'type': 'list_type', 'loc': ('response', 'checks'), 'msg': 'Input should be a valid list', 'input': None}
  {'type': 'list_type', 'loc': ('response', 'users'), 'msg': 'Input should be a valid list', 'input': None}

That is because there is a mismatch between the response_model which is set to Group and the object you returning which is a GroupUpdate. The same applies for User and Nas. And also in the current code, I work with empty list rather than None.
* Unit tests still not cover all the `pyfreeradius` module:

$ coverage run -m unittest test.py
.....
----------------------------------------------------------------------
Ran 5 tests in 0.143s

OK

$ coverage report
Name              Stmts   Miss  Cover
-------------------------------------
database.py           5      0   100%
pyfreeradius.py     333     16    95%
test.py             102      0   100%
-------------------------------------
TOTAL               440     16    96%

Note that I am working on the unit tests of the API itself as per Testing.

This is intentional. I've removed the username from the UserUpdate class, since the actual username is passed on in the url when making the call. If not, you could pass one username in the URL, and another in the body, and the one in the body would be ignored, since I use the one from the URL right now. This might be confusing.
Also, when patching, there is a difference between having a null or an empty list []. Passing null to the attributes for example won't update the attributes, while passing an empty list will remove all current attributes. Therefore, the defaults in the *Update objects are None instead of the [] in the original objects.
I'm not sure what I need the change for this?

About the username/groupname/nasname, no need to have it as attribute of the Update models (just like you did), we just need to use the query parameter.
About the null, yes I am aware of the difference with [], especially in the JSON Merge Patch strategy. I think we need to change the original behavior where I preferred to use empty lists instead of None and update the unit tests. I could do this change.

Before changing the original behavior, I tried this:
@router.patch('/groups/{groupname}', tags=['groups'], status_code=200, response_model=Group, responses={**e409_response})
def patch_group(groupname: str, group: GroupUpdate, response: Response):
    if not group_repo.exists(groupname):
        raise HTTPException(404, 'Given group does not exist')

    for user in group.users or []:
        if not user_repo.exists(user.username):
            raise HTTPException(422, f"Given user '{user.username}' does not exist: create it first")

    current_group = group_repo.find_one(groupname)
    if (not current_group.replies and group.replies == []) and (not current_group.checks and group.checks == []):
        raise HTTPException(422, 'Group must have at least one check or one reply attribute')

    group_repo.update(groupname, group)
    response.headers['Location'] = f'{API_URL}/groups/{groupname}'  # used groupname instead of group.groupname
    return group_repo.find_one(groupname)                           # simply re-fetch the group once updated

So it's better but I am still encountering an error easy to reproduce:
curl -X 'POST' \
  'http://localhost:8000/groups' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "groupname": "my-group",
  "replies": [
    {
      "attribute": "Filter-Id",
      "op": ":=",
      "value": "10m"
    }
  ]
}'

201 Created:
{"groupname":"my-group","checks":[],"replies":[{"attribute":"Filter-Id","op":":=","value":"10m"}],"users":[]}

Now I remove the replies, expecting an HTTPException that'd forbid it:
curl -X 'PATCH' \
  'http://localhost:8000/groups/my-group' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "replies": []
}'

Internal Server Error

Trace:
INFO:     <IP_ADDRESS>:57120 - "POST /groups HTTP/1.1" 201 Created
INFO:     <IP_ADDRESS>:42542 - "PATCH /groups/my-group HTTP/1.1" 500 Internal Server Error
ERROR:    Exception in ASGI application
Traceback (most recent call last):
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/uvicorn/protocols/http/httptools_impl.py", line 399, in run_asgi
    result = await app(  # type: ignore[func-returns-value]
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/uvicorn/middleware/proxy_headers.py", line 70, in __call__
    return await self.app(scope, receive, send)
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/fastapi/applications.py", line 1054, in __call__
    await super().__call__(scope, receive, send)
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/starlette/applications.py", line 123, in __call__
    await self.middleware_stack(scope, receive, send)
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/starlette/middleware/errors.py", line 186, in __call__
    raise exc
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/starlette/middleware/errors.py", line 164, in __call__
    await self.app(scope, receive, _send)
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/starlette/middleware/exceptions.py", line 65, in __call__
    await wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/starlette/_exception_handler.py", line 64, in wrapped_app
    raise exc
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/starlette/_exception_handler.py", line 53, in wrapped_app
    await app(scope, receive, sender)
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/starlette/routing.py", line 756, in __call__
    await self.middleware_stack(scope, receive, send)
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/starlette/routing.py", line 776, in app
    await route.handle(scope, receive, send)
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/starlette/routing.py", line 297, in handle
    await self.app(scope, receive, send)
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/starlette/routing.py", line 77, in app
    await wrap_app_handling_exceptions(app, request)(scope, receive, send)
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/starlette/_exception_handler.py", line 64, in wrapped_app
    raise exc
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/starlette/_exception_handler.py", line 53, in wrapped_app
    await app(scope, receive, sender)
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/starlette/routing.py", line 72, in app
    response = await func(request)
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/fastapi/routing.py", line 296, in app
    content = await serialize_response(
  File "/tmp/freeradius-api-allow-updates/venv/lib/python3.10/site-packages/fastapi/routing.py", line 155, in serialize_response
    raise ResponseValidationError(
fastapi.exceptions.ResponseValidationError: 1 validation errors:
  {'type': 'model_attributes_type', 'loc': ('response',), 'msg': 'Input should be a valid dictionary or object to extract fields from', 'input': None}

I still appreciate the help and the will to enhance this projet but I am surprised the code wasn't fully tested on your side. That's why I insist about the full code covarage of pyfreeradius and soon, the full code coverage of api.py (I can add it after merging this PR).

Please note I just added unit tests of the API in fe4d33c. I created a tests/ directory and renamed the original test file without modifying it so that it doesn't impact your changes so much (I will modify it later to follow pytest naming convention). I also updated the README.


dev: add poetry as a requirement in the README.md

Describe the enhancement request
The README doesn't mention the need to have poetry installed in order to run the make setup command. Add this requirement to the README and a link to the poetry installation steps.
Time: 30 minutes

Can I take this?

Sure!


Center point of the 3D editor has visual glitches

Ubuntu 17.04, Godot Build: 6b99950
Issue description:
The light blue center point of the 3D editor (I'm quite sure there is a actual name for it, but hell if I know) has visual glitches, and it seems to be fighting with the red and dark blue lines.

This could possibly be fixed by turning the origin into a mesh, which would display a similar shape, but slightly thicker, so that it overlaps the grid lines.

It seems that there is no origin representation anymore now. So I suppose this should be closed.


Bug: Registration & Login page needs responsiveness

Description
When the registration page & the login page is being opened with smaller or larger screens, they are taking up spaces in a distorted way.
Proposed Solution
The UI of the registration and login page should be clean and pleasant after opening in different screen sizes.
Screenshots
No response
Browser 🥦
Google Chrome
Checklist ✅

[X] I checked and didn't find similar issue
[X] I have read the Contributing Guidelines
[ ] I am willing to work on this issue (leave this unchecked for no).

@ItsRoy69 Hi, I would like to help you address this issue. Could you please assign the project to me? Thank you.

Go for it

@ItsRoy69 hey again, thanks for the assignment, there is something I want to share with you before I modify the code
Current UI of the register page

because of using position fixed you had to add margin-top to all your pages ( it can be fixed using sticky)
Can I remove the image on the registration page for mobile devices ( or even use it as bg )?
Can I reduce the gaps to make the content fit on the desktop without the need to scroll?
Can I eliminate the extra space on the footer?
Can I reduce the size of the form title?

Kindly inform me about the details. This will enable me to initiate the fixing process at the earliest.

Use sticky for the image
Better as it'll be clean then
No will be prioritised but if the form looks clean then do
Yes
Same as 3

@ItsRoy69 Hi again, I have a question about this project, I created issue #174, and I fixed that and created a PR, but I could not assign that to myself also no one responded to that PR, what can I do about that?


Refactor to use Builder package and filter namespaces with Predicates

I was going to use a MultiNamespaceCache to enable cross namespace watching, but after looking into it more there are some performance warnings when using a large number of namespaces and a preference for using Predicates for including/excluding namespaces.
Swapping to the builder pattern aligns with the expected use of controller-runtime from what I can tell and makes it very easy to leverage Predicates, model parent-child references, and other commons tasks besides.
Since this may be a somewhat significant change I did a review of features that may be better implemented using the common flow of Predicates:

https://github.com/mongodb/mongodb-atlas-kubernetes/pull/272 could be done by adding a predicate to disable listening.
https://github.com/mongodb/mongodb-atlas-kubernetes/pull/213/files added +200 lines to the code base, but may have been implemented with a Predicate based on Delete requests that ignores the request if the label exists.
https://github.com/mongodb/mongodb-atlas-kubernetes/issues/270 works fine if you watch all namespaces, but if you want to restrict namespaces it doesn't because you can't find the Global API Key. This PR fixes that issue using predicates.

Using the controller Builder package also connects you to other facets of controller-runtime that you may be interested in pursuing. For instance you can define Owns relationships between AtlasClusters and ConnectionSecrets so that the controller knows to garbage collect ConnectionSecrets if the owner disappears. (Docs) Or just separating the control logic for ConnectionSecrets into their own controller.
I hope this is helpful! Thank you for letting me review your project and let me know if there was a reason for the previous code and I can close this PR. If you can't tell we're very excited about your work :)

Documented reasons to not use MultiNamespaceCache:

Note that this is not intended to be used for excluding namespaces, this is better done via a Predicate. Also note that you may face performance issues when using this with a high number of namespaces.

I see SetupWithManager sets up the watches etc.


"AttributeError: module 'tensorflow' has no attribute 'flags"' when uses command "g2g-datagen"

As title, I was applying g2g-datagen to generate cosmos data, then I got an error message:
File "/Users/ppxtc1/anaconda2/envs/g2g/lib/python3.6/site-packages/tensor2tensor/bin/t2t_datagen.py", line 58, in
flags = tf.flags
AttributeError: module 'tensorflow' has no attribute 'flags'
This might be due to Tensor2Tensor is not compatible with Tensorflow 2.

Hi Sunny :-)
Yes, so, the way to fix all of these issues is either
1 -  Make sure you are using TF v1.5
2 - Replace the TF imports from this:
import tensorflow as tf

to this:
import tensorflow.compat.v1 as tf
tf.disable_v2_behavior()

as documented here: https://www.tensorflow.org/guide/migrate

@tycheng-sunny Actually, it's Tensor2Tensor itself that seems to be causing issues. What version of T2T and TF do you have installed?
See this issue: https://github.com/tensorflow/tensor2tensor/issues/1771

Yes I think you were right.
The error message shows up when I tried to pip install tensor2tensor. I installed TF v2.1.
I have changed to TF v1.15, the error message is fixed.
However, there is another issue that:
OSError: /tmp/t2t_datagen/COSMOS_25.2_training_sample/real_galaxy_catalog_25.2.fits not found.

Ah yes, so the problem here is that you first need to download the GalSim COSMOS dataset. You can do it using:
$ galsim_download_cosmos -s 25.2

hi! i'm also having tensorflow compatibility issues.
i'm running the following in a colab notebook:
!pip install tensorflow-gpu==1.15
!pip install unagi
!pip install galaxy2galaxy
import tensorflow as tf
!mkdir hsc_anomaly_small
!mkdir hsc_tmp
!g2g-datagen --problem=img2img_hsc_anomaly_small --data-dir=hsc_anomaly_small --tmp_dir=hsc_tmp

i'm getting this error on the last line:
ImportError: This version of TensorFlow Datasets requires TensorFlow version >= 2.1.0; Detected an installation of version 1.15.0. Please upgrade TensorFlow to proceed.

i tried the solution above of changing the tensorflow import to
import tensorflow.compat.v1 as tf
tf.disable_v2_behavior()

but i think this isn't the import causing the issue.
the notebook is here, feel free to play around: https://colab.research.google.com/drive/1hzaa5_ROrhXu-ZyTuDQ52-Kd-aaGhV0a?usp=sharing
thanks!!


python3Packages.mcstatus: 5.1.1 -> 5.1.2

Motivation for this change
Update to latest upstream release 5.1.2
Change log: https://github.com/Dinnerbone/mcstatus/releases/tag/release-5.1.2
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 118178 at e4c12e82 run on aarch64-linux 1

2 packages built successfully:

python38Packages.mcstatus
python39Packages.mcstatus

Result of nixpkgs-review pr 118178 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.mcstatus
python39Packages.mcstatus


How do I view the heatmap?

Hello,
I've used the plugin for a while but I have no idea on how to view the HEATMAP. The files are saved as .heatmap - How do I open these?

I don't think this actually works.

When you press Open Heatmaps Folder button, there are Heatmap Files and Heatmap Images folders. The files stored in the Heatmap Images folder are actually PNG files, they just aren't saved with a file extension for some reason. If you rename those files to have .png at the end, you should be able to view them.

My issue is that there are no .png files, just heatmap files.

Hello all. I'm almost done being busy with university stuff and can finally get around to fixing the heatmap plugin issues. Well, actually it probably won't be until May 15th that I can start, but yee.
When I originally published the plugin, I forgot to add ".png" to the filename of the heatmap images, so on Windows they appear as some sort of unknown file but can be fixed by just adding ".png" to their name (I was developing it on linux where the images would still be recognized as images despite not having the extension)
Although: I'm still not sure what the extent of it is, but for many people the image creation part of the plugin doesn't work at all, in which case there will be a .heatmap file (which is basically a deflated 2D integer matrix), but nothing in the Heatmap Images folder. I'll be fixing this too in about 3 weeks

Thanks for the update! I look forward to using this plugin :)

Hello @gowerr @DekuOnyx @Fincap, I have a shadow JAR aka a preview of the World Heatmap update/fix which you can test out downloading it here and then running java -jar -ea worldheatmap.jar on it in a terminal. I would recommend making a backup of your ~/.runelite/worldheatmap folder (it's in your home directory) before testing it, just in case something were to go wrong and your original .heatmap files disappeared or something (don't remove it, just make a backup copy of it somewhere)
It would be super coolio if some of you could test it out and tell me if there are still any problems. Also there are some new features. One of em is a heatmap combiner tool that can be used to combine .heatmap files that were saved under different usernames, because originally I forgot to take into account that people's usernames can change. Now, the heatmap files go by unique player ID (and the image filenames properly end with ".png")

Hello @gowerr @DekuOnyx @Fincap, I have a shadow JAR aka a preview of the World Heatmap update/fix which you can test out downloading it here and then running java -jar -ea worldheatmap.jar on it in a terminal. I would recommend making a backup of your ~/.runelite/worldheatmap folder (it's in your home directory) before testing it, just in case something were to go wrong and your original .heatmap files disappeared or something (don't remove it, just make a backup copy of it somewhere)
It would be super coolio if some of you could test it out and tell me if there are still any problems. Also there are some new features. One of em is a heatmap combiner tool that can be used to combine .heatmap files that were saved under different usernames, because originally I forgot to take into account that people's usernames can change. Now, the heatmap files go by unique player ID (and the image filenames properly end with ".png")

Any idea why this fix hasnt made it to the main client yet?

@Nick2bad4u Ahhh... Well, I was about to add it a few days after leaving that comment, but then it turned out that there was a dependency issue, or something along those lines, and I ended up fixing it and implementing a complicated but successful memory optimization change, and added a yuge amount of updates (the plugin will now track heatmaps of thing such as kills, deaths, loot drops etc.), instead of just having a releasable update. I'll attach the changelog here so you can see some of what's been done. I'm trying to refrain from making any more additions so that I can just push the zamn update: changelog.txt
p.s. the plugin will also allow exporting the full world map including underground areas

Omg~~ Im so excited for that update now!

Did this ever make it into the game?

Did this ever make it into the game?

After all these millennia the update is pending review by RuneLite and will probs be live in 2 weeks or so 😎 you can see some pics on the new Readme


Fix resolution media query

According MDN page I add support data for old Opera and old Firefox.

@Fyrd Autoprefixer 5.1 will need this PR to clean this old prefixes.

@ai These Firefox versions support the standard min-resolution: dpi format, which trumps their support for the non-standard min--moz-device-pixel-ratio. Can you change those back in your PR? Thanks.

@Fyrd only Firefox >= 16 supports min-resolution: dpi so I left y there. As I understand Firefox < 16 supports only min-device-pixel-ratio so I add a x with note there.
I didn’t understand what versions I need to fix :(.

@ai In my tests Firefox 3.6+ support min-resolution: dpi. Do you have any test that indicates otherwise?

Very strange. MDN page says:

-moz-device-pixel-ratio may be used for compatibility with Firefox older than 16

https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries
As I understand it means, that < 16 didn't support min-resolution (also this is new spec, I think it doesn't even exits in 3.6).

Looking at https://developer.mozilla.org/en-US/docs/Web/CSS/resolution I'm seeing 3.5+. And, as mentioned, it's working in my tests. :)

Resolution page is a page of units, not the query. And units are exists in 3.5. Can I see a test, maybe there is some issue there? (Very strange that FF 3.5 supports min-resolution even without a prefix, because there is no spec in that time).

http://tests.caniuse.com/?feat=css-media-resolution - The second test should be lime if @media (min-resolution: 1dpi)  matches, which according to BrowserStack screenshots works in Firefox 3.6:
http://www.browserstack.com/screenshots/f6508589b83765e44029978f00a0cf73f6d61523 (and I've confirmed it stays red in a browser without support)

(sorry, didn't mean to close)

Awesome tests! :) What means yellow and green support? Can I look at tests source code?

If you're seeing yellow under the browser column, that just means the current support for that browser is set to "partial". Currently for the source code just...view source. ;) At some point I plan on putting all the data on GitHub too so it's easier to see.

Yeap, seems like you are right. Firefox really supports min-resolution since 3.5 O_o

@Fyrd done, I update Firefox data.

Thanks!


Pipelines, Automated Releases, etc.

Done.  Released v1.0.0 via pipeline.
https://github.com/cloudfoundry-community/tmate-boshrelease/releases/tag/v1.0.0


add uptime plugin

Hello, I add uptime plugin, but I didn't get how I can test it?

@ispite
PRs like this one are for adding code. If you want to ask a question put it in an existing or new issue, or ideally just message us on discord.
To test your plugin, you can either use test_plugin_script.py to see how the plugin handles a single command. You can choose which message you want to be sent to your plugin.
However, for this case, I presume that the best way to test it is just to run the bot by executing main.py, and connect to the IRC server and see what happens. To run your plugin, make sure you add it to the plugins config file. If you are having difficulties connecting to the IRC server or running your plugin let me know. I had both of those issues just two weeks ago and now I feel confident with honeybot so don't worry.


Create devcontainer.json

Hi,
thank you for your contribution!
Can you explain the benefits you expect from adding a devcontainer.json?
Indeed the "standard" dev environment is to use android studio. It comes with everything bundled so there is no specific setup, apart from installing android studio...
Regards


Github actions badge not working on private repo

Are you experiencing an issue with...
My own instance of shields
🐞 Description
I have a private repo on github.
Also i have my own hosted shields server:
https://githubshieldsio.herokuapp.com
This is all set with a PAT token so it should read all the info from the repo.
Now the badge of the workflow can't find the repo.
When i set the repo to public, then the badge does work!
🔗 Link to the badge
Example of a badge reading the same repo (but does work)
https://githubshieldsio.herokuapp.com/github/package-json/v/danielgroen/affiliate-program
The badge that doesn't work.
https://githubshieldsio.herokuapp.com/github/workflow/status/danielgroen/affiliate-program/prod
💡 Possible Solution
No response

See https://github.com/badges/shields/discussions/5676.

Unlike most of our github badges which call an API endpoint, this one is basically a scraper or wrapper for github's own badge that allows you to apply the shields styles/icons/etc to it.
You will find that if you call https://github.com/danielgroen/affiliate-program/workflows/prod/badge.svg when you're logged in to github, it works. If you call it when you're not logged in, its a 404. With all our other badges that use the GitHub API, providing a token allows us access to private resources. This badge is an outlier in this respect. If it is possible to use a token in the request (I've not checked), we'd happily take a PR for this but at the moment this specific badge won't work for private repos.

Going to close this as a duplicate of #4681 in favor of keeping things consolidated under #4587


generate collection permalink

PR to generate different permalinks by locales

Thanks! Have a nice holidays!

Thanks! When will you merge develop brach to master?

30m ;)
On Thu, 28 Jul 2022, 19:54 Michał Krajewski, @.***>
wrote:

Thanks! When will you merge develop brach to master?
—
Reply to this email directly, view it on GitHub
https://github.com/bluszcz/jekyll-strapi-4/pull/22#issuecomment-1198457354,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABWF55MRNUAFHY22N2UE73VWLCL3ANCNFSM54TOQ57Q
.
You are receiving this because you modified the open/close state.Message
ID: @.***>


Why Bruno has a dog as icon?

Hi,
my team today really wondered why Bruno chose a dog as icon. We came to the idea, that maybe you chose it because dogs attack postmans. That idea was mindblowing. Was that already in your mind?
Cheers

I bet it's also really good at fetch():ing.

haha，this is really an interesting explain.   : )

The name Bruno and the icon come from "Bruno". Source: https://youtu.be/7bSMFpbcPiY?si=B7h0XqR6kizyFqfn&t=870

Another tool is also the dog icon, Apidog， Is the icon a bone?

Consider also that Bruno is not afraid of Postman. He happily goes in space....

Name is good, but could change the icon to a little abstract. Feels out of place and not professional.


Hello, is this warehouse still maintained? Is there time to upgrade Expo to 40?

@conr2d

@cppfuns I am sorry, but this is a prototype of our first wallet project and no more maintained. I'm not a maintainer of this, but just updated the license by the request from the other.

@cppfuns I am sorry, but this is a prototype of our first wallet project and no more maintained. I'm not a maintainer of this, but just updated the license by the request from the other.

@cppfuns很抱歉，但这是我们第一个钱包项目的原型，不再维护。我不是这个的维护者，而是根据另一个的请求更新了许可证。

Thank you for your reply. I am trying to upgrade. Since I contacted RN for the first time, I still insist on fixing the problem

@cppfuns很抱歉，但这是我们第一个钱包项目的原型，不再维护。我不是这个的维护者，而是根据另一个的请求更新了许可证。

Thank you for your reply. I am trying to upgrade. Since I contacted RN for the first time, I still insist on fixing the problem


feat: publish example on expo

Feature Request
Great package!
I'm starting to play with it, reading the docs, etc. I think the "dev user experience" could be improved by providing a link to expo to quickly see how it's going.

Thanks for opening up this issue!
By a link to expo, do you mean an Expo Snack of the example application? If so, I think that since the example application is ejected, it may not be feasible (from what I remember, only Expo Go applications worked in Expo Snacks).

Ah OK, that's unfortunate. Expo Snack is quite good to play around.

https://snack.expo.dev/@bachelier/react-native-header-example?platform=android

Oh, I guess I was wrong! Thanks for creating this - I will add a Snack now. :)

Thanks for the suggestion @MBach! This has been merged and released as a new version (0.12.2). You should be able to see the new QR code and link on npm.


☂ SolidJS eslint plugin rules

Description
no-react-specific-props
https://github.com/solidjs-community/eslint-plugin-solid/blob/main/docs/no-react-specific-props.md
Disallow React prop compatibility which was deprecated in Solid 1.4.0.
Implemented in https://github.com/biomejs/biome/pull/2427
components-return-once
https://github.com/solidjs-community/eslint-plugin-solid/blob/main/docs/components-return-once.md
Solid components only run once, and so conditionals should be inside JSX.
WIP https://github.com/biomejs/biome/pull/2439
prefer-show
https://github.com/solidjs-community/eslint-plugin-solid/blob/main/docs/prefer-show.md
Enforce using Solid's  component for conditionally showing content. Solid's compiler covers this case, so it's a stylistic rule only.
prefer-for
https://github.com/solidjs-community/eslint-plugin-solid/blob/main/docs/prefer-for.md
Enforce using Solid's  component for mapping an array to JSX elements. This rule is an error by default.
no-destructure
https://github.com/solidjs-community/eslint-plugin-solid/blob/main/docs/no-destructure.md
Disallow destructuring props. In Solid, props must be used with property accesses (props.foo) to preserve reactivity.
no-react-deps
https://github.com/solidjs-community/eslint-plugin-solid/blob/main/docs/no-react-deps.md
Disallow usage of dependency arrays in createEffect and createMemo.
style-prop
https://github.com/solidjs-community/eslint-plugin-solid/blob/main/docs/style-prop.md
Require CSS properties in the style prop to be valid and kebab-cased (ex. 'font-size'), not camel-cased (ex. 'fontSize') like in React, and that property values with dimensions are strings, not numbers with implicit 'px' units.

I'll take a jab at style-prop!
Does Biome already have a list of all known css rules?
eslint-plugin-solid imports a package with the list for fixing camel to kebab on known rules and erroring on unknown rules.

Good luck 🫡 feel free to drop an issue to the ESLint plugin if you have any questions


code_writers: make all buffer_format inline

This avoids duplicate symbol definition when linking with clang.

Looks reasonable, thanks!


Review computation of the Jacobians in the centroidal-momentum cost

Which quantity do you want to compute here?
_Originally posted by @jcarpent in https://github.com/loco-3d/crocoddyl/pull/644#discussion_r354490593

Can we please use more specific issue titles? :-)

I'll answer here instead of https://github.com/loco-3d/crocoddyl/pull/644#discussion_r354490593.
We are computing the derivatives of the residue (hg-href). The computation of hg in pinocchio is done in the com frame of reference. The computation of the derivatives is then also done in the same frame.
When you want to compute the derivative, you are trying to do lim (dq->0) (hg(q) - hg(q+dq))/dq. Since hg is computed in the CoM frame of reference, there are two changes that need to be accounted for in hg(q+dq).

First is because of the change in hg because of the change in configuration (q+dq). This is done in pinocchio.

Second is the change in hg because of the change in CoM frame of reference because of the change in configuration (q+dq). This is what we are doing here.

This was validated in the unittests by finite differencing, which I is here: https://github.com/loco-3d/crocoddyl/blob/master/unittest/test_costs.py#L80

@proyan I think you're making some confusions here:

dAg/dq expressed the variations of the centroidal momentum due to the change in the configuration (taking into account the change of the center of mass positions of all the bodies).
This is true in any with respect to any Plücker coordinate systems.
the second term you're computing is with respect to the motion of Plücker coordinate systems.

In other words, the Jacobian you're computing cannot be moved thanks to SE3.act for instance. And the term you have added can be removed if all the quantities you expressed are done in the same coordinate systems, e.g, the frame aligned with the world and centered on the CoM ;)

@proyan To conclude the previous discussion, you don't have to translate the reference frame by a small amount. It is like spatial vs classic acceleration ;)

@jcarpent
I don't think #650 is related here. I'm not sure why that error is happening, but it is not because of this topic.
I know that we are taking care of the moving reference frame when doing derivatives. However, what we actually need to get is the descent direction, and this includes the movement of the reference frame as well. This, as you mentioned, is the difference between the spatial and the classical accelerations as you put it, or th Ring and Dot derivatives as Featherstone puts it.
I've added a simple python script to demonstrate what the confusion is.
import pinocchio
from pinocchio.utils import rand, zero
import numpy as np
EPS = 1e-8

urdf_filename = "<YOUR URDF FILE PATH HERE>.urdf"

# Load the urdf model
rmodel    = pinocchio.buildModelFromUrdf(urdf_filename)

# Create data required by the algorithms
rdata     = rmodel.createData()

q0 = pinocchio.randomConfiguration(rmodel)
v0 = rand(rmodel.nv)
a0 = rand(rmodel.nv)

def df_dq(model, func, q, h=EPS):

    dq = zero(model.nv)
    f0 = func(q)
    res = zero([len(f0), model.nv])
    for iq in range(model.nv):
        dq[iq] = h
        res[:, iq] = (func(pinocchio.integrate(model, q, dq)) - f0) / h
        dq[iq] = 0
    return res

def fn(q):
    pinocchio.computeCentroidalMomentum(rmodel, rdata, q, v0)
    return rdata.hg.vector

#FINITE DIFFERENCING:

dhg_dq = df_dq(rmodel, fn, q0)

#FROM PINOCCHIO:

dhg_dq_pin, _, _, _ = pinocchio.computeCentroidalDynamicsDerivatives(rmodel, rdata,
                                                                     q0, v0, a0)

#After accounting for the moving coordinate system:

pinocchio.computeCentroidalMomentum(rmodel, rdata, q0, v0)
pinocchio.ccrba(rmodel, rdata, q0, v0)
pinocchio.jacobianCenterOfMass(rmodel, rdata, q0)
pinocchio.computeRNEADerivatives(rmodel, rdata, q0, v0, a0)
dhg_dq_act = dhg_dq_pin.copy()

for i, Ji in enumerate(rdata.Jcom.T):
    dhg_dq_act[3:, i] -= np.matrix(np.cross(np.array(Ji).squeeze(),
                                            np.array(rdata.hg.linear).squeeze())).T

print "The ring notation norm", np.linalg.norm(dhg_dq_act-dhg_dq)
print "The dot notation norm", np.linalg.norm(dhg_dq_pin-dhg_dq)

Here, what we get from pinocchio is the dhg_dq_pin, which is similar to Equation 2.39 of Featherstone. It is the derivative in the CoM frame. What we want to do is to take into account the movement of the CoM frame as well, which means we are not interested by Equation 2.39, but Equation 2.40

@jcarpent
I don't think #650 is related here. I'm not sure why that error is happening, but it is not because of this topic.
I know that we are taking care of the moving reference frame when doing derivatives. However, what we actually need to get is the descent direction, and this includes the movement of the reference frame as well. This, as you mentioned, is the difference between the spatial and the classical accelerations as you put it, or th Ring and Dot derivatives as Featherstone puts it.
I've added a simple python script to demonstrate what the confusion is.
import pinocchio
from pinocchio.utils import rand, zero
import numpy as np
EPS = 1e-8

urdf_filename = "<YOUR URDF FILE PATH HERE>.urdf"

# Load the urdf model
rmodel    = pinocchio.buildModelFromUrdf(urdf_filename)

# Create data required by the algorithms
rdata     = rmodel.createData()

q0 = pinocchio.randomConfiguration(rmodel)
v0 = rand(rmodel.nv)
a0 = rand(rmodel.nv)

def df_dq(model, func, q, h=EPS):

    dq = zero(model.nv)
    f0 = func(q)
    res = zero([len(f0), model.nv])
    for iq in range(model.nv):
        dq[iq] = h
        res[:, iq] = (func(pinocchio.integrate(model, q, dq)) - f0) / h
        dq[iq] = 0
    return res

def fn(q):
    pinocchio.computeCentroidalMomentum(rmodel, rdata, q, v0)
    return rdata.hg.vector

#FINITE DIFFERENCING:

dhg_dq = df_dq(rmodel, fn, q0)

#FROM PINOCCHIO:

dhg_dq_pin, _, _, _ = pinocchio.computeCentroidalDynamicsDerivatives(rmodel, rdata,
                                                                     q0, v0, a0)

#After accounting for the moving coordinate system:

pinocchio.computeCentroidalMomentum(rmodel, rdata, q0, v0)
pinocchio.ccrba(rmodel, rdata, q0, v0)
pinocchio.jacobianCenterOfMass(rmodel, rdata, q0)
pinocchio.computeRNEADerivatives(rmodel, rdata, q0, v0, a0)
dhg_dq_act = dhg_dq_pin.copy()

for i, Ji in enumerate(rdata.Jcom.T):
    dhg_dq_act[3:, i] -= np.matrix(np.cross(np.array(Ji).squeeze(),
                                            np.array(rdata.hg.linear).squeeze())).T

print "The ring notation norm", np.linalg.norm(dhg_dq_act-dhg_dq)
print "The dot notation norm", np.linalg.norm(dhg_dq_pin-dhg_dq)

Here, what we get from pinocchio is the dhg_dq_pin, which is similar to Equation 2.39 of Featherstone. It is the derivative in the CoM frame. What we want to do is to take into account the movement of the CoM frame as well, which means we are not interested by Equation 2.39, but Equation 2.40

There is no error, this unittest is passing

You have an error here:
res[:, iq] = (func(pinocchio.integrate(model, q, dq)) - f0) / h

When you do finite differences over Lie groups, you have to be sure that you're expressing all the terms in the same frame. Here, f0 and func(pinocchio.integrate(model, q, dq)) are not expressed at the same point, explaining the difference above.
What it is not clear to me is: do you really need to translate your Jacobians inside the DDP itself? I'm not sure of that.

I agree, but in DDP what we are eventually trying to find lies in different frames, since the CoM frame also evolves. Definitely it would be easier if all references were in the global frame, but that would introduce additional computations.
I don't really see an alternative to doing this here. Eventually we need to have our own compute-all-terms, and then perhaps we can simplify the translations. Untill then we need to adapt with Pinocchio's outputs.
On December 10, 2019 6:46:37 PM GMT+05:30, Justin Carpentier<EMAIL_ADDRESS>wrote:

You have an error here:
res[:, iq] = (func(pinocchio.integrate(model, q, dq)) - f0) / h

When you do finite differences over Lie groups, you have to be sure
that you're expressing all the terms in the same frame. Here, f0 and
func(pinocchio.integrate(model, q, dq)) are not expressed at the same
point, explaining the difference above.
What it is not clear to me is: do you really need to translate your
Jacobians inside the DDP itself? I'm not sure of that.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/loco-3d/crocoddyl/issues/648#issuecomment-564027338

No, you can expresse all the quantities at the origin. You just need to translate them ;)

So I would translate hg and href to origin. Then I would translate the dhg to origin. And then I would translate everything back to local frame to communicate with centroidal solver?
On December 10, 2019 10:42:01 PM GMT+05:30, Justin Carpentier<EMAIL_ADDRESS>wrote:

No, you can expresse all the quantities at the origin. You just need to
translate them ;)
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/loco-3d/crocoddyl/issues/648#issuecomment-564135564

Yep. It should be something like that. You can be even more efficient. We can discuss that by Skype if you want.

Is there a reason of why the centroidal solver expressed the href in the local frame?
For me, it makes sense to have everything expressed at the origin.

Yes, and not. We are following the original notations of Orin et al. to express the centroidal wrench around the CoM (which is invariant by translation).
But, we may think to have the choice of expressing at another reference frame of course. We can add an optional argument to these functions to express at the origin too.

@cmastalli I think in fact your question was asked to @proyan.
My answer makes no sense then. I will remove it.

Yes, it makes sense. I think an argument, if you are receptive, of adding a ReferenceFrame.World/Local might be useful here.
I'll do the changes next week.
On December 10, 2019 11:50:25 PM GMT+05:30, Justin Carpentier<EMAIL_ADDRESS>wrote:

Yes, and not. We are following the original notations of Orin et al. to
express the centroidal wrench around the CoM (which is invariant by
translation).
But, we may think to have the choice of expressing at another reference
frame of course. We can add an optional argument to these functions to
express at the origin too.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/loco-3d/crocoddyl/issues/648#issuecomment-564165236

It will be much more something like WORLD/LOCAL_WORLD_ALIGNED ;)

@proyan I have merged the cost unittest, and effectively the centroidal-momentum is not passing.
Do you have time to solve this issue?

No, you can express all the quantities at the origin. You just need to translate them ;)

@jcarpent let me understand this statement. We need to transform the coordinate vector that expresses the spatial momentum in frame coordinates to a Cartesian vector, is that correct?
If so, then my understanding is that the force conversion to Cartesian vector is as follows
import pinocchio
...
c = frame_id
c_m = pinocchio.Force.Random() # spatial force defined in the frame coordinate c
oMff = pinocchio.SE3(data.oMf[frame_id].rotation, np.zeros(3))

o_m_wf = oMff.act(c_m)
print("linear momenta", o_m_wf.linear)
print("angular momenta", o_m_wf.angular)

right?
But I don't know how to convert the momenta derivatives

Same strategy.

@jcarpent  I have another general question for you.
I don't understand the motivation behind tracking a spatial vector in frame coordinates. Instead I would expect to build a cost function that tracks a Cartesian vector because the users can easily define a reference in the Cartesian space. Is there something that I missed here?
I asked myself the same question for the force tracking cost in ongoing PR #788.

It really depends on your application. From the local Frame, it might be a sensor based tracking.

It really depends on your application. From the local Frame, it might be a sensor based tracking.

Then, should we define an API cost that accepts all options?, e.g. for the centroidal momenta cost will be like:

spatial momenta expresses in local coordinates (body coordinates)
spatial momenta expresses in frame coordinates (CoM frame coordinates)
Cartesian momenta expresses in the world frame

Or should we write independent cost functions?


bug: cairo test case test_ecdsa_recover_public_key fails

Bug Report
test case test_ecdsa_recover_public_key failed.
Cairo version:
main branch
Current behavior:

Expected behavior:

Steps to reproduce:

Related code:

#[test]
fn test_ecdsa_recover_public_key() {
    let message_hash = 0x503f4bea29baee10b22a7f10bdc82dda071c977c1f25b8f3973d34e6b03b2c;
    let signature_r = 0xbe96d72eb4f94078192c2e84d5230cde2a70f4b45c8797e2c907acff5060bb;
    let signature_s = 0x677ae6bba6daf00d2631fab14c8acf24be6579f9d9e98f67aa7f2770e57a1f5;
    assert_eq(
        @ecdsa::recover_public_key(:message_hash, :signature_r, :signature_s, y_parity: false)
            .unwrap(),
        @0x7b7454acbe7845da996377f85eb0892044d75ae95d04d3325a391951f35d2ec,
        'recover_ecdsa_public_key failed'
    );
    assert(
        ecdsa::check_ecdsa_signature(
            :message_hash,
            public_key: ecdsa::recover_public_key(
                :message_hash, :signature_r, :signature_s, y_parity: true
            )
                .unwrap(),
            :signature_r,
            :signature_s
        ),
        'ecdsa returned false'
    );
}

Other information:

I think it failed because signature_r should in the valid range [1, n-1], but it's not.
signature_r : 0xbe96d72eb4f94078192c2e84d5230cde2a70f4b45c8797e2c907acff5060bb
n: 0x800000000000010ffffffffffffffffb781126dcae7b2321e66a241adc64d2f
I am new to this. Free to correct me if I am wrong.
@orizi Please help me to review.

I don't understand the issue - all i see is that you copied a test from the corelib which passes on our CI all the time.

assuming you checked the values out of Cairo context - you probably used the wrong y_parity value.
Closing for now - feel free to reopen with more elaboration if the issue remains.


Fixes for the structure missalignments

Just a few quick fixes for your awesome decompiler. I've noticed the field offsets on the metadata files didn't match with il2cpp dumper's output and looking further into it with Ghidra and the other files revealed a few issues.
Looks like types with generic parameters are not located so I made a hack around it since I'm not familiar with the code (you should definitely change that) and the structs are not pieced together as they should, as I explained in the comment.
Very cool project, keep at it!

Hey this is super cool of you, thanks! Looks like it should work, so I'll merge this now :+1:


delete redundant issue tests

/run-all-tests

/run-all-tests

seems that we could add back some tests concerning blob and text

Are blob and text test cases run normally?

@Novemser They should be fixed by......NOW！

/run-all-tests

/run-all-tests


GitHub Actions: Test on current versions of Node.js

Do we really need npm install -g node-gyp?

I merged these but the tests still look broken

The tests are broken on modern versions of Node.js. because this code needs real maintenance...

https://github.com/nodejs/node-gyp/issues?q=ffi-napi
https://github.com/node-ffi-napi/node-ffi-napi/issues
node-ffi-napi/node-ffi-nap#247
node-ffi-napi/node-ffi-napi#255
node-ffi-napi/node-ffi-napi#253
node-ffi-napi/node-ffi-nap#257

also dependencies are ancient. Someone has to fork node-gyp as well, it is not mantained as far as I can see

@Kreijstal Please look at node-ffi-napi/node-ffi-napi#247 as mentioned above for alternatives.