BUG: WinUI3 x:Bind in GridView

Describe the bug
Using {x:Bind} on a DependencyPropery inside a Control which is used in the ItemTemplate of a GridView doesn't work. It shows the FallBackValue and not the correct property. If you change the ItemsPanel of the GridView to a StackPanel it works ok. Normal {Binding} also works ok.
In the following example I have two GridViews. One without an ItemsPanel, the second one with a StackPanel. The GridViews ItemSource is databound to a List of Employee (Name/Salary) objects. The ItemTemplate contains a UserControl (EmployeeControl) which has an Employee DependencyProperty. This property is set using x:Bind.
<Window
    x:Class="ProblemDemo.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:ProblemDemo"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d">

    <Grid Padding="8">
        <Grid.RowDefinitions>
            <RowDefinition />
            <RowDefinition />
        </Grid.RowDefinitions>
        <GridView ItemsSource="{x:Bind Employees}">
            <GridView.ItemTemplate>
                <DataTemplate x:DataType="local:Employee">
                    <local:EmployeesControl Background="Red"
                                            Employee="{x:Bind}" />
                </DataTemplate>
            </GridView.ItemTemplate>
        </GridView>

        <GridView ItemsSource="{x:Bind Employees}"
                  Grid.Row="1">
            <GridView.ItemTemplate>
                <DataTemplate x:DataType="local:Employee">
                    <local:EmployeesControl Background="Blue"
                                            Employee="{x:Bind}" />
                </DataTemplate>
            </GridView.ItemTemplate>
            <GridView.ItemsPanel>
                <ItemsPanelTemplate>
                    <StackPanel Orientation="Horizontal" />
                </ItemsPanelTemplate>
            </GridView.ItemsPanel>
        </GridView>
    </Grid>
</Window>

using Microsoft.UI.Xaml;
using System.Collections.Generic;

// To learn more about WinUI, the WinUI project structure,
// and more about our project templates, see: http://aka.ms/winui-project-info.

namespace ProblemDemo {
    /// <summary>
    /// An empty window that can be used on its own or navigated to within a Frame.
    /// </summary>
    public sealed partial class MainWindow : Window {

        internal List<Employee> Employees = new() {
            new("Fons", 2000),
            new("Ellen", 5000),
            new("Jim", 3000),
        };

        public MainWindow() {
            this.InitializeComponent();
        }

    }

    public class Employee {
        public Employee(string name, double salary) {
            this.Name = name;
            this.Salary = salary;
        }

        public string Name { get; set; }
        public double Salary { get; set; }
    }
}

The EmployeeControl has a StackPanel with 2 TextBlock controls in it. The TextBlock Text is databound using x:Bind to the Name and Salary. It also has a 'dummy' FallbackValue.
<UserControl x:Class="ProblemDemo.EmployeesControl"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:local="using:ProblemDemo"
             RequestedTheme="Dark"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             mc:Ignorable="d">

    <StackPanel Background="{x:Bind Background}"
                Spacing="8"
                Padding="8">
        <TextBlock Text="{x:Bind Employee.Name, FallbackValue=NameFallBack}"
                   FontWeight="Bold" />
        <TextBlock Text="{x:Bind Employee.Salary, FallbackValue=0}" />
    </StackPanel>
</UserControl>

using Microsoft.UI.Xaml;
using Microsoft.UI.Xaml.Controls;

// To learn more about WinUI, the WinUI project structure,
// and more about our project templates, see: http://aka.ms/winui-project-info.

namespace ProblemDemo {
    public sealed partial class EmployeesControl : UserControl {
        public EmployeesControl() {
            this.InitializeComponent();
        }

        public Employee Employee {
            get => (Employee)GetValue(EmployeeProperty);
            set => SetValue(EmployeeProperty, value);
        }

        public static readonly DependencyProperty EmployeeProperty = DependencyProperty.Register(nameof(Employee), typeof(Employee), typeof(EmployeesControl), new PropertyMetadata(default));

    }
}

When you run the code you will see that the first GridView (Red) is showing the FallbackValue. This is the BUG. The second one (Blue) works ok. This is becuase it has the StackPanel in the ItemsPanel. It will stop working you change it to an ItemsStackPanel or ItemsWrapGrid.
Steps to reproduce the bug

Steps to reproduce the behavior:

Clone the repository.
Open the Solution
Run the app

Expected behavior
The Red StackPanels should show the correct Name and Salary of all employees. Just like the blue ones do.
Screenshots

Version Info

NuGet package version:
[WinUI 3 - Windows App SDK 0.8: 0.8.2]
[WinUI 3 - Windows App SDK 1.0: 1.0.0-experimental1]
[WinUI 3 - Windows App SDK 1.0: 1.0.0-preview1]

Windows app type:

UWP
Win32

Yes

Windows version
Saw the problem?

Insider Build (xxxxx)

May 2021 Update (19043)
Yes

October 2020 Update (19042)

May 2020 Update (19041)

November 2019 Update (18363)

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes

Xbox

Surface Hub

IoT

Additional context

Any idea whether this issue will get any follow-up.

@RealTommyKlein thoughts?

@sonnemaf if you put the grids in a separate page outside of Window and host that page in the window, does it work then?
Wondering if there's just a class of issues like #4966 where x:Bind isn't setup to work from Window?

@michael-hawker No it does not. I found this bug while developing a new game. It used a Page which was navigated to from a Frame inside the Window. I don't think it is Window related. I think it is more serious.

I have just tried to the new Microsoft.WindowsAppSDK 1.0.0-preview1. The problem is not fixed with this version.

@sonnemaf I just noticed, does it matter if you use the proper {x:Bind (local:Employee)} syntax for the binding? I don't think {x:Bind} by itself is actually supposed to work for pathless casting.

This looks like a bug with ItemsStackPanel, causing x:Binds to be evaluated in an incorrect order.  As a workaround, the x:Binds in EmployeeControls.xaml should use Mode=OneWay.
x:Bind's logic is initially evaluated when the content in its scope is fully initialized.
When x:Bind is used with data root of a control or page, it uses the root's FrameworkElement.Loading to determine when to run. When x:Bind is used in a template, it instead uses the template root's FrameworkElement.DataContextChanged event, or the framework can directly run the x:Bind logic by invoking IDataTemplateComponent.ProcessBindings or IDataTemplateTemplateExtensions.ProcessBindings.
In the working case with non-ItemsStackPanel roots in GridView.ItemsPanel, the events looks like this:

GridView's template instances instantiate the EmployeeControl control and sets its Background property
The x:Bind logic for GridView's template instance runs as a result of DataContextChanged firing, setting the EmployeeControl.Employee property
EmployeeControl's x:Bind logic (setting its TextBlocks text to Employee fields) runs as a result of a Loading event

In the non-working case with ItemsStackPanel as the GridView.ItemsPanel (which is its default value):

GridView's template instances instantiate the EmployeeControl control and sets its Background property
EmployeeControl's x:Bind logic (setting its TextBlocks text to Employee fields) runs as a result of a Loading event.  However, EmployeeControl.Employee hasn't been set yet, so the x:Binds evaluate to incorrect values.
The x:Bind logic for GridView's template instance runs as a result of a ProcessBindings call from the framework, setting the EmployeeControl.Employee property

I made a repro here (link will only work for MSFT folks).  @stephenlpeters can you redirect to someone on the controls team who is more familiar with ItemsStackPanel?  It may have something to do with when ItemsStackPanel calls Measure for its template instances (Measure is what would trigger the FrameworkElement.Loading event and cause x:Bind's logic to run).

Thank you for looking into it.
I can confirm that the Mode=OneWay is a valid workaround. I still think it is a Bug which should be fixed. It is not only in the 'ItemsStackPanel' the 'ItemsWrapPanel' has the same issue.

I had the same issue, and using the Mode=OneWay workaround indeed made mine work. However, to make it work, I had to convert a whole set of plain properties to DependencyProperties, and it was quite a tedious operation, so I really hope this bug gets fixed soon.
(Actually, I just realised I could have got a help from LLMs like ChatGPT for those conversions. Welp, it's too late...)


Feature Request: Make the prompt input field stick to the bottom

Thanks for this great extension! I recently tried to move it to the bottom area to switch between terminal or ChatGPT down there. However, with the features overview, I cannot see the prompt input anymore. See:

@AmShaegar13 thanks for the suggestion. I will look into this, in the meantime you can increase the height to be able to see the prompt. Though it's not optimal, it will unblock until I release a fix.

@AmShaegar13 after you login on a tall screen(Increase the height to see the input box, or just a question to pass the login screen) you should be able to see the prompt input stuck to the bottom.

Ah, thanks for the workaround. That'll do it for now.

@AmShaegar13 I rolled out a fix now. Please upgrade to V3.6.3 to be able to smoothly use the extension placed at the bottom of the tab.

@gencay You are awesome! Thanks a lot!


31 remove tests

jinja2 is needed for the table produced at the end of the experiments

I have removed the sys.path hack... :-)

I know run 'make experiments during ci/cd'

I made sure there is a checkpoints folder :-)

And I solved the Secret Santa problem ;-)

@tschm I only added the hack because I wanted the main file that holds the actual reference implementation to be in the root of the repo (markowitz.py). I'm not sure if moving it so a subfolder is preferred here.
Are you sure we need any of these additional libraries?

We need at least jinja2 for now. My experiments crashed when it came to creating the table saying jinja2 is missing. Loguru is not needed yet. Cvxsimulator also not needed at this stage

For me experiments.py is the entry point and hence could be top level. I think markowitz.py is better in the experiments "package". Easier and cleaner?

committed your changes
On Sat, 9 Dec 2023 at 20:48, Philipp Schiele @.***>
wrote:

@.**** approved this pull request.
Had two small comments, then good to go from my side.
—
Reply to this email directly, view it on GitHub
https://github.com/cvxgrp/markowitz-reference/pull/32#pullrequestreview-1773766331,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAPTQ74W6VYK2JERAWHI2K3YISI4LAVCNFSM6AAAAABANZSEJ6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTONZTG43DMMZTGE
.
You are receiving this because you were mentioned.Message ID:
@.***>


Publish sources generated for the protobuf schema

That would help with navigating code that uses semanticdb3. Due to some reason, this confuses Intellij.

Lack of sources also breaks goto definition in metals, IntelliJ indexes dependency sources and when there are none it shows a scalap-like output from the classfiles.


Deprecated selector in elastic-tabstops/styles/elastic-tabstops.less

In elastic-tabstops/styles/elastic-tabstops.less:
Starting from Atom v1.13.0, the contents of atom-text-editor elements are no longer encapsulated within a shadow DOM boundary. This means you should stop using :host and ::shadow pseudo-selectors, and prepend all your syntax selectors with syntax--. To prevent breakage with existing style sheets, Atom will automatically upgrade the following selectors:

atom-text-editor::shadow span.hard-tab => atom-text-editor.editor span.hard-tab

atom-text-editor::shadow span.hard-tab.indent-guide:first-child => atom-text-editor.editor span.hard-tab.indent-guide:first-child

Automatic translation of selectors will be removed in a few release cycles to minimize startup time. Please, make sure to upgrade the above selectors as soon as possible.

PR is welcome!


the jeddict plugins bundled with netbeans 9.0 didn't recognized

after downloading jeddict bundled with netbeans  it doesn't recognize the preinstalled jeddict plugins  , the category persistence show me default options even the folders  jeddict and jedditc-extensions existe .
Product Version: Apache NetBeans IDE 9.0 (Build incubator-netbeans-release-334-on-20180708)
Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
Runtime: Java(TM) SE Runtime Environment 10.0.1+10
System: Linux version 4.10.0-38-generic running on amd64; UTF-8; en_US (nb)
User directory: /home/khaled/.netbeans/9.0
Cache directory: /home/khaled/.cache/netbeans/9.0
the downloaded jedddict version  : v5.2

Can you share the screenshot. Also which project type, you are using for generating the source code.

i'm using maven java ee 7 web project
On Dec 7, 2018 5:30 AM, "Gaurav Gupta"<EMAIL_ADDRESS>wrote:

Can you share the screenshot. Also which project type, you are using for
generating the source code.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jeddict/jeddict/issues/302#issuecomment-445119508,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APqFjOerDk_pQq8BnVVNypaOvQsDiMEUks5u2e7-gaJpZM4ZHX3o
.

the category persistence show me default options
Can you share more details about this and a screenshot will help too (as per current details looks like, new modeler file option is not visible to you).

May you also confirm that Jeddict plugin are activated under "Tools menu > Plugins > Installed".


ENH+TST: A batch query option

Codecov Report
Base: 77.71% // Head: 75.89% // Decreases project coverage by -1.81% :warning:

Coverage data is based on head (6746290) compared to base (b3f4e4c).
Patch coverage: 81.81% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #12      +/-   ##
==========================================
- Coverage   77.71%   75.89%   -1.82%
==========================================
  Files          25       24       -1
  Lines        6407     6368      -39
==========================================
- Hits         4979     4833     -146
- Misses       1428     1535     +107

Impacted Files
Coverage Δ

dcm/util.py
78.72% <68.75%> (+1.58%)
:arrow_up:

dcm/store/base.py
70.27% <70.27%> (ø)

dcm/tests/conftest.py
78.50% <71.42%> (-16.46%)
:arrow_down:

dcm/net.py
80.78% <89.15%> (-2.25%)
:arrow_down:

dcm/cli.py
72.69% <91.48%> (+1.45%)
:arrow_up:

dcm/tests/test_sync.py
97.88% <95.00%> (ø)

dcm/filt.py
42.12% <100.00%> (ø)

dcm/info.py
100.00% <100.00%> (ø)

dcm/route.py
76.99% <100.00%> (-0.63%)
:arrow_down:

dcm/store/local_dir.py
58.90% <100.00%> (+0.18%)
:arrow_up:

... and 12 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


fix(svelte): prefer git over package.json

When using the Svelte LSP on a monorepo, the preference for a package.json may set an incorrect root dir.
To address that, prefer finding the git "root" instead.

package.json is a common file for the frontend. The priority here should be fine for most people. I think you can adjust it locally

package.json is a common file for the frontend.

Indeed, it is, that's why it's kept as a fallback. This change doesn't affect those who rely on a package.json, but fixes the issue with monorepos
Besides, there's precedent for preferring .git over package.json:
https://github.com/neovim/nvim-lspconfig/blob/2c007c79eedfca0ec652c50d571cb0c52d1577ba/lua/lspconfig/configs/solidity.lua#L7
https://github.com/neovim/nvim-lspconfig/blob/2c007c79eedfca0ec652c50d571cb0c52d1577ba/lua/lspconfig/configs/somesass_ls.lua#L8
https://github.com/neovim/nvim-lspconfig/blob/2c007c79eedfca0ec652c50d571cb0c52d1577ba/lua/lspconfig/configs/prismals.lua#L12


option names for karmor

This PR fixes some of the issues described in #66

I am converting the PR to draft, please ping when it's ready

Ready for review

Please request a review once the PR is fully ready.

@Ankurk99 review pls

squashed 👍🏽

Hey @s1ntaxe770r can you please address the ci-go warning and squash your commits into one?

@Ankurk99  does this look good now?

Hey @s1ntaxe770r, the commits are not squashed yet, can you please do so?

the naming changes are still necessary?
Issue: https://github.com/kubearmor/kubearmor-client/issues/66
cc: @Ankurk99 @nyrahul

@yasin-cs-ko-ak Yes, and we need to update the changes to reflect the currect version. For eg insight command is no more there.


[feature req] Focus password field after fill

When a password is selected and form is filled, the password field should be focused so that the pre-filled form can be submitted by simply pressing ENTER.
Currently no element on the site is focused so after filling the form one must pull one's hands away from the keyboard and reach for the mouse, which is rather inconvenient.

This is already implemented, but might be broken on a particular website - please share the link where it doesn't work and I'll have a look if it is possible to fix (some websites have an awful markup).

As far as I can tell it does not work on any website.  I mostly use this on intranet systems so I can't give you specific sites but if you have access to, say, OpenNebula, Jenkins, OwnCloud or RainLoop instance, these are all the type of sites where I can confirm the focus is not working. Another might be Aliexpress. It doesn't even work here on GitHub.
Using Firefox 57.0.2 on Arch Linux.

Could you fill out the issue template, to make sure you are on the latest version?
https://github.com/dannyvankooten/browserpass/blob/master/ISSUE_TEMPLATE.md

of course, sorry, didn't expect a feature req. become a bug report :)
General information
Operating system + version: Arch Linux, N/A
Browser + version: FF 57.0.2
If installed an official release, put a release version: 2.0.9
Browserpass extension version as reported by your browser: 2.0.9
Exact steps to reproduce the problem
ctrl+shift+L, select entry, hit enter
What should happen?
A form field (preferably password) should be focused.
What happened instead?
a form is filled but no element is focused

Huh, it's a Firefox issue, I do reproduce it on github.com. Thanks for the report 🙂
As a temporary workaround, you can enable "Auto-Submit login forms" in the addon options, surprisingly this feature works even thought it is implemented in the same manner as autofocus feature.

Had a closer look, apparently after the extension popup is closed, Firefox contrary to Chromium does not return the focus to the website window, so we cannot programmatically put focus to any element as the entire window is not focused.
I've seen some weirdness in Firefox's focusing behavior before, and someone came up with workarounds that seem to work fine, like the one below:
https://github.com/dannyvankooten/browserpass/blob/684e4eadc57d5df74d4488775c6fdf22634a1745/chrome/script.browserify.js#L247-L252
But I can't think of any workaround for this bug. I'll mark the issue as help wanted in case someone thinks of a workaround, but I'm afraid there's nothing we can do until the behavior is fixed in Firefox itself.

Perhaps filling an upstream bug? I'm not sure I understand the mechanics of this misbehaviour well enough to fill one but maybe someone else does?

That would certainly be useful, I use this feature daily in Chromium and I definitely think it's an important one to have.
I don't think I understand the full mechanics too in order to submit a bug report, and I'm not even entirely sure that this is a bug in Firefox or just me not knowing how to get the focus to the main page.
I think we need someone knowledgeable to investigate this a bit further, and when reporting an upstream bug maybe even create a simplified (and yet fully working) example to help the developers reproduce and understand the issue.
If someone does create an upstream bug, please post the link here for others to follow.

Yeah, this bug (not focusing the web view) is driving us Tridactyl users insane.
On the other hand, PassFF somehow manages to get around this, so maybe look at how they do it?

This project is mostly community-driven, feel free to investigate and make a PR, I will gladly provide explanations of how things work in this project, as well as review & merge the PR 🙂

Accidentally stumbled upon the fact that it seems PassFF does not manage to get around this after all.

By the way, if you trust "Auto-submit login forms" option, you can turn it on in the extension options - this works in Firefox.

This is awesome news! I'll wait until 61 becomes stable and test on Linux (right now it's 59 and bug is present).

I still seem to have this bug with Firefox 62 on Linux. After filling (and auto-submitting) a form with browserpass I need to press Shift-Tab (or 4 × Tab) to get focus back to the actual website before I can use Vimium again. The same happens when I just press Ctrl-Shift-L and then follow up with Esc.
Not that big of a deal, but a bit of a nuisance nonetheless :slightly_smiling_face:

Just tried on Firefox 62 and confirm that the bug is still reproducible for me. Unfortunately I don't know what I can do about it, thus closing. If anyone has any ideas, a hint or a PR is very welcome.

Odd. Has been working for me in Firefox Developer Edition since v. 61 on Mac (not prior though so was clearly fixed) as I pointed out above. Still working today in 63.0b13.

Not sure if it's helpful, but Bitwarden seems to have a way of filling form data that retains focus somehow. I'm not (much of) a coder, but they seem to use a different mechanism for interacting with the page:
https://github.com/bitwarden/browser/blob/master/src/browser/browserApi.ts#L91

On a first glance it looks they are using exactly the same API as we do, maybe you are in the lucky group of people who don't repro the bug, or Firefox is inconsistent in it's ability to retain focus.


feat(localize): updated translation from Crowdin

:tada: This PR is included in version 3.5.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


pages cleanup

Summary:

What: change pages to use SDS List/ListItem components directly, added padding to the bottom of NarrowContainer component (replacing bottom div that was previously used for spacing)
Ticket: No Ticket, just feedback from resources page PR
Env: rdev

Demos:
see rdev
Notes:
Checklist:

[x] I merged latest trunk
[x] I manually verified the change
[x] I added labels to my PR
[x] I tested in multiple browsers
[ ] I added relevant unit tests
[ ] I have notified others of changes they need to make locally (migrations, jobs, package updates, etc)

thanks for the thoughtful feedback @vincent-czi, i'm going to merge this in now


"list" questions should repeat subquestions for each answer

For example the question "which other data will you re-use" will allow people to give a list of answers. For each of these we want to ask the same subquestions: do you have permission, will you download, etc.

Note: this should be done after login/persistence.

Implemented in v0.2


Allow date fields in Priority picker

What would you like to be added?
I would like to be able to choose my due date field as the sort priority in the Board view
Why is this needed?
The due date of a note is the main driving factor in what I should work on next, and ordering based on arbitrary numerical fields means a lot of manual shuffling of "ordinal" properties. The ability to order by a date field would let me pick between, for instance, a start, end, or due date as my primary sort, which I think would solve the majority of sorting issues people may have. It would certainly solve mine.

I know that drag-and-drop is a next priority for the project, so I'd like to point out that this would also somewhat automate the sorting based on that. If I drag an item later on the calendar because it's been delayed, then it would also fall down the order on the Board view as a nice side effect.


Replace libobj library with tinyobj (#37)

This revision deprecates libobj and use tinyobj by @syoyo (https://github.com/syoyo/tinyobjloader).

Codecov Report

Merging #42 into master will increase coverage by 0.12%.
The diff coverage is 55.25%.

@@            Coverage Diff             @@
##           master      #42      +/-   ##
==========================================
+ Coverage   77.34%   77.46%   +0.12%
==========================================
  Files         361      361
  Lines       16876    16853      -23
==========================================
+ Hits        13052    13056       +4
+ Misses       3824     3797      -27

Impacted Files
Coverage Δ

Includes/Core/Geometry/TriangleMesh3.h
100% <100%> (ø)
:arrow_up:

Sources/Core/Geometry/TriangleMesh3.cpp
54.94% <54.94%> (+5.26%)
: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 4b36de2...900637a. Read the comment docs.


Confusing wording of a sentence in section 8.5.2

8.5.2. P4 Type Specifications in p4info.proto
In this sentence:
"P4DataTypeSpec is meant to be used in P4Info, everywhere where
the P4Runtime client can provide a value for a P4_16 expression."

should "value" be replaced with the word "type"?  It seems like the
message "P4Data" is intended for conveying P4_16 values, isn't it?

what about this:

P4DataTypeSpec is meant to be used in P4Info, to specify the expected format of the P4-dependent values being exchanged between the P4Runtime client and server. Each P4DataTypeSpec message corresponds to a compile-time type in the original P4_16 program (e.g. the type parameter of an extern).


Position in 3D space is off

Something seems wrong with positioning the Effekseeker node in 3D space (last tried in Godot 3.5.1). The Effekseeker node should be placed on exactly the same place as the red sphere on impact. But there seems to be an offset. The Effekseer node is also dragged with the camera as the player starts moving again (it doesn't stick to its position).
There's no documentation I can find that explains how Effekseer handles rendering and placement etc. in Godot. The Effekseeker node also seem to move to different location every time spawned.
My setup. I have a scene that includes the Effekseer node with a Spatial node as its parent.
I then spawn the VFX scene by adding the VFX scene to the main game scene and I set the positioning by setting the global_transform.origin where it should be.
Godot 3.5.1
Effekseer tool 1.70
Effekseer Plugin 1.70.1
https://user-images.githubusercontent.com/42893106/204132256-569d943f-d152-42df-a93d-cab998646946.mp4

Could I get a minimal reproduction project?
EffekseerEmitter node's 3D position works in my environment.
The effect 3D position is calculated from the global_transform.origin of the EffekseerEmitter node.

Sure thing. here's a quick small project with the same problem... I discovered also that this problem happens when the camera moves. When not moving the camera the position for the FX is correct. I also placed a red sphere here to illustrate where the FX should be positioned.
effekseer_test.zip

Thanks! I reproduced it in my environment.
We will now investigate the cause in detail.

I found a simple bug in the plugin code.
If the Camera node is a child of another moving node, the effect renders incorrectly.
This issue has already fixed. Please try latest release.

Just tried it... now it works! Fantastic! Thanks!


Fix link to example in README.md

We publish the README to hex.pm but rely on implicit linking on github which will result in 404 for users trying to hit examples from hexdocs.
Closes #76
I originally said we'd fix this once the repo is transferred to jelly-beam, but that's a bit silly, a bug exists, it should be fixed. We can just update it as part of the transfer.

Alternatively, we can just go ahead and update this to jelly-beam and transfer after the merge.


Issues with 'version `GLIBC_2.32' not found' when running clippy on CI

# flake.nix

{
  description = "chainlink-terra";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";
    rust-overlay.url = "github:oxalica/rust-overlay";
  };

  outputs = inputs@{ self, nixpkgs, rust-overlay, flake-utils, ... }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs { inherit system; overlays = [ rust-overlay.overlay ]; };
      in rec {
        devShell = pkgs.callPackage ./shell.nix {};
      });
}

# shell.nix

{ stdenv, pkgs, lib }:

pkgs.mkShell {
  nativeBuildInputs = with pkgs; [
    (rust-bin.stable.latest.default.override {
      extensions = ["rust-src"];
      targets = [
        "x86_64-unknown-linux-gnu"
        "wasm32-unknown-unknown"
      ];
    })
    cargo-generate
    cargo-tarpaulin
  ];
  RUST_BACKTRACE = "1";
}

When running nix develop -c cargo clippy --all-targets -- -D warnings it fails during proc macro checking:
    Checking thiserror v1.0.29
error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /home/runner/work/foo/target/debug/deps/libthiserror_impl-22080d5093a0fbd6.so)
   --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/thiserror-1.0.29/src/lib.rs:213:9
    |
213 | pub use thiserror_impl::*;
    |         ^^^^^^^^^^^^^^

However compiling, running tests, nix develop -c cargo fmt or nix develop -c cargo build --release --target wasm32-unknown-unknown all works fine.
Possibly related: https://internals.rust-lang.org/t/bootstrap-fails-with-linker-error-while-running-on-non-nixos-nix-environment-wsl2-ubuntu/15066/2

Cannot reproduce on a empty project with a derive(thiserror::Error) struct.
Please check these:

nix flake update.
Are you using any cargo config like .cargo/config*, ~/.cargo/config* or $CARGO_HOME? Please disable them.
Delete target directory and run nix develop --ignore-environment -c cargo clippy --all-targets -- -D warnings

If possible, please also provide the (minimized) project's Cargo.toml and source code.

I am also getting this. It seems that the rustc binary is not properly patched and uses system libc:
❯ which rustc
/nix/store/lkmigamdvgjb0aipx782qrzizdp02w5j-rust-default-1.56.1/bin/rustc

❯ ldd $(which rustc)
        linux-vdso.so.1 (0x00007fff878d0000)
        librustc_driver-1a7f7f6d0c5586ea.so => /nix/store/dh285vqm29i487zfi57csbdjww7agyvz-rustc-1.56.1/lib/librustc_driver-1a7f7f6d0c5586ea.so (0x00007f35718d3000)
        libstd-65a28bf1738424c0.so => /nix/store/dh285vqm29i487zfi57csbdjww7agyvz-rustc-1.56.1/lib/libstd-65a28bf1738424c0.so (0x00007f3571527000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f35714ef000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f35714e4000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f35714dd000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f357130e000)
        libLLVM-13-rust-1.56.1-stable.so => /nix/store/dh285vqm29i487zfi57csbdjww7agyvz-rustc-1.56.1/lib/libLLVM-13-rust-1.56.1-stable.so (0x00007f356bf14000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f356bef9000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f356bdb5000)
        /nix/store/jsp3h3wpzc842j0rz61m5ly71ak6qgdn-glibc-2.32-54/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f35759df000)
        libz.so.1 => /nix/store/ds491f6b5pdk3xxnc2w103asyz1y4cfc-zlib-1.2.11/lib/libz.so.1 (0x00007f356bd98000)

Compared to the rustc in nixpkgs:
❯ ldd $(which rustc)
        linux-vdso.so.1 (0x00007ffe0dbe5000)
        librustc_driver-91277fe408b8ac49.so => /nix/store/sw7kr9clh3y3rpghgh50j023nbnwqz9i-rustc-1.55.0/bin/../lib/librustc_driver-91277fe408b8ac49.so (0x00007ff2674e7000)
        libstd-6556354a51bce6a2.so => /nix/store/sw7kr9clh3y3rpghgh50j023nbnwqz9i-rustc-1.55.0/bin/../lib/libstd-6556354a51bce6a2.so (0x00007ff26732b000)
        libc.so.6 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/libc.so.6 (0x00007ff267166000)
        libLLVM-12.so => /nix/store/a96n4dxdfk76sxmx8jmdiy3l2yhqzym4-llvm-12.0.1-lib/lib/libLLVM-12.so (0x00007ff260cb4000)
        libstdc++.so.6 => /nix/store/7fv9v6mnlkb4ddf9kz1snknbvbfbcbx0-gcc-10.3.0-lib/lib/libstdc++.so.6 (0x00007ff260add000)
        libgcc_s.so.1 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/libgcc_s.so.1 (0x00007ff260ac3000)
        libpthread.so.0 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/libpthread.so.0 (0x00007ff260aa3000)
        libm.so.6 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/libm.so.6 (0x00007ff260962000)
        libdl.so.2 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/libdl.so.2 (0x00007ff26095d000)
        /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/ld-linux-x86-64.so.2 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib64/ld-linux-x86-64.so.2 (0x00007ff26af14000)
        libffi.so.8 => /nix/store/2z8hacx9dphisbf7syd9hvkiw4578r23-libffi-3.4.2/lib/libffi.so.8 (0x00007ff26094e000)
        librt.so.1 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/librt.so.1 (0x00007ff260943000)
        libz.so.1 => /nix/store/c5giadpm71mvla6202mhz32x9criabna-zlib-1.2.11/lib/libz.so.1 (0x00007ff260926000)
        libncursesw.so.6 => /nix/store/jzjqfff4cldlm2wpld313a2s1v6r3ycb-ncurses-6.2/lib/libncursesw.so.6 (0x00007ff2608b4000)
        libxml2.so.2 => /nix/store/jjl2npsfbcwbd80c1ap6ls40s7hak53s-libxml2-2.9.12/lib/libxml2.so.2 (0x00007ff260746000)

More specifically, the (working) Nixpkgs one has rpath like:
$ readelf -d $(which rustc) | head -20

Dynamic section at offset 0x2da8 contains 28 entries:
  Tag        Type                         Name/Value
...
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/nix/store/sw7kr9clh3y3rpghgh50j023nbnwqz9i-rustc-1.55.0/lib:/nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib]
...

whereas the one from this overlay has
readelf -d $(which rustc) | head -20

Dynamic section at offset 0x61bc0 contains 31 entries:
  Tag        Type                         Name/Value
...
 0x000000000000001d (RUNPATH)            Library runpath: [/nix/store/dh285vqm29i487zfi57csbdjww7agyvz-rustc-1.56.1/lib]
...

where glibc is missing from the rpath.

I'm getting this error too on cargo clippy when using proc macros. I'm using Nix on Ubuntu 20.04.3 on WSL2.
$ ldd --version
ldd (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31

I tried Mozilla's overlay as well as using the cargo package from nixpkgs-unstable directly, and I'm getting the same error there as well.

More specifically, the (working) Nixpkgs one has rpath like:
...
where glibc is missing from the rpath.

That's unrelated. glibc is set as interpreter, so it automatically adds to RPATH. Even if you manually add it, it would still be stripped as unnecessary paths in the "shrinking RPATH" step.
I cannot reproduce it on my Arch VM, but do reproduce it on GitHub CI. The log said cargo is actually invoking cargo-driver from rustup, outside environment of nix. It's more weird that nix-shell --pure, which unset all environment variables outside, still doesn't help. I can confirm that cargo, cargo-clippy and clippy-driver are all reachable from PATH in nix-shell environment with type. Not sure what magic happens in here.
CI log, (using nightly default, but still it try to invoke rustup's stable clippy-driver)
https://github.com/oxalica/rust-overlay/runs/4398112100?check_suite_focus=true#step:5:22

I also run into this problem.  I can confirm that this only happened on Ubuntu with nix on CI, and works good on NixOS.

Okay, I got it. When cargo  searching for subcommands, it looks up $CARGO_HOME/bin/<cmd> first, then ~/.cargo/bin/<cmd>, finally through $PATH. This order is hard-coded in

https://github.com/rust-lang/cargo/blob/rust-1.57.0/src/bin/cargo/main.rs#L196-L202
https://github.com/brson/home/blob/v0.5.1/src/lib.rs#L108-L130

I don't think rust-overlay could do anything here, since we are building from upstream binaries and cannot patch the source.
For anyone running into this issue, please run rm -rf ~/.cargo/bin to get rid of non-nix binaries in CI environment.

@oxalica I don't have a very thorough understanding of Nix, but would it be possible to somehow use $CARGO_HOME in my Nix environment to prioritize the correct binary?

would it be possible to somehow use $CARGO_HOME in my Nix environment to prioritize the correct binary?

Yes and no. You can set it to rust-bin.<whatever-version>.default so it can pick up binaries from ours first. But if so, you are not able to use any 3rd party crates. cargo will try to write crate index and sources into $CARGO_HOME/registry and fail due to read-only /nix/store.
Personally, I hate the design of CARGO_HOME since everything related or unrelated is mixed and squeezed into a single directory, and you are not able to fine-tune each one, only can move the hodgepodge together around.

Oof. Looks like I'll have to uninstall Cargo, then. Thanks!

For future reference, when running into this issue it appeared to me as the following error:
error: process didn't exit successfully: `rustc -vV` (exit status: 127)
--- stderr
rustc: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

I searched for this error message on the issue log but couldn’t see something that fit. Based on what I read in https://github.com/NixOS/nixpkgs/issues/92946, I added the following to my devShell:
{
  LD_LIBRARY_PATH =
    # Clippy appears to requires zlib on linux
    lib.optionals pkgs.stdenv.isLinux
      (lib.makeLibraryPath [ pkgs.zlib ]);
}

This then uncovered the GLIBC_2.32 error:
 error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /home/runner/work/fathom/fathom/target/debug

This led me to this issue! Based on the above discussion, I removing my devShell hack above, and added the following fix which seemed to do the trick:
# This is a workaround for https://github.com/oxalica/rust-overlay/issues/54,
# avoiding link errors when running cargo commands with `nix develop`.
- name: Remove existing binaries from ~/.cargo/bin
  run: rm --recursive --force --verbose ~/.cargo/bin

Hope this helps anyone in the future!
Yet again wishing for https://github.com/rust-lang/rfcs/pull/1615 😅


Content management strategy for questions & translations

Is your feature request related to a problem? Please describe.
It is challenging to keep track of question text and translations, and ensure we aren't requesting translations that have already been created. Would also like to share best practices for questions and share translation work across the City/other entities.
Describe the solution you'd like.
Consider creating a repository in Github.
What priority is this?
A clear description of whether this is high, medium, or low priority for you and why (eg, it is majorly blocking a user group, it has been requested several times, etc).
Associated civic entity
Is this request associated with a specific civic entity? If so, please add the associated civic entity to the label (eg, label with 'seattle' if this request is coming from Seattle admins, CBOs, or residents.
User Group
If this request or piece of feedback comes from a resident, add the label 'Resident feedback'.
If this request or piece of feedback comes from a CBO or TI, add the label 'TI'.
If this request or piece of feedback comes from an admin, add the label 'Program Feedback'.
Additional Context
Add any other context or screenshots about the feature request here.
Done when:
What conditions need to be met before this issue can be closed?

@avaleske FYI

@elisekalstad would the thoughts in https://github.com/civiform/civiform/issues/5774 help with this?
Other relevant issues include:

A status page showing what translations are missing: #1240
Alerts if a translation is missing: #5243
Add Yes/No question type: #5907

https://designsystem.digital.gov/patterns/create-a-user-profile/

https://designsystem.digital.gov/patterns/create-a-user-profile/

@elisekalstad which pattern from that link are you calling attention to?

Gwen's ideas: do a separate repository for wiki, not part of main project code base; could also pair with "discussions" or start with "discussions" then move to wiki when finalized.


Leftover console.log

There is a leftover log statement in the render function of chrome/Chrome.js. As one can imagine, this spams the console quite a bit :D

#177

This issue should be reopened given that the leftover console.log has popped up again.
See comments on #174

+1

Thanks so much for the fix on this. Any chance of a fresh NPM version so we can install?


Push test artifacts to an artifactory instance to free space on Jenkins master

Recent serious test failures with core dumps resulting in large test artifacts have accelerated the need to switch to using artifactory for storing test artifacts.  Since this is already supported (merely a matter of using some pre-existing parameters in the test pipeline script, ARTIFACTORY_SERVER, etc).

Just need information on the existing AdoptOpenJDK artifactory server (and ensure credentials in Jenkins for it), to switch over to using it.

Storage on Jenkins server was increased so this will be closed for now (with option to re-open and complete if needed).


Getting an error when trying to sign message

On my ubuntu 20 machine I have already installed  and configured CryptoPro.
So now I am trying to sign message using number571/go-cryptopro but getting the following error:
E[-2146893792][CreateContainer: CryptGenKey]
panic: error code: -3

goroutine 1 [running]:
github.com/number571/go-cryptopro/gost_r_34_10_2012.GenPrivKey(0xc000048cb0, 0x4b99e0, 0xc0000ac401)
        /root/go/pkg/mod/github.com/number571/go-cryptopro@v1.0.3/gost_r_34_10_2012/gost.go:92 +0x25a
github.com/number571/go-cryptopro/gost_r_34_10_2012.init.0()
        /root/go/pkg/mod/github.com/number571/go-cryptopro@v1.0.3/gost_r_34_10_2012/gost.go:18 +0x69
exit status 2

Here is the code
cfg := gkeys.NewConfig(gkeys.K256, "mkk", "password")

	priv, err := gkeys.NewPrivKey(cfg)
	if err != nil {
		fmt.Println(err)
		return
	}

	msg := []byte("hello, world!")
	sign, err := priv.Sign(msg)
	if err != nil {
		fmt.Println(err)
		return
	}

        fmt.Println(msg)

@number571 plz help to solve this error

Hm... This problem from CryptGenKey(hProv, AT_SIGNATURE, CRYPT_EXPORTABLE, &hKey) C code line. You can find out the cause of the error in more detail using printf of the returned code in C and compare it with the Crypto Pro constants http://cpdn.cryptopro.ru/default.asp?url=content/csp_trunk/html/Titul.html. Maybe problem in CRYPT_EXPORTABLE param.

@number571 thank you very much.
@number571 what is the format for container name when trying to make a new config instance? jsut mkk or \HDIMAGE\mkk?

@number571 just noticed that go test also doesnt pass.
package<EMAIL_ADDRESS>go test -v -bench=. -benchtime=100x


Implement readline support

Without readline support, the repl is marginally useful:
Got:
$ yaegi
> import ""typo"^A^[[C^[[C^[[C^C

Is this something you'd consider for this project, or would a usable REPL be out of scope and best suited for a companion project?

The repl is minimalistic at the moment, and we wanted to start with no external dependencies, so yes I tend to see a real powerful REPL as a separate project, but no definitive opinion on that.
Note that you can always use rlwrap (install with your favorite package manager), and alias the yaegi command in alias yaegi='rlwrap yaegi' in your ~/.bashrc,  to have history and command line edition.


Change screen sharing end button accessibility label

When screen sharing is activated, the green button to end the screen sharing on the app has accessibility label "End". Meanwhile, the red button for finishing engagement also has accessibility label "End", which makes it complicated to assert that the screen sharing end button has appeared. With this pull request, the end engagement button will retain its "End" label, but the screen share end button will have "End screen share".
MOB-1406

!merge


Null Safety Support

Hi!
First, thanks for the great package!
I was just wondering if a new version with null-safety support is on the way?

Hi, what do you mean by null-safety? As in entering null in the text-field?

Thanks for the quick response.
Flutter 2.0 has introduced null-safety features:
https://flutter.dev/docs/null-safety
https://dart.dev/null-safety/understanding-null-safety
The last link in particular explains what it is and why it is beneficial.
It basically has to do with error handling and requires a few syntax changes to the code. It seems like this will become the norm from v2.0 onwards and needs to be supported by packages in the future.
They (Flutter team) have a video where someone showcases how to migrate an existing app to make use of the null-safety features in 2.0, but mention that every dependency should be upgraded to a null-safety supporting version as well before migrating your app.
According to the associated command this package does not yet support it:

Oh I see, I will be honest with you, I haven't been working with Flutter for almost a year or so properly and don't know what is going on that much.
I will pick up everything after the month of May as I will have more free time from backend work to start maintaining things properly and also creating other packages hopefully.

Thanks for the heads up, all done.


An error when I run SWAV:

when I use CPU in Aistudio to train this net, there is an error occupied :
Traceback (most recent call last):
File "tools/train.py", line 57, in
main(args, cfg)
File "tools/train.py", line 50, in main
trainer.train()
File "/home/aistudio/work/PASSL/passl/engine/trainer.py", line 330, in train
mixup_fn=self.mixup_fn)
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dygraph/layers.py", line 930, in call
return self._dygraph_call_func(*inputs, **kwargs)
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dygraph/layers.py", line 915, in _dygraph_call_func
outputs = self.forward(*inputs, **kwargs)
File "/home/aistudio/work/PASSL/passl/modeling/architectures/swav.py", line 67, in forward
return self.train_iter(*inputs, **kwargs)
File "/home/aistudio/work/PASSL/passl/modeling/architectures/swav.py", line 58, in train_iter
_out = self.backbone(paddle.concat(inputs[start_idx: end_idx]))
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dygraph/layers.py", line 930, in call
return self._dygraph_call_func(*inputs, **kwargs)
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dygraph/layers.py", line 915, in _dygraph_call_func
outputs = self.forward(*inputs, **kwargs)
File "/home/aistudio/work/PASSL/passl/modeling/backbones/resnetswav.py", line 118, in forward
x = self.bn1(x)
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dygraph/layers.py", line 930, in call
return self._dygraph_call_func(*inputs, **kwargs)
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dygraph/layers.py", line 915, in _dygraph_call_func
outputs = self.forward(*inputs, **kwargs)
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/nn/layer/norm.py", line 1096, in forward
sync_batch_norm_out, _, _, _, _, _ = _C_ops.sync_batch_norm(
AttributeError: module 'paddle.fluid.core_avx.ops' has no attribute 'sync_batch_norm'
How can I solve this problem?

You need GPU version of PaddlePaddle for SWAV


don't use turf.distance when calculating width of a degree grid

This pull request makes it so that you can make a grid of the entire world.
Right now if you do squareGrid([-180, -90, 180, 90], 10, 'degrees') weird stuff happens. I want to be able to do that without weird stuff happening.
I feel like there's probably a better way to do this that would allow grids larger than 50% of the earth to work even with other units. That's beyond my ken as of now, though.

"The whole world" in spherical mercator (web mercator) isn't quite [-180, -90, 180, 90], it's [-180, -85.05112877980659, 180, 85.05112877980659]. Right? Could that be why weird stuff is happening? Disclaimer: it could have nothing to do with the weird stuff here and I could be totally off-base.

@devTristan the turf grid methods are really meant for more localized analysis. "square" anything on the global scale is going to be warped and distorted either in how it looks or how it operates. If you want something for global grid analysis that will look nice on a web mercator map, I recommend using tile-cover. By aggregating counts on tiles, you end up with some spatial statistical distortion, but with a nice looking, normalized grid. Here is a code example of this in practice:
https://gist.githubusercontent.com/morganherlocker/481f0c61a20b48feb609/
given:

output:


URL Validation fails basic URL without a schema: www.google.com

Laravel Version: 9.23.0
PHP Version: 8.1.6

Description:
The url validation rule fails on a basic URL starting with www (without specifying the schema), e.g. www.google.com
Steps To Reproduce:
>>> Validator::validate(['test' => 'www.google.com'], ['test' => 'url'])
Illuminate\Validation\ValidationException

A valid url starts with a scheme.


Error message shows: Text fields are not optimised for operations that require Opensearch

"Text fields are not optimised for operations that require per-document field data like aggregations and sorting, so these operations are disabled by default. Please use a keyword field instead. Alternatively, set fielddata=true on [traceId] in order to load field data by uninverting the inverted index. Note that this can use significant memory."
Zipkin show this error message. Please help me resolve this. Thank you so much.

I think if we want to support open search, we need a docker image for it. similar to https://github.com/openzipkin/zipkin/tree/master/docker/test-images/zipkin-elasticsearch7
Are you able to help create this? If not, let us know.

I was able to resolve this error by removing my manually defined index template for zipkin spans. For some reason the traceId was getting mapped to text. When I use the one generated by Zipkin, it maps traceId to keyword only which allowed me to perform searches in the Zipkin ui.

thanks for explaining your resolution, as it helps the next person!


Initial draft to store users persistently using oneffs

//cc @PizieDust
The assumption is: we can retain the stuff in memory. We write to disk on change (at the moment, whenever a new user is created). We keep a reference to the latest store in unikernel.ml (request_handler) - thus we can extract data from !store.
We read the store only once at startup (since later we know about each change and don't need to read again).
Obviously we can have more data (and more types) in there ;)

Thanks! We may consider switching to @hannesm's filesystem from tlstunnel (IIRC). OneFFS is designed with the assumption it is preferable to lose data than have old data (useful for caching). For mollymawk we probably prefer not to lose the user database and instead have failed updates while keeping the old state. If we make backups of the database from the host it's likely not too bad.

Indeed, @reynir. This was meant as a first step, since oneffs is packed up nicely into opam-repository. Of course we can extract the filesystem from tlstunnel and make it available as an opam package. :)


[main] Upgrade to latest dependencies

Cron -knative-prow-robot
/cc knative-sandbox/networking-wg-leads
/assign knative-sandbox/networking-wg-leads
Produced by: knative-sandbox/knobots/actions/update-deps
Details:
bumping knative.dev/networking 8925a50...7390d8c:
  > 7390d8c upgrade to latest dependencies (# 464)

/retest
setup issue.

/hold
The PR is adding empty resources.

@dprotaso Do you have an idea why this PR inserts the empty {}?
https://github.com/knative-sandbox/net-istio/pull/707/files#diff-5a3762febd0f18f90ea54d7e85f460aa71eead72b596c01d59de1db3525aee60R8524-R8525

Fixing by https://github.com/knative-sandbox/net-istio/pull/708


Modified massiveMigrate to check for and return errors after the mass…

…ive connect, ensureMigrationTableExists, and a second connect.
Modified the tests to verify that an error didn't occur after the massiveMigrate and before the runUpMigration.
Modified the test's beforeEach to deal with errors in removeTables.

These changes allow the error I was encountering (Error: permission denied to create extension "uuid-ossp") to be detected/reported by the tests.


Fix UI template image

Docs Build status updates of commit 37f6986:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/assets/images/ui-templates/empty-state.png
:white_check_mark:Succeeded
View

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


Timing bug for Pytorch momentum and nesterov resnet and conformer

Description
Pytorch momentum and nesterov algorithms submission times don't add up: the update and eval times do not add up to the total submisison time. The result is that the meausred submission times for momentum on resnet and momentum and nesterov on conformer are 20% and 50% faster than the other algorithms.
Steps to Reproduce
On branch timing_test_2 (diffs w main are summarized below) run:
torchrun --redirects 1:0,2:0,3:0,4:0,5:0,6:0,7:0 --standalone --nnodes=1 --nproc_per_node=8 submission_runner.py --framework=pytorch --workload=imagenet_resnet --submission_path=baselines/momentum/pytorch/submission.py --tuning_search_space=baselines/momentum/tuning_search_space.json --data_dir=/data/imagenet/pytorch --num_tuning_trials=1 --experiment_dir=/experiment_runs --experiment_name=debug_momentum_timing  --overwrite=True --save_checkpoints=False --max_global_steps=28000 --imagenet_v2_data_dir=/data/imagenet/pytorch 2>&1 | tee -a imagenet_resnet_pytorch_timing.log

Note you'll probably want to modify the paths for the data_dir and imagenet_v2_data_dir depending on where your data is stored.
Also for convenience the command for conformer momentum:
torchrun --redirects 1:0,2:0,3:0,4:0,5:0,6:0,7:0 --standalone --nnodes=1 --nproc_per_node=8 submission_runner.py --framework=pytorch --workload=librispeech_conformer --submission_path=baselines/momentum/pytorch/submission.py --tuning_search_space=baselines/momentum/tuning_search_space.json --data_dir=/data/librispeech --num_tuning_trials=1 --experiment_dir=/experiment_runs --experiment_name=timing_v3_b_pytorch/timing_momentum --overwrite=True --save_checkpoints=False --max_global_steps=20000 --librispeech_tokenizer_vocab_path=/data/librispeech/spm_model.vocab 2>&1 | tee -a librispeech_conformer_pytorch.log

The main diffs between the timing_test_2 branch and main branch are:

I moved the pytorch sync for train_step_start time to  before the prng fold_in step consistent w the jax timing.
Include data_selection time for debugging

Source or Possible Fix
The issue is most likely a bug related to how we time the pytorch DDP update because the eval times and submission times don't add up to the total time.

@runame Maybe this is the link you are talking about?

Yeah, the keyword is torch.cuda.synchronize(), I don't think this is used anywhere in the timing code. See the brief note here. Maybe this is already the bug, but there is also more sophisticated stuff, see e.g. here -- I haven't looked into this though.


Can't develop locally with docker

docs.konghq.com url(s):

Summary
I produced a custom plugin and attempt to make a contribution to Kong
After add my index.md, I attempt to build the kong website by developing locally with docker.But there's some mistake when building it. It report jekyll_1  | npm ERR! Error: EACCES: permission denied, unlink '/usr/bin/yarnpkg'
Steps To Reproduce
1.I add my own index.md and logo into the right dictionary
2.Execute the command make develop under the dictionary docs.konghq.com
3.It reported two errors jekyll_1  | npm ERR! Error: EACCES: permission denied, unlink '/usr/bin/yarnpkg' and jekyll_1  | npm ERR! Error: EACCES: permission denied, unlink '/usr/bin/gulp'
Additional Details
The error logs
jekyll_1  | npm ERR! path /usr/bin/yarnpkg jekyll_1  | npm ERR! code EACCES jekyll_1  | npm ERR! errno -13 jekyll_1  | npm ERR! syscall unlink jekyll_1  | npm ERR! Error: EACCES: permission denied, unlink '/usr/bin/yarnpkg' jekyll_1  | npm ERR!  { [Error: EACCES: permission denied, unlink '/usr/bin/yarnpkg'] jekyll_1  | npm ERR!   cause: jekyll_1  | npm ERR!    { Error: EACCES: permission denied, unlink '/usr/bin/yarnpkg' jekyll_1  | npm ERR!      errno: -13, jekyll_1  | npm ERR!      code: 'EACCES', jekyll_1  | npm ERR!      syscall: 'unlink', jekyll_1  | npm ERR!      path: '/usr/bin/yarnpkg' }, jekyll_1  | npm ERR!   stack: jekyll_1  | npm ERR!    'Error: EACCES: permission denied, unlink \'/usr/bin/yarnpkg\'', jekyll_1  | npm ERR!   errno: -13, jekyll_1  | npm ERR!   code: 'EACCES', jekyll_1  | npm ERR!   syscall: 'unlink', jekyll_1  | npm ERR!   path: '/usr/bin/yarnpkg' } jekyll_1  | npm ERR!  jekyll_1  | npm ERR! The operation was rejected by your operating system. jekyll_1  | npm ERR! It is likely you do not have the permissions to access this file as the current user jekyll_1  | npm ERR!  jekyll_1  | npm ERR! If you believe this might be a permissions issue, please double-check the jekyll_1  | npm ERR! permissions of the file and its containing directories, or try running jekyll_1  | npm ERR! the command again as root/Administrator (though this is not recommended). jekyll_1  |  jekyll_1  | npm ERR! A complete log of this run can be found in: jekyll_1  | npm ERR!     /home/jekyll/.npm/_logs/2019-06-26T08_38_51_088Z-debug.log
jekyll_1  | npm ERR! path /usr/bin/gulp jekyll_1  | npm ERR! code EACCES jekyll_1  | npm ERR! errno -13 jekyll_1  | npm ERR! syscall unlink jekyll_1  | npm ERR! Error: EACCES: permission denied, unlink '/usr/bin/gulp' jekyll_1  | npm ERR!  { [Error: EACCES: permission denied, unlink '/usr/bin/gulp'] jekyll_1  | npm ERR!   cause: jekyll_1  | npm ERR!    { Error: EACCES: permission denied, unlink '/usr/bin/gulp' jekyll_1  | npm ERR!      errno: -13, jekyll_1  | npm ERR!      code: 'EACCES', jekyll_1  | npm ERR!      syscall: 'unlink', jekyll_1  | npm ERR!      path: '/usr/bin/gulp' }, jekyll_1  | npm ERR!   stack: 'Error: EACCES: permission denied, unlink \'/usr/bin/gulp\'', jekyll_1  | npm ERR!   errno: -13, jekyll_1  | npm ERR!   code: 'EACCES', jekyll_1  | npm ERR!   syscall: 'unlink', jekyll_1  | npm ERR!   path: '/usr/bin/gulp' } jekyll_1  | npm ERR!  jekyll_1  | npm ERR! The operation was rejected by your operating system. jekyll_1  | npm ERR! It is likely you do not have the permissions to access this file as the current user jekyll_1  | npm ERR!  jekyll_1  | npm ERR! If you believe this might be a permissions issue, please double-check the jekyll_1  | npm ERR! permissions of the file and its containing directories, or try running jekyll_1  | npm ERR! the command again as root/Administrator (though this is not recommended).

Those errors should be ignorable in my experience.

here's a screenshot of that section from my run of make develop whereby it gets the error but continues on until it eventually
jekyll_1  | [09:25:08] Finished 'default' after 1.43 min
jekyll_1  | [ ▶ ] Access URLs:
jekyll_1  |  -----------------------------------
jekyll_1  |        Local: http://localhost:3000
jekyll_1  |     External: http://<IP_ADDRESS>:3000
jekyll_1  |  -----------------------------------
jekyll_1  |           UI: http://localhost:3001
jekyll_1  |  UI External: http://localhost:3001
jekyll_1  |  -----------------------------------
jekyll_1  | [ ▶ ] Serving files from: dist

I have been solved this problem and built successful. There was two problem when I attempted to build it and  I think it's maybe helpful to others.

The problem of permission
It's the  problem of file owner and group. I work with the root right all the time, but  the file owner and group in docker is my username. Run chown -R <username>:<username> docs.konghq.com/ and then it works.
The ram of the docker
After solve the permission problem, there was another problem that the docker container exited with code 137. It's the problem caused by the docker ram constraint. I work under ubuntu in the VMWare and allocate 1G ram. Because of the resource constraint of docker, the building process exited with cod 137. After increase the ram, I solved the problem and built successful. I think it maybe happen in high probability  who works in virtual machine which has a low resource.

glad to hear you got this sorted


Add program-level quit convenience method

This update adds a convenience function for quitting Bubble Tea programs from outside a Program. So instead of doing this:
p := tea.NewProgram(...)
p.Send(tea.Quit())

You can just…
p := tea.NewProgram(...)
p.Quit()

Can you please add an example of this command?


Question: Where do I add exactly the CNAME?

The instructions say: You can configure a custom domain with GitHub Pages by adding a CNAME file to the public/ folder.  I tried adding the public folder to my repo's root and to src, folder, but there's no CNAME in my build folder still.. what's the correct place for it?

Can you tell us which version of react-scripts are you using? (npm ls react-scripts)
The public folder should already be existed. I have noticed that you need to add the public folder to your repo's root, does that mean there is no 'public' folder already?

I have<EMAIL_ADDRESS>don't recall if I've deleted such a folder though.

It seems I have moved the favicon.ico to src and the index.html from the public folder crapp created -- this is not okay probably?

I see. The issue is that in 0.5.0 we had a breaking change, which introduce the public folder detail
Please update your react-scripts. You can follow the migration guide to keep your current code base, one by one. You can also re-init a new app and move your code base there, but it is not really safe. Do the migration is a lot safer.

Will do, thanks!

Seems like it got resolved.

Does anyone have an example CNAME file used in this context? Thanks.

@alex-wilmer the CNAME file should just be verbatim the address in your DNS record that points to github via CNAME.
e.g. blog.example.com or example2.com
You can find more information here (which suggests you might not even need a CNAME file, don't quote me tho): https://help.github.com/articles/using-a-custom-domain-with-github-pages/

@Timer thanks for the response. If you can suggest a better venue for troubleshooting this I would be happy to move there. I always seem to have trouble wrapping my head around DNS.

the file

does it need to be named something in particular? or literally a file called CNAME ?
This is the site on github pages http://torontojs.github.io/torontojs.com/
The domain is torontojs.com and www.torontojs.com (through goDaddy I believe? I'm communicating with owner of the account intermittently)
If I'm correct, the current CNAME record on godaddy is pointing to torontojs.github.io (which may or not be sufficient?). I followed the instructions in the link you pasted earlier but the app is trying to resolve the bundle in the wrong location.

It should just be a file named CNAME, no extension, with www.torontojs.com in the file. If you don't want to use this approach you can follow these instructions.

@Timer thank you very much! That indeed did the trick. In case anyone else needs to see an example https://github.com/torontojs/torontojs.com/tree/gh-pages


Strange behavior with event listener

So, I have two events for this example:
requestHoist and requestHoist:cancel
socket.on('connect', () => {
     Alloy.Log(`[Socket - Connected]`)

     //
     socket.on('requestHoist', requestHoistFunc)
})

...

//
function requestHoistFunc (evt) {
   // some logic

   socket.on('requestHoist:cancel', resetStatus)
   socket.off('requestHoist', requestHoistFunc) // prevent further requests
}

...

//
function resetStatus () {
  // Here I do an off on all listener and re-add the requestHoist
  socket.off('requestHoist', requestHoistFunc)
  socket.off('requestHoist:cancel', resetStatus)

  socket.on('requestHoist', requestHoistFunc)

  // some more logic
}

The strange behavior starts now... when I receive that cancel event, I CAN'T receive requestHoist event again unless I put my app on background and comes back to foreground again.
I already tried to set an delay to re-add requestHoist listener but still it doesn't work until I do background then foreground and when I do so, when I fire the requestHoist(from server) again, I get it twice on the app... I never face that strange behavior before and I don't know why it's happening... maybe someone here could help me?
TiSDK 7.5.1.GA
Both platforms
iOS -> 1.1.2
Android -> 2.0.0

Hi, i know this issue is pretty old, however, we just released new versions of the socket.io module so i'm going through open issues to close them out.
I'm sure you figured it out by now, but just for the record, there is a logic issue in your posted example. You explicitly call socket.off('requestHoist', requestHoistFunc) in your requestHoistFunc so you won't receive any of those events. There was also an issue in iOS where sometimes event listerners weren't properly removed, which was fixed in the latest version, which explains the duplicate events you received.


Change import paths to github.com/ssbc

The repos were moved and it is time to update the import paths. I also made sure that we use the latest versions.

This relates to failures such as:
Error: service/domain/network/local/discoverer.go:12:2: unrecognized import path "go.cryptoscope.co/netwrap": https fetch: Get "https://go.cryptoscope.co/netwrap?go-get=1": dial tcp <IP_ADDRESS>:443: connect: connection refused

This showed up because some infra went down I imagine which reminded me to update those import paths :laughing:. So I guess the result is positive.


Added eraser and updated readme for snakepaint

Sorry it's taken me a while to get back on this, I haven't tested this yet but the eraser mechanic seems a little bit unnatural from the way it's described. Do you think it would be more intuitive to just have a simple toggle? As in, you just press D and it turns eraser mode on/off?
Like I said, I haven't tested this yet, maybe when I try it out it's more intuitive than I'm thinking. Let me know your thoughts!

Ah, yeah. Don't merge it yet i'm currently trying to create toggle mechanic


Add ability to ignore failures on certain environments

Adds ability to configure a regular expression to indicate environments that can ignore errors. If an environment ignores errors the UI will use a gray icon instead of a red one. The deploy widget will only turn red if an environment that is not ignoring errors fails.
Use case: There are cases when we don't care if an environment is down. In a blue/green stage-active deployment we never care about the "staging" environment. Without this change the deploy widget will almost always be red (as usually no code is staged).
** Update **
Configuration is specified in the deploy widget config
Requires PR #891

Update: Added additional ability to configure on a per dashboard basis.

@MarkRx we might have merge some PR's out of order. Can you see if this conflict can be resolved?

@MarkRx this needs few quick manual merging.

rebased & squashed

Looks like you are saving this config as a system global config. Better if we save it within the widget config. And then modify the deploy widget to have the user to enter the regex pattern. We don't want the same regex affecting every user or we don't want to change the properties file everytime there is a new regex.
Thoughts?

Will look at next week.

@tabladrum done. Screenshot above.
Rebased.

@pxk5958

Done. Will go through an rebase everything once #1042 is merged in.

rebased onto master 2.0.5

@MarkRx @tabladrum  - Does the regex to ignore failures check for environment names and deployment job names.

@nireeshT just the environment names.


Babel plugins

👎 I do not like the idea of changing the functional components by simply classes to place this
static propTypes = {
    router: React.PropTypes.object,
    handleLogoClick: PropTypes.func
};

keep comma-dangle rule

Closing this as the request is inactive for a long time.


adding list of future improvement ideas

yeah - I was actually wondering the same...
My thought behind adding them to the README was more that these are some very high-level "roadmap" items - without any additional details so far.
What are your thoughts about creating such issues which don't have a lot of content?

I think I would still prefer the individual issues and maybe create a project board as a roadmap and put them on there and link in the README if this visibility is desired :)

well - I actually added them as milestones and issues 🙂


Helm repo

repo with clickhouse chart

@lohmag Thanks for the pull request.  We use a DCO on the project. This requires Git signoff. The checks tab at the top of the pull request will show you how to add it to your commits.

@mattfarina done


Show a warning: root folder must contain cargo.toml

FYI-- unless the root project folder added to Atom contains the Cargo.toml, the RLS won't work.
I didn't have any warnings about this requirement in Atom, but did in VSCode.

Rls now sends build failure notifications

It still isn't obvious that you should add a root Cargo.toml. Perhaps we should add a hint client side?

If we can resolve https://github.com/rust-lang-nursery/rls/issues/723 so that ide-rust can listen to build-finished (fail/success) I'll be able to fairly easily add functionality including scanning for a Cargo.toml in parent dirs and showing a hint to add one if not found.

With https://github.com/rust-lang-nursery/rls/pull/657 (ie in the next Rls release) the Rls error message has improved.

This is now good enough to point people in the right direction. Maybe in future we could add a button to auto generate an appropriate Cargo.toml. For now I think this satisfies the issue so I'll close.


Preloading with belongs_to association results in wrong preloaded record (incorrect commit referenced)

Environment

Elixir version (1.2.4):
Database and version (PostgreSQL 9.4):
Ecto version (2.0.0.rc.0..2):
Database adapter and version (postgrex 0.11.1):
Operating system: OS X 10.11.4

Current behavior
I'm loading a simple list of posts with an associated user
   posts =       Post       |> Repo.all       |> Repo.preload(:user)
If I compare post.user_id == post.user.id, I get different results which is wrong.
This happend after an upgrade from 2.0.0.beta.2 to 2.0.0.rc.0.
I tracked the error down to this commit: #1353
fetch_ids = Enum.sort(fetch_ids) |> Enum.reverse() in the commit seems to break a normal associations.
Expected behavior
I should get the correct associated user. post.user_id == post.user.id

Hey, I don't know, if it can help you, but I had my keys messed up today, solved it by updating PostgreSQL to 9.5.2.
Maybe it can help you too.

@sbrink thank you, I will investigate. Meanwhile, could you please try to add a test to our suite? They would be in integration_test/cases/preload.exs. You can run them as MIX_ENV=pg mix test. Thank you!

I can confirm the bug.
@VladShcherbin PG does not guarantee an order to return results if there is no order by, many times, it is by ID, but sometimes it isn't. Upgrading PG may temporarily solve it but the bug is still there. :)

@josevalim: I'll try again. I already found the test file earlier. But it's really some weired behaviour. If I limit the number of posts, I get the correct users again.
@VladShcherbin I'll try that, too

@josevalim thank you! :)


Update trigger.md

Description
Corrected a small grammatical error.
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)

ΛDΛM#9336

Thank you!


txInfo from col-4

Hi!
I have a problem calling txInfo for transaction made in col-4. I am getting 404 not found error while in terra finder it works like a charm.
Here is an example call:
await terra.tx.txInfo('D7BC896AAF3168DC44A2F2F30E47BD9DCB0ADDDB71F74EAFDAC49752205444C4')
terra is in this case LCDClient initialised with col-5
Could you please check this scenario?

+1

not available with LCD. LCDs have data from genesis of col-5 only.


Unable to launch kernel "MIOPEN_DEBUG_CONV_DIRECT_ASM_5X10U2V2"

See detailed issue found in JIRA http://ontrack-internal.amd.com/browse/SWDEV-277901
MIOpenDriver conv -W 341 -H 79 -c 32 -n 4 -k 32 -y 5 -x 10 -p 0 -q 0 -u 2 -v 2 -t 1 -V 0 -i 1
MIOpen Error: /root/Staging/MathLibs/MLOpen/src/hipoc/hipoc_kernel.cpp:86: Failed to launch kernel hipErrorLaunchFailure
RunForwardGPU() failed, rc = 0x7

I've narrow it done to a ASM kernel, by disabling it, the issue is gone would
export MIOPEN_DEBUG_CONV_DIRECT_ASM_5X10U2V2=0

The original issue is about:
if the actual launch param exceed the source specified launch param then the runtime will reject the launch

However, I'm not able to find anything wrong with launch parameter, so I don't know what the root cause of the failure.
Step to reproduce the failure:

launch the docker as given in the JIRA
cd /root/driver/MLOpen/build_hip/
make -j MIOpenDriver
run MIOpenDriver command as given in the JIRA

@muralinr Please look into this issue to find out if this is a launch parameter issue or not. Need you assembly expertise on this issue
cc @JehandadKhan @atamazov

Hello, It's not a MIOPEN issue. I looked at ASM source code and kernel launch solver code to cross check it.  Workgroup info  specified is same in both files.
ASM source filev (kernels/conv5x10u2v2f1.s)
.reqd_workgroup_size: [ 64, 8, 1 ]
Solver file (solver/conv_asm_5x10u2v2f1.cpp):
construction_params.l_wk.push_back(64);
construction_params.l_wk.push_back(8);
construction_params.l_wk.push_back(1);

Should be fixed by #931.


Fix integration tests

This PR is to fix the integration tests that are currently pinned to a working commit
#200

Some additional context that I've found around this.
The tests are failing due to an already known issue, #213, with the container logs format using json-file format. A request was made to convert cri-dockerd to use the cri format for logs.
After digging into this, cri-dockerd is not doing much of anything with the logs. In fact, all it currently does is create a symlink in the pods directory to the log file that is created by docker.
I've started making changes that will instead read the contents from the docker logs file, change the format to CRI, and output the result to a new separate file in the pods folder.


Request OSS-Fuzz project owner approval before importing OSS-Fuzz reports

Automating vulnerability reports from OSS-Fuzz is great, but the unfortunate fact is that OSS-Fuzz is very noisy. It's quite frequent that infrastructure changes cause false positives (see https://github.com/google/oss-fuzz/issues/11881).
Prior to OSV, this was fine because false positive reports could simply be ignored, and then OSS-Fuzz will automatically close them later. Fuzzing is super valuable, so we were more than happy to tolerate a moderate false positive rate, in exchange for avoiding false negatives, provided that false positives were low cost.
OSV completely throws this equation off. As soon as a bad report is imported into OSV, a ton of busywork is triggered downstream. The more OSV is used, the worse this will become. See, for example, https://github.com/google/oss-fuzz-vulns/pull/37 where every imported report was incorrect.
Fuzzers are incredibly valuable, and we do not want to be forced to shut off fuzzers because OSS-Fuzz's false vs true positive tradeoffs are no longer viable.
I think the most natural fix here is that, prior to importing from OSS-Fuzz, OSV should ping the project owners and provide an automated way for project owners to modify the imported report. If the maintainers don't respond after a short period of time, it can import automatically. But maintainers who are active need to have some way to deal with this noise, or we'll have to stop fuzzing.

I came here from https://github.com/google/oss-fuzz/issues/11925 and while I agree that it certainly makes sense to let maintainers vet OSV entries before they are published I think it would be nice if all the entries were published anyway. There are projects that can reject things left and right and it would still be useful to be able get the "raw" feed to double-check.
(more generally I think that the problem is that OSV consumers can be a bit overzealous in that everything is treated as "vulnerability" without vetting anything. Maybe there should be a way to say that some entries are generated based on automated tools and should be vetted. If they are confirmed by maintainers consumers can be confident that entries are vulnerabilities. I proposed "confidence" in another context https://github.com/google/osv.dev/issues/918 but it can probably be applied here)

Maybe there should be a way to say that some entries are generated based on automated tools and should be vetted.

This is a very interesting thought: being able to weight (or even filter) vulnerabilities by their source

That would not be acceptable to us, no. Unfortunately, that is not the reality of how these data sources are consumed. No matter how much weighting you apply, if the system claims that completely fabricated things as vulnerabilities, it will cause a lot of downstream churn, with the churn increasing the more successful you all are at getting your data source to be used.
If there is no way for BoringSSL team to withdraw false positives before they ever make it to OSV, we will be forced to remove our project from OSS-Fuzz and rely on fuzzing in other systems. This would be a significant security loss for everyone. Weighting is not sufficient unless the weight can be set to zero.
To be clear, false positives here doesn't mean there was a subjective disagreement over whether an issue had security consequences. False positives here means the issue did not exist. OSS-Fuzz has false positives all the time when the compiler infrastructure needed to check for uninitialized memory, or other errors, broke. Most recently, it looks like the instrumented C/C++ runtime did not get picked up, so it mistakenly believed all strings were uninitialized. A BoringSSL user could not apply a fix for this issue if they wanted to, because there is nothing to fix.

Unfortunately, that is not the reality of how these data sources are consumed. No matter how much weighting you apply, if the system claims that completely fabricated things as vulnerabilities, it will cause a lot of downstream churn

I completely agree. It annoys upstream projects too when it reaches them. I stopped integrating new projects like https://github.com/google/oss-fuzz/pull/8699 into OSS-Fuzz when I can fuzz them elsewhere to avoid dealing with all that.

withdraw false positives before they ever make it to OSV

My concern is that it offloads that onto upstream projects. I believe that OSV consumers (or whoever relies on that feed) should be able to deal with false positives and bogus vulnerabilities in general.
(Anyway I agree with you that it's not perfect and I'm glad that it has been brought up because I gave up at some point)

Ah yeah, I guess I filed this as a thing for OSV to notify project owners, and that may not be the best option. (I filed a lot of bugs here and mentally mixed them up. 😄) That might be a little annoying. I think I also was assuming OSS-Fuzz was immutable and the fix would have to be in OSV, which introduced the bad assumption on OSS-Fuzz data quality, but perhaps we can do better.
My general feeling is that the earlier a mistake is fixed, the less fanout there is, and the less of a pain everything is. If bad statuses are fixed in OSS-Fuzz, they never make it to OSV. If bad statuses are fixed in OSV, they never make it to OSV consumers. Etc.
How about this as the roadmap?

OSS-Fuzz needs to provide an easy way for project owners to adjust issue status and severity without having to summon an OSS-Fuzz maintainer (https://github.com/google/oss-fuzz/issues/11939 and https://github.com/google/oss-fuzz/issues/11925)
OSS-Fuzz keeps track of whether each issue has been triaged by the project owner, or if it's just totally automated.
To make sure project owners know these now matter (they previously did not), perhaps there should be an automated reply to the issue some time before the issue is made public or imported to OSV or something else. It was a huge unpleasant surprise to me to learn that OSV even existed and had been claiming all these false positive issues as vulnerabilities. (I found out because some tooling at Google started monitoring this and caused me a ton of busywork.)
When OSV imports an issue, if the issue was not triaged, include a big warning that this may not be a real security issue due to frequent OSS-Fuzz false positives
If the project owner later triages the OSS-Fuzz report, OSV should automatically update its entry
OSV should not remove the explicit notice about OSS-Fuzz false positives until something like https://github.com/google/oss-fuzz/issues/11941 is implemented.

It was a huge unpleasant surprise to me to learn that OSV even existed and had been claiming all these false positive issues as vulnerabilities

I think new projects should also be made aware of this integration with OSV upfront because there are projects that just don't want to be involved in any sort of vulnerability management (they can barely fix bugs fuzz targets throw at them).
As far as I can remember in https://seclists.org/oss-sec/2019/q2/165 some things about autogenerated vulnerabilities were discussed. It was kind of controversial but maybe some ideas can be borrowed.

I think there's some blurriness between the OSS-Fuzz and OSV.dev lines here, and I admit I'm not intimately familiar with the lines myself because they are blurry...
Generally speaking, OSV.dev is an aggregator of upstream data sources, and OSS-Fuzz should be able to be thought of as a data source like any other. I think this issue is more appropriate to OSS-Fuzz directly, rather than OSV.dev.
We get feedback like this often enough, where OSV.dev is the messenger, not the originator of the message.

@oliverchang should this be moved over to OSS-Fuzz?

Well, it's a little subtle because OSV is interpreting OSS-Fuzz data in a way that does not match reality. Whether explicitly designed as such or not, OSS-Fuzz is set up so that you cannot assume the data in it works as a source of vulnerabilities. That was fine up until OSV existed. So the immediate cause of the problem is OSV.
But the best fix isn't always necessarily at the immediate cause, so if OSS-Fuzz is on board with doing the dev work needed to support OSV's interpretation (i.e. dramatically shore up project owners' ability to triage issues and correct statuses), that works for me!
That said, I don't think there's any solution that doesn't involve some OSV changes. I think we do need OSV to be much, much more explicit about when issues are unconfirmed, and probably to notify on OSS-Fuzz so that project owners know that the new ramifications of untriaged are clearer.

OSS-Fuzz should be able to be thought of as a data source like any other

It's true but OSV consumers go to upstream projects either directly or via, say, RedHat Product Security to complain about unfixed bugs. In the past bogus CVEs were filed based on OSV data.
I really like the plan proposed in https://github.com/google/osv.dev/issues/2176#issuecomment-2105139193 because it should help to reduce the number of false positives and things like that on the OSS-Fuzz side that but I don't think it's ever going to be safe to assume that every OSV entry coming from OSS-Fuzz is a vulnerability so it should be easy for upstream projects to withdraw/correct entries and consumers should be prepared to vet things themselves.

Turns out it's possible to turn this off so I opened https://github.com/google/osv.dev/pull/2222 (I'll probably add more projects later).

OSV completely throws this equation off. As soon as a bad report is imported into OSV, a ton of busywork is triggered downstream

Given that to judge from https://github.com/ossf/scorecard/pull/3903 half-baked SBOMs are on their way and I presume they should be integrated with OSV/GUAC (though it's hard to tell because as usual PRs are merged with no rationale and details there) I really think this import should be off by default and projects should be made aware of this integration.

Thanks for all the feedback. It's important for us to not turn this off by default for all OSS-Fuzz projects, because we've more often than not observed projects fixing vulnerabilities without ever notifying downstream consumers or requesting a CVE (because it's a lot of work). Hopefully, by adding some metadata to indicate an OSS-Fuzz entry is fully automated and had zero human triage, we can address some of the concerns around quality.
That said, there's a lot of gaps with our current UX, and we'll start planning suggested improvements on https://github.com/google/osv.dev/issues/2176#issuecomment-2105139193 and others soon.

I'd still appreciated it if https://github.com/google/osv.dev/pull/2222 was merged. When the boringssl maintainers are OK with the UX I think it should be fine to unblock those projects too.

It's important for us to not turn this off by default for all OSS-Fuzz projects

That would really be a bummer but with the UX improvements it's still based on the assumption that someone is going to vet those bug reports and I don't think it's going to happen. As mentioned elsewhere I think one option would be to separate the OSS-Fuzz feed from OSV and let consumers who are actually prepared to deal with those bug reports deal with those bug reports.

Hopefully, by adding some metadata to indicate an OSS-Fuzz entry is fully automated and had zero human triage, we can address some of the concerns around quality.

On the OSV consumer side, what's the intended use of this metadata? E.g. would you advise OSV imports at Google to ignore the entries with the bit set? If not, the bit alone isn't very effective.

That would really be a bummer but with the UX improvements it's still based on the assumption that someone is going to vet those bug reports and I don't think it's going to happen.

Not only that, it's currently not possible to vet bug reports. We (BoringSSL) generally keep up with our OSS-Fuzz reports, but there is no mechanism in OSS-Fuzz for us to triage them at all. When OSS-Fuzz is wrong, our only option is to ignore the report and leave the incorrect data alone.
That option was fine before OSV. After OSV, it's a problem.


TODO and FIXME are not highlighted

From kamil.paral on 2011-05-30T03:51:49Z
What steps will reproduce the problem?

I have enabled Tasks highlighting in program preferences. It works for XXX, HINT and TIP, but it doesn't work for TODO and FIXME.

See screenshot. What version of the product are you using? On what operating system? Spyder 2.0.11, Fedora 14
Attachment: screenshot_001.png
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=672

From pierre.raybaut on 2011-05-30T11:39:52Z
This issue was closed by revision 0892870a6ba9 .
Status: Fixed

From pierre.raybaut on 2011-05-30T11:41:06Z
This issue was closed by revision b262a45b5855 .

From pierre.raybaut on 2011-05-30T11:40:40Z
This issue was closed by revision 94a34b7957a6 .

From pierre.raybaut on 2011-05-30T13:39:58Z
Anytime ;)

From kamil.paral on 2011-05-30T11:45:45Z
Great response time, thanks!


feat!: new API for defining actions

I also realized that users are required to set up toast manually. see mobile/src/provider/index.tsx. this stuff should be provided by the toast kit

In the morning, we discussed that we would rather leave setting up environment and required providers up to users, depending on their mobile application situation. For example, kit-react-navigation should expect React Navigation provider to be already in the tree. Expo Haptics should require being configured.
We could make an exception for Toast, as it requires a bunch of "stuff" to be present, but as far as React Navigation / Expo Router / Expo Haptics are concerned, I would rather wait and see till we get more adoption.

yeah I think toast makes sense to include. of course navigation would require outside setup. not sure what configuration would be required for haptics


'ionic serve' sometimes serves old code

Note: for support questions, please use one of these channels:
https://forum.ionicframework.com/
http://ionicworldwide.herokuapp.com/
Short description of the problem:
ionic serve sometimes serves old versions of my code
What behavior are you expecting?
not to do that.
Steps to reproduce:

run 'ionic serve'
2.test app for up to an hour.  at some point it will revert back to previous version.

insert any relevant code between the above and below backticks

Which @ionic/app-scripts version are you using?
3.1.8
Other information: (e.g. stacktraces, related issues, suggestions how to fix, stackoverflow links, forum links, etc)

+1 i put up the #1434  issue about a month ago,but my issue is always , still no response from the devs for almost a month

This is a difficult issue to track down. In our tests, we have not been able to replicate this. So not sure how much more we can track down. If you dont mind, can you create a minimal test case app, and push it to github? This will help us best debug the issues

merging with #1434


Create an abstraction to the Sesolve and Mesolve interface

See https://github.com/anyonlabs/Snowflake.jl/pull/237#discussion_r1215140042 for justification.

We need to keep in mind https://github.com/anyonlabs/Snowflake.jl/pull/237#discussion_r1215147461

Not relevant anymore since the solvers have been removed


Ability to create envelope by sending the documents in a multipart request

If you are using a multipart/form-data POST request, you do not have to base64 encode your documents. You place the envelope definition in one part and the document bytes in another:
--AAA
Content-Type: application/json
Content-Disposition: form-data
<ENVELOPE DEFINITION GOES HERE>

--AAA
Content-Type:application/pdf
Content-Disposition: file; filename="contract.pdf"; documentid=1
<DOCUMENT BYTES GO HERE>

--AAA--

Hi, thank you again for the PR.
Since the SDK is produced by CodeGen, we unfortunately can't accept direct PRs to the CodeGen output, the SDK.
Good news is that we have internal ticket DCM-2352 which will update the SDKs to use multi-part mime. The Jira is currently planned for 2021.


Implement delete update and confirmation for schedule meeting

close #240

Could you add a bit of spacing here:

Here's the updated UI with additional space. That was a good idea.


net: ethernet: provide a way to get ethernet config

Is your enhancement proposal related to a problem? Please describe.
Ethernet API provides get_config function internally for drivers only, but not exposed to user to get ethernet configuration on runtime.
Describe the solution you'd like
Add a specific function exposed to users to get ethernet configuration
int net_eth_get_config(struct net_if *iface, enum ethernet_config_type config_type,
					   struct ethernet_config *config)

Describe alternatives you've considered
Add public functions in ethernet driver, add them in header file, but so much driver related.

@jukkar said it already exists in ethernet management API (see closed PR #53367)


Search SDK: Merging all v2.0-preview feature work to AutoRest branch

See individual commits for details.
FYI @chaosrealm @seansaleh @Yahnoosh @mhko

@brjohnstmsft I see there are breaking changes as there is change in public surface area of few types/API's. We would like to avoid such changes. Just want to confirm if they are intentional for this preview release?

@shahabhijeet These breaking changes are intentional. Our .NET SDK has not been published to NuGet since I incremented the major version number.


how to set sample weight  for binary classfication

I Know tf.losses.sparse_softmax_cross_entropy could set weights for different samples, But I don not know how to use it in my_custom_model
for example, in the ctr predicition, I want set 10 weights for the order samples, and the weight of click samples and the unclick sample is still 1.
Here is my unweighted code
`
def my_custom_model(features, labels, mode, params):
net = tf.feature_column.input_layer(features, params['feature_columns'])

for units in params['hidden_units']:
    net = tf.layers.dense(net, units=units, activation=params["activation"])

logits = tf.layers.dense(net, params['n_classes'], activation=None)

if mode == tf.estimator.ModeKeys.PREDICT:
    predictions = {
        'probabilities': tf.nn.softmax(logits),
        'logits': logits,
   }
   return tf.estimator.EstimatorSpec(mode, predictions=predictions)

loss = tf.losses.sparse_softmax_cross_entropy(labels=labels, logits=logits)

metrics = {'auc': tf.metrics.auc(labels=labels, predictions=tf.nn.softmax(logits)[:,1])}

if mode == tf.estimator.ModeKeys.EVAL:
    return tf.estimator.EstimatorSpec(mode, loss=loss, eval_metric_ops=metrics)

assert mode == tf.estimator.ModeKeys.TRAIN
optimizer = tf.train.AdagradOptimizer(learning_rate=0.1)
train_op = optimizer.minimize(loss, global_step=tf.train.get_global_step())
return tf.estimator.EstimatorSpec(mode, loss=loss, train_op=train_op)

train_input_fn = tf.estimator.inputs.pandas_input_fn(x=data_train, y=data_train_click, batch_size = 1024, num_epochs=1, shuffle=False)
classifier.train(input_fn=train_input_fn)`
Here data_train_click is a Series, which the click samples are 1 and the unclicked samples are 0.
And in the weight Series data_train_weight , the order samples are 10 and the others are 1.
However, I don't known how to use data_train_weight in my model.

This question is better asked on  StackOverflow since it is not a  bug or feature request. There is also a larger community that reads questions there. Thanks!


CC: Restiched integration doesn't fully work

The result of redstone.getBundledInput will only return the first n 1 bits, where n is the number of bundled cables pointed towards the computer in the block. For example, if you have the maximum number of cables connected, 5, like so:

and write<PHONE_NUMBER>0101012 (555516, or 2184510), you'll read in<PHONE_NUMBER>0000002 (554016, or 2182410).
I believe this line might be causing the bug, using (acc and mask.inv()) instead of (res and mask.inv()).

Thanks for reporting this. I'll look into it as soon as I can.

I believe this line might be causing the bug, using (acc and mask.inv()) instead of (res and mask.inv()).
This does indeed look like the problem. I had the some problem while reading and fixed it there. Looks like it forgot to fix it here though.

Ok, the fix for this has been released in v0.3.2.


chore: clean up ip types

Changes

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#709  👈
#708
#707
#706
#696
#695
#689
#688
#687
#686
#685
#684
#683
#682
#674
#673
#672
#671
#670
#669
#668
#667
#697
#641
#635
#633
#632 : 1 other dependent PR (#700 )
#628 : 1 other dependent PR (#629 )
#613
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @MasterPtato and the rest of your teammates on  Graphite


Improve kotlin api generator to provide replacement for a deprecated method

minor typo fix.

Thank you for your contribution. That's merged and backported now.


doubleclick on map get's polygon stuck in "self intersection" state

When using both allowSelfIntersection: false, and finishOn: dblclick to finish polygons, the double click gets the polygon stuck in an intersecting state.
To reproduce: jsfiddle

Initialize with:

map.pm.addControls({
  position: 'topleft',
});

map.pm.setGlobalOptions({
  allowSelfIntersection: false,
  finishOn: 'dblclick',
});

Click the draw polygon button

Create a polygon with 3 (or more) vertices

Finish by clicking the mouse button twice (dblclick).

Polygon is now stuck in an intersecting state, so it can't be closed/finished.

I've updated the title, as it turns out that it doesn't have anything to do with the finishOn: 'dblclick' part. Also without that setting, the polygon gets stuck when double-clicking the map.

Thx for reporting! This is already fixed in the develop branche https://github.com/geoman-io/leaflet-geoman/pull/621
But I found a new bug in the develop version. When dblclick is called no vertex is created.

That's awesome!
Regarding your finding. Is that a bug, or a feature? I think it is actually a nice user experience if a double click doesn't add a vertex. Especially in the mode where double click finishes the feature. This would prevent accidental vertex insertions, where users don't won't to add a vertex, but just want to finish the feature.

We can discuss about this but I use it to create the last vertex and then finish it at the same time. When I want to finish the polygon without creating a vertex I click on the first marker.
@codeofsumit how do you see that?

Would it be possible to publish a patch or prerelease that contains this bug fix?

I will release a patch version within the next few days 👌

@codeofsumit Any idea when this patch is going to go out as an npm package.
Picked up the code change on develop and this fix works great, but having problems getting our build pipeline working against your dev branch and would prefer to fix to an npm release.

Yeah sorry for not having released sooner. I'm on it!


refactor(radio-group): ts to sfc

Description

Linked Issues
cc: https://github.com/oku-ui/primitives/issues/492

LGTM! It's immaculate. You are wonderful