Deprecate some kinds of doc comments

With the intention of removing them in 2.0.
It is ridiculous how many kinds of comments we have, lets settle on one kind of doc comment and have done. We can make it really easy for people to migrate with tool support. Personally, I would like to keep only ///, but I don't really care as long as we just have one kind.

I remember seeing a similar issue/RFC somewhere already. While I personally do not ever use block comments/doc-comments and would be fine removing them, I do not see how you would document crate without //!?

Please don't remove /* */. It's convenient to quickly comment out code while debugging. Multi-line comments a good thing.

@alfiedotwtf Any decent editor can comment out multiple lines faster than you can type /* */

@gsingh93 No. I can comment out code thousands of lines apart by bouncing in Vim without leaving my keyboard, which in reality only modifies two lines.

I can do the same thing in Emacs without leaving my keyboard, and I'm betting you can do it in Vim as well.

We are talking about doc comments here! I'm guessing @nrc is referring to the little-used /** */ and /*! */ doc comments. Those comments would still work - they just would no longer be recognised as documentation.
:+1: from me (although I would like to see //! remain)

:fire: :skull: Death to /*! :skull: :fire:

I'm :+1: on removing all block comments. We do have a lot of comments, but It'd be weird to remove one kind of doc comments. The symmetry is nice.

-100 for removing non-doc block comments. I don't care much about block doc comments.

:+1: to this RfC. Nobody seems to use the block doc comments. We can land a deprecation lint for this syntax, too.
However, I feel we should keep the inner doc comments (//!) around.
IMO we should not remove regular block comments at all.

I use block doc comments all the time for module/crate level documentation. I think it's a nice convenience. I'm not sure I'd argue strongly to keep them if I'm their sole benefactor though.

:+1: for removing block doc comments

Discussed previously: https://github.com/rust-lang/rust/issues/6782 which was moved to https://github.com/rust-lang/rfcs/issues/287.

I’ve used /*! … */ in doc-comments that contain large code example. It’s really annoying to prefix every line with ///  when writing code. (Auto-indenting the new line on  doesn’t work, for example.)

Block comments vs per-line has always been a hot topic, removing one in favour of the other would be generally unpopular. Maybe dropping either //! /*! / or /// /* */ makes sense but you'd have to keep the option of block comments vs per-line prefix. Most self-respecting languages leave this style choice to the programmer.
Personally I don't think that the current system is particularly confusing, it's perhaps just overly verbose.

@AngusP note that this issue is primarily about documentation comments, not regular ones.

@Manishearth though I'd argue that the same degree of choice should be available in doc comments as regular ones, both for ease of use and to encourage developers to write documentation comments.

My opposition to block doc comments is primarily that the official style guide says not to use them... which basically makes them worthless? Normal block comments are good because they're tools for "make all this code go away for now", but docs are never temporary.

For deprecating doc blocks, against deprecating normal blocks, which I use inline while building stuff out all the time. Against removing //! because it makes documenting modules much more pleasant.

I'm against removing one style (block vs line) of comments in preference to another; I'm also not really bothered by the existence of multiple types of doc comment.

@nrc Please make OP more clear that this issue is only about documentation comments. People are getting confused.

I disagree.
To me, it seems pretty nice how everything stands. Every comment style has a unique, non-replaceable purpose.

Dropping either block or line (documentation) comments now would be pretty unpopular. If Rust never had block comments, it would have been much cleaner because then there would have been just 3 types of comments. It would have been more characters but simpler too. (And it's easier to add stuff than remove, at least in languages)

Having outer and inner documentation comments allows for unambiguously deciphering what is being documented. 4 types of documentation comments felt a little silly to me initially. Soon, I realized having outer and inner doc-comments is in fact useful. Then, because there's 2 styles of comments, there's 2x2 doc-comments.

Removing either form will make it harder for people and tools to decipher what is being documented and it would be rude/not nice to remove either form as they both have documented recommended uses.

If anything will be dropped, please please keep the symmetry. Either drop all of one kind or don't. Having block comments but not block documentation comments will be pretty odd.

RFC-505 has a statement:

Avoid block comments.

Block (documentation) comments are useful as they reduces visual noise in large amounts of text by removing the need for a comment token on every line. While they are recommended against, IMO they are still pretty useful.
Single line (documentation) comments are useful as they add information to every line, marking the line explicitly as a comment. They are also more convenient for short pieces of text.

Off-Shoot Idea: How about some syntactic sugar for #[doc="..."] to make life simpler? Then we could simply drop all kinds of documentation comments and use attributes directly. Just a thought.


Competition creation - Competition formula options (checkbox lisibility)

As labels can break, put them in a full column could be better

376645b7e0989455a8e573a9a2999c5101a92297


ToggleButton Background Property Has No Effect, and Some Other Changes After Upgrading Package

Usage Information
Material.Avalonia 3.7.2, Avalonia 11.1.2, Windows 11 Pro 23H2
Description
I upgraded Material.Avalonia to 3.7.2 and noticed a few problems:

ToggleButtons background becomes transparent
Button class Icon now has background default theme color as background (i changed every usage of class Icon into Mini
SideSheet close button now has background color

Reproduction Steps
For the toggle button:

Create a toggle button with a background

<ToggleButton Background="Red">Toggle Button</ToggleButton>

See the result without no background

For the sidesheet

Create a sidesheet

<controls:SideSheet Name="FiltersSideSheet" SideSheetOpened="{Binding ShowFilters, Mode=TwoWay}"
                            SideSheetDirection="Right" SideSheetContent="{Binding}">

See the result with the close sidesheet button having background

Expected Behavior
Is this expected or intentional? I thought Background would still work on ToggleButton and SideSheet close button would have transparent background.
Actual Behavior
As provided above
Regression?
Previously styled as expected in Material.Avalonia 3.0.2
Known Workarounds
For Button Class Icon i could replace with class Mini, but havent found workarounds for SideSheet.
Update:
Figured to style the border inside template to mimic the background used in previous version.
<ToggleButton
    Margin="4"
    IsChecked="{Binding IsVisible, Mode=TwoWay}">
    <ToggleButton.Styles>
        <Style
            Selector="ToggleButton /template/ Border#PART_RootBorder">
            <Setter Property="Background"
                    Value="{Binding Converter={StaticResource SeriesBackgroundColorConverter}}">
            </Setter>
        </Style>
    </ToggleButton.Styles>
    <TextBlock Text="{Binding Name}"
               TextDecorations="{Binding IsVisible, Converter={StaticResource SeriesStrikethroughApplicant}}" />
</ToggleButton>

Anything else?
No response
Could you help with a pull-request?
No
Is there an existing issue for this?

[X] I have searched the existing issues

I'll take a look, but at least ToggleButtons has a small rework to make it consistent with other buttons, probably it will help: https://github.com/AvaloniaCommunity/Material.Avalonia/pull/375

I'm sorry I dont quite understand, does that mean for the ToggleButton part it is by design?

Update:
I figured that i could style the border inside the template to mimic how backgrounds look in older version
<ToggleButton
    Margin="4"
    IsChecked="{Binding IsVisible, Mode=TwoWay}">
    <ToggleButton.Styles>
        <Style
            Selector="ToggleButton /template/ Border#PART_RootBorder">
            <Setter Property="Background"
                    Value="{Binding Converter={StaticResource SeriesBackgroundColorConverter}}">
            </Setter>
        </Style>
    </ToggleButton.Styles>
    <TextBlock Text="{Binding Name}"
               TextDecorations="{Binding IsVisible, Converter={StaticResource SeriesStrikethroughApplicant}}" />
</ToggleButton>

For the SideSheet button part it seems to be caused by class Icon for button has changed since the previous version, while in the SideSheet the button still uses class Icon for the close button.
Workaround since i couldn't change the class used by sidesheet close button
<controls:SideSheet Name="FiltersSideSheet" SideSheetOpened="{Binding ShowFilters, Mode=TwoWay}"
                    SideSheetDirection="Right" SideSheetContent="{Binding}">
    <controls:SideSheet.Styles>
        <Style Selector="controls|SideSheet#FiltersSideSheet /template/ Button#PART_CloseButton.icon">
            <Setter Property="Background" Value="Transparent" />
            <Setter Property="Foreground" Value="Red" />
            <Setter Property="assists:ShadowAssist.ShadowDepth" Value="Depth0" />
        </Style>
    </controls:SideSheet.Styles>

I'm sorry I dont quite understand, does that mean for the ToggleButton part it is by design?

No, i mean what i've updated ToggleButton styles and probably it can help you resolve your problem. I've still doesn't have time to properly look at the problem (i hope at the weekend i can find some time).

So I have taken a look at #375 and it seems like the background property of ToggleButton isn't used on the PART_RootBorder like it used to. https://github.com/AvaloniaCommunity/Material.Avalonia/commit/70f8eeea9df24ae05d4696224375c6688ee87e4d#diff-7d3e797ee256a1e80943f025db2d39957199c7cd1e329467723cd8dca4c84ee0L26
I don't know if it is intentional but i tried adding that back into Background of PART_RootBorder and it shows the background as expected.
<Border Name="PART_RootBorder"
                Background="{TemplateBinding Background}"

I'm not confident to open a pull request since I haven't yet understood many basic concepts in Avalonia and styling stuff, but if you think that's a correct way then i could help with a (very simple) PR 😄

Yep, seems like this is the right way. Open that PR)

Hi I created the PR https://github.com/AvaloniaCommunity/Material.Avalonia/pull/398 😄
Then the next part is probably for class Icon used in SideSheet that causes the close button to have primay color background..

Thank you very much @SKProCH


Styling issues on error messages for Date Input field

The date input field when in error has the wrong font face

I have not been able to replicate this in testing, no further information from original reporter


Connection not getting reused

Q
A

Bug?
no

New Feature?
no

Version
6.3

Actual Behavior
Too many TCP IP connections are getting created. Active connections are not getting reused even a single guzzle client instance is being used.
Expected Behavior
Connections should be reused and not created for each request.
Steps to Reproduce
I have built a wrapper on top of Guzzle Client. Through this, I set the required headers and request body param. The wrapper holds an instance of Guzzle\Client which is a singleton instance and instantiated once.
$this->httpClient->setupClientInstance();

        $this->httpClient->setRequestBody(
                $data,
                $method == 'get' ? HttpClient::QUERY_TYPE : HttpClient::JSON_TYPE
            );

        return $this->request($url, $method, $options);

public function setupClientInstance() {
       if (isset(self::$instances[$clientKey])) {
            $this->client = self::$instances[$clientKey];
        } else {
            $this->client = new Client($this->options);
            self::$instances[$clientKey] = $this->client;
        }
  }

public function request($url, $method = 'GET', $options = [])
 {
     $options = array_merge($this->options, $options);

     /** Merge the headers */
     $options = array_merge($options, ['headers' => $this->headers]);

     try {
         $this->response = $this->client->request($method, $url, $options);
     } catch (Exception $e) {
         if ($this->withExceptions) {
             throw $e;
         }
     }

     return $this;
 }

When I see the number of open TCP ports it is equal to the number of requests sent.
In the response, I am getting 'Connection: keep-alive'
Am I missing something? How can I reduce the connection count and make persistent connections work in this case?

I find that when I do not set any handler with the client, my connections are getting reused.
//        $this->httpClient->setHandler(RetryHandler::getMiddleware(3, 1000));
Any workaround here? How to reuse connection along with handler?

You simply need to use the same handler in all your guzzle instances.
Closing.. This does not seem to be a bug or a possible bug. For support questions please use the channels listed here https://github.com/guzzle/.github/blob/master/.github/SUPPORT.md


ARROW-13597: [C++][Compute] Remove AddOnLoad helper

These AddOnLoad's constructors can be removed by LTO (which means the factories don't make it to the registry), so make registration more rugged

@github-actions crossbow submit homebrew-r-autobrew

@github-actions crossbow submit homebrew-r-autobrew

@github-actions crossbow submit homebrew-r-autobrew

Just to be clear, the two failing R jobs (autobrew and sanitizer) don't do LTO.

@github-actions crossbow submit homebrew-r-autobrew

@github-actions crossbow submit homebrew-r-autobrew

What's the status of this?

@nealrichardson in short we have a fix which resolves the issue back at https://github.com/apache/arrow/pull/10916/commits/5d5b6465b0700ff8c9ded4abcf7d5db9fef9aa2f but we don't like it because ExecNode factories which are outside libarrow.so won't be automatically loaded- for example "scan" node won't be present until arrow::dataset::Initialize() is called. Most of this PR is me experimenting with ways to keep the registration automatic.


fix: sfc filename in @farmfe/js-plugin-vue

Description:
A fixed filename is used to generate sfc code, causes same filename in vnode and same component name in Devtools.
BREAKING CHANGE:
Related issue (if exists):

Thanks!


Updates for C# 8 needed.

We need this page to be updated for C# 8 and Visual Studio 2019

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

ID: 3d252158-0367-77c8-1816-dbc385c5c40b
Version Independent ID: 575872e5-6273-f8f6-e3e2-2b911cd9d009
Content: The history of C# - C# Guide
Content Source: docs/csharp/whats-new/csharp-version-history.md
Product: dotnet-csharp
GitHub Login: @erikdietrich
Microsoft Alias: wiwagn

Thank you for opening this issue. I'll add it to the backlog.
@BillWagner Not sure if you'll be updating this for C# 8 preview's but this issue can track that work.
Thanks again!

Yes. I'll add the details for the 8 preview and features.
Get Outlook for Androidhttps://aka.ms/ghei36

From: Andy De George<EMAIL_ADDRESS>Sent: Monday, May 6, 2019 9:13:40 PM
To: dotnet/docs
Cc: Utkarsh Bais; Author
Subject: Re: [dotnet/docs] Updates for C# 8 needed. (#12188)
Thank you for opening this issue. I'll add it to the backlog.
@BillWagnerhttps://github.com/BillWagner Not sure if you'll be updating this for C# 8 preview's but this issue can track that work.
Thanks again!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/docs/issues/12188#issuecomment-489668529, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AEM5HT22XS4RBBBQALIYOC3PUBG2ZANCNFSM4HK3E6JQ.

@UtkarshBais Thank you for your commitment to making the docs better 😄 We're going to hold off on this as I we're not sure if we want to add preview information to the release information or wait until C# 8.0 is finished. @BillWagner will handle the updates. Thanks!

Oki doki !
Get Outlook for Androidhttps://aka.ms/ghei36

From: Andy De George<EMAIL_ADDRESS>Sent: Thursday, May 9, 2019 11:24:15 PM
To: dotnet/docs
Cc: Utkarsh Bais; Mention
Subject: Re: [dotnet/docs] Updates for C# 8 needed. (#12188)
@UtkarshBaishttps://github.com/UtkarshBais Thank you for your commitment to making the docs better 😄 We're going to hold off on this as I we're not sure if we want to add preview information to the release information or wait until C# 8.0 is finished. @BillWagnerhttps://github.com/BillWagner will handle the updates. Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/docs/issues/12188#issuecomment-491003178, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AEM5HT32OYTWS7EIYG4HR2LPURQMPANCNFSM4HK3E6JQ.

If you're interested in helping, you can always review the community project where we add issues that we need help. https://github.com/dotnet/docs/projects/35

Oh sure. I'll take a look. Always wanted to contribute. Thanks a ton !
Get Outlook for Androidhttps://aka.ms/ghei36

From: Andy De George<EMAIL_ADDRESS>Sent: Thursday, May 9, 2019 11:35:03 PM
To: dotnet/docs
Cc: Utkarsh Bais; Mention
Subject: Re: [dotnet/docs] Updates for C# 8 needed. (#12188)
If you're interested in helping, you can always review the community project where we add issues that we need help. https://github.com/dotnet/docs/projects/35
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/docs/issues/12188#issuecomment-491006826, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AEM5HT3ZN2D3BKCPRLU2PDTPURRU7ANCNFSM4HK3E6JQ.

Since C# 8 is now released can you guys add it to the docs?


vue-charts hides localization option from the user

Google's library allows you to specify the language in its settings
https://developers.google.com/chart/interactive/docs/basic_load_libs#load-settings
The googleChartsLoader in vue-charts calls google.charts.load(version, options); but doesn't expose the language option in its interface googleChartsLoader (packages = ['corechart'], version = 'current', mapsApiKey = false)

@haydenbbickerton please bump npm version for repo.
language options is on master branch, but not on npm --save version
at master is next configuration, use like:
<vue-chart
  :chart-type="chartType"
  :columns="columns"
  :rows="rows"
  language="pl"
  :options="options"
 />


Blender imports normal maps to PortableCompressedTexture2D creating huge tscn inherited scenes

Tested versions
4.1.3
System information
Windows 10
Issue description
Creating an inherited scene from a glb with a normal map imported from Blender creates a huge file due to storing the normal map as PortableCompressedTexture2D.
Steps to reproduce

Import GLB with a normal map assigned in Blender.
Create an inherited scene from the glb.
The tscn will be around 6x the size.

Minimal reproduction project (MRP)
N/A (I currently don't have an asset to share but I will try and make one and update this).

Related to https://github.com/godotengine/godot/issues/34641.

Is the normal map embedded in the GLB, or is it a separate image file?

Related to Materials generated from .gltf file are too big in filesize #34641.

Is the normal map embedded in the GLB, or is it a separate image file?

It came from the GLB, so it should have been embedded in the glb but a lot smaller using Basis Universal:

As a workaround, save the inherited scene to a binary .scn file, so that its binary data isn't serialized as text (which is larger and slower).

Oh I didn't know scns were different, I'll keep that in mind.

Should I save the textures externally now if I want to keep them as TSCNs?

Yes, TSCN/TRES really aren't designed to embed large amounts of binary data.

Should I save the textures externally now if I want to keep them as TSCNs?

Yes, TSCN/TRES really aren't designed to embed large amounts of binary data.

Actually, this is how the non-normal map textures are stored with embedded setting:

And this is the normal map:

Is this a bug?

I just noticed an interesting debugger message:


Feature Request: Separator Support in Activity Bar for Icon Grouping

Feature Description:
I am proposing a feature for the Visual Studio Code Activity Bar that would allow users to group icons using separators. This would enhance the organizational capabilities of the Activity Bar by visually distinguishing between different sets of tools or extensions.
Current Limitation:
At present, all icons on the Activity Bar are uniformly spaced without the ability to insert dividers or groupings. I found a workaround using an extension that adds icons designed as dashed horizontal lines to act as separators. However, this approach has limitations:

The separator icons occupy the space of a full icon, leading to inefficient use of space and visually unappealing gaps between actual tool icons.
The spacing between these makeshift separator icons and adjacent tool icons remains large, disrupting the visual flow.
These separators do not dynamically show or hide based on the presence of icons from specific groups (e.g., showing only when related extension icons are active), leading to situations where separators may cluster together without any icons between them, which is aesthetically displeasing and confusing.

Suggested Feature:

Dynamic Separators: Introduce the ability to add separators in the Activity Bar that do not occupy the full space of an icon and can dynamically appear or disappear based on the grouping of active icons.
Customization Options: Allow users to define groups of icons that can be visually separated on the Activity Bar. This includes specifying which icons belong to a group and potentially customizing the appearance of the separators.

Conclusion:
The ability to group icons with separators in the Activity Bar would be a significant usability enhancement for VSCode. It addresses the limitations of current workarounds and provides a more organized and visually appealing interface. I hope the VSCode team will consider this feature for future updates.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


Check .git in formatter progress checkouts for build

From the formatter progress CI logs:
2023-08-07T03:49:02.5178602Z + mkdir -p /home/runner/work/ruff/ruff/target/progress_projects
2023-08-07T03:49:02.5193474Z + '[' '!' -d /home/runner/work/ruff/ruff/target/progress_projects/build ']'
2023-08-07T03:49:02.5194228Z + '[' '!' -d /home/runner/work/ruff/ruff/target/progress_projects/django ']'
2023-08-07T03:49:02.5194966Z + git clone --filter=tree:0 https://github.com/django/django /home/runner/work/ruff/ruff/target/progress_projects/django
2023-08-07T03:49:02.5209260Z Cloning into '/home/runner/work/ruff/ruff/target/progress_projects/django'...

2023-08-07T03:51:17.4726088Z 2023-08-07T03:51:17.472404Z ERROR Failed /home/runner/work/ruff/ruff/target/progress_projects/build: no python files in ["/home/runner/work/ruff/ruff/target/progress_projects/build"]

Seems that build exists but is an empty cached folder. These changes should fix this by a) checking for .git instead of just the folder existing b) running the commit checkout unconditionally. The latter is also important if we ever want to update the SHAs.

The CI failure is unrelated, this fixes the problem with build it was intended to fix

Do we know what's caching the folder in the first place? Because I didn't see any caching configuration related to it.

i don't know what caused this intially

I think it does clean "Anything that is not a dependency.", it's just that build looks like something that needs to be cached (https://github.com/Swatinem/rust-cache/blob/b919e1427f59422679cf2ed5fc6ddc010f753026/src/cleanup.ts#L37)


Feature/801 deployment

Created scripts for the 8.01 deployment. Basically just copied all the prod stuff over, replaced prod with prod-801 and then double checked that all the replacements were correct.

Do not merge until #77 is resolved


rkt fly panic

$ sudo ./rkt run --interactive --insecure-options=image --stage1-path=./stage1-fly.aci --volume data,kind=host,source=/mnt,readOnly=false --mount volume=data,target=/mnt docker://fedora --exec /bin/bash
image: using image from file ./stage1-fly.aci
image: using image from local store for url docker://fedora
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x404013]

goroutine 1 [running]:
main.evaluateMounts(0xc8200b73b0, 0x26, 0xc8200c2420, 0x6, 0xc82001a540, 0x0, 0x0, 0x0, 0x0, 0x0)
	/opt/build-rkt/gopath/src/github.com/coreos/rkt/stage1_fly/run/main.go:125 +0x1d83
main.stage1(0xc8200c2020)
	/opt/build-rkt/gopath/src/github.com/coreos/rkt/stage1_fly/run/main.go:248 +0xa65
main.main()
	/opt/build-rkt/gopath/src/github.com/coreos/rkt/stage1_fly/run/main.go:367 +0xaa

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
	/usr/lib/go/src/runtime/asm_amd64.s:1721 +0x1

imApp is dereferenced without checking for nil: https://github.com/coreos/rkt/blob/master/stage1_fly/run/main.go#L125
When the image "docker://fedora" is converted to ACI, its manifest does not have an "app" section:
$ sudo rkt image cat-manifest --pretty-print sha512-44387804be54 | grep '"app":'
$

The image "docker://busybox", however, has an "app" section:
$ sudo rkt image cat-manifest --pretty-print sha512-c4a1753aa990
...
	"app": {
		"exec": [
			"sh"
		],
		"user": "0",
		"group": "0"
	},

That explains why it works on busybox but not on fedora.

Aha.
Well, anyway; good to know I have a workaround for the moment :)


⚠ Auth has degraded performance

In 7eb3a6a, Auth (https://auth.k2lin.com) experienced degraded performance:

HTTP code: 200
Response time: 2419 ms

Resolved: Auth performance has improved in 4d04195.


Truly multi-view datasets

In the paper, your method is motivated by learning from multiple views of the same dataset.  You've done experiments where you use data augmentation to create multiple synthetic views of the same training images, but have you done experiments / do you have thoughts on the best way to do experiments on datasets that are truly multiview?
I'm thinking something like

adjacent frames in a video
two images taken from different angles

Do you think you'd still want to maximize mutual information between the global descriptor of view A and local descriptors of view B?  Or would it make more sense to just maximize MI between the global descriptors of the views?
Thanks!

I think maximizing MI between higher and lower level features still makes sense in this case. When the InfoNCE matching/scores are computed in a relatively high-dimensional space (compared to the eg 128d/256d spaces used in most current contrastive rep learning code), rather complicated conditional distributions over the lower level features can be captured by the simple "dot products and softmaxes" approach. For more insight, see e.g. "Breaking the Softmax Bottleneck: a High Rank RNN Language Model" -- https://arxiv.org/abs/1711.03953


Update coil from 1.0.0-rc3 to 1.0.0

Updates coil to 0.10.0.
Changelog: https://github.com/coil-kt/coil/blob/master/CHANGELOG.md#100---october-22-2020

@thatfiredev  I knew I remembered that username from somewhere! ;)


Improve BodyParser API documentation

Description

Motivation and Context

How Has This Been Tested?

Checklist:

[x] I have submitted a CLA form
[x] If applicable, I have updated the documentation accordingly.
[x] If applicable, I have added tests to cover my changes.

Codecov Report

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

@@           Coverage Diff           @@
##           master    #1186   +/-   ##
=======================================
  Coverage   87.01%   87.01%
=======================================
  Files          38       38
  Lines        2249     2249
=======================================
  Hits         1957     1957
  Misses        292      292

Flag
Coverage Δ

#Kitura
87.01% <ø> (ø)
:arrow_up:

Impacted Files
Coverage Δ

Sources/Kitura/bodyParser/BodyParser.swift
81.15% <ø> (ø)
: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 b7e4a66...c7fc669. Read the comment docs.


NIFI-12634 Ignore Blank Prefix Values in Kubernetes Components

Summary
NIFI-12634 Updates KubernetesConfigMapStateProvider and KubernetesLeaderElectionManager to ignore blank prefix values as provided in default configuration files.
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[X] Apache NiFi Jira issue created

Pull Request Tracking

[X] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[X] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[X] Pull Request based on current revision of the main branch
[X] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[X] Build completed using mvn clean install -P contrib-check

[X] JDK 21

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

Thanks for the fix @exceptionfactory! Code and unit tests look good. +1 will merge.


Hyphen(-) issue

Hyphen(-) in markdown should be show as a list, i think we should escape hyphen(-) to "-", otherwise  after converted, hyphen(-) will be show as a list, but i expected only a normal hyphen(-), not list.

Hello @cainianhua, thanks for your suggesting.
I'm not sure I got your problem already. Can you describe it with some code examples please?
For me the following looks like the expected behavior:
> ReverseMarkdown.convert 'foo-bar' => "foo-bar\n\n"
> ReverseMarkdown.convert '
foo-bar
' => "- foo-bar\n"

Is there something I'm missing?

Sorry for that, i lost a important condition, Hyphen(-) should be in the beginning, like that:
ReverseMarkdown.convert('-test') #=> -test\n

I expected the result should be \\-test\n in this case, otherwise, it will show in page like this:

test

But I only want to show as original value, like that:
-test

@cainianhua That sounds more like a problem of the markdown implementation you're using. In Redcarpet (a very common ruby implementation) the following works quite like expected:
irb(main):004:0> Redcarpet::Markdown.new(Redcarpet::Render::HTML).render('-test')
=> "
-test
\n"

Maybe you misunderstand my meanings, actually, I just have a html fragment, like this:

-test

After called convert:
ReverseMarkdown.convert('

-test

') #=> -test\n\n

It will display as list, like that:

test

But i only want to show as a plain text, like this:
-test

Hello @cainianhua
I understand your example, but I think you're jumping to the wrong conclusion.
Which markdown converter do you use to transform -test\n\n back into HTML?
In Redcarpet (https://github.com/vmg/redcarpet) the result would be what you expected:
-test
\n
I think the markdown converter you're using has a bug and shouldn't create a list from the given string.
Do you agree with my analysis or am I missing something?

Test string should be

- test

 (with a space between - & test). This issue makes perfect sense to me.

Hi @sdhull,
please let me know what the expected result for the input you provided is.
You won't be able to get the exact HTML that you provided in a full round trip though. The
 will always be lost, because markdown has no representation for it.
So from my point of view this conversion looks OK:
ReverseMarkdown.convert "

- test

"
=> "- test\n\n"

If the HTML contains markdown formatted content, like in this example the list item, this content will inevitably be transformed at some point.
Even if we managed to spot those cases and escape them, markdown renderers would not care anyway:
md.render "\- foobar" # use redcarpet
=> "
\n
foobar
\n
\n"

Ohhh I see. Well in that case, I'd suggest closing this issue.
It might be worth adding a "Limitations" section to the readme pointing out that if the HTML you're converting to markdown has markdown-formatted text (text that would be interpreted by markdown parsers as lists, headers, hr's, etc), then a "roundtrip" (eg converting from html to markdown back to html) will inevitably produce a different result than what you started with.
On a somewhat related tangential note, I'd love to be able to turn off escaping of node text altogether (considering it only escapes * & _, it cannot be considered complete and as you point out -- redcarpet ignores escaping in some circumstances anyway). But that's another issue. I could submit a PR for it even.

@sdhull Sounds good, I'd be happy to merge any PR to improve documentation.


Autoclicker: Add version <IP_ADDRESS>

Created a manifest for Autoclicker
A full-fledged autoclicker with two modes of autoclicking, at your dynamic cursor location or at a prespecified location. The maximum amounts of clicked can also be set (or left as infinite).
Judging by weekly downloads, I'm surprised no one suggested it already:
https://sourceforge.net/projects/orphamielautoclicker/files/stats/timeline
Unsure if autoupdate is needed. What do you think?

[X] I have read the Contributing Guide.

/verify

I think autoupdate is not needed. The last update was 2019.


Code modifications in the 2nd round review of JOSS paper.

We are collecting all possible code modifications here during the 2nd round of JOSS paper review, and will have another release once the paper is finalized.

@nbwuzhe also need to include the fix in plot_reconstruction

@nbwuzhe also need to include the fix in plot_reconstruction

The signature of plot_reconstruction is correct. Just the script has an scrubbed argument when calling it, which has been fixed in the same commit.

@nbwuzhe I missed that, but it makes sense now. Thanks for fixing those issues and thanks @felixhorger for bringing them up to us


Rename some options to improve clarity and intent of them

lock -> shouldLock
poll -> pollFrequency
retry -> retryPolicy

Codecov Report
Attention: Patch coverage is 94.73684% with 1 line in your changes missing coverage. Please review.

Project coverage is 82.96%. Comparing base (ffde4c2) to head (c3aa5f6).

Files
Patch %
Lines

lib/core/execution.ts
75.00%
1 Missing :warning:

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #131   +/-   ##
=======================================
  Coverage   82.96%   82.96%
=======================================
  Files          22       22
  Lines        1186     1186
  Branches      311      311
=======================================
  Hits          984      984
  Misses        202      202

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

Will merge, I don't think this is a controversial change, we can always revert if stuff goes wrong.


Remove all Catena-X (NG) references

This issue tracks the removal of all occurrences of CatenaX-ng in this repository as part of the broader goal to deprecate this organization.

[ ] Search for Catena-X (NG) in code, configuration, and documentation.
[ ] Remove or adapt references accordingly.
[ ] Close this issue once zero references remain.

Use this query to track your progress (overall): GitHub Search Query
This query should display only results in related repository
Work summarized in https://github.com/eclipse-tractusx/sig-release/issues/838

Only mentioned in docs https://github.com/search?q=repo%3Aeclipse-tractusx%2Ftractus-x-umbrella catenax-ng&type=code


custom/script module with tail causes a lot of CPU wakeups

Describe the issue
Using the custom/script module with tail = true will cause the CPU to wake up 40 times a second even if there is no new output from the script.
Expected behavior:
Resources are only consumed when there is work to be done. Polybar is actually very efficient as far as CPU time goes, but all of the polling does not bode well for the battery life as it prevents the CPU from going into deeper sleep states.
Actual behavior:
CPU is woken up 40 times a second with nothing to compute.
To Reproduce
[bar/top]
width = 100%
height = 34
background = #00000000
foreground = #ccffffff
modules-right = nothing

[module/nothing]
type = custom/script
exec = cat
tail = true

Then start powertop to monitor the CPU wakeups.
Polybar Log
gunca@Guntars ~$ polybar -l trace top
* Loading config: /home/gunca/.config/polybar/config
- config: Current bar section: [bar/top]

* Loaded monitor eDP1 (1920x1080+0+0)
* Bar geometry: 1920x34+0+0; Borders: 0,0,0,0
- bar: Attach X event sink
- bar: Attach signal receiver
- controller: Install signal handler
- controller: Setup user-defined modules
* Starting application
- controller: Main thread id = 1
* Starting module/nothing
* Entering event loop (thread-id=1)
* module/nothing: Invoking shell command: "cat"
* Eventqueue worker (thread-id=2)
- bar: Create renderer
- renderer: Get TrueColor visual
- renderer: Allocate colormap
- renderer: Allocate output window
- renderer: Allocate window pixmaps
- renderer: Allocate graphic contexts
- renderer: Allocate alignment blocks
- renderer: Allocate cairo components
- renderer: Load fonts
* Configured DPI = 96x96
warn: No fonts specified, using fallback font "fixed"
* Loaded font "fixed" (name=Noto Sans, offset=0, file=/usr/share/fonts/noto/NotoSans-Regular.ttf)
* Bar window: 0x2400001
- bar: Reconfigure window
- bar: Set window WM_NAME
- bar: Set window _NET_WM_WINDOW_TYPE
- bar: Set window _NET_WM_STATE
- bar: Set window _NET_WM_DESKTOP
- bar: Set window _NET_WM_PID
- bar: Map window
- bar: Draw empty bar
- bar: Setup tray manager
* Disabling tray manager (reason: missing `tray-position`)
* module/nothing: Rebuilding cache
- bar: Force update
* Redrawing bar window
- bar: Received expose event

Environment:

WM: Metacity
Distro: Arch
Output of polybar -vvv:

polybar 3.4.0

Features: +alsa +curl -i3 -mpd +network(libnl) +pulseaudio +xkeyboard

X extensions: +randr (+monitors) +composite +xkb +xrm +xcursor

Build type: Release
Compiler: /usr/bin/c++
Compiler flags: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -Wall -Wextra -Wpedantic -O3 -DNDEBUG
Linker flags: -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now

Additional context
This is the likely culprit https://github.com/polybar/polybar/blob/fe7dc28b07afe949ee2e0fae625e2e0d456d0185/src/modules/script.cpp#L37 though I'm not a systems programmer and plead ignorance.

I will take a look at that asap.

It might be hard to improve the situation. I might have a solution but I need to modify a little bit how we stop the modules.
If one of the thread is blocked on a poll, the module can't be stopped. I'll publish my PR soon.

Thanks for looking into it - I just came to the same conclusion. As a workaround I changed the poll timeout to 3000ms and it's working OK for me. The deconstruction of the module can take that much, but I'm fine with that.

Is there any news on this? Where can I change the poll timeout?


[sw, dif_pinmux] Introduce DIF Pinmux header

Introduction
Please note that this is a reworked version of the following PRs:
https://github.com/lowRISC/opentitan/pull/2042 (PadCtrl)
https://github.com/lowRISC/opentitan/pull/1763 (Pinmux)
This is due to major changes in hardware - PadCtrl and Pinmux have
been merged into one (Pinmux).
Please note that all of the PadCtrl functionality was written by Greg
Chadwick, and was copied into this change with some minor naming
changes.
Decisions

I have consolidated the lock functionality into a single function to avoid maintaining 4 copies of lock and lock_get functions.
I have followed Greg's approach in the above mentioned PadCtrl change, and consolidated all MIO and DIO function pairs a single function (sleep configuration and pin attributes setting are done in two functions instead of 4). It makes it easier from reviewers and maintenance point.
In the original PadCtrl change Greg had an additional function enable to dif_padring_write_attrs, but I think that write alone should be sufficient.

@msfschaffner thanks! Much appreciated, I will fix up your suggestions next time I am working on the header!

I also think the wakeup detector interface functions are still missing.

@msfschaffner - completely missed your comment, and the wake-up functionality, sorry.
I think I should add the wake-up functionality now.

The latest push has the following changes:

Complete wake-up functionality
dif_pinmux_<insel,outsel>_t types have been removed, and the generic dif_pinmux_index_t type is used instead. Rationale is that instead having numerous uint32_t typedefs - have a generic uint32_t index and document the meaning thoroughly in the API that uses it.

Wake-up API
It feels more ergonomic to split the detector enable functions into edge and timed. This is done similarly to the AES DIF, when we have different operation modes covered by the same configuration register, but have a separate start/end function for every mode.

I've had another look through with the wakeup changes, and it seems OK to me. Splitting the API for timed vs edge detection seems fine to me, though I'm not sure I'd be objecting if they weren't split.
@gkelly: could you please take a look and confirm you're happy with the wakeup APIs that have been added.

I've had another look through with the wakeup changes, and it seems OK to me. Splitting the API for timed vs edge detection seems fine to me, though I'm not sure I'd be objecting if they weren't split.

This way seems a bit clearer to me. The initial way I was doing it - having a single configure routine, but then dependent on what mode you use, you would need to call an additional function that sets PINMUX.WKUP_DETECTOR_CNT_TH_<N>. It is not the end of the world and can be documented, but to me the way I have done it is cleaner.

That's a good point, thanks for elaborating.
[Sidenote: I know there's already a lot of work in putting the header up for review, but I did wonder if we might finalise review faster if we encouraged a little more information transfer - having written the header you obviously put thought into all sorts of options. Your current PR description lists some of the decisions made. Perhaps having a listing like that and keeping it up to date as the PR evolves is something we might think about for future PRs.]

[Sidenote: I know there's already a lot of work in putting the header up for review, but I did wonder if we might finalise review faster if we encouraged a little more information transfer - having written the header you obviously put thought into all sorts of options. Your current PR description lists some of the decisions made. Perhaps having a listing like that and keeping it up to date as the PR evolves is something we might think about for future PRs.]

I think it is a good idea, we probably could even put together a GitHub PR template - at least for SW side.

A note about the PR description discussion: I'd personally appreciate that sort of thing in the commit messages as well. Since a clone of the repository doesn't contain PR discussion threads, it's probably good to have anything that explains the commits bundled in with them. I guess the best possible thing to do is to update notes in commits each time you rebase, and mirror them in the PR. Of course, that's quite a hassle...

A note about the PR description discussion: I'd personally appreciate that sort of thing in the commit messages as well. Since a clone of the repository doesn't contain PR discussion threads, it's probably good to have anything that explains the commits bundled in with them. I guess the best possible thing to do is to update notes in commits each time you rebase, and mirror them in the PR. Of course, that's quite a hassle...

I guess if we do it at commit point, then as long as people read the commit message they would have them at the PR level as well.


Missing zero_grad() call

Description
It seems like the first two examples (examples/01_simple_layer.py and examples/02_multiple_layers.py) are missing a call to opt.zero_grad() at each iteration. When running on 10 iterations currently the loss decrease then increase again:
Loss error: 1.0298337936401367
Loss error: 0.8178885579109192
Loss error: 0.4703792631626129
Loss error: 0.1962183117866516
Loss error: 0.0619336031377316
Loss error: 0.0884876772761345
Loss error: 0.2775749266147614
Loss error: 0.5320941805839539
Loss error: 0.7531698346138000
Loss error: 0.8695605397224426

How to reproduce
Run examples/01_simple_layer.py or examples/02_multiple_layers.py (it is more noticeable on 10 iterations than 100).
Expected behavior
The loss should decrease consistently, as when opt.zero_grad() is added:
Loss error: 1.1083202362060547
Loss error: 0.3732085227966309
Loss error: 0.1592179238796234
Loss error: 0.0920740887522697
Loss error: 0.0612552836537361
Loss error: 0.0359693244099617
Loss error: 0.0363772809505463
Loss error: 0.0245949663221836
Loss error: 0.0224329363554716
Loss error: 0.0218768958002329

Other information
simply adding opt.zero_grad() after each opt.step() should be sufficient to solve this.

Thanks @PierreTsr,
you are right, many thanks. I noticed that also, but forgot to change it. Will do.


Trace trait is not object-safe

The current Trace trait is not object-safe, so it can’t be used with trait objects:
trait Foo: Trace {
    fn foo(&self);
}

#[derive(Trace)]
struct AnyFoo(dyn Foo);

Could it be made object-safe by turning the associated constants into functions and moving the V: GcVisitor type parameter of Trace::visit<V> up to Trace<V>::visit?

Oh man :frowning_face:  Based on my experiments today, this is hard to do right.
I really don't want to parameterize Trace like Trace<V: GcVisitor>.
I've played around with having a separate set of DynTrace and DynGcVisitor taits (kind of like erased-serde) but its hard to write blanket impls over regular Trace/GcVisitor traits because they expect statically visible type info.
I'm starting to think maybe I should go closer to the approach you suggested and modify Trace and GcVisitor to be object safe directly.
I really want to keep support for NEEDS_TRACE, but that is hard to do since associated constants aren't supported on trait objects :frowning: There is no way to add a special where Self: Sized bound. Maybe I can move it to a separate trait and then specialize?
Kind of just throwing out random suggestions here. This project is still a little experimental :smile: :wink:
This is related to #16 because both arrays and trait objects are ?Sized.

The new Pointee type and the nightly ptr_metadata API may significantly change this. (See rust-lang/rust#81513)
I'm hesitant to refactor the API design to depend so heavily on a nightly feature, however that may be the only way I can reasonably implement this feature.
In practice, however, zerogc is already limited to nightly because the simple collector requires nightly (although this is mostly for convenience at this point).


📃:  Pangram Checker Game

:red_circle: Title :  Pangram Checker Game
:red_circle: Aim :  Check whether it is pangram or not
:red_circle: Tech Stack Used :  HTML , CSS
Screenshots 📷

:white_check_mark: To be Mentioned while taking the issue :

Full name :  Damini Chachane
What is your participant role? GSSOC

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎

no games allowed


Consider switching to libflate

inflate crate is only used by png, with no other high-profile users. Everybody else uses either libflate or flate2 crates, since they're much faster and have better compatibility.
Since version 0.1.25 libflate carries just one trivial unsafe block (I've killed off everything else), so its safety story is as good as inflate. There seems to be no reason not to switch.

It would be fine for decoding. For encoding however, libflate doesn't have many options for compression levels, and can't compress as well as the currently used deflate and flate2. We may want to keep deflate for encoding for now (has no unsafe use in the latest release), or alternatively swap to using flate2 for everything once the unsafe bits of the encoder and api bridge in miniz_oxide have been removed or thoroughly checked for soundness.

Thanks for the mention, I certainly was not aware of libflate and it seems to be progressing rather speedily. Its development seems (from commit log) focussed on decoding right now, not necessarily a bad thing. Imo, having upsides and downsides in both crates is a good result of competing implementations. Using both has a tradeoff of build time and should be an implementation details (with no public features) to not be confusing. Also, if anyone spot ways to improve libflate maybe we get the best of both worlds?

I concur with keeping deflate for encoding, at least for now. However, for decoding inflate seems to be strictly inferior than the alternatives at this point. I've updated the title to make it more clear.

miniz_oxide (the Rust backend for flate2) has been making great strides in terms of safety lately, and it is much faster than both inflate and libflate. It's now a viable contender. However, some of the (upcoming) safety improvements are going to require Rust 1.34

Given that image has switched to 1.34 as well that should be no problem.

miniz_oxide (the Rust backend for flate2) is now 100% safe, forbids unsafe code, and is 2.5x faster than libflate. There is an even bigger gap compared to inflate. It also does both encoding and decoding.
There is still some unsafety in flate2 even when using miniz_oxide backend, and potentially devastating one too, so I believe the best bet is to use miniz_oxide directly.

I'm having trouble integrating miniz_oxide as stream decoding is not supported. It's not as simple as switching the inflater class as inflate does all the necessary internal buffering. It also needs no explicit indication for EOS (although I'm not sure how it does that) which is a problem insofar as PNG allows an arbitrary number of consecutive IDAT chunks containing compressed data, sliced at arbitrary positions within the compressed byte stream. Properly detecting the end of the image data requires some work on the internal state machine.
Integration work in this branch: https://github.com/image-rs/image-png/tree/miniz-oxide

Note: It's currently failing tests due to panic! within miniz_oxide:

tests/pngsuite/PngSuite.png: thread 'render_images' panicked at 'index out of bounds: the len is 65536 but the index is 65536', /home/andreas/.cargo/registry/src/github.com-1ecc6299db9ec823/miniz_oxide-0.3.3/src/inflate/core.rs:761:34
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   6: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
   7: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:384
   8: rust_begin_unwind
             at src/libstd/panicking.rs:311
   9: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
  10: core::panicking::panic_bounds_check
             at src/libcore/panicking.rs:61
  11: miniz_oxide::inflate::core::transfer
             at /home/andreas/.cargo/registry/src/github.com-1ecc6299db9ec823/miniz_oxide-0.3.3/src/inflate/core.rs:761
  12: miniz_oxide::inflate::core::decompress_inner
             at /home/andreas/.cargo/registry/src/github.com-1ecc6299db9ec823/miniz_oxide-0.3.3/src/inflate/core.rs:1545
  13: miniz_oxide::inflate::core::decompress
             at /home/andreas/.cargo/registry/src/github.com-1ecc6299db9ec823/miniz_oxide-0.3.3/src/inflate/core.rs:1030
  14: png::decoder::stream::ZlibStream::decompress
             at src/decoder/stream.rs:705
  15: png::decoder::stream::StreamingDecoder::next_state
             at src/decoder/stream.rs:395
  16: png::decoder::stream::StreamingDecoder::update
             at src/decoder/stream.rs:200
  17: png::decoder::ReadDecoder::decode_next
             at ./src/decoder/mod.rs:146
  18: png::decoder::Reader::next_raw_interlaced_row
             at ./src/decoder/mod.rs:471
  19: png::decoder::Reader::next_interlaced_row
             at ./src/decoder/mod.rs:285
  20: png::decoder::Reader::next_row
             at ./src/decoder/mod.rs:273
  21: png::decoder::Reader::next_frame
             at ./src/decoder/mod.rs:264
  22: check_testimages::render_images::{{closure}}
             at tests/check_testimages.rs:72
  23: check_testimages::process_images
             at tests/check_testimages.rs:29
  24: check_testimages::render_images
             at tests/check_testimages.rs:68
  25: check_testimages::render_images::{{closure}}
             at tests/check_testimages.rs:66
  26: core::ops::function::FnOnce::call_once
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libcore/ops/function.rs:235
  27:  as core::ops::function::FnOnce>::call_once
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/liballoc/boxed.rs:787
  28: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  29: std::panicking::try
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libstd/panicking.rs:275
  30: std::panic::catch_unwind
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libstd/panic.rs:394
  31: test::run_test::run_test_inner::{{closure}}
             at src/libtest/lib.rs:1408
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

flate2 provides a higher-level wrapper on top of miniz_oxide that allows more convenient stream decoding. However, flate2 creates buffer of uninitialized memory as the output, and not overwriting that buffer fully could be a devastating security vulnerability for an image decoder. Perhaps flate2 could optionally zero-initialize the buffer for high-assurance use cases?

Also that panic is very cool because I've fuzzed miniz_oxide and couldn't find any panics. Please report it on the issue tracker!

The use of the wrappers from libflate likely requires some larger reworks. It consumes some wrapped BufRead and consequently interprets an empty input buffer as eof. We would need to keep reading more PNG chunks to check if there is more data to refill the input buffer. Communicating via an io::* interface also means io::Error everywhere instead of differentiating between corrupt stream and real io errors.

Also that panic is very cool because I've fuzzed miniz_oxide and couldn't find any panics. Please report it on the issue tracker!

Currently uses the inflate::core interface directly instead of relying on decompress_to_vec. I think this was not covered by any fuzzing yet.


Decide on structure of solution and API surface

Since we're starting to get the ball rolling on porting all the major features from Go, I think it's time to start discussing how we should structure the solution (files, directories, projects, etc) and also the API surface (packages, naming conventions, namespacing, etc).
To me, the main challenge is that there are two desirable goals that can conflict:

The API surfaces in .NET and Go should be as similar as possible
.NET and Go have different conventions and capabilities

Some concrete questions to get the discussion started:

Should the structure of the NuGet packages map 1-to-1 to the structure of the Go packages? Importing Go packages is a lot more lightweight than importing NuGet packages, both due to different versioning strategy and due to the standard tooling. Having a granular separation of packages has a lot of value, but maintaining installs/upgrades of all packages in a .NET solution can have a tendency to be a bit painful.
Go lacks namespaces - in C# code they are often abundant. Should we keep the flat structure of the Go API or should certain things be moved into sub-namespaces?
In Go, non-receiver functions are accessed through <package>.<function>, e.g. actor.Spawn(). The closest emulation of this in C# is static methods. This can cause internal conflicts with package/namespace names. E.g. if you have a namespace Proto.Actor containing a static class Actor, it will have to be referenced as Actor.Actor. Shouldn't cause issues for user-code, but might be a bit messy internally.
Go doesn't have classes or constructors - structs are created through "factory" functions, e.g. mailbox.NewBoundedProducer(). Should we keep this pattern/naming convention to make the APIs identical, or should we instead use class constructors, e.g. new BoundedMailboxProducer()?
In Go, there is only one way to access a field on the underlying struct of an interface - through receiver functions defined on the interface, e.g. context.SetReceiveTimeout() or context.ReceiveTimeout(). In C# this could be implemented with a non-automatic property context.ReceiveTimeout for both get/set; or with an automatic property with a private setter and a public context.SetReceiveTimeout() (if you don't want complex logic inside the setter); or with a private field and both a context.GetReceiveTimeout() and a context.SetReceiveTimeout() method. How should we value idiomaticity vs. consistency?

Some initial thoughts:
It's not important to follow the API of Go in C# in a verbatim way. as long as the concepts are the same, its all fine.
I'm all for being idiomatic, driving adoption would be hard if the API feels alien.
My vote goes to ".NET and Go have different conventions and capabilities"
The only really important aspect is that the proto contracts and the named base actors are present in both C# and Go.

Should the structure of the NuGet packages map 1-to-1 to the structure of the Go packages?

As you point out, importing stuff in Go is easier.
IMO, it would make little sense in having mailboxes as a separate library in .NET.
(I'm undecided on Routing, it might OK or it might be too fine grained to have that in a separate lib)

Go lacks namespaces - in C# code they are often abundant. Should we keep the flat structure of the Go API or should certain things be moved into sub-namespaces?

Let's go for what is most idiomatic. in .NET you can have circular deps between namespaces, in Go you can only have your flat package and sub packages.
Not sure how that should look or what goes where on the top of my head.

In Go, non-receiver functions are accessed through ., e.g. actor.Spawn(). The

IMO, Actor.FromProducer and Actor.Spawn reads sort of nice. but that shouldnt really be an argument for having code with conflicts.
We could do what the TPL does, use Actors as the namespace and Actor as the Static API.
maybe even make Proto the root namespace so we have

Proto
Proto.Actor (API)
Proto.Actors (related types, Props and what not)
Proto.Mailbox (API)
Proto.Mailboxes (impls)

Not sure if that is a good idea, just throwing stuff out there :-)

In Go, there is only one way to access a field on the underlying struct of an interface - through receiver

As this code has real side-effects like spinning up a timer, I would like to avoid a property setter for it.
Having a SetReceiveTimeout(..) makes readers see that this might be more than just mutating a value.
But we could absolutely have a ReceiveTimeout get prop to read and reason about the timeout.
Not sure I actually answered anything :-P but lets brainstorm a bit and try to come up with something that will work long term for the API

I'm all for being idiomatic, driving adoption would be hard if the API feels alien. My vote goes to ".NET and Go have different conventions and capabilities"

I too am going to vote in favor of this approach. Regardless of the community, whether it be .NET or Go, adoption is definitely driven up by familiar patterns and following idioms. If the core concepts and tenants are familiar between implementations, we'll be in great shape.
Great discussion!

Cool, we all agree on idiomaticity over consistency then :)

as long as the concepts are the same, its all fine

Perhaps it would be good to clearly define what the concepts are - somewhat like a glossary? Would be useful both for documentation and for keeping an eye on whether the APIs diverge in a way they shouldn't. Random idea: it would be great to have language-agnostic documentation based around these core concepts, with examples in both languages. Thoughts?

IMO, it would make little sense in having mailboxes as a separate library in .NET.

Not necessarily - there could be use-cases where you want just an asynchronous mailbox without a full actor system. E.g. the Zipkin tracing stuff we've been working on where we do use a mailbox to collect spans :)

Actor.FromProducer and Actor.Spawn reads sort of nice. but that shouldnt really be an argument for having code with conflicts.
We could do what the TPL does, use Actors as the namespace and Actor as the Static API.
maybe even make Proto the root namespace so we have

They would still read like that from user-code though - it's only internally that you'd get namespace conflicts (because if you're in the namespace Proto.X, the compiler will interpret Actor as the namespace Proto.Actor, even if you add a using statement for Proto.Actor).
But would we then use Proto as the namespace for the whole public API? I.e. all packages have the same namespace. It could be nice for the user since you'd get less namespace bloat - but it could also make auto-completion worse if you get too many types available from one namespace. Anyway, something we could consider - it's not unheard of either, MS re-uses namespaces in multiple assemblies all the time.

As this code has real side-effects like spinning up a timer, I would like to avoid a property setter for it.

Yeah a property getter with a set method feels like the way to do it. Having logic in property setters is kind of frowned upon these days :) As you say, a property indicates no side-effects, whereas a method indicates there are.

This feels like it's pretty much done and settled.


Hd

Please close this issue.
As this does not serve any specific function.
Thank you.
@NitkarshChourasia


[release/v1.1] Pin ratelimit image to 26f28d78

cc @zhaohuabing

the wasm test is failing, @envoyproxy/gateway-maintainers any idea which PRs from main need to be backported into v1.1 to fix the flake ?

@arkodg can you try with https://github.com/envoyproxy/gateway/pull/4014?

@arkodg can you try with #4014?

thanks ! raised https://github.com/envoyproxy/gateway/pull/4151

/retest

@arkodg can you try with #4014?

thanks ! raised #4151

you may need rebase?

thanks for the rebase @zirain !


Strange tilemap flickering effect in some resolutions

Godot version
3.3.4 stable
System information
Linux Mint, GLES3/GLES2, GeForce GTX 1070/PCIe/SSE2
Issue description
I have a pixel art game in which I observe a strange flickering effect in a tilemap when the player is moving.
It's like if a portion of the screen is 1 pixel deviated from it should be. I've tried to record it but for some reason, in the recording the video is OK.
I am playing at fullscreen, but if I launch it windowd in a lower resolution the effect disappears too.
I have tried all of the recommended settings that I could find related to this issue, including:

GPU Pixel snap
Switching to GLES2 with Nvida Rect Flicker Workaround
Removing the smoothness and the drag margins of the camera
Change the process mode of the camera

None of the above fixes the flicker effect when I run the game in fullscreen.
What could be the cause of this?
Steps to reproduce

Create a 2D pixel art game
Add a moving object and a tilemap
Play in fullscreen

Minimal reproduction project
No response

Is it similar to #35606?

@Calinou the project I have uses assets that I can't share, but I'll try to change them with free ones and upload a reproducible project.
@jmb462 I have tried to look for the option you mention but I couldn't find it, I don't have a 2d menu under rendering/quality :/
@lawnjelly based on the description provided by the ticket that you mention, it seems that yes, it looks like the same issue.


Support NSwag JSON schema types and formats

See https://github.com/RicoSuter/NJsonSchema/blob/dde6f76a80b8acd55ff4f51e04c77b6b742f4294/src/NJsonSchema/Generation/ReflectionServiceBase.cs#L69

Yikes, not sure why GitHub made all the whitespace changes. Be sure to Hide whitespace

@microsoft-github-policy-service agree

Yikes, not sure why GitHub made all the whitespace changes. Be sure to Hide whitespace

Can you submit without the whitespace?
It's probably an auto-format feature in your editor.
The thing is the whitespace touches lots of lines, which can interfere with git blame and viewing history.

Looks like it doesn't compile
src\libraries\Microsoft.PowerFx.Connectors\OpenApiExtensions.cs(712,17): Error CS0152: The switch statement contains multiple cases with the label value '"file"'

Updated. The file case has already been fixed since 1.2.0

/AzurePipelines run

/AzurePipelines run


Add parameters to customize animated theme transition in MaterialApp

Allow to customize animated theme transition in MaterialApp class.
This PR allows to set the duration, the curve and a callback method to theme transitions in MaterialApp.

I have submitted my CLA.

I apologize for taking forever to respond to this PR.
This is (was) an interesting idea however ThemeData is a very (very) large class and adding properties whose value is not another component theme is not advisable, since most developers are unlikely to discover them. In this case, the feature hasn't been requested (and upvoted) via an existing issue. We'd only consider extending ThemeData in this way if there were many requests for it.
I am going to close the PR for now. If you'd really like to see this feature landed please file an issue that explains why it's needed, give other developers time to show their interest via up-votes, and then re-open this PR and include tests.


Tab switcher not working with Atom 1.7

The tab list not disappearing when releasing alt key.

Thanks for the report!
I've pushed an attempt to fix this to the atom-17 branch. Will merge it in soon hopefully -- I'd just like to try it out for a bit first.

Hi,
I tried your atom-17 branch but it does not work with my keybindings. I try to use ctrl-tab and ctrl-shift-tab keybindings. When I release keys it does not select the hovered tab.
I changed my keybindings following what you did in your commit. It look likes :
  'shift-ctrl-tab': 'tab-switcher:previous'
  'ctrl-tab': 'tab-switcher:next'
  'ctrl-tab ^ctrl': 'tab-switcher:select'
  'ctrl-shift-tab ^ctrl': 'tab-switcher:select'

Can you help me by providing an example on how to use it correctly please ?
Thanks.

It works ! 😄
I'am on your atom-17 branch and my keymap.cson looks like :
'atom-workspace':
  'ctrl-tab' : 'tab-switcher:next'
  'ctrl-tab ^ctrl' : 'unset!'
  'ctrl-shift-tab' : 'tab-switcher:previous'
  'ctrl-shift-tab ^ctrl' : 'unset!'
'ol.tab-switcher-tab-list':
  '^ctrl' : 'tab-switcher:select'

… Hhhm … Doesn't work for me …
However: The main reason why I actually installed tab-switcher was to have a working MRU on my Ctrl-Tab / Ctrl-Shift-Tab window switching. After being forced to disable tab-switcher and to comment out its key bindings, I just realized that Atom 1.7.2 seems to have implemented window tabbing MRU itself – which makes tab-switcher obsolete for me.

@GerZah Yes I know but I don't like this new MRU feature.
I want, just like other good IDEs a window to switch to more than my previous tab. That's why I love tab-switcher and it worked great before Atom 1.7.
PS : I'm on OSX 10.11.5 / Atom 1.7.2

Glad you were able to figure out the key bindings @FlorianBezagu . In the spirit of a couple of PRs, I've added some notes based on your suggestion to the readme.
Pushed as v1.4.0.

Great !
Thanks for your work. 👍


plugin will run twice if call resolveConfig and createServer

Describe the bug
// server.ts
import * as vite from 'vite'

async function createServer () {
  const config = await vite.resolveConfig({})
  const merged = vite.mergeConfig(config, {
    server: { middlewareMode: true }
  })
  merged.assetsInclude = []
  const server = await vite.createServer(merged)

  await server.ssrLoadModule('./src/foo.ts')
  await server.close()
}

await createServer()

// vite.config.ts
import { defineConfig } from 'vite'

let counter = 0

export default defineConfig({
  plugins: [
    {
      name: 'test-plugin',
      transform (code) {
        const c = `${code};${counter++};`
        console.log('code:', c)
        return {
          code: c
        }
      }
    }
  ]
})

><EMAIL_ADDRESS>start /Users/himself65/Code/vite-issue
> node ./server.js

build.terserOptions is specified but build.minify is not set to use Terser. Note Vite now defaults to use esbuild for minification. If you still prefer Terser, set build.minify to "terser".
(!) Could not auto-determine entry point from rollupOptions or html files and there are no explicit optimizeDeps.include patterns. Skipping dependency pre-bundling.
code: export default function foo() {
  return "hello foo";
}
;0;
code: export default function foo() {
  return "hello foo";
}
;
0;
;0;

Reproduction
https://github.com/himself65/vite-issue/tree/case-4
Steps to reproduce
pnpm run start
System Info
System:
    OS: macOS 14.2.1
    CPU: (12) arm64 Apple M2 Max
    Memory: 23.55 GB / 96.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.19.0 - ~/Library/Caches/fnm_multishells/55374_1704111397287/bin/node
    Yarn: 1.22.19 - ~/.yarn/bin/yarn
    npm: 10.2.3 - ~/Library/Caches/fnm_multishells/55374_1704111397287/bin/npm
    pnpm: 8.11.0 - ~/Library/Caches/fnm_multishells/55374_1704111397287/bin/pnpm
  Browsers:
    Chrome: 120.0.6099.129
    Safari: 17.2.1
  npmPackages:
    vite: ^5.0.10 => 5.0.10

Used Package Manager
pnpm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

I suppose configFile: false will solve this.

Yes, configFile: false should do the trick. It's running twice because there's two plugins of it running. One from your resolveConfig() call, another from Vite's internal resolveConfig() call (the latter can be disabled with configFile: false. Alternatively, you can pass your server.middlewareMode config etc directly to createServer(...). It will also merge with the loaded config file internally. Closing as expected behaviour.

I suppose configFile: false will solve this.
// server.ts
import * as vite from 'vite'

async function createServer () {
  const config = await vite.resolveConfig({})
  const merged = vite.mergeConfig(config, {
    configFile: false,
    server: { middlewareMode: true }
  })
  merged.assetsInclude = []
  const server = await vite.createServer(merged)

  await server.ssrLoadModule('./src/foo.ts')
  await server.close()
}

await createServer()

the test-plugin will run once see also: vitejs.dev/guide/api-javascript.html#createserver<EMAIL_ADDRESS>
Thanks!


Applying custom model on Android

Hi, I have trained my own model and trying to apply it on android.
I tried changing "yolov4-416-fp32" to my custom model, "yolov4-3000.tflite", changed Image "kite.jpg" to my image and updated coco.txt to my label names.

but the app crushes when I click detect button, fail to  run"tfLite.runForMultipleInputsOutputs(inputArray, outputMap);".
I checked every line and flags in the android studio, but could not figure out what went wrong, so I compared my tflite file with original one.

And I found they have different structure, and guess that was why. So tried converting tflite file with my save weights, but always ends up different neural network structure from original one.
I don't know what I have done wrong, so could anyone successfully applied custom model on android give me some tips?

can you pls tell how to get this structure for own model?

I used Netron.  All you have to do is download the program and put your model in there
https://github.com/lutzroeder/netron

I used this default setting but the app get crush anybidy can help me?


This adds in logging for parameters

I found in my testing that it would be helpful to include logging in the DebugLogger of the params

Thanks @veverkap!
The only thing I'd change is to use the name "query" or "query params" or "query attributes" instead of just "params" to not introduce confusion with body params.

Ahh. Good pointer. I'll do that.
On Wed, May 17, 2017 at 5:14 AM Tymon Tobolski<EMAIL_ADDRESS>wrote:

Thanks @veverkap https://github.com/veverkap!
The only thing I'd change is to use the name "query" or "query params" or
"query attributes" instead of just "params" to not introduce confusion with
body params.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/teamon/tesla/pull/75#issuecomment-302071551, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABXTKtIkTzT5V9SSmvOMD_3-sfqgGMKks5r6uSXgaJpZM4NdWWS
.

--
Sent from Gmail Mobile

@teamon I've changed it to
 _ = Logger.debug "#{prefix} Query Param '#{k}': '#{v}'"

HTH


Export Section Functionality in Emissions Module

As an ECMPS user I want to be able to export Emissions data using the export page on the left navigation panel of the ECMPS application.
Given a user navigates to the export page of the ECMPS application
When they select emissions and click the export button
Then the applicable emissions data they chose via the configuration and filters will be exported from the ECMPS applications
Given a user navigates to the export page of the ECMPS application
When they select a module (Emissions, Monitoring, QA)
Then all of the data from the selected modules within the year and quarter highlighted will be exported

[ ] Connect Emissions Export API to the Export page in the ECMPS application

[ ] Preview will not be required to export Monitoring and Emissions and the preview button is only enabled for QA.

*Need to collaborate with QA Team for this ticket

When the Emissions checkbox is checked, the Export button should be enabled.
Clicking export should download a JSON file with export data.
The Export button should be disabled while downloading.


[Bug Report] version 2.0.1 breaks builds

While version 1.2.6 was working just fine after an upgrade to 2.0.1 the build breaks for no reason. (and on multiple projects which use this dependency)
The following log output is from Circle CI build. I am wondering what the reason could be.
Any idea, Denis?
#!/bin/bash -eo pipefail
npm test

><EMAIL_ADDRESS>test /home/circleci/vscode-atlasmap
> node ./out/test/runTest.js

Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stableDownloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 3784693/95471832 (4%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 7585789/95471832 (8%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 11517949/95471832 (12%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 16039929/95471832 (17%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 19890174/95471832 (21%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 23150583/95471832 (24%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 26263545/95471832 (28%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 30490615/95471832 (32%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 34422775/95471832 (36%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 39239665/95471832 (41%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 41074673/95471832 (43%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 45809664/95471832 (48%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 50839549/95471832 (53%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 55295997/95471832 (58%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 60227584/95471832 (63%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 65323001/95471832 (68%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 70074359/95471832 (73%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 75284473/95471832 (79%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 79937533/95471832 (84%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 85114865/95471832 (89%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: 89964537/95471832 (94%)Downloading VS Code 1.53.2 from https://update.code.visualstudio.com/1.53.2/linux-x64/stable: complete
Downloaded VS Code 1.53.2 into .vscode-test/vscode-linux-x64-1.53.2
Fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"

(electron) Sending uncompressed crash reports is deprecated and will be removed in a future version of Electron. Set { compress: true } to opt-in to the new behavior. Crash reports will be uploaded gzipped, which most crash reporting servers support.

Warning: 'sandbox' is not in the list of known options, but still passed to Electron/Chromium.

[main 2021-02-18T07:08:16.466Z] update#setState idle

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

(node:317) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron.  See https://github.com/electron/electron/issues/23506 for more information

(node:399) Electron: Loading non-context-aware native module in renderer: '/home/circleci/vscode-atlasmap/.vscode-test/vscode-linux-x64-1.53.2/VSCode-linux-x64/resources/app/node_modules.asar.unpacked/vscode-sqlite3/build/Release/sqlite.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.

(node:399) Electron: Loading non-context-aware native module in renderer: '/home/circleci/vscode-atlasmap/.vscode-test/vscode-linux-x64-1.53.2/VSCode-linux-x64/resources/app/node_modules.asar.unpacked/spdlog/build/Release/spdlog.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.

Exit code:   1
Done

Failed to run tests
npm ERR! Test failed.  See above for more details.

Exited with code exit status 1

CircleCI received exit code 1

@lhein the log you attached is insufficient for detecting an issue. I can see only this error in the above log:
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

Which may be unrelated and is 100% not related to async-wait-until.
Could you share an example of how you use async-wait-until after upgrading? I think the way the function should be imported is different now.
Before, there supposed to be namespace-like import:
import * as waitUntil from 'async-wait-until';

While for v2.*, there's an ES module-like import:
import { waitUntil } from 'async-wait-until';

Hi Denis,
take a look at this PR for instance:
https://github.com/redhat-developer/vscode-didact/pull/424/files
The error output is "non-existent" and that makes it really hard to investigate. The interesting part is that this issue occurs in 4 of our projects which use async-wait-until while the others are not affected. That made me believe it has a connection.

An additional thing I observed...
When starting the tests from withing VSCode using 1.2.6 all works great. When switching to 2.0.1 using the new import statement the test dies right after start with error ReferenceError: window is not defined. Maybe this is useful.

@lhein this is interesting; thanks, will try to figure it out ASAP

@lhein okay, the fix's on the way; 2.0.2 should be published in ~20 minutes

awesome news. thanks for the quick help!

It doesn't see to help. Just upgraded to 2.0.2 and it still is broiken with the same error message.
https://github.com/redhat-developer/vscode-didact/runs/1935375646?check_suite_focus=true#step:9:41

Interesting

@lhein could you try 2.0.3?

that one does the trick. Thank you Denis!

Closing it 👍


Add support for onPress

Fixes #6

@alanshaw review/merge welcome 😉

@alanshaw Sorry to bug you again, I know things can get busy 😄  just pinging you in case you forgot about this PR. Could you review and let me know if this LGTY?

Thank you @kytwb - sorry for the delay!


SFTP UploadFiles fails with overflow

UploadFiles 1.0.0 fails each time with an error "Arithmetic operation resulted in an overflow."
Longer error message is as follows:
SFTP transfer failed: 1 Errors: Failure in PutFile: File 'file.xml' could not be transferred to '/In'. Error: Arithmetic operation resulted in an overflow. 1 files transferred: file.xml. Latest operations:
11:17:35Z: FILE LIST C:\folder\file.xml
11:17:37Z: CheckIfDestinationFileExists: Checking if destination file  exists
11:17:37Z: PutFile: Uploading destination file file.xml
11:17:37Z: File transfer failed: Failure in PutFile: File 'file.xml' could not be transferred to '/In'. Error: Arithmetic operation resulted in an overflow.
11:17:37Z: CleanUpFiles: Removing temporary file C:\folder\file.xml

File name and path have been edited.

This issue was fixed in the later versions of the Task. The newest version is 1.0.2. Could you try to use the latest one and report if the issue continues?

@RikuVirtanen Frends UI is showing the latest version in the repository being 1.0.0.
Enabled repositories are:

https://www.myget.org/F/frends/api/v2
https://www.myget.org/F/frends-community/api/v2
https://www.myget.org/F/frends-tasks/api/v2

That is because the Task is not published to its NuGet feed yet so it can only be imported to the Frends UI by downloading the repository to local machine and creating the NuGet package manually which then needs to be imported to the Frends UI.

Issue fixed by manually building a new NuGet version and importing it to Frends.


Dependencies issues (get_it)

flutter pub get

Running "flutter pub get" in myApp...
Because stacked 1.9.5 depends on get_it ^5.0.6 and no versions of stacked match >1.9.5 <2.0.0, stacked ^1.9.5 requires get_it ^5.0.6.
So, because myApp depends on both get_it ^6.0.0 and stacked ^1.9.5, version solving failed.
pub get failed (1; So, because myApp depends on both get_it ^6.0.0 and stacked ^1.9.5, version solving failed.)
exit code 1

At pubspec.yaml:
environment:
  sdk: ">=2.10.0 <3.0.0"
dependencies:
  flutter:
    sdk: flutter

  get_it: ^6.0.0
  stacked: ^1.9.5

flutter --version

Flutter 2.0.1 • channel stable • https://github.com/flutter/flutter.git
Framework • revision c5a4b4029c (6 days ago) • 2021-03-04 09:47:48 -0800
Engine • revision 40441def69
Tools • Dart 2.12.0

Thanks @lcsvcn the null safety functionality is quite a lot of work. We depend on other packages that also need to be updated. These upgrades are big mess up if you have many packages that you use. I'll add this to my list as an intermediary release and I'll update get_it.

I see that stacked already upgrade to version 1.9.6 and have dependency to get_it 6.0.0 on git.
But I get this when run flutter pub get:
Because *** depends on stacked ^1.9.6 which doesn't match any versions

I still have to push that version up. I'm doing that in a few minutes. Just finished up all the git notification responses.

1.9.6 is published


Add fantasy-land canonical method names

This PR is to resolve #656
This currently includes mappings and tests for the following types:

fantasy-land/of => _.of (the tests require ap from #643)
fantasy-land/map => _.map
fantasy-land/chain => _.flatMap
fantasy-land/filter => _.filter
fantasy-land/alt => _.otherwise
fantasy-land/concat => _.concat

Additionally, the following mappings can be added after #657:

fantasy-land/empty => _.empty
fantasy-land/zero => _.empty

Can you make the tests pass? I think you're missing fantasy-land/ap.

I think the that's the last of it. I had to rework the ap - noValueOnError tests a bit because I think I was using the noValueOnErrorTest function incorrectly to get a false positive.
I also had to rework the _.of tests because I had only partially (and incorrectly) implemented them awaiting _([]).ap
I believe those are the only changes since your previous review.

Ok, one more thing: I just updated package-lock.json because it was mismatched with package.json (+ fantasy-land). If you have a preferred way of minimizing some of those changes, I can revert and update it that way.

As always, thanks for the careful and thoughtful reviews!

All this fantasyland work you've done has been great. Thanks!

How does this all end up getting rolled up into a release?

I need to manually run a grunt task. I'll do that after I add some advertisement about the Fantasy Land work (in #663).

3.0.0-beta.7 is released.


Update sbt-scala-native, scala3lib to 0.4.16

About this PR
📦 Updates

org.scala-native:sbt-scala-native
org.scala-native:scala3lib

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

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

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

labels: library-update, early-semver-minor, semver-spec-patch, commit-count:1

Superseded by #118.


#30 File watcher

This is a major feature for Killgrave, since now when you made any changes above the imposters file, you need to restar manually the server, this isn't be a problem if you already have a very stable mock server, but when you are creating and configurating your server this action is very frecuently.
For that with this PR I want to add this new feature, using the flag -watcher. The server would be reload with any changes above the imposters path that you choosed on starting.

Resolve #30


Correct LICENSE - Copyright cannot be edited as was done

Hi @will-i-amv,
I'm correcting your LICENSE file in your fork of my repo to restore the original copyright of the content, which per the license cannot be removed. The license states that the copyright notice must appear in all copies and derivative works:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

You can find more information here

ping @will-i-amv

Fixed, sorry for the late response.


Startup Hangs when using LogWriter

This pertains to PR #134 I worked on and it introduced the issue.
When it was suggested to move captureFifoToFile to the handler, I forgot about the fact that if Firecracker is not started before we start listening on the log.fifo then os.Open in captureFifoToFile will block. Since we moved captureFifoToFile to a handler, this blocks the handlers which execute before we start Firecracker so it'll never unblock., shown here.
Mostly creating this issue to spark a discussion on the best place to put captureFifoToFile. The implementation before the above PR did not work with Jailer as the sdk jailer setup would change the path to the LogFifo in the config before we tried to listen on it.
I've outlined workflows from what I understand needs to happen in the case of jailer and plain firecracker.
Firecracker:

Create log.fifo and metric.fifo
Start Firecracker
Configure logging and metrics via API
Call captureFifoToFile

Jailer:

Create log.fifo and metric.fifo
Jailer chroot for vm setup
Hard link log.fifo and metric.fifo into jailer chroot for VM
Jailer start Firecracker
Configure logging and metrics via API
Call captureFifoToFile on original log.fifo path (not hard linked)

Investigating this more, now that I've dug into it seems like the VM is started but we try and listen to the fifos before we tell Firecracker about them. Seems like captureFifoToFile should be in BootstrapLoggingHandler (which was originally how things were). The issue there is jailer messes with the fifo paths in the config.

@cpheps - Hello, thank you for taking a deep dive into this. I am a little confused to why captureFifoToFile now blocks. Can you elaborate on that a little? Why does enabling jailer cause it to block?

So jailer itself isn't the issue with hanging. There was an issue previously where using the FifoLogWriter wouldn't work if you were using jailer and your original log.fifo location was not ./log.fifo. That is no longer an issue but it should be considered when implementing a fix. I'll elaborate on it more at the bottom.
The current hanging issue happens when you have a FifoLogWriter specified in either a jailer or non-jailer configuration.
The main issue lies in this chunk of code from handlers.go.
var defaultFcInitHandlerList = HandlerList{}.Append(
	SetupNetworkHandler,
	SetupKernelArgsHandler,
	StartVMMHandler,
	CreateLogFilesHandler,
	BootstrapLoggingHandler,
	CreateMachineHandler,
	CreateBootSourceHandler,
	AttachDrivesHandler,
	CreateNetworkInterfacesHandler,
	AddVsocksHandler,
)

We currently call captureFifoToFile inside CreateLogFilesHandler which is before BootstrapLoggingHandler. When we do the os.Open inside captureFifoToFile it hangs since we have not sent the PUT /logger, which is inside BootstrapLoggingHandler. This means Firecracker is not sending down either log.fifo or metric.fifo. The behavior when doing a read only open on a fifo pipe is to block until something sends down the pipe.
Based on that it would make sense to move captureFifoToFile into BootstrapLoggingHandler after we send the PUT /logger API call to Firecracker. This was the original behavior but there is an issue with this when using jailer. In jail.go This chunk of code sets the LinkFilesHandler to be after CreateLogFilesHandlerName but before BootstrapLoggingHandler
// AdaptHandlers will inject the LinkFilesHandler into the handler list.
func (s NaiveChrootStrategy) AdaptHandlers(handlers *Handlers) error {
	if !handlers.FcInit.Has(CreateLogFilesHandlerName) {
		return ErrRequiredHandlerMissing
	}

	handlers.FcInit = handlers.FcInit.AppendAfter(
		CreateLogFilesHandlerName,
		LinkFilesHandler(filepath.Join(s.Rootfs, rootfsFolderName), filepath.Base(s.KernelImagePath)),
	)

	return nil
}

The LinkFilesHandler modifies the configuration values for LogFifo and MetricsFifo to point to the hard links inside the vm chroot as seen here:
			for _, fifoPath := range []*string{&m.Cfg.LogFifo, &m.Cfg.MetricsFifo} {
				if fifoPath == nil || *fifoPath == "" {
					continue
				}

				fileName := filepath.Base(*fifoPath)
				if err := linkFileToRootFS(
					m.Cfg.JailerCfg,
					filepath.Join(rootfs, fileName),
					*fifoPath,
				); err != nil {
					return err
				}

				if err := os.Chown(filepath.Join(rootfs, fileName), *m.Cfg.JailerCfg.UID, *m.Cfg.JailerCfg.GID); err != nil {
					return err
				}

				// update fifoPath as jailer works relative to the chroot dir
                               // This overwrites the user config!!!!!
				*fifoPath = fileName
			}

Now that the config has been changed when captureFifoToFile is called inside of BootstrapLoggingHandler it attempts to create a log writer pointing at the hard links which have a relative path inside the vm chroot. It will accidentally work if your original config values for LogFifo and MetricFifo are ./log.fifo and ./metrics.fifo respectively.
It's a bit of confusing issue so hopefully the explanation makes sense. I don't have a great solution for this yet, wanted to see what the core dev team thought about it.

@cpheps - I went ahead and create a PR for a fix. I tested this and ensured that this is properly working with the fifo writer. Please let me know if you run into any other issues.


fix: change form hook names

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Codecov Report

Merging #636 (abc7cb9) into tagged-release/forms-and-views (72f6d67) will not change coverage.
The diff coverage is n/a.

@@                       Coverage Diff                       @@
##           tagged-release/forms-and-views     #636   +/-   ##
===============================================================
  Coverage                           89.79%   89.79%
===============================================================
  Files                                  96       96
  Lines                                3576     3576
  Branches                              966      966
===============================================================
  Hits                                 3211     3211
  Misses                                339      339
  Partials                               26       26

Impacted Files
Coverage Δ

.../codegen-ui-react/lib/amplify-ui-renderers/form.ts
94.87% <ø> (ø)

...codegen-ui-react/lib/forms/form-renderer-helper.ts
90.09% <ø> (ø)

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 72f6d67...abc7cb9. Read the comment docs.


Update Source URL in README.md

Currently the source url points to either a private repo, or a non existent repo that doesn't match this repo.
Description
Please include a summary of the change and which issue is fixed. Also, please include the motivation and context for the change. List any dependencies that are required for this change.
Check the relevant boxes:

[ ] Bug fix (nonbreaking change that fixes an issue)
[ ] New feature (nonbreaking change that adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Examples or tests (addition or updates of examples or tests)
[x] Documentation update
[ ] CI related update (pipeline, etc.)

Checklist

[ ] If relevant, a test for the change has been added or updated as part of this PR.
[ ] If relevant, documentation for the change has been added or updated as part of this PR.

Merge

Merge using "Squash and merge".
Make sure to use a relevant conventional commit message that is based on the PR contents. The commit message determines whether a new version of the modules needs to be released, and if so, which semver number to use).

I have included this change in https://github.com/terraform-ibm-modules/terraform-ibm-icse-key-management/pull/386