has.set for nested model

Hi,
i wish to change set method for nested model. Example:
const Test = Nested.Model.extend({
title: String.has.set( function (value, name) { console.log('this happens'); }),
struct: Nested.Model.extend({
a: Number
}).has.set( function (value, name) { console.log('this never happens'); })
});
let a = new Test();
a.struct = '12345'; // struct.set never called
What's wrong?

First, change is these examples is being rejected, because set hook returns 'undefined'.
Second, you have to wrap attribute definitions in 'attributes' or 'defaults' object. Or, use Model.defaults instead of Model.extend.
Model.defaults( attrSpec ) is an equivalent of Model.extend({ defaults : attrSpec }). Used for inline models definitions.
const Test = Nested.Model.defaults({
title: String.has.set( function (value, name) { console.log('this happens'); }),
struct: Nested.Model.defaults({
a: Number
}).has.set( function (value, name) { console.log('this never happens'); })
});

Also, there's an important detail about set hook. It executed only when an attribute's value is being changed, not when something inside of the structure is changed. It happens before the actual change, and gives you an opportunity to change the value before it will be set.
And when it's called, assigned value is being converted to the attribute type. You're assigning the string to the attribute with model type. Obviously, it can't be converted to the model, as type is incompatible. In this case, it will be delegated to a.struct.set( '12345' ) for the chance it's an object hash (so, a.struct value is not changed as there's an attempt to update struct in place, and no set hook is being called).  But since the value is the string, nothing will happen, but you will receive an error in the console. Something about string is not an object hash.

Thanks a lot

If your intention is not to alter the value before it's being set (which is very rarely needed), it's better to use 'change:struct' listener. That's what we're doing the most of the time.
These events happens after update, and any additional changes made in event handlers won't trigger any additional model 'change' events (and won't cause additional renders) as they are executed in the scope of the current transaction.
const Test = Nested.Model.defaults({
    title: String,
    struct: Nested.Model.defaults({
        a: Number
    })

    initialize : function(){
        this.listenTo( this, {
            'change:title' : function(){ ... },
            'change:struct' : function(){ ... }
        }
    }
});

In 2.0 beta (which is mostly functional now), you can use .has.watcher to subscribe for 'change:attr':
It might work in 1.3 as well, but I'm not really sure.
const Test = Nested.Model.defaults({
    title: String.has.watcher( function (value, name) { console.log('this happens'); }),
    struct: Nested.Model.defaults({
        a: Number
    }).has.watcher( function (value, name) { console.log('this never happens'); })
});


Fix termination of sshd processes when SSHAccess is disabled

How to categorize this PR?

/area security
/kind bug
What this PR does / why we need it:
This PR fixes a bug which was causing the termination of cluster pod sshd processes when SSHAccess is disabled. The command used to kill existing sshd connections pkill -x sshd kills sshd processes regardless of whether they are from the host or container.
To fix this issue we add the -P 1 flag to pkill which causes the termination of only processes with parent pid = 1. The container processes cannot have such ppid and the ones on the host would have inherited ppid=1 when the sshd service was stopped https://github.com/gardener/gardener/blob/720e534ee0ece2bd5fc5aa16d38559887daf2946/pkg/component/extensions/operatingsystemconfig/original/components/sshdensurer/templates/scripts/disable-sshd.tpl.sh#L9-L12
Selecting by ppid would also catch orphaned connections that have persisted through service restart.
Which issue(s) this PR fixes:
Fixes #10108
/cc @dimityrmirchev
Special notes for your reviewer:
Release note:

A bug has been fixed causing `sshd` running in cluster pods to receive a SIGTERM when `SSHAccess` for worker nodes is disabled.

/hold
Will add systemctl mask sshd to disable-ssh script as additional fail safe

/unhold

/retest

/lgtm

/retest

/retest


Linear and Gamma Color Spaces

Until now we did not handle gamma of images. This means that all operations on colors were applied to a non-linear colors space, which is not correct in most cases.
Thus, this PR will result in slightly different colors for many operations on images and colors e.g. resampling.
Changes:

This PR handles gamma at loading and saving of images.
We introduced a new color type sRGB. It represents values in the non-linear gamma space.
RGB represents linear color values.
This means that all operations on RGB happen from now on on the linear color values, as it should be.
PixelImageIO.read[RGB] loads an image and linearizes the colors.
PixelImageIO.read[sRGB] reads the values as they are, namely in gamma space.
The transformation between sRGB and RGB is according to W3 specification.

I vote for SRGB too.

I changed sRGB to SRGB and addressed the rest of the suggestions.


feat: Adds an option to mine only implemented rules

This PR is going to address #295 .

LGTM! This will help me a whole lot in my work to find stuff to repair, thanks @khaes-kth

LGTM! This will help me a whole lot in my work to find stuff to repair, thanks @khaes-kth


stm32mp15 build artifacts

Optimize files to only those required for flashing

https://github.com/meta-flutter/meta-flutter/pull/35


Add ConnectRequest and ConnectResponse

issue: https://github.com/milvus-io/milvus/issues/24158

/approve
/lgtm


actually connect Electrum to ElectrumX

ElectrumX does not seem to respect the SERVICES= variable currently.
It only does RPC which is a bit pointless on a remote box.

The problem was that ElectrumX wasn't synced yet.
Good to document this.
Idea: web/cli dashboard showing block sync status for each of the components.


When I use the latest version. LLVM always print "nw_protocol_get_quic_image_block_invokeis "

When I use the latest version. LLVM always print "nw_protocol_get_quic_image_block_invoke dlopen libquic failed ".
I can not request anything?
What can I do ?

This is system logging that's always printed and has nothing to do with your issue. I suggest you investigate your issue.


[Task]:  Tracking issue to add tfx RunInference tests to Python 3.10 PostCommit tests

What needs to happen?
tfx-bsl wheel is not built for Python 3.10. Don't add tfx-bsl RunInference tests to Pythpn 3.10 PostCommit test suite.
Issue Priority
Priority: 2
Issue Component
Component: run-inference

.close-issue

for my education and done-and-done review, which PR adds these tests?

https://github.com/apache/beam/pull/23456

Thanks. There is still a TODO left referencing this issue: https://github.com/apache/beam/issues/23966


Remove Pipelines TODO comment

System.IO.Pipelines has been investigated in https://github.com/microsoft/reverse-proxy/pull/330.

Thanks 😃

Thanks 😃


remove the type parameter of the trait Ledger and of HasTransaction

This will simplify the code a bit in the sense it will make it simpler to manipulate trait only object.
close #417

Codecov Report

Merging #434 into master will decrease coverage by 0.04%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #434      +/-   ##
==========================================
- Coverage   47.33%   47.28%   -0.05%
==========================================
  Files         123      123
  Lines       12027    12027
==========================================
- Hits         5693     5687       -6
- Misses       6334     6340       +6

Impacted Files
Coverage Δ

chain-impl-mockchain/src/environment.rs
94.38% <ø> (ø)
:arrow_up:

chain-impl-mockchain/src/ledger.rs
93.02% <ø> (ø)
:arrow_up:

chain-core/src/property.rs
94.66% <100%> (ø)
:arrow_up:

chain-impl-mockchain/src/transaction.rs
89.65% <0%> (-3.45%)
:arrow_down:

...tocol-tokio/src/network_transport/response_code.rs
60.6% <0%> (ø)
: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 4f05b85...a18fac7. Read the comment docs.


Helper error on fresh clone

I just cloned this repo into my project and I get them Warning immediately.
Warning (512): Method GalleryHelper::new_gallery_button does not exist [CORE/Cake/View/Helper.php, line 192]
I checked the file here on github as well and that function does not exist.

I also noticed that there is no code in general for adding albums. Why is this?

I believe that a
# in Plugin/Gallery/View/Gallery/index.ctp
echo $this->Gallery->link(null, null,
       array('class' => 'btn btn-primary pull-right', 'style' => 'margin-top: 10px')
);

is now used instead -- a link to upload photos, as used for example here:
https://github.com/hugodias/cakegallery/blob/master/View/Gallery/index.ctp#L11

@ptica fixed that in the master branch on #10 . Check that out @greenmanspirit


The status message is selected instead of all rows if select one row then press Ctrl+A on the previewed tab of tabular data

Storage Explorer Version: 1.34.0-dev (98)
Build Number: 20240508.1
Branch: rel/1.34.0
Platform/OS: Windows 10/Linux Ubuntu 22.04/MacOS Sonoma 14.4.1(Apple M1 Pro)
Architecture: x64/x64/arm64
How Found: Exploratory testing
Regression From: Not a regression
Steps to Reproduce

Expand one storage account -> Blob Containers.
Upload one .parquet file -> Preview it.
Select one row -> Press Ctrl+A.
Check whether all rows are selected.

Expected Experience
All rows are selected.
Actual Experience
The status message is selected.

Correct, we have not added keyboard shortcuts to select all rows in preview.

Verified this issue on the build 20240526.2. Fixed. So, we are going to close it.


Can I use wasm-loader with inline import statement?

In webpack loader documentation, loaders such as style-loader, file-loader can be applied by inline import statement like import Styles from 'style-loader!css-loader?modules!./styles.css';.
When I try inline import with wasm-loader import '!!wasm-loader!filename.wasm';, a compilation error has occurred.
Module parse failed: magic header not detected
File was processed with these loaders:
 * ./node_modules/wasm-loader/index.js
You may need an additional loader to handle the result of these loaders.
Error: magic header not detected

Can I use wasm-loader with inline import statement? Does wasm-loader only support webpack configuration?

I'm getting the same error on pixi's basis_transcoder trying to import @pixi/basis/assets/basis_transcoder.wasm
error -<EMAIL_ADDRESS>Module parse failed: magic header not detected
File was processed with these loaders:
 * ../../node_modules/wasm-loader/index.js
You may need an additional loader to handle the result of these loaders.
Error: magic header not detected

using webpack 4.44.1

I'm getting the same error on pixi's basis_transcoder trying to import @pixi/basis/assets/basis_transcoder.wasm
error -<EMAIL_ADDRESS>Module parse failed: magic header not detected
File was processed with these loaders:
 * ../../node_modules/wasm-loader/index.js
You may need an additional loader to handle the result of these loaders.
Error: magic header not detected

using webpack 4.44.1

Thanks for reporting this. I'll take a look and see what the issue. I don't think I ever added a test case for that back in the day when I wrote this.

Thanks for reporting this. I'll take a look and see what the issue. I don't think I ever added a test case for that back in the day when I wrote this.

Thanks for reporting this. I'll take a look and see what the issue. I don't think I ever added a test case for that back in the day when I wrote this.

Thanks for reporting this. I'll take a look and see what the issue. I don't think I ever added a test case for that back in the day when I wrote this.


Storing info

Added two basic operations to store a route and to retrieve all routes to solid/routes.js, just to show how this could be achieved using solid-file-client. A temporal text field is added to the upload route view so route points can be specified somewhere, until we get file actual processing. Work on this branch or on branches derived from it can continue, but I think it is important to get a common base to make all other operations over.
Resolves #29.

Maybe delete the functionality of writing points? I check the other part now, we must resolve conflicts.

@InigoGutierrez do you know what app source should I add to my POD in order to work?? I´ve tried with localhost but it doesn´t work.

And nice job! :)

The needed url is http://localhost:3000 (without a dash at the end).

The needed url is http://localhost:3000 (without a dash at the end).

Thanks!


Add Django 3 support

These are some of the changes required by for compatibility with Django 3.0 ( #601 )
I don't know my way around the project so there are some tasks left to do.

Support for python 2.7, and versions of Django << 2.0 have to be dropped.
six has to be added as a dev
tests for Django << 2.0 & Python << 3 have to be removed and replaced with tests for Django 3.0.

https://docs.djangoproject.com/en/3.0/releases/3.0/#features-deprecated-in-3-0
https://docs.djangoproject.com/en/3.0/releases/3.0/#removed-private-python-2-compatibility-apis

Closing because a better PR is already made #600

Coverage remained the same at ?% when pulling db43470c05a4a08abb5828c5725626fcd88d707f on hugodes:django-3 into 22ccd9781462a820f963f57018ad3dcef85053ed on jazzband:master.

Coverage remained the same at ?% when pulling db43470c05a4a08abb5828c5725626fcd88d707f on hugodes:django-3 into 22ccd9781462a820f963f57018ad3dcef85053ed on jazzband:master.

Coverage remained the same at ?% when pulling db43470c05a4a08abb5828c5725626fcd88d707f on hugodes:django-3 into 22ccd9781462a820f963f57018ad3dcef85053ed on jazzband:master.


Add basic css. Add normalized css. Run into issue. Didn't push this t…

…o heroku due to issue with normalized file. Do not merge to master unless the issue is resolved

Did exactly as instructed. This has not solved the issue.
Showing /Users/apprentice/phase3/blog/app/views/layouts/application.html.erb where line #7 raised:
Asset was not declared to be precompiled in production.
Add Rails.application.config.assets.precompile += %w( normalize.css ) to config/initializers/assets.rb and restart your server
Extracted source (around line #7):
5
6
7
8
9
10
<%= csrf_meta_tags %>

<%= stylesheet_link_tag    'normalize', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload' %>

Rails.root: /Users/apprentice/phase3/blog


Unable to Add Sampler

Hi,
I get the below error when i try to add the sampler.
ERROR o.a.j.g.a.AddToTree: Exception while adding a component to tree.
java.lang.NullPointerException: testDirectory.selectedFile must not be null
at com.microsoft.playwright.jmeter.samplers.PlaywrightTestSamplerGUI.modifyTestElement(PlaywrightTestSamplerGUI.kt:151) ~[jmeter-playwright-0.4.0-20230609.044954-1.jar:?]
at com.microsoft.playwright.jmeter.samplers.PlaywrightTestSamplerGUI.createTestElement(PlaywrightTestSamplerGUI.kt:142) ~[jmeter-playwright-0.4.0-20230609.044954-1.jar:?]
at org.apache.jmeter.gui.GuiPackage.createTestElement(GuiPackage.java:373) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.gui.action.AddToTree.doAction(AddToTree.java:67) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.gui.action.ActionRouter.performAction(ActionRouter.java:87) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.gui.action.ActionRouter.lambda$actionPerformed$0(ActionRouter.java:69) ~[ApacheJMeter_core.jar:5.5]
at java.awt.event.InvocationEvent.dispatch(Unknown Source) ~[?:1.8.0_202]
at java.awt.EventQueue.dispatchEventImpl(Unknown Source) ~[?:1.8.0_202]
at java.awt.EventQueue.access$500(Unknown Source) ~[?:1.8.0_202]
at java.awt.EventQueue$3.run(Unknown Source) ~[?:1.8.0_202]
at java.awt.EventQueue$3.run(Unknown Source) ~[?:1.8.0_202]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_202]
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source) ~[?:1.8.0_202]
at java.awt.EventQueue.dispatchEvent(Unknown Source) ~[?:1.8.0_202]
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) ~[?:1.8.0_202]
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) ~[?:1.8.0_202]
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) ~[?:1.8.0_202]
at java.awt.EventDispatchThread.pumpEvents(Unknown Source) ~[?:1.8.0_202]
at java.awt.EventDispatchThread.pumpEvents(Unknown Source) ~[?:1.8.0_202]
at java.awt.EventDispatchThread.run(Unknown Source) ~[?:1.8.0_202]
2023-07-04 12:16:15,477 ERROR o.a.j.u.JMeterUtils: testDirectory.selectedFile must not be null

Thanks for the report, what version of JMeter are you using? I'll release a patch to fix this bug

Please download and use the JAR from the latest release https://github.com/tonybaloney/jmeter-playwright/releases/tag/0.4.2


Facebook Custom Audience docs edit

Description of the change

Description here

Type of change

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

Related issues

Fix #1

Checklists
Development

[ ] Lint rules pass locally
[ ] The code changed/added as part of this pull request has been covered with tests
[ ] All tests related to the changed code pass in development

Code review

[ ]  This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
[ ] "Ready for review" label attached to the PR and reviewers mentioned in a comment
[ ] Changes have been reviewed by at least one other engineer
[ ] Issue from task tracker has a link to this pull request

Once E2E testing is completed with sources team we will merge it


Update JsonAdapted classes

Convert attributes to types that can be understood by JSON (e.g. String, number).


sudo crouton -t xfce failing to run debootstrap when i try to run the installer

```chronos@localhost / $ sudo crouton -t xfce
Installing xenial-amd64 chroot to /usr/local/chroots/xenial
Downloading bootstrap files...
/tmp/crouton-installer-cache/crouton: 95: /tmp/crouton-installer-cache/crouton.46K/installer/ubuntu/bootstrap: /tmp/crouton.GEZ/debootstrap: Permission denied
debootstrap error log:
tail: cannot open '/tmp/crouton.GEZ/xenial-amd64/debootstrap/debootstrap.log' for reading: No such file or directory
Failed to run debootstrap.

Above is me trying to get crouton for the first time on my Chromebook (ASUS).
I followed the steps but when i try to run the installer with `sudo crouton -t xfce` it failed to run the debootstrap?
If someone can tell me how to fix this that would be awesome :)

on a powerwashed chromebook download crouton, open a shell, run `sudo install -Dt /usr/local/bin -m 755 ~/Downloads/crouton`.
Then, put in `sudo crouton -t xfce` and the same error will occur hopefully.
I think crouton is either outdated or chrome did something thats stopping crouton

try a different -r like bullseye -r bullseye -t  xfce

```chronos@localhost / $ sudo crouton -t xfce
Installing xenial-amd64 chroot to /usr/local/chroots/xenial
Downloading bootstrap files...
/tmp/crouton-installer-cache/crouton: 95: /tmp/crouton-installer-cache/crouton.46K/installer/ubuntu/bootstrap: /tmp/crouton.GEZ/debootstrap: Permission denied
debootstrap error log:
tail: cannot open '/tmp/crouton.GEZ/xenial-amd64/debootstrap/debootstrap.log' for reading: No such file or directory
Failed to run debootstrap.

Above is me trying to get crouton for the first time on my Chromebook (ASUS).
I followed the steps but when i try to run the installer with `sudo crouton -t xfce` it failed to run the debootstrap?
If someone can tell me how to fix this that would be awesome :)

on a powerwashed chromebook download crouton, open a shell, run `sudo install -Dt /usr/local/bin -m 755 ~/Downloads/crouton`.
Then, put in `sudo crouton -t xfce` and the same error will occur hopefully.
I think crouton is either outdated or chrome did something thats stopping crouton

This is a dupe: https://github.com/dnschneid/crouton/issues/4803

so what is it the crouton shell need to set the /tmp files for RWX for the debootstrap process to run now this always was the case
sudo mount -i -o remount,exec /tmp/

so what is it the crouton shell need to set the /tmp files for RWX for the debootstrap process to run now this always was the case
sudo mount -i -o remount,exec /tmp/
i already tried that didnt fix the problem

nevermind, i powerwashed the chromebook and it workd sorry


Add example related to get access real k8s cluster

All examples regarding work with cluster related to creating kind cluster in Setup. But can you also add at least 1 example how to use it with KUBECONFIG file because it's not clear. Thanks.

I figured it out, but still not clear there is some alternative to get config or create env from $HOME/.kube/config ?
Something like config.GetConfig() from "sigs.k8s.io/controller-runtime/pkg/client/config" package.

Did you try using the ResolveKubeConfigFile() helper ?
import (
     "sigs.k8s.io/e2e-framework/klient/conf"
)

.....
     path = conf.ResolveKubeConfigFile()

xref: https://github.com/kubernetes-sigs/e2e-framework/blob/cd133e286ac7059c7743561cb6441542d60674f4/klient/conf/config.go#L67


Expose Winit's KeyEvent::repeat in KeyboardInput

Objective
I would like to know if an event was emitted because of "key repeats" or not.
Winit already exposes this information, but it isn't sent along by Bevy, which this PR intends to address.
Solution
Expose winit::event::KeyEvent::repeat in bevy::input::keyboard::KeyboardInput.
Testing
Just hold any regular key down and only the first event should have KeyboardInput::repeat set to false. Most OSs have "key repeat" enabled by default.

Changelog

Added KeyboardInput::repeat signifying if this event was sent in response to a "key repeat" event or not.

AFAICS this change is additive so this:

Added KeyboardInput::repeat signifying if this event was sent in response to a "key repeat" event or not.

Could be moved to the Changelog section of the PR description and the Migration Guide removed.
Thanks for adding it!

AFAICS this change is additive so this:

Added KeyboardInput::repeat signifying if this event was sent in response to a "key repeat" event or not.

Could be moved to the Changelog section of the PR description and the Migration Guide removed.

Ah, that was by mistake!
Thanks!


Partial contextual keyword is prohibited also on field (member)

Type of issue
Typo
Description
From Partial member (C# Reference)

The partial keyword isn't allowed on constructors, finalizers, overloaded operators, or event declarations. Before C# 13, partial wasn't allowed on properties or indexers.

If I'm not wrong, field is also (type) member. I am not sure about sense of this phrasing. Maybe is field missing deliberately.

Page URL
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/partial-member
Content source URL
https://github.com/dotnet/docs/blob/main/docs/csharp/language-reference/keywords/partial-member.md
Document Version Independent Id
85bf7eb0-b476-94b6-e10a-d0f42fee407b
Article author
@BillWagner
Metadata

ID: b4eedbc9-36be-6c79-fcb4-d5fe6998e5b1
Service: dotnet-csharp
Sub-service: lang-reference

partial is not supported for field

Okay. I did not figure it out. partial field would imply that it must be definitely not-null initialized (e.g. by field initializer) and readonly likely also so field is having "implementation".


Write json parser for Req body

Checkout https://serde.rs

@gregor-tokarev  still relevant?

Obsolete


[SIP] Add support for Progress OpenEdge Database

[SIP] Proposal for adding support for Progress OpenEdge Database
Motivation
Currently there's no support for Progress OpenEdge. It has been asked a few years ago already: https://github.com/apache/superset/issues/2874
Proposed Change
Example for SQL execution:
https://community.progress.com/s/article/sample-python-code-to-access-an-openedge-db-through-odbc
New or Changed Public Interfaces
New dependencies
pyodbc
Migration Plan and Compatibility
None.
Rejected Alternatives

I don't think we need a SIP for this... please feel free to open a PR adding support at any time.


fixes #67 DialPipe problem with multiple calls / waiting for busy pipe

(I believe this change also should be used instead of PR #75 -- that PR is potentially extraordinarily buggy.)
This changes a few things to try to ensure that we never wind up with
a result of ERROR_FILE_NOT_FOUND, due to a race between closing the
last pipe instance and opening the next.
First we keep an "open" client instance (unused) while the listener
is open, so that we are guaranteed to always have an active pipe
instance.  This means attempts to open while no other instances exist
result in ERROR_PIPE_BUSY instead of ERROR_FILE_NOT_FOUND.
Second we have changed the loop for dialing to eliminate a race condition
that is more or less inherent in WaitNamedPipe when synchronizing with
CreateFile.  The real timeout needs to be some larger value than the
WaitNamedPipe timeout, and furthermore WaitNamedPipe is not very nice
with the Go runtime, since it is a blocking system call.  Instead we
just put the goroutine to sleep for 10 milliseconds, and keep retrying
the CreateFile until the maximum timeout is reached.  If no timeout is
specified we assume a reasonable and large default of 5 seconds, which is
similar to a TCP connection timeout.
This isn't perfect, as a client attempting to connect to an extremely
busy pipe server can be starved out by other clients coming in while
it is in that brief sleep, but this potential race was already present
with WaitNamedPipe.  The numerous retries (by default 500 retries!)
mean its pretty unlikely to occur, and if a single client hits the
race once, it has an excellent chance of getting in the next cycle.
(A real "fix" that is completely race free and fair would require
changes in the underlying Named Pipe implementation, or some other
kind of external coordination.)

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

Hmm... I probably would have liked to have added my own copyright and update to the code... (still MIT licensed.) If its possible to do that somewhere, text more or less to the effect of:
Portions Copyright 2018 Garrett D'Amore<EMAIL_ADDRESS>(or skip the Portions word.) . If this is too much a hassle, then don't worry about it.

This probably also fixes #46 -- since WaitNamedPipe was the only blocking code remaining.

cc @jstarks @johnstep

FYI. I was able to reproduce original issue by running my test version of Portainer on Windows Server, version 1803 and I cannot see it anymore on version which contains content from this PR (more detail on that portainer PR).
Any change to get this one merged?

I can confirm that this PR helps Portainer work stable with the named pipe bind mounted into a Windows container running a Docker swarm on Windows Server 1803 with Docker EE 18.03.1-ee-1

@jstarks @johnstep Ping?  This PR addresses a very important reliability issue, and at least three different projects are waiting for this to be integrated.  If there is something wrong with this, or concerns with what I've done here, then feedback would very much be appreciated.

I do not have permission to merge this.

@jstarks   time to allow merge this pull ?

Hard to believe I submitted this 19 days ago; the silence from the repo maintainers is deafening.

Sorry for the delays. I'm looking at this now. I want to write a quick test to understand the behavior of something before I merge this.

OK, I think this pull request is actually three changes:

Increase the default timeout to 5 seconds.
Poll instead of using WaitNamedPipe.
Keep the original dummy client handle open for the lifetime of the pipe server.

I understand why increasing the timeout may be useful, but this seems like something the client can easily do without a change to go-winio. I do suspect that the default 50ms is probably too short to be useful given the problems with fairness. But I'm worried that extending it to a full 5 seconds might affect existing clients negatively. Maybe a compromise would be something like 250ms.
WaitNamedPipe has its problems. As you mention, it blocks the OS thread (which go-winio generally tries to avoid), it has various races, it does not guarantee that the client will win the race and be able to connect to the pipe, and most importantly for #67, it does not work reliably inside containers. It does have the advantage, though, that it wakes up immediately when a connection is available. I wonder if a better change wouldn't be to keep the WaitNamedPipe call, but if it fails any reason other than timeout, to sleep for 10ms and loop around again. That would probably resolve #67 and other race conditions.
This suggestion doesn't fix the issue that WaitNamedPipe blocks the OS thread, of course. If this is important to resolve, I would suggest making a change to use FSCTL_PIPE_WAIT with an asynchronous DeviceIoControl call. This fsctl is what WaitNamedPipe uses, and it is documented as part of the SMB protocol. It appears to have a non-blocking implementation.
I don't understand the third change. I can't see any behavior differences whether I keep the original client handle open or not. Unless you are aware of a behavior that I am not, I think it's better to close that client handle to avoid unnecessary resource consumption.

@jstarks thanks for good comments.
I changed default timeout to 250 ms and added client handle closing now on this commit: https://github.com/olljanat/go-winio/commit/972aaec17501edc2ae66b43541f799eec50cf7c5 and did some testing with Portainer and I can tell that this combination at least still fixes #67
@gdamore I think that it is better if you comment about suggestion to still use WaitNamedPipe?

I think using WaitNamedPipe is probably more trouble than it's worth.  In
theory it would be better with the immediate wake up but as it doesn't
actually correct anything and as it blocks the caller I think it's better
not to use it and aim for simplicity.
5s was chosen to match TCP timeouts making this behave more like other
net.Pipe implementations. That said it is trivial to override as that is
just a default so I am happy with whatever you think is best there.
Keeping the old pipe open was intended to make it easier to distinguish
between the two cases of a listener not existing at all and a listener that
has not yet accepted the connection.  The former case you want to fail fast
without a time out.  The latter should keep trying because presumably
something is there and you have just missed it.
Again the semantic I am trying to provide is more like TCP or UNIX domain
pipes which both behave this way.
On Sat, Jul 14, 2018, 7:50 AM Olli Janatuinen<EMAIL_ADDRESS>wrote:

@jstarks https://github.com/jstarks thanks for good comments.
I changed default timeout to 250 ms and added client handle closing now on
this commit: olljanat@972aaec
https://github.com/olljanat/go-winio/commit/972aaec17501edc2ae66b43541f799eec50cf7c5
and did some testing with Portainer and I can tell that this combination at
least still fixes #67 https://github.com/Microsoft/go-winio/issues/67
@gdamore https://github.com/gdamore I think that it is better if you
comment about suggestion to still use WaitNamedPipe?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/go-winio/pull/80#issuecomment-405028207,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPDfRMoGmzocewPA8PnfX8JKpKGOi12ks5uGgU1gaJpZM4U1QgD
.

@jstarks / @gdamore so what we can do get this one fixed?
There is already three PRs #75 , this one and #84 which all are trying to solve same issue but bit different way. We should choose which one to focus and do needed changes to get is merged.

Hmm.. I have a question.
If the client handle is closed, but we haven't called DisconnectNamedPipe nor closed the server handle, is the server pipe instance still retained and busy (so no new client handles will connect to it, and so that the we won't get ERROR_NOT_FOUND in CreateFile on the client?)
If so, then closing the file handle would be perfectly reasonable.  In such a case, there would be no need to retain the client handle.  A better comment explaining this would be helpful.  There is still that race condition I mentioned, where some other clients connects before we do.  That would be unfortunate, and again would be easily fixed in a follow up.

What I've observed (and I think we have tests to confirm) is that keeping the server handle open is sufficient to retain ownership of the pipe and to ensure that clients get ERROR_PIPE_BUSY. So keeping the client handle open is not necessary.

Do you want me to follow up with a modification to this PR for the above alterations (2 second timeout, close client handle) or address at your end?

Ok, coming shortly.

Done.  Would be good to test it before integrating. :-)

Thanks! I'll take a look a little later today and merge it. If @olljanat has time to validate it in his workload, that would be useful.

@jstarks my workload looks working very nicely with this one.
@gdamore good work 👍

Thanks @gdamore for the fix, @olljanat for verification, and everyone for their patience on this.


@orta => Adds the new ‘bell’ notifications tab

Implements #483.
Next week I still need to do:

[x] Fix icon to proper dimensions.
[x] Think of the best way to ensure no notification count requests are made during tests, which are all failing and now disabled.
[x] Update badge when a push notification comes in.
[x] Update badge after sign-in during on boarding (currently you need to launch the app signed-in for the number to populate)
[x] Add state for when a user is not signed-in.
[x] Update app icon badge after polling for notification count.
[x] If app was not already running, tapping a notification does not open the notifications tab.
[x] The in-app notification view no longer dismisses.
[x] Look into when notifications are considered ‘seen’ and implement that.
[x] Ensure the notifications view is up-to-date. This is probably what #592 is about.
[ ] Preload notifications tab when a push notification arrives. Deferring to #595, for now.
[ ] Fix in-app notification view animation. Deferring to #596, for now.
[ ] Refactor. Deferring to #604, for now.

@orta This needs rebasing, but can be reviewed.

OK, feels pretty solid to me. :+1:


x/tools/gopls: unimported completions do a lot of work

I noticed unimported completions were adding 30ms latency to every completion request via imports.GetAllCandidates. It seems to be mostly from allocations:
filepath.Join in findPackage
path.Join in canonicalize
filepath.Rel in canUse
strconv.Atoi in ImportPathToAssumedName (perhaps due to error allocation)
There is also an ioutil.ReadDir call in findPackage that gets called hundreds of time. It was trying to read non-existent directories in the module cache that do exist for different versions of the module.
Maybe the easiest thing is to offer some way to disable unimported package name candidates, leaving unimported package member candidates. That way we wouldn't call GetAllCandidates at all most of the time. I know we don't want config option bloat, though.
Maybe another option is to have a very coarse cache of the result of imports.GetAllCandidates that gets busted whenever any watched file event comes? It's weird that everything is mostly cached already but we still do some much work every time.
/cc @heschik

Closing - this doesn't seem to be an issue anymore.


Fixes false negatives in UnnecessaryAbstractClass

This PR fixes a false positive in UnnecessaryAbstractClass.
Before this PR the class B wasn't flagged:
interface A {
    val i: Int
}
abstract class B : A

And the same here:
abstract class A {
    abstract val i: Int
}
abstract class B : A()

This PR also improves the messages reported for this rule.

I guess the mentioned code snippets aren't flagged a second time by the empty rule set, right?

I guess that some cases are flagged by that rule set too. And I think that it's good that both rules flag it because one developer could have one of those issues disabled.

If I remember correctly, we excluded those cases for exactly this reason. Thus, the same code is not flagged twice by two different rules. I could be wrong here, however.

I guess that some cases are flagged by that rule set too. And I think that it's good that both rules flag it because one developer could have one of those issues disabled.

I didn't introduce those cases in this PR. Those cases where there already, they weren't tested but they were flagged. I just extended the tests to ensure that I didn't break anything.

I'm afraid, I didn't understand this statement.  As I understood the description of the rule, you fixed a false-positive in this PR (e.g. abstract class B : A as well as abstract class B : A()).

I didn't introduce those cases in this PR. Those cases where there already, they weren't tested but they were flagged.

This rule was already flagging code at the same time as the empty rule set. I didn't introduce that issue here. For example:
abstract class A : B {}

It was flagged by UnnecessaryAbstractClass and by EmptyClassBlock.
For that reason I say that I didn't introduce this "double report", it was there. For sure, now there are more "double reports" but that is because now UnnecessaryAbstractClass is working as expected.

Thanks for the elaboration, Brais! It's good to merge.


pq.write_to_dataset() and ds.write_dataset() both throw InvalidLocationConstraint when using S3FileSystem

I've been having some issues with writing a dataset or table to s3. I'm using pyarrow 4.0.1 with python and am just wondering if I've missing something because I keep getting the following error:
Error
OSError: When creating bucket 'my-existing-bucket': AWS Error [code 100]: Unable to parse ExceptionName: InvalidLocationConstraint Message: The specified location-constraint is not valid

My Code
import pyarrow.dataset as ds
from pyarrow import fs
import pyarrow.parquet as pq

source_uri = "s3://my-existing-bucket/old_prefix/"
dataset = ds.dataset(source_uri)

target_uri = "s3://my-existing-bucket/new_prefix/"
filesystem, path = fs.FileSystem.from_uri(uri)

# both of these write methods product the error below

# First write type
ds.write_dataset(dataset, path, filesystem=filesystem, format="parquet")

# Second write type
pq.write_to_dataset(dataset.to_table(), path, filesystem=filesystem)

I've checked and my region is set to us-east-1 which is correct for me. Additionally, I was able to write a single parquet file using pq.write_table so I know my credentials are in working order.
pq.write_table(dataset.to_table(), path, filesystem=filesystem)

Finally, the target bucket was also created in us-east-1 so I don't think it's a region issue, but that is about all I could find online about this.

It appears us-east-1 has special rules regarding the LocationConstraint.  See https://github.com/boto/boto3/issues/125 for details.  I've created ARROW-13228 to track this.
Are you sure you are using my-existing-bucket in both cases?  Note that the error you are getting says "When creating bucket".  Both dataset write methods will create a bucket if it does not exist so my guess is that path does not start with "my-existing-bucket".  If you are intentionally creating a new bucket then you can workaround this error by manually creating the destination bucket outside of Arrow.

@westonpace I'm 100% sure I'm using the exact same path variable for each of these writing methods. I've annotated what works and what doesn't below. I can also confirm that the path variable returned from fs.FileSystem.from_uri(target_uri) does indeed start with the bucket name like so: my-existing-bucket/new_prefix/
filesystem, path = fs.FileSystem.from_uri(target_uri)

# Throws InvalidLocationConstraint error
ds.write_dataset(dataset, path, filesystem=filesystem, format="parquet")

# Throws InvalidLocationConstraint error
pq.write_to_dataset(dataset.to_table(), path, filesystem=filesystem)

# Writes single file
pq.write_table(dataset.to_table(), path, filesystem=filesystem)

Are there any solutions you can think of for writing a large dataset as many parquet files from pyarrow to unblock me while we debug?

Ok, yes, I looked a little further.  I did not realize that the dataset code calls CreateDir even if the bucket already exists (it uses CreateDir to test if the bucket exists).  So this is ARROW-13228.  If you are able to wait for version 5.0.0 (~a month out) then you can get a fix there.  Alternatively you can use the latest nightly build or build from source.
Another workaround may be to use s3fs, PyFilesystem, and FSSpecHandler:
import s3fs
import pyarrow.fs
s3fs_instance = s3fs.S3FileSystem()
filesystem = pyarrow.fs.PyFileSystem(pyarrow.fs.FSSpecHandler(s3fs_instance))

A final workaround could be to create your own filesystem implementation that wraps a pyarrow.fs.S3FileSystem instance (e.g. proxy pattern) and for create_dir it simply returns True.


Add basic e2e tests for Metal LB operator

The tests are validating that all the nodes in the cluster and
the operator pods are running after operator deployment.

LGTM


Source code in oceanparcels.org/_modules is outdated

The source code for FieldSet.from_nemo on http://oceanparcels.org/_modules/parcels/fieldset.html does not match https://github.com/OceanParcels/parcels/blob/master/parcels/fieldset.py#L158.
It looks like the HTML files in oceanparcels.org/_modules are outdated.

Fixed now, thanks for noting that these files in _modules were indeed outdated


Added non-const accessors for Link child objects

Signed-off-by: Nate Koenig<EMAIL_ADDRESS>🎉 New feature
Summary
I need the ability to access mutable versions of child objects. This is part of my effort to support building and editing the SDF DOM programmatically. I've added private helper functions in order to reduce code duplication.
Test it
Run the tests.
Checklist

[x] Signed all commits for DCO
[x] Added tests
[x] Updated documentation (as needed)
[x] codecheck passed (See contributing)
[x] All tests passed (See test coverage)
[x] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

Codecov Report

Merging #838 (22375f0) into sdf12 (1d833c1) will increase coverage by 0.02%.
The diff coverage is 98.18%.

:exclamation: Current head 22375f0 differs from pull request most recent head e84718f. Consider uploading reports for the commit e84718f to get more accurate results

@@            Coverage Diff             @@
##            sdf12     #838      +/-   ##
==========================================
+ Coverage   90.71%   90.74%   +0.02%
==========================================
  Files          78       78
  Lines       12447    12487      +40
==========================================
+ Hits        11291    11331      +40
  Misses       1156     1156

Impacted Files
Coverage Δ

src/Link.cc
97.95% <98.18%> (+0.32%)
: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 1d833c1...e84718f. Read the comment docs.

This pull request has been mentioned on Gazebo Community. There might be relevant details there:
https://community.gazebosim.org/t/new-ignition-releases-2022-04-13-fortress-edifice/1367/1


Random JPEG corruption

The code works fine, but in some cases, it randomly appears to generate invalid JPEGs. For example, using the call
hstego.py embed secret.txt source.jpg stego.jpg MyP4ssw0rd101

results in a jpeg with a visible artifact, where the extraction with hstego.py extract throws an error:
Error: Corrupt JPEG data: 46 extraneous bytes before marker 0xd9
Traceback (most recent call last):
  File "/usr/local/bin/hstego.py", line 104, in <module>
    juniw.extract(stego_img_path, password, output_msg_path)
  File "/usr/local/lib/python3.8/dist-packages/hstegolib.py", line 533, in extract
    plain = cipher.decrypt(bytes(ciphertext))
  File "/usr/local/lib/python3.8/dist-packages/hstegolib.py", line 180, in decrypt
    self.aes_decrypt()
  File "/usr/local/lib/python3.8/dist-packages/hstegolib.py", line 175, in aes_decrypt
    self.decrypted = unpad(decrypted, AES.block_size)
  File "/home/c11/.local/lib/python3.8/site-packages/Crypto/Util/Padding.py", line 92, in unpad
    raise ValueError("Padding is incorrect.")
ValueError: Padding is incorrect.

This seems to happen especially when choosing a larger secret size, such as 1000 characters in this case, and happens completely randomly in about 10% of the cases.
Source:

Stego:

Another broken stego:

In contrast, a correct stego:

Secret
11wLUd2r2CfBRjEiUUHwXUim3pAwJXVIWPe10eq3pWCEDQxivEcQgJCj8KdQr8iMVMLWzBZofj2t7zZ0C9QqScabvB1kKh6p2PJ1ZspEZr5hpeh1o6rEgPpbboMtWQgYq0XPqMbQBh5yJmz5qpKXC98lwUcSvJyjHV87phVyOYxiJul9h5guDpd7JGZCXVvoy1tljNj7vgnEZZMGc2Anrmu92RLZwHLsICdzZL7TzsfYP1p04xntji2l9OI4dbutoWtLrymqoSPEREETBzNvhNeplvrMWjEIF7e63OvrqK5GWHjfH6YwUDjD6aYcImtXrVcutXjirpyL4f0LkZIEkzPqavQsfJNWozOgW8OLvKezzfJjCZvwYJk6EAwuSKOEHluotG7oYmlYP4FbdBVCSDGeNDWnXv0ogsaX9gJfQ4Dp7ROkaru24BgPMDDt6Dfk5EHCuasKc39jUVS4MK4QVjppw0i2DMmHa1TUbLmBNvvrOLukfw89fxybyhb91LQbMu3vDp5ai0Q6LIoyCw7st6Rpl1zmKNLfHOaTBf1tdPxwflvsh0iY69Mp8JZTgu8wGgPRKOKvmHsR0lHhlzEq7afFtFgZ9oVOTspnF8i1PYSOJk53jHtorW4klkItXlH0e4ntCTsa2KyJ23MkLDYAkatVJBMqwdoYiZPu2HS2aQMcSgMlutveTo7mxUas7MQnvogw58yfZIG1zckrVfVxSchP6IFCcgzYSdSVmO9JhPKez4VThyQ9a7XfNmr0QoWqSyMEMVX1upfrr8KW6iefqBKBvB9KxfAPdUbyz6zrtdjkj1HqkvVY4nhxwrFtWOJ8ss4qz3hseObOQqC8jfelSLiMCwFhKWpCPr2MuiCX4ltUb5aIiE38YkUkgjP0ECAb3Bxwr7TvtMOSPyl5BoDjYhRCOrCa1LB5W81NESG7meX9bIEm5RTb6uoSj03jJEopLnAZDRez3B8eUKQXjr8pkwFTvIAEXy2qjAPwZ1td

Fixed! Install using:
sudo pip3 install<EMAIL_ADDRESS>Thank you very much for reporting.


SMGPR : the induced points are different for each model

In the implementation of calculate_factorization of the class SMGPR,
Z_0 (induced points of models[0]) is used for all the SGPR models but since the
models are optimized separately, all the sets Z_i are different.
In the original PILCO implementation all the models share the same induced points.
Could this affect the performances of SMGPR ?
I saw that GPFlow seems to be able to handle shared induced inputs.
https://gpflow.readthedocs.io/en/master/notebooks/advanced/multioutput.html

GPflow multioutputs is not available for the moment for GPR and SGPR.
https://github.com/GPflow/GPflow/issues/1209


Set instance variable values at initialization and remove unused variables to avoid spamming rake warnings.

Fixes https://github.com/farcaller/rly/issues/2.

Do the tests work for you locally?

I saw the same errors locally as well. I saw this sentence Failures listed here are expected and do not affect your suite's status. So I thought it's fine. On a second look, the following one seems to be a real failure:
Failures:

  1) Rly::LRTable attaches the lookahead symbols to grammar rules FIXED
     Expected pending 'verify that values in LRItem#lookaheads are meaningful' to fail. No error was raised.
     # ./spec/parse/lr_table_spec.rb:195

Looking.

I just tried backing off my changes line by line to isolate the issue.
Any chance you still remember what that error is about (I know it's been a few years...)?

Looking at it the tests are broken because of some files missing and I have no clue where my local checkout is – that was three notebooks ago.

Thanks for fixing this!


A new example: camera controls

Description
A stand-alone camera example.
List of changes

Added example "11_simple_camera.py"
The example uses the canon "example_window.py" for context creation
The camera class is built using following tutorials:
https://learnopengl.com/Getting-started/Camera
http://in2gpu.com/2016/03/14/opengl-fps-camera-quaternion/

Thank you!

I noticed the camera controls don't work on OS X (and probably not Linux) because it checks OS specific key IDs (a trap I have fell into in the past as well). I'll fix that when converting it to the new example system.


#1 Create form and show data

Value Proposition
As a user
I want to insert the things that made me grateful today
So that I can read it afterwards in my list of entries
Description

Acceptance Criteria

[ ] A headline with a question is shown
[ ] An input field for the users input is shown (label: "tbd")
[ ] A submit button is displayed
[ ] The input field is required
[ ] After submitting the input is displayed in the list of entries
[ ] Another headline marks the beginning of the entry list

Tasks
(for developers team)

[ ] Create a form component with one required input field
[ ] add a submit button to the form
[ ] add event.preventDefault to the form submit
[ ] Create form validation (required, no empty spaces)
[ ] Render the answers to a card

Complexity
L

Hi @ckskr  👋
Great first User Story.
I have just a few super picky suggestions:
Description

the headline at the top of your wire frame "Great to have you here" is not mentioned in the user story. Only the existing elements should be visible in the wire frame, so please add the headline to your user story or remove it from the wire frame.

Acceptance Criteria

Submit button: Your button says "Add to my Diary", which is probably the list 😉. However, the Diary isn't mentioned anywhere else. I would suggest you to stay consistent and perhaps add Diary to the list headline.
What happen if the user send the form without the required input field?  Is there a message shown?
The "things I'm grateful" for are showing as a list, but the input is probably a <textarea> - I would like to recommend you to think about the implementation.

Tasks

I'm a little bit confused about: Render the answers to a card  What answers? 😬
You could add Component Testing (requested) to your tasks.
You could add Story Book (optional) to your tasks.

If you have any questions, feel free to ask.

Looks good, found a typo in AC, row 7
"to fill the input fiels" +d
cheers
R.


Client Allocation Request for: McKurz Capital Incorporated

Client Allocation Questions
Core Information

Name: McKurz Capital Incorporated
Website / Social Media: @mckurz
Region: North America
DataCap Requested: 1TiB
Addresses to be Notarized: f3vn6ehbqdfsw36272obqpmekuswz5pqs47mtk27h56tmgaltmderm5g5sfj77unb47oiyef4zeszbtqu4lt6a
Notary Requested: andrewxhill

@georgemac510 Please subscribe to notifications for this Issue to be aware of updates. Notaries may request additional information on the Issue.

Hi Andrew,
Can I please change the DataCap requested to 1 TiB?
Thanks,
John McLaughlin

Hi @georgemac510,
I've made the edit to your application, please verify that everything above looks correct.
I can use the original responses to continue the vetting process. Since this is a renewal (previous application here https://github.com/filecoin-project/filecoin-plus-client-onboarding/issues/341), could you answer a couple of new questions before we move forward?
Usage

What portion of the originally granted datacap have you used to date?
If less than 100% could you provide a short justification for why the early application?
If less than 100% and using a new target address, do you still plan on utilizing the original datacap too?

Deployment

Can you provide any information on the deals you've created and miners you've used with your previously allocated datacap?
Are there any significant changes to your original application in terms of use-case, data inputs, or miner allocation?

thanks!

Hi Andrew,
Thank you so much for updating and considering my new verification
request.  The answers to the above follow:
Usage
1)  I have 889.05 GiB left in my granted DataCap, so ~111 GiB's
used.
2)  I have been using the granted allocation toward Slingshot
2.3 on the Fin-File Crypto project and due to a family emergency was not
able to finish and submit my work for 2.3. Having dealt
with family issue and getting back to development and hacking, I would
like                       to use the remainder of the granted allocation
for Slingshot 2.4 and my dataset Top 100 Crypto Investor Dataset. The new
application will be used for Sligshot 2.4 as well
On Tue, Jun 1, 2021 at 12:16 PM Andrew W. Hill @.***>
wrote:

Hi @georgemac510 https://github.com/georgemac510,
I've made the edit to your application, please verify that everything
above looks correct.
I can use the original responses to continue the vetting process. Since
this is a renewal (previous application here #341
https://github.com/filecoin-project/filecoin-plus-client-onboarding/issues/341),
could you answer a couple of new questions before we move forward?
Usage

What portion of the originally granted datacap have you used to
date?
If less than 100% could you provide a short justification for why
the early application?
If less than 100% and using a new target address, do you still plan
on utilizing the original datacap too?

Deployment

Can you provide any information on the deals you've created and
miners you've used with your previously allocated datacap?
Are there any significant changes to your original application in
terms of use-case, data inputs, or miner allocation?

thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/filecoin-project/filecoin-plus-client-onboarding/issues/497#issuecomment-852253782,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AH32A2F3GJSRB553TJL64CTTQUBULANCNFSM45ZN52PQ
.


Make code work on Node 4

Fixes #3714

Funny enough I just hit the same thing at work a few days ago but I was able to successfully convince all my coworkers to upgrade to Node 6.
Sadly I don't think I can yell loudly enough to convince everybody who might want to run the React Router examples though.
cc @jquense 🙃

Merging this as a trivial tooling change

:P


Add YAML files to set up build pipelines for nightly tests

Description
This pull request adds YAML files to set up build pipelines running nightly tests.
Specific Changes
We added three YAML files inside the folder build/yaml.
The added files are:

nightly-simple-build-test: builds the project and run the tests inside the pipeline.
nightly-build-test: deploys a bot in Azure in a Windows environment and runs the tests for that bot.
nightly-build-test-unix: deploys a bot in Azure in a Linux environment and runs the tests for that bot.

These files are configured to run the pipeline nightly in the master branch if there were changes. This can be edited in the file or using the UI in the pipeline set up.
How to use
The next steps will guide you through the configuration of a Build pipeline based on the YAML files.
Prerequisites
These requisites are not needed for the nightly-simple-build-test.

Azure DevOps organization.
Azure subscription. Required to create and delete Azure resources.
One app registration in Azure. More info
Configure an Azure Connection Service. Steps here
Luis service subscription

Set up build pipeline
1- Create a pipeline using the classic editor, this options allows us to select the YAML file to configure the pipeline.

2- Configure the repository and branch.

3- In the Configuration as code, select the YAML option.

4- In section YAML, write the build name and select the build YAML file inside the folder build-CI-yaml in the root of the directory.

5- In the Variables section add the following variables.

For the nightly-build-test:

TestBotAppdId
TestBotAppSecret
LUISAPPIDSECRET
LUISSUBSCRIPTIONKEYSECRET
AzureSubscription (Connection name from Connected Service)

For the nightly-build-test-unix:

TestBotAppdId
TestBotAppSecret
LUISAPPIDSECRET
LUISSUBSCRIPTIONKEYSECRET
AzureSubscription (Connection name from Connected Service)
AzureDeploymentUser
AzureDeploymentPassword

For the nightly-simple-build-test you don't need to add any variable.

Add a Connection Service
This step is required to use your Azure Subscription for the Windows and Linux CI builds. If you already have a Connection Service configured, save its Connection name to use it later as AzureSubscription.
For more info go to this link.
1-  In your Azure DevOps project, go to project settings -> Service Connections -> New service connection.

2- Select Azure Resource Manager and click Next. In the dialog select use the full version of the service connection dialog.

3- Fill all the fields and check the Allow all pipelines to use this connection option. Save the name you are using in Connection name, this will be the variable AzureSubscription in following steps

Testing
In the following images, you can see the builds running in a pipeline from the YAML file.

Pull Request Test Coverage Report for Build 96204

0 of 0   changed or added relevant lines in 0 files are covered.
1774 unchanged lines in 243 files lost coverage.
Overall coverage remained the same at 78.076%

Files with Coverage Reduction
New Missed Lines
%

/libraries/Adapters/Microsoft.Bot.Builder.Adapters.Facebook/FacebookAdapter.cs
1
94.85%

/libraries/Adapters/Microsoft.Bot.Builder.Adapters.Facebook/FacebookAdapterOptions.cs
1
86.67%

/libraries/integration/Microsoft.Bot.Builder.Integration.ApplicationInsights.Core/ApplicationBuilderExtensions.cs
1
71.43%

/libraries/Microsoft.Bot.Builder.AI.LUIS/LuisApplication.cs
1
96.36%

/libraries/Microsoft.Bot.Builder.AI.LUIS/V3/LuisApplication.cs
1
96.43%

/libraries/Microsoft.Bot.Builder.AI.LUIS/V3/LuisUtil.cs
1
96.35%

/libraries/Microsoft.Bot.Builder/BotStateSet.cs
1
85.0%

/libraries/Microsoft.Bot.Builder.Dialogs.Adaptive/Actions/BaseInvokeDialog.cs
1
87.5%

/libraries/Microsoft.Bot.Builder.Dialogs.Adaptive/Actions/Case.cs
1
87.5%

/libraries/Microsoft.Bot.Builder.Dialogs.Adaptive/Actions/EditActions.cs
1
93.75%

Totals

Change from base Build 96073:
0.0%

Covered Lines:
19320

Relevant Lines:
24745

💛  - Coveralls

:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.Luis.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.QnA.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.ApplicationInsights.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Azure.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Dialogs.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Integration.ApplicationInsights.Core.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Integration.AspNet.Core.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.TemplateManager.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Testing.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Configuration.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Connector.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Schema.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Streaming.dll compared against version 4.6.3

Suggest naming the files adding "functional", as in "nightly-build-functional-test-unix.yml" and "nightly-build-functional-test-windows.yml".

@matiasroldan6 Can you update per @BruceHaley suggestion?

:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.Luis.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.QnA.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.ApplicationInsights.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Azure.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Dialogs.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Integration.ApplicationInsights.Core.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Integration.AspNet.Core.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.TemplateManager.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Testing.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Configuration.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Connector.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Schema.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Streaming.dll compared against version 4.6.3


feat: Implement Test Runner workflow for Windows

Resolves #105.

Building raftify-py whl on Windows CI is failing for following error.
ImportError while importing test module 'D:\a\raftify\raftify\binding\python\tests\utils.py'.

The reason for the failure is not clear, but I will exclude Python tests in the Windows environment from the CI pipeline. (The build on an actual Windows machine works fine.)

Thanks!


How to set the Badge count in iOS when the App is not running

Hi,
I am trying to figure out a way to set badge count when the App is in the background or is not running at all (killed by the User). I have tried to dig around but don't find anything for iOS.
I see from the documentation that I can set that for Android using this data payload
    "data": {
    	"title": "Badge Test",
    	"message": "Badges, we don't need no stinking badges",
    	"badge": 7
    }

where the number against the badge key will be set against the App icon for devices that support that.
However I am not clear on how to do that for iOS. I see ways to do that by setting content-available and processing the message when the App is in background and calling the function setApplicationIconBadgeNumber  from the code to set the badge count but if the App is not running in the background then how do I set the badge count for iOS through data in the push notification I send to the device?
The description for the function setApplicationIconBadgeNumber says "Set the badge count visible when the app is not running". I must be missing something obvious here because how do I call that function to set a badge count provided in the message when the App is not running?
Thank you for your help and pointers.
Sanjay.

To set the iOS badge you can send it on the payload like this:
{
    "aps" : {
        "alert" : "You got 9 emails.",
        "badge" : 9
    }
}

Thank you @jcesarmobile. I am using GCM and I have tried payload like below but that didn't change/set the badge number. Do I need to do anything different or is this supposed to work?
{
            "notification": {
                "title": "Badge Message",
                "body": "Show badge count"
            },
            "data": {
                "badge": 12
            }
}

I think it should go inside notification, but better check GCM docs.


[TECH ED] Design Basics

Link to the coursework
https://scrimba.com/learn/design
Why are we doing this?
Runtime 1 hour 8 minutes.
This course will help you with your Cake project, and give you some fundamentals of design to help you interpret and express design as code.
Maximum time in hours
1.5
How to get help
Share your blockers in your class channel. Use the opportunity to refine your skill in Asking Questions like a developer.
How to submit
No submission step

Kamino cloned this issue to maz786/Coursework-Planner

Kamino cloned this issue to RbAvci/My-Coursework-Planner


Error on launch

I cannot launch this due to
e: C:\src\flutter\.pub-cache\hosted\pub.dartlang.org\mobile_scanner-1.0.0\android\src\main\kotlin\dev\steenbakker\mobile_scanner\MobileScanner.kt: (29, 1): Class 'MobileScanner' is not abstract and does not implement abstract member public abstract fun onRequestPermissionsResult(p0: Int, p1: Array<(out) String!
>, p2: IntArray): Boolean defined in io.flutter.plugin.common.PluginRegistry.RequestPermissionsResultListener
e: C:\src\flutter\.pub-cache\hosted\pub.dartlang.org\mobile_scanner-1.0.0\android\src\main\kotlin\dev\steenbakker\mobile_scanner\MobileScanner.kt: (69, 5): 'onRequestPermissionsResult' overrides nothing
e: C:\src\flutter\.pub-cache\hosted\pub.dartlang.org\mobile_scanner-1.0.0\android\src\main\kotlin\dev\steenbakker\mobile_scanner\MobileScanner.kt: (70, 66): Type mismatch: inferred type is Array<CapturedType(out String)>? but Array<(out) String!> was expected
e: C:\src\flutter\.pub-cache\hosted\pub.dartlang.org\mobile_scanner-1.0.0\android\src\main\kotlin\dev\steenbakker\mobile_scanner\MobileScanner.kt: (70, 79): Type mismatch: inferred type is IntArray? but IntArray was expected

Changing the lines to the proposed ones lets me run it.
Thanks so much for this great plugin!

(Also, there are two warnings
/C:/src/flutter/.pub-cache/hosted/pub.dartlang.org/mobile_scanner-1.0.0/lib/src/mobile_scanner.dart:50:20: Warning: Operand of null-aware operation '?.' has type 'WidgetsBinding' which excludes null.
 - 'WidgetsBinding' is from 'package:flutter/src/widgets/binding.dart' ('/C:/src/flutter/packages/flutter/lib/src/widgets/binding.dart').
    WidgetsBinding.instance?.addObserver(this);
                   ^
/C:/src/flutter/.pub-cache/hosted/pub.dartlang.org/mobile_scanner-1.0.0/lib/src/mobile_scanner.dart:131:20: Warning: Operand of null-aware operation '?.' has type 'WidgetsBinding' which excludes null.
 - 'WidgetsBinding' is from 'package:flutter/src/widgets/binding.dart' ('/C:/src/flutter/packages/flutter/lib/src/widgets/binding.dart').
    WidgetsBinding.instance?.removeObserver(this);
```)

I see this is to be fixed in pull request #63! Thanks.


Set header param to receive a Widget to allow custom header

We are unable to provide a custom header widget.

Customheader may can help

Any example @peng8350 ?

Thanks I did.


Feedback on attaching Azure Static Disk to Windows pod

The doc doesn't really give a good example for mounting a static disk on Windows pods, it just talks about changing the mount, but if you deploy this example pod on a windows node it gives this error:
Warning  FailedMount             97s (x15 over 17m)   kubelet                  MountVolume.MountDevice failed for volume "azure" : azureDisk - mountDevice:FormatAndMount failed with diskMount: format disk failed, error: exit status 1, output: "Format-Volume : Cannot validate argument on parameter 'FileSystem'. The argument "ext4" does not belong to the set \r\n"FAT,FAT32,exFAT,NTFS,ReFS" specified by the ValidateSet attribute. Supply an argument that is in the set and then try \r\nthe command again.\r\nAt line:1 char:161\r\n+ ... ew-Partition -UseMaximumSize | Format-Volume -FileSystem ext4 -Confir ...\r\n+                                                              ~~~~\r\n    + CategoryInfo          : InvalidData: (:) [Format-Volume], ParameterBindingValidationException\r\n    + FullyQualifiedErrorId : ParameterArgumentValidationError,Format-Volume\r\n \r\n" and clean up failed with :remove \var\lib\kubelet\plugins\kubernetes.io\azure-disk\mounts\m708605900: The system cannot find the file specified.
With this error I found this Github thread - https://github.com/MicrosoftDocs/azure-docs/issues/34509 - with this comment fixing the error above:
@lingtham for the static disk issue, can you try adding the fsType to NTFS in the windows pod yaml and try.
volumes:
- name: azure
azureDisk:
kind: Managed
diskName: myAKSDisk
diskURI: /subscriptions//resourceGroups/MC_myAKSCluster_myAKSCluster_eastus/providers/Microsoft.Compute/disks/myAKSDisk
fsType: NTFS
Could we add this fsType: NTFS to the doc as needed for Windows? or, could we maybe provide a full example like this?:
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample
labels:
app: sample
spec:
replicas: 1
template:
metadata:
name: sample
labels:
app: sample
spec:
nodeSelector:
"kubernetes.io/os": windows
containers:
- name: sample
image: mcr.microsoft.com/dotnet/framework/samples:aspnetapp
resources:
limits:
cpu: 1
memory: 800M
requests:
cpu: .1
memory: 300M
ports:
- containerPort: 80
volumeMounts:
- name: azure
mountPath: 'D:'
volumes:
- name: azure
azureDisk:
kind: Managed
diskName: myAKSDisk
diskURI: /subscriptions/ce1ba766-26d0-4cc5-bca6-ccaae1c275b7/resourceGroups/MC_AKSrg_akswin_eastus/providers/Microsoft.Compute/disks/myAKSDisk
fsType: NTFS
selector:
matchLabels:
app: sample

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

ID: 74be7378-92bc-0e59-0b70-c6b10e80d9b6
Version Independent ID: f7f1eeb3-efe7-86e2-1fd7-04341b2c77cc
Content: Create a static volume for pods in Azure Kubernetes Service (AKS) - Azure Kubernetes Service
Content Source: articles/aks/azure-disk-volume.md
Service: container-service
GitHub Login: @mlearned
Microsoft Alias: mlearned

Thank you for the feedback.
We've added a task to our backlog and will prioritize accordingly.
#please-close


Cannot wallet inscribe in regtest: Bitcoin Core wallet but not in ord index

Enviroment
Bitcoin Core version v24.0.0
ord 0.15.0
Ubuntu 22.04
bitcoin.conf
txindex=1
server=1

I'm following the guide at https://docs.ordinals.com/guides/testing.html
I successfully execute the commands:
Run bitcoind in regtest with:
bitcoind -regtest -txindex
Create a wallet in regtest with:
ord -r wallet create
Get a regtest receive address with:
ord -r wallet receive
Mine 101 blocks (to unlock the coinbase) with:
bitcoin-cli -regtest generatetoaddress 101 <receive address>
But when I run:
ord -r wallet inscribe --fee-rate 1 --file <file>
I get an error:
error: output in Bitcoin Core wallet but not in ord index: d3cc91e2117ee63b1f05f26c7913fc9d1267893ecac5a90d65169c356d685519:0
Please, can you help me understand what might be causing this issue?

You need to delete the ord regtest folder and start from scratch. Mine was located at ~/.local/share/ord/regtest


Ground truth object search failing even when the object has been seen

I am trying to run the system in ground truth mode - no correlation or or vision detector being used to see approximate best amount of time it takes to search for an object.
I ran the following test script. The system consistently ends up going near the cellphone but looks up in the end and says target not found
import os
import sys

ABS_PATH = os.path.dirname(os.path.abspath(__file__))
sys.path.append(os.path.join(ABS_PATH, "../../experiments/thor"))

import thortils as tt

from experiment_thor import (Methods,
                             make_trial,
                             OBJECT_CLASSES,
                             read_detector_params)

def prepare(scene_type):
    detector_models = read_detector_params()
    targets = OBJECT_CLASSES[scene_type]["target"]
    corr_objects = OBJECT_CLASSES[scene_type]["corr"]
    return detector_models, targets, corr_objects

def _test_method(method, scene_type, target_class, scene="FloorPlan21"):
    valscenes = tt.ithor_scene_names(scene_type, levels=range(21, 31))
    if scene not in valscenes:
        raise ValueError("Only allow validation scenes.")

    detector_models, targets, corr_objects = prepare(scene_type)
    if target_class not in targets:
        raise ValueError("{} is not a valid target class".format(target_class))

    trial = make_trial(method, 0, scene_type, scene, target_class,
                       detector_models, corr_objects=corr_objects,
                       visualize=True)
    trial.run()

if __name__ == "__main__":
    room_type = 'bedroom'
    goal_obj_type = 'CellPhone'
    scene = 'FloorPlan321'
    _test_method(Methods.GT_HIERARCHICAL_TARGET, room_type, goal_obj_type, scene=scene)

To investigate, you can try printing out the agent’s belief as it approaches. See how the belief about the object’s height changes especially when approaching.
I don’t remember exactly, but it’s possible that the belief over the object’s height is uniform even in groundtruth mode.
I suspect that when the agent gets too close to the cellphone, the cellphone is actually not in FOV, so the agent doesn’t get observations about the target. As a result might update its belief about the object’s height and think it needs to look up. I am not sure why it consistently looks up though.

To investigate, you can try printing out the agent’s belief as it approaches. See how the belief about the object’s height changes especially when approaching.
I don’t remember exactly, but it’s possible that the belief over the object’s height is uniform even in groundtruth mode.
I suspect that when the agent gets too close to the cellphone, the cellphone is actually not in FOV, so the agent doesn’t get observations about the target. As a result might update its belief about the object’s height and think it needs to look up. I am not sure why it consistently looks up though.

So the height belief oscillates between same and below as it approaches the object of interest. Yes, you are right in that when it is quite close the object is not in the FOV. I would, however, expect it to look down as the probability is higher for the object being below as compared to above and not call done when looking up.
Is there any way to debug this in a more formal way? I have used the TreeDebugger you pointed me to and it's a great tool. But it is hard to debug all possible paths in monte carlo simulations as there are 100s of simulations and and each simulation has many steps and each step has it's own tree.
Is there some simple way to store the tree at each step of the simulation? To see what made it decide to take an action at a particular step (basically looking back after execution of the steps and hence only need to look at 1 tree instead of 100s of trees)

Not sure if I totally follow, but you can do ‘dd.mbp’ which highlights the preferred / best-case scenario.
I would specifically look at the belief state when the target is in FOV (not just the image, but also the sensor model), and the step afterwards where it goes out of FOV. And indeed I would use the debugger and check if the agent gets rewarded after it looks down — it’s possible that in this particular scene, for some reason, when the agent gets too close to the target, the target just won’t be in the FOV of the sensor model. I know it’s weird but it’s possible for Ai2Thor scenes.

It would be good to also check what sequence of actions and observations drives the agent towards the target. This can be marked in the debugger with dd.mbp.

My understanding is,  please correct me if I'm wrong, The Treedebugger, whenever initialized has the tree from the current step - so if we have taken 4 steps already in the environment and I initialize the debugger - it will show the best actions to take from this point on and we would not know why the previous 4 steps were taken.
Since at any given time, we run 100+ simulations, we have 100+ trees to look at and this makes the debugging hard to see what future action the agent is going to take from the current state.
Is this is the case or am I missing something?

This is not quite right:

Since at any given time, we run 100+ simulations, we have 100+ trees to look at

There is only one tree. The rest is correct. I’d say for the most part, at a given time, I only care about what the agent will do next (planning). I don’t care about what it has done before.

This is not quite right:

Since at any given time, we run 100+ simulations, we have 100+ trees to look at

There is only one tree. The rest is correct. I’d say for the most part, at a given time, I only care about what the agent will do next (planning). I don’t care about what it has done before.

Yes there is only 1 true tree - but at any given point there are multiple paths that can be taken from there and each has it's own potential tree - so if I want to look at what the belief state is during different possible monte carlo simulations, there would be multiple possible trees amongst which only one will be the real tree based on the action taken right?

Each simulation particle travels down the tree along a path. Not a tree.

Each simulation particle travels down the tree along a path. Not a tree.

Oh right, there is only 1 tree and all the branches are the multiple simulations.
Just a clarification about the way the tree is stored - as soon as one action is taken, the next node corresponding to the action is made the root node right (and basically pruning every other simulation once an action has been taken)

Yes, but only if the ha node (i.e. QNode) has a child observation that matches the real one.

I believe I may have found the issue - It is in the belief update: https://github.com/zkytony/cos-pomdp/blob/1e3c7fe940a2165b5c5c384ebf047e8139d437ec/cospomdp_apps/thor/agent/components/belief.py#L119
It says - if the object is not visible then it must be above or below and if the object is visible it is same.
There's multiple potential pitfalls that I see:

Consider the scenario when the object is at a lower height but far so it is visible without looking down.

a.  When the agent is far and sees the object, it's belief  that object is at the same height increases very strongly even thought technically it should be increasing the belief about lower height and not same height
b. Now when the agent gets close to the object, it no longer sees it so belief about the object being higher or lower increases. This is what leads to the potential of the agent looking up - because it's belief of object being above is higher than it should be.
There is another part of the code that I am not sure I fully understand
https://github.com/zkytony/cos-pomdp/blob/1e3c7fe940a2165b5c5c384ebf047e8139d437ec/cospomdp_apps/thor/agent/components/belief.py#L128
Here, both the if and else are checking if current pitch is maximum (checking if pitch == 330) because that is the max in thor_v_angles.  It looks like elif is also checking for that? is this a typo or a particular expected behaviour that needs this to happen?

Consider the scenario when the object is at a lower height but far so it is visible without looking down.

Assuming "far" is still within detectable range by the sensor model, then the agent would receive observation of the object, update its belief (doesn't have to look down). This seems to match what you are describing.  This behavior is demonstrated in the example shown in 0:27-1:00 of the video.

This is what leads to the potential of the agent looking up - because it's belief of object being above is higher than it should be.

Isn't this fine though? The agent would look up, didn't see it there, and increase the belief that the object is lowere, and eventually look down. (I believe the sensor model does account for tilt of the sensor even though the FOV is 2D -- to the extent I could implement).

Here, both the if and else are checking if current pitch is maximum (checking if pitch == 330)

That must have been a typo... I believe I meant to say min() for the elif case.

Consider the scenario when the object is at a lower height but far so it is visible without looking down.

Assuming "far" is still within detectable range by the sensor model, then the agent would receive observation of the object, update its belief (doesn't have to look down). This seems to match what you are describing. This behavior is demonstrated in the example shown in 0:27-1:00 of the video.

Ok, maybe I missed something. If the height belief says the object is same, I would assume it needs no action in terms of up or down is required. As soon as the agent gets close, it no longer has any idea where the object now is - in terms of height. How about using the height information to update belief - we do get object height from the detector and if the object height is low we say it's low irrespective of when it's seen. Keep updating that belief every time the object is detected - do you think that would be ok or do you see any issues with that?

This is what leads to the potential of the agent looking up - because it's belief of object being above is higher than it should be.

Isn't this fine though? The agent would look up, didn't see it there, and increase the belief that the object is lowere, and eventually look down. (I believe the sensor model does account for tilt of the sensor even though the FOV is 2D -- to the extent I could implement).

Here, both the if and else are checking if current pitch is maximum (checking if pitch == 330)

That must have been a typo... I believe I meant to say min() for the elif case.

If it checks for min - which is technically 0, it is actually checking if it's level - we should probably be checking for the extremes right? which are 30 and 330?

If the height belief says the object is same, I would assume it needs no action in terms of up or down is required.

My idea of height in the belief was a relative concept. Always relative to the current view pose. That would result in a different behavior than what you would expect. I personally find that reasonable. If I walk around to find a salt shaker with my head fixed (unless I intentially tilt it), then the target would go out of my sight as I move closer to it. Then, if I really believe that the object is in that 2D location, my relative height belief would be updated to prompt me to look down.  Try to imagine this.
I did mention this in the paper, but the space was limited. "...estimate target object height among a discrete set of possible height values, Above, Below, and Same, with respect to the camera’s current tilt angle."

How about using the height information to update belief

If you could build a (vision)-based detector that can estimate detected object's height, then sure. It's not a good idea of course to take the height z value from the simulator and shove it through the observation model (I assume you are not doing this).

If it checks for min - which is technically 0, it is actually checking if it's level

Actually, since that code is in update_target_belief_3d which is belief update, I'd assume that the angles in next_srobot are not mapped 0-360, but directly read from the simulator which can be negative. v_angles as defined [here](https://github.com/zkytony/cos-pomdp/blob/1e3c7fe940a2165b5c5c384ebf047e8139d437ec/cospomdp_apps/thor/constants.py#L32) could also be negative (the min is -30). So the two are in the same space.

I looked at the commit history, and looks like I was trying different parameters for prior_*. But yes, I think you are getting at the crux (height belief update affects lookup/down). I believe I got it to work pretty consistently eventually. It could be possible that 5b9dd741fac3fe823d8dc62d21992881cd4ba7cc was a post-hoc logic clean-up but the experiments were run using an earlier version of the code that date. I don't remember exactly.   It might be worth checking out an older commit on that date (Sep 13, 2021) and see if the behavior is different.

If it checks for min - which is technically 0, it is actually checking if it's level

Actually, since that code is in update_target_belief_3d which is belief update, I'd assume that the angles in next_srobot are not mapped 0-360, but directly read from the simulator which can be negative. v_angles as defined here could also be negative (the min is -30). So the two are in the same space.

Then there might be an issue here - I actually printed out the v_angles - it takes the values of 30, 0, 330, and 300. It's coming from  bu_args["v_angles"]. It looks like this set of v_angles are being initialized here https://github.com/zkytony/cos-pomdp/blob/1e3c7fe940a2165b5c5c384ebf047e8139d437ec/cospomdp_apps/thor/agent/cospomdp_complete.py#L285
(the v_angles stored in task_config are 60, 30,0, -30) but after this line, they are changed to 30, 0, 330, 300.  (The grid pitch function is at https://github.com/zkytony/cos-pomdp/blob/1e3c7fe940a2165b5c5c384ebf047e8139d437ec/cospomdp_apps/thor/agent/components/action.py#L114)

Ah… one thing I forgot. Ai2thor has a coordinate system. But the pomdp agent uses a different coordinate system (based on the grid map). That’s why there is that grid_pitch conversion.

Ah… one thing I forgot. Ai2thor has a coordinate system. But the pomdp agent uses a different coordinate system (based on the grid map). That’s why there is that grid_pitch conversion.

so I then I would guess that using max/min with these updated values wouldn't lead to desired results? I guess it needs to be updated to checking values in this new set of values?

Yes, you may be correct. If so, I am more certain that that’s a post-hoc logic cleanup after experiments which made a mistake. The original issue you raised regarding ground truth agent behavior may be a result of this.

So this seems to be alleviating the issue of getting a good height belief - I now use the depth projection to get a better confidence of height and it is working well - the confidence over what height an object is quite high - in the case I was trying it was below with 0.9999. The original issue still occurs though - even with this high confidence of the object being below, the agent ends up looking up in the end

As you can see, the confidence of the object being below is as close to 1 as possible. When this sequence of actions starts, it's actually looking down - then it ends up taking a couple of look actions and then calls done. Any reason you think this could be happening even with this very high confidence of height being below?

This is indeed pretty strange. I can't think of a reason this would happen other than there's a bug somewhere. The bug is likely not in height belief update, but maybe in the sensor model, or transition model. Because LookUp when believing the object is "below" caused high value (meaning a detection) -- you can confirm this by using the TreeDebugger, and do dd.mbp if you hit a case where LookUp has the highest value.
The experiments were run on Sep 13, 2021. Looking at the commit history of the repo, I did some organization / clean-up which might have introduced a bug. I don't think this occurred (or at least would have ben fixed when I started the experiments). You might want to check out an older commit and see if the behavior persists (if you don't want to debug the current state of the code).

Another possibility is: When the object is believed to be "below", for some reason, the agent (i.e. planner) thinks that LookUp and LookDown would both result in detection of the object. This could be due to an inaccuracy of tilting implemented in the sensor model, which would result in a fan that cover the 2D area the agent has highest belief in whether it looks up or down. This would not be a bug but a limitation of the sensor model that's implemented.

Another possibility is: When the object is believed to be "below", for some reason, the agent (i.e. planner) thinks that LookUp and LookDown would both result in detection of the object. This could be due to an inaccuracy of tilting implemented in the sensor model, which would result in a fan that cover the 2D area the agent has highest belief in whether it looks up or down. This would not be a bug but a limitation of the sensor model that's implemented.

you were right. This was the issue - https://github.com/zkytony/cos-pomdp/blob/1e3c7fe940a2165b5c5c384ebf047e8139d437ec/cospomdp/models/sensors.py#L51 - the computation of the difference in pitch - this seems to be outputting the wrong value - telling the agent looking up is correct instead of look down - and the reason for incosistent behaviour is the change in arctan function was not using the right values - so sometimes even with wrong values it worked out ok so it was succeeding once in a while but most of the time it was getting the wrong fact that looking up is correct.
Here is the updated code
    rx, ry, rz = robot_pos3d
    tx, ty, tz = target_pos3d

    dist = ((tx - rx)**2 + (ty - ry)**2 ) ** 0.5
    delta_y = rz - tz
    pitch = (np.arctan(delta_y/ dist) * 360) % 360

We need to use all of x,y and z to compute the relative angle to look at.
There is another weird behaviour now - on longer tasks - it is getting stuck in an infinite loop of look up / lookdown or RotateLeft/ RotateRight. Is the something that is possible through the POMDP itself or could it be a bug?

I didn’t deal with z of the target location in this paper. The belief is over target’s 2D location. So your fix would be doing something different and you’re on your own. The repeated lookup/lookdown behavior that you get is likely a reasonable result given the POMDP you created but the POMDP itself may not be desirable - you would have to debug the search tree. I’ve done this many times.

I didn’t deal with z of the target location in this paper. The belief is over target’s 2D location. So your fix would be doing something different and you’re on your own. The repeated lookup/lookdown behavior that you get is likely a reasonable result given the POMDP you created but the POMDP itself may not be desirable - you would have to debug the search tree. I’ve done this many times.

Sorry I think my memory was foggy and what I said here isn’t completely correct. I can’t recall how the numerical height of the target is passed into pitch_facing. The height belief should be relative. But yes, pitch should be calculated by arctan( height / dist ) as you showed. Not exactly sure what I was doing there…
If the agent keeps looking up and down, that means it thinks that would result in target detection even though it’s far away from the target. You may want to look at why that’s happening. There should be a detection range in the sensor model that has a role to play - target outside that range should have exponentially lower probability of detection.

The height is computed based on the belief - if the belief about the target object is that it is high, then the height is robot_height + delta. If it's same, then it's passed robot height and if it's below, object's height is stored as robot_height - detla.
My guess with why it's repeating is because of the hierarchical nature - the higher level POMDP is providing a sub-goal but the lower level isn't able to achieve it so the higher level system is giving the same goal over and over. I will check out the tree in more detail if this is the case.
Thank you very much for your prompt responses and detailed explanations. It has been very helpful. I'm trying to build an multi-object search based on the existing code so it was very important each of the objects to be found independently or the possibility of failure would compound.

Thanks for digging into this! Let me know if you encounter any further issue. I hope to help get this resolved.

Hey I finally figured it out.
It was mostly the rotation difference issue -
All rotations represented in code (except for AI2Thor ones - we can ignore them for this purpose), are represented as angles between 0 and 360. The issue with the yaw_facing and pitch_facing functions was that they were trying to find nearest angles in this scale.
But what was happening was, the angle 350, ideally should have been classified as being closest to 0, but the diff works by taking absolute diff, which means that 330 would be classified as closest to 330, thereby not giving reward, messing up with the planning thereafter. I switched all angle differences function to account for this and now I am able to get close to 100% in single object search with perfect vision.

Amazing. That sounds like something I could have potentially missed. Feel free to open a PR!
I would be very eager to see a video of ground truth object search working many times in a row!

I might need some time before I can open the PR. The updated code has a lot of my other changes to achieve multi-object search.
I can definitely show you some of the videos once the multi-object search works because that is basically a similar problem in a harder setting than a single-object search anyway.
Thanks for all the help throughout the debugging process :)

I see. I’m glad it works. Do what’s best for you.


IOU- Missing bullets after clicked on the currency symbol

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Go to staging.new.expensify.com
Log in with any account
Press the big green + to open the global create menu.
Select "request money"
Tap on the currency symbol ($ in US)

Expected Result:
Bullets should be displayed after clicked on the currency symbol
Actual Result:
Missing bullets after clicked on the currency symbol
Workaround:
Unknown
Platform:

Where is this issue occurring?

Web
iOS
Android
Desktop App
Mobile Web

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: No
Email or phone of affected tester (no customers): any
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/93399543/176306464-bdc56f23-f1ae-4bdf-beff-ea585d593752.mp4

Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

This may be a side-effect of #7702

@roryabraham is this the new expected behavior for currency list?

Yes, this is the new expected UI. Do we need to update the regression tests?

Yeah I was coming to ask why we need the bullets, it looks better without them.
Going to remove blocker

We can close this as soon as we confirm we've updated regression tests to reflect the new UI on this page.

@kbecciv @mvtglobally do we need to update regression tests to reflect the new UI on this page?

@luacmartins @roryabraham Steps in the regression don't mention the checkmark, we only need to verify that the currency is selected in the currency list. I think we're good to close this out without any changes there.