Fields "operation_Id" and "operation_ParentId" not being logged when using TrackException

List of NuGet packages:

microsoft.applicationinsights.workerservice 2.20.0
microsoft.extensions.hosting 6.0.1

Runtime version: net5
Hosting environment: Windows console

Describe the bug
Behavior:
Calling TrackException(ExceptionTelemetry telemetry) does not record operation_Id or operation_ParentId, despite the fact that the ExceptionTelemetry.Context.Operation.Id has been set.

For trace (as opposed to exception) telemetry, calling TrackTrace(TraceTelemetry telemetry) does record these two values.
Expected:
Exceptions should behave the same way as traces in this case, so that we can correlate them.
To Reproduce
The console app below runs a few threads which each logging both a track and an exception, setting the operation ID. Entries generated in the exceptions table are missing the data.
Note that you need to sub your AI instrumentation key.
AppInsightsBadOpIdRepro.zip

It looks like this is also the case for TrackEvent.

I'm getting the same issue using .NET 6 with an App Service.
Using Microsoft.Extensions.Logging's ILogger I can create traces with the ParentId and OperationId populated, but if I use TrackTrace or TrackException these values are non-existent.


[Better Discord isn't recognized with newest Canary]

Describe the Bug
After the latest Discord Canary update BD doesn't install successfully.
It appears to install correctly but Discord is unchanged.
Attempting to Repair the installation fails.
To Reproduce

Download latest AppImage from betterdiscord.app
chmod a+x the AppImage
Launch the AppImage
Installation Succeeds
Launch Discord Canary
Quit Discord Canary
Launch AppImage and select Repair
Repair Fails

Expected Behavior

Download Latest AppImage from betterdiscord.app
chmod a+x the AppImage
Launch the AppImage
Installation Succeeds
Launch Discord Canary
Add Plugins and Themes

Screenshots
This is the output from the attempted repair:

Starting Repair...
Creating required directories...
✅ Directory exists: /home/kevin/.config/BetterDiscord
✅ Directory exists: /home/kevin/.config/BetterDiscord/data
✅ Directory exists: /home/kevin/.config/BetterDiscord/themes
✅ Directory exists: /home/kevin/.config/BetterDiscord/plugins
✅ Directories created
Downloading asar file
✅ Package downloaded
Injecting shims...
Injecting into: /home/kevin/.config/discordcanary/0.0.131/modules/discord_desktop_core
❌ Could not inject shims to /home/kevin/.config/discordcanary/0.0.131/modules/discord_desktop_core
❌ ENOENT: no such file or directory, open '/home/kevin/.config/discordcanary/0.0.131/modules/discord_desktop_core/index.js'
The repair seems to have failed. If this problem is recurring, join our discord community for support.

Discord Version
Canary 103747 (a51374a) Linux 64-Bit
The system also describes it as version 0.0.131
Additional Context
My system information:
Manjaro Linux 21.1.6
Display: Wayland
Desktop: Sway

Feel free to close this issue.
I gave up and purged my system of BetterDiscord and Discord.
Then I installed the latest official stable version of Discord for Arch.
I was able to use the AppImage to successfully install BD.


Update magnolia to 0.12.1

Updates com.propensive:magnolia from 0.12.0 to 0.12.1.
Release Notes/Changelog
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.propensive", artifactId = "magnolia" } ]

labels: semver-patch

 Here is an overview of what got changed by this pull request:

Coverage increased per file
===========================
+ src/main/scala/org/scalacheck/magnolia/package.scala  100

See the complete overview on Codacy


Update cri to v1.11.0.

Update cri to v1.11.0. Release note: https://github.com/containerd/cri/releases/tag/v1.11.0
Signed-off-by: Lantao Liu<EMAIL_ADDRESS>

geez, 23k lines @Random-Liu ;)

@crosbymichael Kubernetes api update is usually super huge... A lot of auto generated files... The actual code change in cri is not that big.

@Random-Liu ya, i'm just joking

Codecov Report

Merging #2430 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #2430   +/-   ##
======================================
  Coverage      45%     45%
======================================
  Files          92      92
  Lines        9412    9412
======================================
  Hits         4236    4236
  Misses       4493    4493
  Partials      683     683

Flag
Coverage Δ

#linux
49.23% <ø> (ø)
:arrow_up:

#windows
41.3% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

LGTM


build: remove unused kokoro configs

Trying to see what I can get away with deleting.  This could be a bad idea.

Note we're using continuous for build cop, I'd ideally like to keep test.sh.

👋 what if we create a tracking ticket in google-cloud-node and do this more systemically? In this particular case it looks like we failed to delete the Windows config in Google 3, which is part of the problem.


libstk generates huge static lib

Describe the bug
I noticed when linking libstk to my application that it seems to fail due to Runtime library mismatch (MD vs MT). Anyway, when I was investigating the VCPKG folder, I saw that the libstk.lib is much bigger than than any other lib in that directory (~45megs). This library shouldn't be as large as this surely? Is there some kind of packaging/build issue?
Environment

OS: Windows 10
Compiler: VS2019

To Reproduce
Steps to reproduce the behavior:

./vcpkg install libstk:x64-windows-static
Check output directory for binaries.

Expected behavior
The library is small and the binary shouldn't be as big as it is.

In fact, libstk's CMakeLists.txt is written by a contributor, and its official build is to use makefile. In CMakeLists.txt we build all the source files into a library, we don't know if this is reasonable.

It seems after linking with the STK static lib, the resulting binary isn't as inflated as expected and a lot of the contents must be discarded. The static STK lib in my case (in release) is 27 megs but the resulting binary is only 270kb. Can probably just ignore this issue I'd say. Thanks


PUT /v3/conversations/${conversationId}/activities/${activityId} return 403 ServiceError Unknown

We receive odd responses from time to time when updating messages in MS Teams:
Request:

Path: /v3/conversations/${conversationId}/activities/${activityId}
Method: Put
Headers:

Authorization: Bearer xxx
Content-Type: application/json; charset=utf-8

Body:

{
    "type": "message",
    "attachments": [
        {
            "contentType": "application/vnd.microsoft.card.adaptive",
            "content": {
                "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
                "type": "AdaptiveCard",
                "version": "1.0",
                "msteams": {
                    "entities": []
                },
                "body": [
                    {
                        "type": "Container",
                        "items": [
                            {
                                "type": "Container",
                                "items": [
                                    {
                                        "type": "TextBlock",
                                        "text": "...",
                                        "wrap": true
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "type": "Container",
                        "items": [
                            {
                                "type": "Container",
                                "items": [
                                    {
                                        "type": "TextBlock",
                                        "text": "...",
                                        "wrap": true,
                                        "weight": "Bolder",
                                        "size": "Medium"
                                    },
                                    {
                                        "type": "TextBlock",
                                        "text": "...",
                                        "wrap": true
                                    }
                                ],
                                "style": "warning",
                                "bleed": true
                            },
                            {
                                "type": "ActionSet",
                                "actions": [
                                    {
                                        "type": "Action.OpenUrl",
                                        "url": "...",
                                        "title": "Schedule onboarding call"
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "type": "Container",
                        "items": [
                            {
                                "type": "Container",
                                "items": [
                                    {
                                        "type": "TextBlock",
                                        "text": "...",
                                        "wrap": true,
                                        "weight": "Bolder",
                                        "size": "Medium"
                                    },
                                    {
                                        "type": "TextBlock",
                                        "text": "...",
                                        "wrap": true
                                    }
                                ],
                                "style": "good",
                                "bleed": true
                            }
                        ]
                    },
                    {
                        "type": "Container",
                        "items": [
                            {
                                "type": "Container",
                                "items": [
                                    {
                                        "type": "TextBlock",
                                        "text": "...",
                                        "wrap": true,
                                        "weight": "Bolder",
                                        "size": "Medium"
                                    },
                                    {
                                        "type": "TextBlock",
                                        "text": "...",
                                        "wrap": true
                                    }
                                ],
                                "style": "warning",
                                "bleed": true
                            }
                        ]
                    },
                    {
                        "type": "Container",
                        "items": [
                            {
                                "type": "Container",
                                "items": [
                                    {
                                        "type": "TextBlock",
                                        "text": "...",
                                        "wrap": true,
                                        "weight": "Bolder",
                                        "size": "Medium"
                                    }
                                ],
                                "style": "accent",
                                "bleed": true
                            }
                        ]
                    },
                    {
                        "type": "Container",
                        "items": [
                            {
                                "type": "Container",
                                "items": [
                                    {
                                        "type": "TextBlock",
                                        "text": "...",
                                        "wrap": true,
                                        "weight": "Bolder",
                                        "size": "Medium"
                                    }
                                ],
                                "style": "accent",
                                "bleed": true
                            }
                        ]
                    },
                    {
                        "type": "Container",
                        "items": [
                            {
                                "type": "Container",
                                "items": [
                                    {
                                        "type": "TextBlock",
                                        "text": "...",
                                        "wrap": true,
                                        "weight": "Bolder",
                                        "size": "Medium"
                                    }
                                ],
                                "style": "accent",
                                "bleed": true
                            }
                        ]
                    },
                    {
                        "type": "Container",
                        "items": [
                            {
                                "type": "Container",
                                "items": [
                                    {
                                        "type": "TextBlock",
                                        "text": "6. Next steps",
                                        "wrap": true,
                                        "weight": "Bolder",
                                        "size": "Medium"
                                    }
                                ],
                                "style": "accent",
                                "bleed": true
                            }
                        ]
                    }
                ]
            }
        }
    ]
}

Response:
{
    "error": {
        "code": "ServiceError",
        "message": "Unknown"
    }
}

I have the same error message as you but with a response code 400 with the following request:
Request:

Path: /v3/conversations/<conversation_id>/activities
Content-Type: application/json
Authorization: Bearer
Body:

{
    "type": "message",
    "from": {
        "id": <App ID>,
        "name": "<Bot Name>"
    },
    "conversation": {
        "id": <Conversation ID>,
        "name": ""
    },
    "recipient": {
        "id": "29:<Recipient ID>",
        "name": "<Recipient Name>"
    },
    "text": <Text Message>
}

Thank you for the report, @michaelwittig. It looks like you're trying to use an Adaptive Card in Slack. Is that correct? Slack doesn't support Adaptive Cards, so your card would be converted to an image that looks like this:

If that's what you're intending, then I have a few questions:

Does the problem occur with messages that don't include any Adaptive Cards?
Does the problem occur when sending a message rather than updating one?
Have you considered using the Slack adapter?
Have you considered using Block Kit?

@jimsam - I'm sorry but I don't think I have enough information to diagnose your issue. Perhaps I could investigate further if you provide repro steps.

@v-kydela A few minutes ago I managed to solve my issue by another closed issue that I found, the problem was that the URL that documentation has to make a new activity is a POST at https://smba.trafficmanager.net/apis/v3/conversations/ but actually is  https://smba.trafficmanager.net/amer/v3/conversations/
I really didn't found anywhere what other variation might exists (apis, amer ...) but I am good for now thanks.

Hi @v-kydela
Sorry. We use the request to update a message in Teams, not Slack.

@jimsam - You had been using a service URL for Skype. Teams uses region-specific service URL's. Can you tell us what documentation you're talking about?
@michaelwittig - In case your issue is the same as Jim's can you let me know what your host URL is?

@v-kydela No, I use this for a bot that I build for Teams in order to get a new activity to a conversation with a specific user in Teams from another application, the reference for that has here

@jimsam - That doc says https://smba.trafficmanager.net/apis is only an example and does not say it is a service URL you should use for Teams. The doc says:

Use the serviceUrl property in the incoming activity to identify the base URI that your bot should use to issue its response.

If the doc is still confusing and is leading customers to use https://smba.trafficmanager.net/apis as their service URL then is there some way it could be more clear?

@v-kydela I think that I was confused at that point because I didn't read the whole documentation most likely because the /apis/ was making a lot of sense and never got to a point to question the actual URI when I got the error.
But as you point out there is a part of the documentation that describes where to find the correct URI, you just need to read all of it and not partially as I did.

@jimsam not sure why you hijack that issue  for an error report that is not the same. as you mentioned, your response code is different. So please go and open your own issue.
@v-kydela no, I don't run into the sam issue as @jimsam and I don't appreciate that he discusses a very different problem here. We use endpoints such as https://smba.trafficmanager.net/amer/, https://smba.trafficmanager.net/emea/, ... depending on the tenant. I would appreciate if we could talk about my original error report. Receiving those generic ServiceError Unknown is not helpful and should be fixed. This is also not my first request I send to your APIs. We make a bunch of calls and most of them work. But for the one I shared with you we sometimes receive the generic Unknown error. We had the same issue before with other endpoints and it ended with a fix on your side.

@michaelwittig - I'm sorry but I can't seem to reproduce the error so far, though it sounds like you're saying it's intermittent. Are you sending the request in Postman? Is the message in a personal, group, or channel chat?
In any case, it looks like Teams should implement more verbose error messages.

@v-kydela It's a channel message. A retry of the request does not fix the problem. For certain conversations/activities is always fails with the above error. Is it possible that error like: channel removed e.g. are not properly handled?

@michaelwittig - Thank you for the info. Whether the channel is deleted or the conversation ID is just made up, I get a descriptive error message when trying to update an activity:
{
    "error": {
        "code": "ConversationNotFound",
        "message": "Conversation not found."
    }
}

I tried updating an activity in a channel thread using a fake ID, and I got a descriptive error message again:
{
    "error": {
        "code": "ActivityNotFoundInConversation",
        "message": "Message does not exist in the thread."
    }
}

However, I do get the unknown error when I try updating an activity in a channel thread using an activity ID that existed at one point but has since been deleted. Is it possible that this is the cause of the errors you're seeing? Also, is the purpose of your report to say that your attempts to update activities are failing when they shouldn't, or are you saying you expect to see an error message but you'd just like the error message to be more descriptive? I will escalate this in either case because the unknown errors are clearly a problem either way, but I need to know if there's also a problem with Update Activity not working when it should.

@v-kydela It's possible but I don't know. We see this Unknown Error in the wild not on my tenant, but tenants I have no control over. Therefore, I have no idea what those tenants are doing. All I see is an error message that is of ne help to figure out what's going on. And you are asking me to reverse engineer that :) Sorry, I guess it's easier to just look at the code and ensure that no one ever throws an "Unknown" error. .

@michaelwittig - All right, well for now I guess we should treat this as an issue with the error message. I will unassign myself so the appropriate people can have a look at it.

@michaelwittig, can you share your bot id, conversation id (partial would be OK) and timestamps of the events where you got the error. I'll look it up on the Azure Bot Service end. Is this a recent problem, and if yes when did it start happening?
Going though this thread, I assume this is happening in Slack channel only and any reference to Teams/Skype is irrelevant.
Also, can you confirm the error code is 403? That would be unusual if the error only happens with a specific payload.

@arturl My issue is about updating messages in MS Teams, not Slack. Sorry for the confusion.

can you share your bot id, conversation id (partial would be OK) and timestamps of the events where you got the error.
bot id: 1dd5785b-d8b3-400d-8e1f-af7c939cd70f
conversation id: (not available anymore, we drop logs after 14 days)
activity id:<PHONE_NUMBER>547
time: ~Dec 3, 2020 05:17:22.948 PM

Is this a recent problem, and if yes when did it start happening?
No, it happens from time to time.

Also, can you confirm the error code is 403?
Yes, 403.

@michaelwittig , is this a prod bot? If you can provide us the tenant id as well i can check the logs for the bots?

@Trinetra-MSFT, yet, it is. Tenant id: f1123783-951a-416c-be65-baaf60761486

@Trinetra-MSFT any news on this issue?

@Trinetra-MSFT any news on this issue?

@NickEricson can you help me out here?

@NickEricson can you help me out here?

We’re going to update error code returned to the bot. Fix would be deployed to Production by 2nd of February.

We’re going to update error code returned to the bot. Fix would be deployed to Production by 2nd of February.

Thanks for the update @MichaelHaydenAtMicrosoft

Thanks for the update @MichaelHaydenAtMicrosoft

@MichaelHaydenAtMicrosoft I can confirm that I'm not seeing the error anymore in our logs.

Hi ALL,
I am also facing similar issue.


Use AR functionality of model viewer

I want to view a 3D model in AR using model-viewer. But, I do not want to show my 3D model or any poster on the browser using model viewer.
I will be customizing my 3D model on the browser using Babylon.js natively (as I had earlier started with this approach) and then I want to show the customized 3D model in AR. There will be just a button, and on clicking this button, a 3D model  should be visible in AR using model viewer. Is this possible?
And if yes, then how?

Interesting; that's not really a use case we had in mind, but it should be possible. You could simply make a small model-viewer element and then make a custom AR button that completely covers it. The 3D model would still load and render in the background, but it'll only render once if it's not being interacted with, and the shader compilation and such are all shared with the WebXR experience anyway.


After integrating Skywalking agent with Springcloud gateway 4, traceid cannot be printed

Search before asking

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

Apache SkyWalking Component
Java Agent (apache/skywalking-java)
What happened

日志不会从gateway开始生成，用的agent版本9.0.0，服务集成apm-toolkit-logback-1.x也是9.0.0
What you expected to happen
如何解决
How to reproduce
想要日志从网关开始查起
Anything else
No response
Are you willing to submit a pull request to fix on your own?

[X] Yes I am willing to submit a pull request on my own!

Code of Conduct

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

Gateway 4.x is not supported. No one supported a PR about this.

All supported things are listed here. https://skywalking.apache.org/docs/skywalking-java/v9.0.0/en/setup/service-agent/java-agent/supported-list/
And please use English next time. We would not follow Chinese issue on GitHub. Only Slack CN channel is recommended for Chinese.

Gateway 4.x is not supported. No one supported a PR about this.

when can skywalking-java-agent support gateway 4.x , do you have any plan?

不支持网关 4.x。没有人支持关于此事的公关。

skywalking-java-agent什么时候可以支持gateway 4.x，你们有什么计划吗？

https://bothsavage.github.io/article/240121-skywaking

询问前先搜索

[x] 我在问题中搜索过，没有发现类似的问题。

Apache SkyWalking 组件
Java 代理 (apache/skywalking-java)
发生了什么
 日志不会从网关生成开始，使用的代理版本9.0.0，服务集成apm-toolkit-logback-1.x也是9.0.0
您期望发生什么
如何解决
如何重现
想要的日志从网关开始查起
还要别的吗
没有反应
您愿意提交拉取请求来自行修复吗？

[x] 是的，我愿意自己提交拉取请求！

行为守则

[x] 我同意遵守该项目的行为准则

https://bothsavage.github.io/article/240121-skywaking


Allow setting DisableCompression in NewAutoTransport

Fixes #2006.
Go's http client helpfully adds an "Accept-Encoding: gzip" header if not
already present, and unzips the response if it did so. While this is
often the right thing to do, it is not the right thing to do if we're
reverse proxying since (a) it means we add a header to the request the
client didn't actually ask for (b) it means we end up uncompressing
things in the proxy, which e.g. for activator/QP is not what we want.
/kind enhancement

Changes

:gift: Add NewProxyAutoTransport which is an auto-transport with DisableCompression=true set on the underlying transports.

Release Note

Adds NewProxyAutoTransport(), this method returns a transport which automatically selects between HTTP and H2c, and which is suitable for use by reverse proxies. Specifically it sets DisableCompression=true on the underlying transports.

/assign @vagababov @markusthoemmes

My history as chrome developer taught me that most people out there don't set gzip and you can reap up to 20-30% bandwidth savings just doing that. Now, question is, would it stop gzipping if user asked to?

@vagababov no it won't, it does the right thing if the header was actually passed by the client (i.e keeps it uncompressed all the way along the chain) -- it only does the silently adding the header and uncompressing if the header isnt supplied:

// DisableCompression, if true, prevents the Transport from
// requesting compression with an "Accept-Encoding: gzip"
// request header when the Request contains no existing
// Accept-Encoding value. If the Transport requests gzip on
// its own and gets a gzipped response, it's transparently
// decoded in the Response.Body. However, if the user
// explicitly requested gzip it is not automatically
// uncompressed.

/lgtm


SearchBar does not align text vertically

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce

Add a SearchBar widget
Make its height 40 points, which is less than the default (via constraints: const BoxConstraints(minHeight: 40, maxHeight: 40))

Expected results
Nicely looking search field with everything centered vertically.
Screenshots from my actual application:
This is how it looks with the default height of 56, which is what I would expect:

Actual results

Note how the icon is positioned correctly. It's just the text.
Code sample
Code sample
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'SearchBar Bug',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: Scaffold(
        appBar: AppBar(
            flexibleSpace: const SearchBar(
          leading: Icon(Icons.search, size: 20),
          hintText: 'Search',
          constraints: BoxConstraints(minHeight: 40, maxHeight: 40),
        )),
      ),
    );
  }
}

Flutter Doctor output
Doctor output
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.10.0, on Microsoft Windows [Version 10.0.19045.2965], locale en-AT)
[✓] Windows Version (Installed version of Windows is version 10 or higher)
[✗] Android toolchain - develop for Android devices
    ✗ Unable to locate Android SDK.
      Install Android Studio from: https://developer.android.com/studio/index.html
      On first launch it will assist you in installing the Android SDK components.
      (or visit https://flutter.dev/docs/get-started/install/windows#android-setup for detailed instructions).
      If the Android SDK has been installed to a custom location, please use
      `flutter config --android-sdk` to update to that location.

[✓] Chrome - develop for the web
[✓] Visual Studio - develop for Windows (Visual Studio Community 2019 16.11.26)
[!] Android Studio (not installed)
[✓] VS Code (version 1.78.2)
[✓] Connected device (3 available)
[✓] Network resources

! Doctor found issues in 2 categories.

Hi @anlumo
Can you please share the complete sample code? It seems it's missing leading icon. Even I add it but still can't see the issue.
Also, which device are you testing on?

Edited the code to include the icon, but it doesn't make a difference here. I'm testing this as Windows desktop app (Windows 10).
Here is what I see:

Thanks for your response. I also can see this issue on other platforms as well. It's more visible when moving SearchBar to body center as below sample code:

Sample code
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'SearchBar Bug',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: const Scaffold(
        body: Center(
          child: SearchBar(
            leading: Icon(Icons.search),
            hintText: 'Search',
            constraints: BoxConstraints(minHeight: 40, maxHeight: 40),
          ),
        ),
      ),
    );
  }
}

Demo

web
web - enabling inspector

ios
android

flutter doctor -v (stable and master)
[✓] Flutter (Channel stable, 3.10.1, on macOS 13.0.1 22A400 darwin-x64, locale en-VN)
    • Flutter version 3.10.1 on channel stable at /Users/huynq/Documents/GitHub/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision d3d8effc68 (26 hours ago), 2023-05-16 17:59:05 -0700
    • Engine revision b4fb11214d
    • Dart version 3.0.1
    • DevTools version 2.23.1

[✓] Android toolchain - develop for Android devices (Android SDK version 32.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-33, build-tools 32.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14E222b
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.78.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.64.0

[✓] Connected device (3 available)
    • RMX2001 (mobile) • EUYTFEUSQSRGDA6D • android-arm64  • Android 11 (API 30)
    • macOS (desktop)  • macos            • darwin-x64     • macOS 13.0.1 22A400 darwin-x64
    • Chrome (web)     • chrome           • web-javascript • Google Chrome 113.0.5672.126

[✓] Network resources
    • All expected network resources are available.

• No issues found!

[!] Flutter (Channel master, 3.11.0-6.0.pre.153, on macOS 13.0.1 22A400 darwin-x64, locale en-VN)
    • Flutter version 3.11.0-6.0.pre.153 on channel master at /Users/huynq/Documents/GitHub/flutter_master
    ! Warning: `flutter` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/flutter, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    ! Warning: `dart` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/dart, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision e49d35d3a6 (35 minutes ago), 2023-05-18 22:26:29 -0400
    • Engine revision bca11a423f
    • Dart version 3.1.0 (build 3.1.0-125.0.dev)
    • DevTools version 2.23.1
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 32.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-33, build-tools 32.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14E222b
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.78.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.64.0

[✓] Connected device (3 available)
    • RMX2001 (mobile) • EUYTFEUSQSRGDA6D • android-arm64  • Android 11 (API 30)
    • macOS (desktop)  • macos            • darwin-x64     • macOS 13.0.1 22A400 darwin-x64
    • Chrome (web)     • chrome           • web-javascript • Google Chrome 113.0.5672.126

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.


user.activity.lastActivity not getting set for new users/users with no activity

https://github.com/robotnoises/bebop/commit/599bcce86540a697f6d8b4b19b69c43cd9d2d763


Fix Skipping trial on swapping

As per the docs https://laravel.com/docs/5.3/billing#changing-plans

If you would like to swap plans and cancel any trial period the user is currently on, you may use the  skipTrial method:

$user->subscription('main')
        ->skipTrial()
        ->swap('provider-plan-id');

However the Subscription model doesn't have a skipTrial() method, this PR adds the proper method.

It would be nice to make this available on Laravel Cashier ~6.0 for laravel 5.2, because in documentation it says that skipTrial() method exists when it actually not there.


fix(Designer): Scope Nodes can be moved to Invalid locations

Requirement Checklist

[X] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes or features)
[ ] Docs have been added or updated (for bug fixes or features)

Type of Change

[X] Bug fix
[ ] Feature
[ ] Other

fixes #5535

[ ] This is a breaking change.

Screenshots or Videos (if applicable)

https://github.com/user-attachments/assets/2b283f38-aae0-497e-b798-b076207beb7c

Can we write any Unit tests for this?
Also we saw other invalid location issues when @Eric-B-Wu was testing for codeview. Can you sync up with him?

Can we write any Unit tests for this? Also we saw other invalid location issues when @Eric-B-Wu was testing for codeview. Can you sync up with him?

It was just that this function lives in the component hook; I'll create a helper file and put it out to write unit tests for this. I'll sync with Eric offline to verify other invalid location issues!

Can we write any Unit tests for this? Also we saw other invalid location issues when @Eric-B-Wu was testing for codeview. Can you sync up with him?

I've sync with Eric; the action is not supposed to have runafters for both a node and the upstream of that node. Since this doesn't seem quite relevant to the drag&drop experience, I'll be filing a seperate ticket and work on it.


Is this repository still active

Hi,
I'm slowly building up a patchset and trying to decide if I should try upstreaming them here or maintain my own fork.
thanks,
Karl.

Hi,
Wondering if anyone has had a chance to review this query yet.
thanks,
Karl

I just opened #4; I'll close this issue as the project is clearly alive again!


SPM support + Swift 5

This PR adds support for:

Swift Package Manager
Swift 5

Hope it's useful!

Happy to contribute back!
Hope you are able to merge it soon so I can point my projects to this repo instead of my fork. :)


Signature verification of ES256 fails

According to the specs, it should be:

-7 (ES256), where kty is 2 (with uncompressed points) and crv is 1 (P-256).

However it is unclear how this "kty is 2 (with uncompressed points)" is applied. In the browser's Crypto module, there is no such parameter for ECDSA Keys, only for the named curve.
This kind of makes it impossible for the browser to verify signatures in the demo, or a big crypto lib should be added as dependency.
Note: Recently, Windows Hello switched from RS256 to ES256, dunno exactly when.

The issue runs much deeper than that. The crypto modules from the Browser and NodeJS differ and are incompatible. 😞  ...So basically, making a module running both in the browser and in node becomes more problematic. Making a test suite also, since it must then test both cases. As a matter of fact, I haven't been able to make a "platform neutral" testing suite yet.

Done. Requires Node 19+ from now on.


Add branch name for projects without a release

Problem
Trying to install a library with no release gives:
scratch/main> lib.install @staccatosemibreve/optics

@staccatosemibreve/optics has no releases.

So we need to make sure there's a release at all! Otherwise we need to include the branch name.

Solution
Check that there's a release (instead of just comparing Nothing and Nothing).
Caveats/Notes
Originally I was going with something like:
withDefault false (map2 (==) project.latestVersion (BranchRef.version br))

But then I noticed other code in this file seemed to prefer pattern matching, so I went with that.

Nice! I'll let @hojberg


Update docker registry to twun.io's registry chart

Signed-off-by: Czékus Máté<EMAIL_ADDRESS>
Description
Docker Registry used the old stable chart which was outdated and the only still updated 1:1 feature comaptible one was twuni's chart.
Motivation and Context

[X] I have raised an issue to propose this change, which has been given a label of design/approved by a maintainer (required) #274

How Has This Been Tested?
Manually by running arkade install docker-registry with all the flags.
Are you a GitHub Sponsor yet (Yes/No?)

[ ] Yes
[X] No

Types of changes

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Documentation

[ ] I have updated the list of tools in README.md if (required) with ./arkade get -o markdown
[ ] I have updated the list of apps in README.md if (required) with ./arkade install --help

Checklist:

[X] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[X] I have updated the documentation accordingly.
[X] I've read the CONTRIBUTION guide
[X] I have signed-off my commits with git commit -s
[ ] I have added tests to cover my changes.
[X] All new and existing tests passed.

[X] I have tested this on arm, or have added code to prevent deployment

Thanks for the tag @Shikachuu!
The twun.io domain is privately held and operated by myself, primarily for package distribution under appropriate subdomains (helm.twun.io among them). As you can see, there's no HTTP front-end of consequence at the parent domain.
This chart is also available via a GitHub-owned domain (see https://github.com/twuni/docker-registry.helm/issues/22#issuecomment-1004519481 for details), so if you prefer, you can use https://twuni.github.io/docker-registry.helm. I dual-publish each release to both repos, with provenance, and intend to continue supporting both. FWIW, of the two URLs, the GitHub-owned one is more likely to transition toward community governance one day.
My primary goals for maintaining this chart are:

to maintain compatibility with users of the stable chart
to ensure compatibility with modern Docker+Helm+Kubernetes tooling
to fix any defects

So if you're using the stable chart, you should be fine updating to this one.

I spoke to @justincormack at Docker, and it seems like there is no official Helm chart for the OSS registry.
So therefore, as discussed on Discord @Shikachuu, please:

Make it very clear in the command help messages that this is a community chart, not "official"
Use the GitHub publishing address instead
Link to @canterberry's GitHub repo in the post-installation notes and in the help message

Once you have that arranged, I'll merge this PR.
@canterberry out of interest, is there still support for ARM architectures?

I appreciate the diligence, @alexellis ! All correct, to my knowledge.
As for ARM support: I think that depends exclusively on the image and whether it's built for ARM architecture. The chart supports custom images, so even if there wasn't an official ARM-compatible image, one could in theory compile (or locate) one and reference that instead.
I haven't seen any ARM-related changes come through in the chart, so should be status quo. Feel free to create an issue in twuni/docker-registry.helm if there's a compatibility issue we might be able to resolve in the chart.

I spoke to @justincormack at Docker, and it seems like there is no official Helm chart for the OSS registry.
So therefore, as discussed on Discord @Shikachuu, please:
* Make it very clear in the command help messages that this is a community chart, not "official"

* Use the GitHub publishing address instead

* Link to @canterberry's GitHub repo in the post-installation notes and in the help message

Once you have that arranged, I'll merge this PR.
@canterberry out of interest, is there still support for ARM architectures?

Done :heavy_check_mark:

Thank you both. @canterberry your input is very much appreciated
If you're interested in linking back to arkade install docker-registry from your docs / README, it's a very quick and convenient way to do an automated / 1-line installation with auth/tls.
https://blog.alexellis.io/get-a-tls-enabled-docker-registry-in-5-minutes/


chore(authproxy): deploy fork of openshift-oauth-proxy

Welcome to Cryostat! 👋
Before contributing, make sure you have:

[x] Read the contributing guidelines
[x] Linked a relevant issue which this PR resolves
[x] Linked any other relevant issues, PR's, or documentation, if any
[x] Resolved all conflicts, if any
[x] Rebased your branch PR on top of the latest upstream main branch
[x] Attached at least one of the following labels to the PR: [chore, ci, docs, feat, fix, test]
[x] Signed all commits: git commit -S -m "YOUR_COMMIT_MESSAGE"

Related to cryostatio/cryostat3#469
Description of the change:
This change adds allows the users to provide...
Motivation for the change:
This change is helpful because users may want to...
How to manually test:

Insert steps here...
...

/build_test

/build_test

https://github.com/cryostatio/cryostat-operator/actions/runs/9406709722


add z and elf libraries as libbpf dependency for arm64 cross-compile

Description
Add z and elf libraries as libbpf dependency for arm64 cross-compile
Type of change /PR 类型

[ ] New feature (cross-compile dependency)

Checklist/检查列表

[ ] I have performed a self-review of my own code / 自己已经检查代码

LGTM


bug: events are missing in mixpanel

What is happening?

Section description
Provide as much context as you can. Give as much context as you can to make it easier for the developers to figure what is happening.

The BNB_MESSAGE_COUNT POLY_MESSAGE_COUNT TWITTER DISCORD TELEGRAM no longer show in mixpanel and the correspoding reports are broken
What is the expected behaviour?

Section description
If you know, please write down what is the expected behaviour. If you don't know, that's ok. We can have a discussion in comments.

Social media numbers should be sent once a day
message counts should be sent once per hour
historical data (such as eth-main message count) should still be in the mixpanel report

this was fixed

I only see current url now (as volume.finance), but not the actual page that is viewed

this was reopened by mistake


How do i run this project on CPU?

@TangeniThePyGuru does it work with the code, It seems like the same, if I do not install cuda, the code above is just the same as code below.
here is the error,
CUDA driver library cannot be found.
If you are sure that a CUDA driver is installed,
try setting environment variable NUMBA_CUDA_DRIVER
with the file path of the CUDA driver shared library.
:
Do you have a idea to solve that?


Include guard issue - include guards are being created based on the file name but don't include anything about the path, creating conflicts when using two files with the same name [13730]

We have two IDLs with the same name but different namespaces:
e.g.
one_project/a_folder/SomeThing.idl
one_project/b_folder/SomeThing.idl
Using the FastDDSGen tool we have seen that the generated code is actually creating matching include guards because the include guards are just based on the file name.
Can this be patched to generate the include guards using the folder the IDL is in or some additional information to distinguish between two IDLs with matching names and different contents?

Not helpful, but I ran into this issue today. I think an easy fix in fast-dds-gen would be to use the '#pragma once' instead in the headers for guards.

Found this issue after submitting a PR. Agreed that #pragma once might be cleaner provided it is available on supported compilers.

Labeling this ticket as enhancement and moving it to the Ideas discussion forum where enhancements and feature requests are discussed.


[Proposal] Remove most class="hidden" for Fomantic checkbox/radiobox

According to https://fomantic-ui.com/modules/checkbox.html#/usage
The <input class="hidden" type="(checkbox|radio)" tabindex="0" ...> could be simplified to <input type="(checkbox|radio)"  ...>
The "hidden" CSS class here is very ambiguous and seems not help about UI/UX in most cases. The comment for it is:
/* Initialized checkbox moves input below element to prevent manually triggering */
.ui.checkbox input.hidden {
  z-index: -1;
}

The hidden class seems to for the purpose of allowing a click on the label to toggle the checkbox which is not possible with their suggested HTML.
It's possible to make checkboxes toggleable through label by putting them inside it, for example https://jsfiddle.net/silverwind/seb670f3/, so something like that should be preferrable.
Generally like to remove the fomantic checkbox/radio module and implement these ourselves.

To be more aggressive, I prefer to use native checkbox/radio/select as much as possible instead of these Fomantic UI checkbox/radio/dropdown. GitHub is using native HTML input elements as much as possible. And these native elements are more friendly for all browsers and a11y.

Can we label this kind/ui?
Instead of nesting <input type="checkbox" /> (or radio) inside a <label>, they can be associated with id and for.
I agree with getting rid of ::before.
(:before is valid, too. But : is usually preferred for pseudo-classes, whereas :: is used for pseudo-elements).

It's feasible. But Fomantic UI checkbox has some features which is not simple.

Which would that be? Looking through their documentation I couldn't spot anything, that couldn't be done with a few lines of HTML and JS.

It's feasible. But Fomantic UI checkbox has some features which is not simple.

Which would that be? Looking through their documentation I couldn't spot anything, that couldn't be done with a few lines of HTML and JS.

I mean the API for the Fomantic checkbox. I did a grep by .checkbox in the web_src/js directory. All these code should rewritten.

Fomantic checkbox fails if user blocks remote fonts e.g. gfx.downloadable_fonts.enabled=false in Firefox, or popular browser extensions like uBlock
Example from gitea demo:

Indeed, that's another argument for native checkboxes with SVG overlay, like we already do for Markdown checkboxes.

Close this one. Wait for the rewriting the checkbox code using the native element.


Enhance header filtering in getHeadersApplicableToAllResources function to exclude falsy values

Types of changes

[x] Bug fix (a non-breaking change which fixes an issue)
[ ] New feature (a non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

This pull request includes a small change to the src/utils/headers.ts file. The change ensures that only headers with non-falsy values are included in the result.

src/utils/headers.ts: Added a filter to remove headers with falsy values in the getHeadersApplicableToAllResources function.

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes (if not applicable, please state why)

@vejja Thank you for the review. I've added new tests for publicAssets to ensure there are no empty headers and that headers are correctly set according to the routeRules.

@Baroshem LGTM


FW auto landing with range finder

Tested auto landing with lidar lite range finder.
In general auto landing worked but the terrain altitude estimate from the ekf stays constant at the inititial value. Looks like the range state of the ekf is always zero.
Is there some parameter which I have overseen?
Log:
http://logs.uaventure.com/view/LRaKGWPLiPz6e34wwsi3jn

Cool, thanks for testing! I guess the next step is then to do more bench tests with the EKF and work out what the bottom distance estimate is doing.

The upper plot shows a problem which can occur during fixed wing auto landing.
At a certain distance before the landing waypoint FW_LND_HHDIST the plane should stop navigating waypoints but rather lock to a constant heading. However, I had several flights where this distance (15m) was never reached and the plane started to roll abruptly at some point (see picture below). I'm very sure that the plane never entered heading hold mode because the mavlink message here https://github.com/PX4/Firmware/blob/master/src/modules/fw_pos_control_l1/fw_pos_control_l1_main.cpp#L1223 never appeared in QGC.

You can see that the landing occurred between waypoint 4 and 5. You can also see that the plane passed the landing wapoint on the side and then tried to navigate to it after, at least that's the only thing I can imagine.

This is the corresponding mavlink text:
'''
TAKEOFF DETECTED
Flight mode: ALTCTL
Flight mode: AUTO_MISSION
offboard mission now running
#audio: Landing, on slope
#audio: Landing, limiting throttle
#audio: Landing, flaring
Flight mode: ALTCTL
Flight mode: STAB
LANDING DETECTED
DISARMED by safety switch
[cmd] arming state: STANDBY
[sdlog2] logging stopped
data link #0 lost
'''

In the upper plot you can see that the plane was commanded to a high roll angle during the final landing approach. This bug is fixed in #2868

Just out of curiosity why did it want to roll? Did it overshoot and want to go around? Once it is at the height it was it's too late to do anything about it anyway so limiting it makes sense.

@SimonWilks When the plane reaches FW_LND_HHDIST it computes to target heading to be the bearing between the previous and the landing waypoint. If this heading does not match the yaw angle of the plane at that instant it will try to correct by rolling. It's clearly visible in the upper plot.

BTW, I misused the ATSP.q variables to capture some interesting variables which were not logged.
So don't get confused why e.g.  the distance to the landing waypoint is ATSP.qw :-)

when the terrain estimate is working again enable the  FW_LND_USETER param which is set to 0 in your log

@thomasgubler I am actually using a small terrain estimator module. I temporarily adapted the fw_pos controller to use it's terrain estimate, so even though the parameter is zero, it's using the estimate. The estimate is logged in GPOS.TALT (it's the distance from the plane to the ground.) When I'm happy with the landings I will try to integrate the estimation part into the ekf. To be honest I have no idea what they are doing there, so I decided to write one from scratch.

This is the branch I'm using https://github.com/tumbili/Firmware/tree/fw_lidar_landing

This is a new log from a flight I did today:
http://logs.uaventure.com/view/268qnVvnnJq6wYQHV7hg5a
The problem with the unexpected roll is gone after the fix.
Landing is nice, the tuning of the pitch controller could be better. Terrain estimation with the lidar works great.

Nice! I think we generally need better pitch defaults. The default tuning is always terrible. Could you spend some time tuning that on your next test run?

@LorenzMeier  @thomasgubler This is now tested very extensively.  They key to a good landing behaviour is a well tuned attitude and TECS controller. I think I could spend some time tuning the TECS controller (also based on the APM guide) because if altitude is not tracked well the plane will over or undershoot the landing waypoint.
One other thing that we also might look at is the handling of aborted landings. In case of an aborted landing the navigator should reset to the waypoint before the landing waypoint. Right now I think the plane tries to target the landing waypoint directly which is not a good idea.

This can be closed together with #2964 when done.


Update migration-api-overview.md

Category

[X] Content fix/addition

What's in this Pull Request?
Resubmitting key area from a March 29th PR that didn't go live.  Adding section Entering user identifiers in UseGroup.xml.

Docs Build status updates of commit fbf95c3:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/apis/migration-api-overview.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 71eda22:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/apis/migration-api-overview.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


PerfForesightConsumerType can't handle CRRA of 1.0

Describe the bug
Trying to run the .solve() method for an PerfForesightConsumerType throws an error when CRRA is 1.0. Other agent types don't throw this error.
To Reproduce
from HARK.ConsumptionSaving.ConsIndShockModel import PerfForesightConsumerType
agent=PerfForesightConsumerType()
agent.CRRA=1.0
agent.solve()
Expected behavior
The model should be able to compile without errors.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: Windows
Browser Firefox
Econ-ARK and Python version 0.13.0 and Python 3.9.13

Additional context

I thought we fixed this years ago, ugh.
On Tue, Jun 27, 2023 at 8:59 PM DominicWC @.***> wrote:

Describe the bug
Trying to run the .solve() method for an PerfForesightConsumerType throws
an error when CRRA is 1.0. Other agent types don't throw this error.
To Reproduce
from HARK.ConsumptionSaving.ConsIndShockModel import
PerfForesightConsumerType
agent=PerfForesightConsumerType()
agent.CRRA=1.0
agent.solve()
Expected behavior
The model should be able to compile without errors.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: Windows
Browser Firefox
Econ-ARK and Python version 0.13.0 and Python 3.9.13

Additional context
—
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/issues/1293, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADKRAFO7Y4YYL57FW6ZPFSDXNN6XNANCNFSM6AAAAAAZWKLU5I
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I think at some point someone went through and fixed the 1-CRRA stuff and
had it refer to utility functions instead, and the utility functions should
correctly handle CRRA=1. Maybe that's not the case.
The code definitely will break down for CRRA ~= 1, for numeric reasons.
On Wed, Jun 28, 2023 at 11:06 AM Alan Lujan @.***>
wrote:

there's a lot of hardcoded 1.0 - self.CRRA throughout the code base. I'm
surprised other models run for CRRA = 1.0
—
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/issues/1293#issuecomment-1611616129,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADKRAFJVNBGKTOV6WKQC32LXNRB57ANCNFSM6AAAAAAZWKLU5I
.
You are receiving this because you commented.Message ID:
@.***>


Latest version crashes, game still crashes from ticking entity

Here is the log from version 1.0.3 for Minecraft 1.19.2, it crashed because of ticking Amaranth seeds: https://mclo.gs/d3FgzCH
the log from version 1.0.4 (1.19.2), crashed just at startup https://mclo.gs/tvZbjWb
I would like to update: I found what mod was actually causing the problem, a mod that is supposed to automatically plant dropped seeds as one of it's features. You can probably disregard the second half of this bug report.

If you remove MixinExtras, does it work then?

I can't exactly remove mixinextras, it was added by another mod and removing it probably breaks a ton of other mods.

It gives the exact same error with no other mods in 1.19.2 https://mclo.gs/V0HeIfw

It gives the exact same error with no other mods in 1.19.2 https://mclo.gs/V0HeIfw

--version 1.19.2 --gameDir /home/********/.local/share/PollyMC/instances/1.19.2/.minecraft --assetsDir /home/********/.local/share/PollyMC/assets --assetIndex 1.19 --uuid  --accessToken  --userType  --versionType release --launchTarget forgeclient --fml.forgeVersion 45.0.49 --fml.mcVersion 1.19.4 --
Shows you are trying to 1.19.4 on 1.19.2
Just tested in a clean 1.19.2 build and it's loading just fine for me.

This was found to be the fault of mods that are using the beta version of MixinExtra instead of the release version. New version is pushed using the beta.


Deprecated features message during chef-server-ctl reconfigure

We need to update the cookbook code to avoid this deprecation warning from the runit resource:
Deprecated features used!
  Resource component_runit_service needs `provides :component_runit_service` in addition to `resource_name :component_runit_service` declaration at 1 location:
    - /opt/opscode/embedded/lib/ruby/2.6.0/forwardable.rb:230:in `setup_run_context'
   See https://docs.chef.io/deprecations_resource_name_without_provides/ for further details.

I suspect the error is here: https://github.com/chef-cookbooks/enterprise-chef-common/blob/master/libraries/component_runin_supervisor_resource_mixin.rb#L4

Fixed in https://github.com/chef/chef-server/pull/2437


Festobionic Flower: User defined functions not being generated!

Describe the bug
User defined functions are not being generated for Festobionic Flower. The function signature is generated, however, the actual function body is missing.
To Reproduce
Steps to reproduce the behavior:

Go to lab.open-roberta.org
Click on Festobionic Flower
In Expert -> Functions toolbox, select any block to define a function.
Click on Open/close source code view
See (or don't!) missing function body.

Expected behavior
User defined functions (both signature and body) should be properly generated.
Screenshots

Device information

Type: Desktop
OS: Ubuntu 20.04
Browser Firefox 104.0

additionally tests for the Flower plugin are added!


Feat(eos_cli_config_gen): add dot1x unauthorized access|native vlan membership egress to ethernet interfaces

Enhancement summary
add the following two dot1x options to ethernet interfaces:

dot1x unauthorized native vlan membership egress
dot1x unauthorized access vlan membership egress

access-10-021-01.LAN.MU__17:12:28(config)#in eth 82
access-10-021-01.LAN.MU__17:12:30(config-if-Et82)#dot1x unauthorized ?
  access  Applied to access VLAN of access port
  native  Applied to native VLAN of phone trunk port

access-10-021-01.LAN.MU__17:12:30(config-if-Et82)#dot1x unauthorized native ?
  vlan  VLAN configuration

access-10-021-01.LAN.MU__17:12:30(config-if-Et82)#dot1x unauthorized native vlan ?
  membership  VLAN membership configuration

access-10-021-01.LAN.MU__17:12:30(config-if-Et82)#dot1x unauthorized native vlan membership ?
  egress  Grant VLAN membership in egress direction

access-10-021-01.LAN.MU__17:12:30(config-if-Et82)#dot1x unauthorized native vlan membership egress ?
  <cr>

access-10-021-01.LAN.MU__17:13:18(config)#in eth 82
access-10-021-01.LAN.MU__17:13:20(config-if-Et82)#dot1x unauthorized ?
  access  Applied to access VLAN of access port
  native  Applied to native VLAN of phone trunk port

access-10-021-01.LAN.MU__17:13:20(config-if-Et82)#dot1x unauthorized access ?
  vlan  VLAN configuration

access-10-021-01.LAN.MU__17:13:20(config-if-Et82)#dot1x unauthorized access vlan ?
  membership  VLAN membership configuration

access-10-021-01.LAN.MU__17:13:20(config-if-Et82)#dot1x unauthorized access vlan membership ?
  egress  Grant VLAN membership in egress direction

access-10-021-01.LAN.MU__17:13:20(config-if-Et82)#dot1x unauthorized access vlan membership egress ?
  <cr>

Which component of AVD is impacted
eos_cli_config_gen
Use case example
ethernet_interfaces:
  - name: Ethernet82
     dot1x:
       unauthorized:
         native_vlan_membership_egress: true

  interface Ethernet82
   description Data&Voice
   no shutdown
   no logging event link-status
   switchport trunk native vlan 2210
   switchport phone vlan 2510
   switchport phone trunk tagged phone
   switchport mode trunk phone
   switchport
   address locking ipv4 ipv6
   no lldp receive
   storm-control broadcast level 0.5
   storm-control multicast level 0.5
   storm-control unknown-unicast level 0.5
   spanning-tree portfast
   spanning-tree bpduguard enable
   no logging event spanning-tree
   dot1x pae authenticator
   dot1x authentication failure action traffic allow vlan 2210
   dot1x reauthentication
   dot1x port-control auto
   dot1x host-mode multi-host authenticated
   dot1x mac based authentication host-mode common
   dot1x timeout quiet-period 30
   dot1x timeout tx-period 2
   dot1x timeout reauth-period server
   dot1x reauthorization request limit 3
   dot1x unauthorized native vlan membership egress
   dot1x eapol authentication failure fallback mba timeout 0

Describe the solution you would like
ethernet_interfaces:
  - name: <str>
     dot1x:
       unauthorized:
         access_vlan_membership_egress: <bool>
         native_vlan_membership_egress: <bool>

Describe alternatives you have considered
usage of eos_cli
Additional context
No response
Contributing Guide

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

Is it good that I proceed with this data model and make the PR?

Hi Karl, apologies for the delayed response. Yes this model looks good. Thanks.


Fix coroutine integration

Haven't tested the actual build yet. gcc-newest should have coroutines enabled if this works as intended.

Why did you change the test condition which was correct in my patch? You appear to be adding the flag for all gcc, and not just version 10, even though you proved it wasn't necessary for version 11, and didn't exist in version 9.

Why did you change the test condition which was correct in my patch? You appear to be adding the flag for all gcc, and not just version 10, even though you proved it wasn't necessary for version 11, and didn't exist in version 9.

Simply because it doesn't matter, but I can indeed make the condition more specific as well.

@Spongman indeed, thanks. I thought I mentioned this on some issue or PR, but I currently don't have the time to work on this. I'm wondering, would you be interested in finishing this off?

I'd appreciate reviews on this now. I've made a few more configuration changes.
GCC 10 "supports" coroutines with the -fcoroutines flag. However, coroutines like these:
shared_future<void> f() {
    co_return co_await make_ready_future<void>();
}

fail to compile with GCC 10 because the compiler attempts to construct a shared future with an lvalue reference of the future returned from make_ready_future. We could work around this in the test itself by explicitly making the future returned from make_ready_future a shared future, but I don't see much benefit in "fixing" it for GCC 10 when we anyway can't support this for all GCC versions. I.e. requiring GCC 11 seems to me like an acceptable solution, especially since it doesn't come with funny restrictions. Any objections?
The second change is related to GCC making C++20 features available even with -std=c++17. This came up while trying the changes here accidentally with the -fcoroutines flag and HPX_WITH_CXX17. The feature test would detect coroutines support but then the feature macro would not be defined since it's guarded by a __cplusplus check (https://github.com/STEllAR-GROUP/hpx/blob/35c7a2d752d7b6d25299198788ab8646b3609bed/cmake/HPX_AddDefinitions.cmake#L123-L138) and tests expecting coroutines would fail to compile. For coroutines this isn't relevant anymore since I removed the -fcoroutines fallback, but the same happens for simd support. I've removed the conditional definition of those feature test macros. It's a quirk of GCC, but I think it's reasonable to always define the feature test macros if the compiler seems to support the feature, even if it's with the wrong standard. The alternative is going back to not even checking for C++XX features if HPX_WITH_CXXXX isn't enabled.

Performance test reportHPX PerformanceComparisonBENCHMARKNO-EXECUTORFuture Overhead - Create Thread Hierarchical - Latch(=)InfoPropertyBeforeAfterHPX Commit254db57ab5e998619e49744062d14609f1b466dacbe2eb7bc749b0ac35c1fc21d93476ddf5d3d1b7HPX Datetime2021-08-21T11:38:52+00:002021-11-03T10:01:53+00:00EnvfileDatetime2021-08-23T15:21:22.855927+02:002021-11-03T11:17:19.769982+01:00Compiler/apps/daint/SSL/HPX/packages/llvm-11.0.0/bin/clang++ 11.0.0/apps/daint/SSL/HPX/packages/llvm-11.0.0/bin/clang++ 11.0.0ClusternamedaintdaintHostnamenid00446nid00445ComparisonBENCHMARKFORK_JOIN_EXECUTOR_DEFAULT_FORK_JOIN_POLICY_ALLOCATORPARALLEL_EXECUTOR_DEFAULT_PARALLEL_POLICY_ALLOCATORSCHEDULER_EXECUTOR_DEFAULT_SCHEDULER_EXECUTOR_ALLOCATORStream Benchmark - Add-(=)-Stream Benchmark - Scale(=)(=)(=)Stream Benchmark - Triad---Stream Benchmark - Copy(=)(=)(=)InfoPropertyBeforeAfterHPX Commit916f4d8a700533b3273012ecf811d63617592bb2cbe2eb7bc749b0ac35c1fc21d93476ddf5d3d1b7HPX Datetime2021-10-22T15:54:13+00:002021-11-03T10:01:53+00:00EnvfileDatetime2021-10-25T11:52:24.316784+02:002021-11-03T11:17:35.158011+01:00Compiler/apps/daint/SSL/HPX/packages/llvm-11.0.0/bin/clang++ 11.0.0/apps/daint/SSL/HPX/packages/llvm-11.0.0/bin/clang++ 11.0.0ClusternamedaintdaintHostnamenid01196nid00445Explanation of SymbolsSymbolMEANING=No performance change (confidence interval within ±1%)(=)Probably no performance change (confidence interval within ±2%)(+)/(-)Very small performance improvement/degradation (≤1%)+/-Small performance improvement/degradation (≤5%)++/--Large performance improvement/degradation (≤10%)+++/---Very large performance improvement/degradation (>10%)?Probably no change, but quite large uncertainty (confidence interval with ±5%)??Unclear result, very large uncertainty (±10%)???Something unexpected…

Note: I have not tested the "non-standard" coroutines options that we have (emulation, clang's -fcoroutines-ts, MSVC's -await) and will not do so in this PR.

requiring GCC 11 seems to me like an acceptable solution, especially since it doesn't come with funny restrictions.

That's reasonable.

The alternative is going back to not even checking for C++XX features if HPX_WITH_CXXXX isn't enabled.

What's wrong with that? I think this would avoid funny mistakes.

Note: I have not tested the "non-standard" coroutines options that we have (emulation, clang's -fcoroutines-ts, MSVC's -await) and will not do so in this PR.

We might be able to completely get rid of those. Let's stick with enabling coroutines for HPX_WITH_CXX20 only.

The alternative is going back to not even checking for C++XX features if HPX_WITH_CXXXX isn't enabled.

What's wrong with that? I think this would avoid funny mistakes.

We had problems with it in the past which is why we enabled the feature checks unconditionally. However, I don't remember what the exact problem was. I'll try to dig a bit to see if I can find out what the problem was.

Note: I have not tested the "non-standard" coroutines options that we have (emulation, clang's -fcoroutines-ts, MSVC's -await) and will not do so in this PR.

We might be able to completely get rid of those. Let's stick with enabling coroutines for HPX_WITH_CXX20 only.

Yes, that sounds reasonable. I can do that here. Does MSVC also support coroutines without any special flags nowadays (except probably /std:c++20 or whatever the equivalent is there)?

Yes, that sounds reasonable. I can do that here. Does MSVC also support coroutines without any special flags nowadays (except probably /std:c++20 or whatever the equivalent is there)?

I would think so, yes.

The alternative is going back to not even checking for C++XX features if HPX_WITH_CXXXX isn't enabled.

What's wrong with that? I think this would avoid funny mistakes.

We had problems with it in the past which is why we enabled the feature checks unconditionally. However, I don't remember what the exact problem was. I'll try to dig a bit to see if I can find out what the problem was.

I made them unconditional here: https://github.com/STEllAR-GROUP/hpx/pull/4378, but I wasn't smart enough to write why. I would prefer keeping them unconditional though, but I don't feel very strongly about this as long as I can't remember the original reason for making them unconditional.

Aren't these two orthogonal? One is how we specify the C++ standard to rely on, the other is to enable/disable coroutines. Did I misunderstand something?

I fear that at least one of us is misunderstanding the other, if not both... I would call the current behaviour on master orthogonal, i.e. the feature checks do not care about which C++ standard is set (and definitely not vice-versa, but that was never the case and makes little sense). When I say "unconditional" I see that as the same as your "orthogonal". Does this match what you're saying?
Note: there are probably two separate "unconditional" involved here:

Doing the feature checks independently of the C++ standard set.
Defining the feature check macros without __cplusplus guards.
I take the second for granted if we do the first since things are definitely broken otherwise.

Aren't these two orthogonal? One is how we specify the C++ standard to rely on, the other is to enable/disable coroutines. Did I misunderstand something?

I fear that at least one of us is misunderstanding the other, if not both... I would call the current behaviour on master orthogonal, i.e. the feature checks do not care about which C++ standard is set (and definitely not vice-versa, but that was never the case and makes little sense). When I say "unconditional" I see that as the same as your "orthogonal". Does this match what you're saying?

Possibly ;-)
But jokes apart - I think I agree with what you said.

Note: there are probably two separate "unconditional" involved here:

Doing the feature checks independently of the C++ standard set.
Defining the feature check macros without __cplusplus guards.

I take the second for granted if we do the first since things are definitely broken otherwise.

The second is important for depending projects that possibly use a different compiler (version). The guards allow for a minimum of safety if the compiler used for a depending project is too old. We've ran into these issues before, which triggered guarding the macros in the first place.

The second is important for depending projects that possibly use a different compiler (version). The guards allow for a minimum of safety if the compiler used for a depending project is too old. We've ran into these issues before, which triggered guarding the macros in the first place.

What sort of safety does it provide? Compiling applications with a lower C++ version than HPX was compiled with is bound to be broken anyway (and enforced when building with CMake). Compiling applications with the same standard as HPX but a different compiler that doesn't define __cplusplus correctly is broken. Compiling applications with a different compiler with the same or higher standard but that doesn't support the feature that HPX detected was available seems weird. In what situations is that desireable? If one compiler was available to compile HPX, why would one not use that, or a newer compiler, to compile the application?

What sort of safety does it provide? Compiling applications with a lower C++ version than HPX was compiled with is bound to be broken anyway (and enforced when building with CMake). Compiling applications with the same standard as HPX but a different compiler that doesn't define __cplusplus correctly is broken. Compiling applications with a different compiler with the same or higher standard but that doesn't support the feature that HPX detected was available seems weird. In what situations is that desireable? If one compiler was available to compile HPX, why would one not use that, or a newer compiler, to compile the application?

It might have been caused by compilers that claim to be C++yy conforming but in fact were not. Otherwise I agree that this shouldn't happen - however it did happen multiple times. Otherwise we wouldn't have added the guards...

It might have been caused by compilers that claim to be C++yy conforming but in fact were not. Otherwise I agree that this shouldn't happen - however it did happen multiple times. Otherwise we wouldn't have added the guards...

Hrm, so we've had problems with both solutions. And we can't remember what the problems were...
Fair enough, let's go with conditional defines and conditional feature checks again then. We'll find out sooner or later what the problem was, if any. And like you said, it's reasonable to not allow C++20 features with C++17. That's just a GCC quirk after all.

Let's see if I broke something with the latest change. I reverted back to conditionally defining the macros, and made the feature checks conditional on the C++ standard set in the CMake configuration.

It might have been caused by compilers that claim to be C++yy conforming but in fact were not. Otherwise I agree that this shouldn't happen - however it did happen multiple times. Otherwise we wouldn't have added the guards...

Hrm, so we've had problems with both solutions. And we can't remember what the problems were...
Fair enough, let's go with conditional defines and conditional feature checks again then. We'll find out sooner or later what the problem was, if any. And like you said, it's reasonable to not allow C++20 features with C++17. That's just a GCC quirk after all.

I think this situation occurred for instance when HPX was built with C++17, but the consuming project was C++14 only (or similar).

Rebased again. This should be ready to go unless there are comments on the changes to the coroutine_traits.

Performance test reportHPX PerformanceComparisonBENCHMARKNO-EXECUTORFuture Overhead - Create Thread Hierarchical - Latch-InfoPropertyBeforeAfterHPX Datetime2021-11-11T08:14:57+00:002021-11-15T12:21:53+00:00HPX Commit96a2e4bd1c76207dea8d5302784962c92788240631bde338f1e8dfdc6cf79daa6146b6d52adf05a2Compiler/apps/daint/SSL/HPX/packages/llvm-11.0.0/bin/clang++ 11.0.0/apps/daint/SSL/HPX/packages/llvm-11.0.0/bin/clang++ 11.0.0EnvfileDatetime2021-11-11T09:28:13.071121+01:002021-11-15T14:25:15.308487+01:00ClusternamedaintdaintHostnamenid00006nid01332ComparisonBENCHMARKFORK_JOIN_EXECUTOR_DEFAULT_FORK_JOIN_POLICY_ALLOCATORPARALLEL_EXECUTOR_DEFAULT_PARALLEL_POLICY_ALLOCATORSCHEDULER_EXECUTOR_DEFAULT_SCHEDULER_EXECUTOR_ALLOCATORStream Benchmark - Add(=)(=)(=)Stream Benchmark - Scale(=)(=)(=)Stream Benchmark - Triad(=)(=)(=)Stream Benchmark - Copy(=)(=)(=)InfoPropertyBeforeAfterHPX Datetime2021-11-10T19:14:21+00:002021-11-15T12:21:53+00:00HPX Commit71d8dbe40b737be02ea734f9d98fcc0b1e21f01a31bde338f1e8dfdc6cf79daa6146b6d52adf05a2Compiler/apps/daint/SSL/HPX/packages/llvm-11.0.0/bin/clang++ 11.0.0/apps/daint/SSL/HPX/packages/llvm-11.0.0/bin/clang++ 11.0.0EnvfileDatetime2021-11-10T20:28:18.266961+01:002021-11-15T14:25:30.778588+01:00ClusternamedaintdaintHostnamenid00120nid01332Explanation of SymbolsSymbolMEANING=No performance change (confidence interval within ±1%)(=)Probably no performance change (confidence interval within ±2%)(+)/(-)Very small performance improvement/degradation (≤1%)+/-Small performance improvement/degradation (≤5%)++/--Large performance improvement/degradation (≤10%)+++/---Very large performance improvement/degradation (>10%)?Probably no change, but quite large uncertainty (confidence interval with ±5%)??Unclear result, very large uncertainty (±10%)???Something unexpected…

bors merge

bors merge

Following up on the question about if the C++ standard feature checks should be conditional on the standard that is set or not, the answer is: sort of. The changes introduced in this PR are problematic when reconfiguring with a different standard since the variables may stay ON when going down to e.g. 17. Always checking for the features works around that problem. However, in https://github.com/STEllAR-GROUP/hpx-local/pull/2 I've changed the behaviour to allow the feature check to depend on a standard, and if the set standard is too low it will explicitly unset the corresponding variable. See here for the check: https://github.com/STEllAR-GROUP/hpx-local/blob/7acbdc78c6898ed9ec149feea4530708d1bbff54/cmake/HPXLocal_AddConfigTest.cmake#L34-L44.


test_fw_query_on_routes: get first qlog

reverts to previous behavior of getting first qlog: https://github.com/commaai/openpilot/commit/998eb8cde2c81964c883595ee84eeab4172c99ae
@jnewb1 an argument for default seg idx would be nice, just like the default source

@jnewb1 an argument for default seg idx would be nice, just like the default source

Why would you ever want anything except the first segment though? maybe just a "first_segment_only"

Last segment, getting the last liveTorqueParams for example. It just seems more generic

maybe a default slice then, since you also might want the first 2 segments if available


'bool' object has no attribute 'name' when using the image field with parler TranslatableModel

I have a django cabinet custom File that inherits the TranslatableModel something like:
# models.py
class File(TranslatableModel, AbstractFile, ImageMixin):
    FILE_FIELDS = ['image_file']

    # Add caption and copyright, makes FileAdmin reuse easier.
    caption = models.CharField(
        "Interner Titel",
        max_length=512,
        blank=True,
    )

    copyright = models.CharField(
        "Copyright",
        max_length=512,
        blank=True,
    )

    translations = TranslatedFields(
        translated_image_file=ImageField(
            "Übersetztes Bild",
            auto_add_fields=True,
            upload_to=UPLOAD_TO,
            blank=True,
            max_length=1000,
        )
    )

#admin.py

@admin.register(File)
class TranslatedFileAdmin(TranslatableAdmin, FileAdmin):
    top_fields = ["folder", "caption", "translated_image_file"]

    def get_fieldsets(self, request, obj=None):
        res = super().get_fieldsets(request, obj)
        res[0][1]["fields"].append('translated_image_file')
        return res

As hacky as this is, it seems to work. Except when I try to clear the "translated_image_file".
then I get the following erro
  File "python3.9/site-packages/imagefield/fields.py", line 405, in _generate_files
    if previous and previous[0] and previous != (f.name, f._ppoi()):
AttributeError: 'bool' object has no attribute 'name'

f should be an instance of an ImageFieldFile which – in turn – should always have a .name attribute. I'm not sure what is going on here. I do not have any experience with django-parler, maybe the problem has something to do with it?
The code which crashes is only used for clearing old thumbnails. It's nice that django-imagefield tries cleaning up after itself but if this feature proves problematic we could introduce a flag which deactivates this housekeeping. Does everything else work if you deactivate/remove https://github.com/matthiask/django-imagefield/blob/26f126f3a91b94b2e23dbc6b5da86fdb81ed0bee/imagefield/fields.py#L405-L407 ?

AFAIK parler dynamically creates another model that contains all the translations, and then in the admin panel automatically adds widgets for the related table entry in the current language. usually this works very well, but it does some automated stuff in the background which might cause issues.
Everything else seem to work fine though. I'll do some more digging and see if I understand what is going on.

Looks like parler somehow loses the widget and uses the default django image widget. I cannot set the PPOI for the translated image. I feel like it behaves like a regular FileField and loses all "extra features" on clear

That's sad. The django-imagefield widget itself is quite hacky but the activation itself through .formfield(...) isn't https://github.com/matthiask/django-imagefield/blob/26f126f3a91b94b2e23dbc6b5da86fdb81ed0bee/imagefield/fields.py#L355-L363

So I have no idea what exactly is happening behind the scenes but probably managed to work around the issue by adding to the TranslatedFileAdmin class:
    def save_model(self, request, obj, form, change):
        if not obj.translated_image_file:
            obj.translated_image_file = None
        super().save_model(request, obj, form, change)
```


Feat/add tests support all used frameworks

Checklist before requesting a review

[x] I have performed a self-review of my code.
[x] Implemented tests for new features.
[x] I tested the features already implemented.
[x] Added usage examples in the readme.

:tada: This PR is included in version 3.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Utility function to test what is installed

Create utility function to provide a consistent means to test what external commands are installed.
Use the POSIX type utility, which is a builtin in many shells, instead of the popular, but non-standard which.
Signed-off-by: Michael A. Smith<EMAIL_ADDRESS>

Ah, I see this overlaps with #119. Well, I'll leave it in case you want to also merge in the utility function and remove the capturing expressions, too.

Thank you! I'll merge it, and then I'll just update the installed function to use command -v instead (because according to this StackOverflow answer the return code of command is better defined).


Define custom CRD to control the Istio RBAC behavior

The mesh config will be deprecated in the future and we have also decided to introduce a new CRD to control the Istio RBAC behavior.

[x] Remove the RbacConfig from the mesh config.
[ ] Define a new CRD in pilot to allow the control of the Istio RBAC behavior.

cc @liminw  @xiaolanz

I'm fine with it either in mesh config or CRD.


Visual Issues when Adding a CSGBox

Godot 3.1 Beta 9
Windows 10
3D Scene
Add a Spatial
Add a CSG Box
The grid disappears.

The scale also doesn't update in the Inspector when the red dots are changed.

Cannot reproduce on master/beta 10. Looks like this on my end:

Perhaps you zoomed in just the right amount as to see only the box, and it looked like the grid disappearing?

just tested on beta 10.  Same results.

What graphics card (and driver version) are you using?

Surface Pro 2018 i7 16gb ram, Intel Iris Plus 640

Strangely, adding a light fixes this.

Looks to be a driver specific issue that was never reproduced by others. Closing for now.
If you are still encountering this problem in recent versions, I can re-open.


Patch 1

fix #94

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

69 of 71 (97.18%)  changed or added relevant lines in 17 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.07%) to 89.092%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pocketbase/services/utils/crud_service.py
5
6
83.33%

pocketbase/utils.py
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

pocketbase/services/utils/base_crud_service.py
1
87.27%

Totals

Change from base Build<PHONE_NUMBER>:
-0.07%

Covered Lines:
850

Relevant Lines:
924

💛  - Coveralls


Hello! How can I download image data in RPCD?

Hey! Just pushed the downloader, check the instructions here: https://github.com/mediatechnologycenter/aestheval/blob/main/data/DATA.md , but TL:DR, this should do the trick:
python main.py --download_data --dataset_name Reddit --only_images

Let us know if you have any issues!


Enhancement: extend getAllItems with an optional metadata argument

Extend getItems with an optional metadata string argument, where we can pass none (default), minimal and full.
At the moment, only none is implemented.

Assign to me, please ✋

Awesome! Appreciate your help 👏


Fee map

Add a jet for lookup up transaction fees by assetid.

@apoelstra I believe this PR is ready now.  You may want to run it through your CI first to see if it passes all your checks.


error: no such subcommand: tree

I see this: https://github.com/rust-lang/cargo/pull/8062
but for some reason I cannot use it:
$ cargo -V
cargo 1.43.0 (2cbe9048e 2020-05-03)

$ cargo init
     Created binary (application) package

$ cargo tree
error: no such subcommand: `tree`

        Did you mean `new`?

am I doing something wrong? I got Rust from here:
https://static.rust-lang.org/dist/rust-1.43.1-x86_64-pc-windows-gnu.msi

Rust uses a release train model, where it can take 6 to 12 weeks for changes to reach the stable channel. You can read more about it at https://doc.rust-lang.org/book/appendix-07-nightly-rust.html.  cargo tree will be in 1.44 which is now available as beta.  You can also install the old version if you can't use beta (cargo install cargo-tree).


Paragraphs returned from Japanese to English.

After #1414, paragraphs returned from Japanese to English.

ドキュメントの詳細
⚠ このセクションを編集しないでください。 docs.microsoft.com で必須です ➟ GitHub の問題のリンク。

ID: 5b138331-2f10-a05d-7e88-68e62e0b3e4f
Version Independent ID: f923b648-ffe4-8a8a-c189-6e31f1032c10
Content: Microsoft Teams の使用状況レポート
Content Source: Teams/teams-analytics-and-reports/teams-usage-report.md
Service: msteams
GitHub Login: @LanaChin
Microsoft Alias: v-lanac

@officedocsbot assign @officeglobal

@officeglobal Could you please take a look. Thanks!

Working on a fix

@hyoshioka0128 Article has been HumanTranslated and published live. The issue is fixed

@OfficeGlobal Thanks.
Close #1817
https://docs.microsoft.com/ja-jp/microsoftteams/teams-analytics-and-reports/teams-usage-report


Feature Extractor Refactor

Description

This PR changes the default behavior of FeatureExtractor class to leverage models from timm rather than torchvision. By using timm we can easily access the features we care about rather than relying on forward_hooks

Changes

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

Checklist

[X] My code follows the pre-commit style and check guidelines of this project.
[X] I have performed a self-review of my code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have made corresponding changes to the documentation
[X] My changes generate no new warnings
[X] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing tests pass locally with my changes

I made an assumption here that the layers will follow the format of layer<num_of_layer like here
But I can see the DFKDE model uses the key avgpool. What is the preference here? to support anyname or restrict the config to layer<num_of_layer> convention?

Please let me know if this looks good @samet-akcay

Please let me know if this looks good @samet-akcay

@ashishbdatta, there will probably be merge conflicts due to #453. I'll review it anyway, and let you know

I made an assumption here that the layers will follow the format of layer<num_of_layer> like here since so many configs use this convention
But I can see the DFKDE model uses the key avgpool. What is the preference here? to support anyname or restrict the config to layer<num_of_layer> convention?

I'd be in the favour of supporting any layer but it might be tricky with this new design as timm requires layer indices. Because the model isn't initialized, it is hard to know the layer id which corresponds to the name. Here is an idea - Instead of splitting based on layer maybe we can update the config to reflect
 layers:
    - block 1: 1
    - block 2: 2
    - block 3: 3

 layers:
    - avgpool: 4

Since we only need the id, the layer key here might be unnecessary, it would make it readable for the users. As this will be a breaking change we can club this with the CLI upgrade and make it part of the 0.4.x release.

We could do something like
def _map_layer_to_idx(self) -> List[int]:
      idx = []
      # Create temp model to search child nodes
      features = timm.create_model(
                        backbone,
                        pretrained,
                        features_only,
                        )
      for i in self.layers
           # Search children nodes and return index they are found at
           idx.append(list(dict(features.named_children()).keys()).index(i))
      return idx

Only problem is that this would return indices of [4, 5, 6] whereas we need indices of [1, 2, 3] because timm for some reason ignores non-nn.Sequential blocks for selecting indices.
For e.g., in a Resnet18 model they ignore conv1, bn1, maxpool1 in their indexing.

Thanks @ashishbdatta. Looking good!


Allow to lookup using secret name and collection path

Allows getting Bitwarden secrets using the name of the Bitwarden Secret and its location (in a collection) instead of an ID.

Hi @joaogbcravo ,
thanks for the PR. I will merge #19 probably later today, so can you rebase your changes afterwards? Then i can take a look. In general this seems like a great addition. As i am not really using collections maybe you can answer my question if they can not be referenced by id already?

Hey! Thanks for considering merging it.
Items in the collection can be picked using ID already. That's not the "problem".
The problem is: it is not so user-friendly to grab the id from bitwarden user interface and commit it to a git repo. If you have a proper bitwarden organization structured by different collections, referencing them by them is much more user-friendly, as you can commit names to the git repo without knowing its ID à priori.

ah and with #19 , dont forget to bump the versions in the Chart.yaml and write a changelog entry :smile:
i need to write a PR action for that :see_no_evil:

I just rebased and added some more two "features":

Sync vault after unlock (otherwise it can not find new secrets (at least not when looking up by name))
Add the ownerreference on the metadata.

hi @joaogbcravo ,
The periodic sync is something that i had in my mind as well. thanks for picking this up 😃
i will have a more in depth look hopefully tomorrow. What i noticed already is definitely not a patch release anymore. i would suggest to bump the chart by a minor (should be major but as this is still a 0.x release minor should be fine) as it ships a new version of the CRD. The application as well as it ships basically a new feature, which you should mention in the README.

terrible sorry about the delay. i completely missed your ping. having a look right now

Closing because is replaced by https://github.com/Lerentis/bitwarden-crd-operator/pull/73


mitm6: init at 0.3.0

Description of changes
Adds a package for mitm6, a DHCPv6 network spoofing application along the lines of Responder.
Referenced in #81418.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

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

[X] Fits CONTRIBUTING.md.

That is right. Just add yourself in a second commit.

AFAIK Nix is lazily computed, so this shouldn't be a performance impact.

The m,any issues of with are well known. But using it in "one line expressions" is acceptable, while nesting withs is not.

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

2 packages built:

mitm6
mitm6.dist


Django 1.5 get_user_model() breaks aldjemy.

If you use Django 1.5's get_user_model function instead of importing the User class, aldjemy won't add the sa attribute to any models in that module (or modules that are setup after it).
For example:
# Django 1.5 style doesn't work
from django.contrib.auth import get_user_model
User = get_user_model()

Results in:
In [1]: Campaign.sa
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-1-8cad6f5ea5c2> in <module>()
----> 1 Campaign.sa

AttributeError: type object 'Campaign' has no attribute 'sa'

instead of:
# Pre-Django 1.5 style does work.
from django.contrib.auth.models import User

This of course breaks Django 1.5's custom User model implementation.  This effects you even if you aren't using a custom model, since many 3rd party apps are switching to get_user_model() for compatibility reasons.

Cant reproduce it. If it matters for you, please, provide broken test for test_project/sample app.