Update to use latest Vue.js

See https://github.com/zaproxy/zap-hud/pull/1109
The Vuejs libs names have changed.
According to https://vuejs.org/guide/quick-start.html#without-build-tools it looks like the *.esm-browser.js files might be the ones to use but I tried changing the build and html/js files to use them and it still didnt work.
Someone with more JS knowledge than me might be able to solve this much more quickly ;)

Can you please explain this a bit more? Maybe including the news from VueJS about the changes and how migration needs to be carried out?

Some answers 😄

I cant honestly remember, other than whats written above, ie all the js libs being renamed and not really knowing which ones to use
Latest would be ideal
Yes
I'd start here: https://github.com/zaproxy/zap-hud/blob/main/package.json#L100-L101
I cant honestly remember, but I'm pretty sure it was unusable

You dont have to use runZap if you have zap installed locally. I just use copyZapAddOn ..

Ok. To check my changes in the HUD code base, each time I need to run copyZapAddOn and run ZAP and then browser with HUD enabled? No other easy way? :P

It depends on what changes you make. If they are just client side then copyHudClientFiles may work ok - you shouldnt have to relaunch ZAP, just launch a new browser. But if you make any java changes you will need to copy the add-on

Hi all,
I spent some time today to learn Vue 3, so that it can help in migrating to the latest version, currently under src/main/zapHomeFiles/hud we have the client side files as follows:

display.css
display.js
display.html

The VueJS code is in .js file, which references to the template being used in .html file and the styles go in .css file. Whereas the latest convention being followed now in Vue 3 is to use a single file component aka SFC with extension of .vue which will contain all three, the html templates, the styles and the vue code.
The display.js file contains multiple components i.e. modal, nav-modal, dialog-modal so if I want to break display.js into a .vue file I should better divide it into smaller SFCs and the structure then may look like:

zapHomeFiles/hud

components

display

modal.vue
nav-modal.vue
dialog-modal.vue
...
It will improve the modularity and code structure a bit, and since we are changing the code structure I have a few more suggestions about changing the directory structure of HUD.

Currently, the java and javascript code is not separated properly, the package files and the gradle files are mixed at same level,  how I think the structure roughly should be is as follows

zap-hud

java code

buildSrc
gradle
src

file.java
file2.java

javascript code

node_modules
package.json
src

components

display

file.vue

In this way, we can separate the two languages resulting in better management of the codebase. The above hierarchy is just a rough and can be improved upon.
This task can drag away from the title of this issue i.e. updating VueJS version but since we're updating the HUD so I guess its the right time to make directory structure changes as well.
What do you guys suggest, given your experience how should this be approached? Should we first update VueJs version and then make directory changes to rest of the repo, or should we do it in parallel? In any case, the HUD is going to get broken and we won't be able to test it untill unless we complete the implementation so the decision need to be taken here wisely as lots of time is going to be invested in it.

I'd recommend updating VueJs first.
That will need to work before we can merge the changes, but then the restructuring can be performed over muyltiple PRs (if that works better).
Comments which explain how the code works are good, as long as they are not of the Adds one to x variety 😁
We have some dev docs in the wiki but they could definitely do with improving / updating.

Thanks @psiinon for feedback.
I will begin with updating Vue first, as for docs, the wiki contains some useful info. Can I somehow update the wiki section? I can try to improve it on the go, but can find any edit button for it. The fork has no wiki at all as a matter of fact.
Thanks

Pick a wiki page and have a look on the right hand side - you should see Clone this wiki locally - you can then update it and submit PRs 😁

Ugh, my bad - the wikis dont support PRs 😦
How about to migrate the HUD internal docs to the website?
Thats a better option and easier to manage.
Maybe under https://www.zaproxy.org/docs/developer/ ?

How about to migrate the HUD internal docs to the website? Thats a better option and easier to manage. Maybe under https://www.zaproxy.org/docs/developer/ ?

Good idea, how does the process looks like?

Have you updated the website before?
Pages are pretty easy to create as long as you're not trying to do anything radically new.
Theres an "Edit on GitHub" link on many of them which should give you a good starting point.
Do you think you'll need multiple pages?
If so then you'll need to create a new directory similar to https://github.com/zaproxy/zaproxy-website/tree/master/site/content/docs/developer

I closed my previous PR #1253; direct upgradation to 3 is def gonna produce lots of issues, so it makes sense to go step by step. Opened a new PR #1287 that upgrades to 2.7 which is an Extended LTS version (going out of support by the end of this year).


Docs: Add possibility to register kata runtime via daemon.json

Instead of a systemd dropin, one could also use Dockers /etc/docker/daemon.json which might better suite some orchestration tools or just use cause you do not have to reload systemd.

thanks @morph027 for raising this issue, the documentation has been updated now it includes that information.
see https://github.com/kata-containers/documentation/tree/master/install/docker


Local inference on A6000?

I'd love to test this out on my system -- any hope?
I was working on installing the collab dependencies locally, but I'm stuck here.
sed -i 's:jax[tpu]:jax:' setup.py

You can probably skip that line. The important thing is that you end up with a version of JAX installed that has support for your GPU: https://github.com/google/jax#pip-installation-gpu-cuda


Cannot compile with Xcode 6.1.1

When I add SWXMLHash.swift to my project I get the following errors:

Am I doing something wrong? I'm using OSX 10.10 and targeting My Mac.

Hi @omaralvarez - are you using the version from the master branch? That version is targeting Swift 1.2 (which didn't come until Xcode 6.3). The latest Xcode release from the AppStore is actually Xcode 6.4, though I'm not sure if you can upgrade or not.
If you can upgrade, that would be first recommendation. If for whatever reason you can't, I'd suggest checking out some of the earlier versions. I think that 0.6.4 is the most current version that works with Swift 1.1, but I'm not positive.

Yes, you are totally right, I was using the last release of SWXMLHash and my Xcode was not updated. Upgraded to Xcode 6.4 and everything is working fine. Thanks!!


Personifying Error Messages

@ThorbenStaufer please (later) have a look at research about "Personifying Error Messages", this is tightly related to Gamification and strongly attributes to less demotivate people while using programs.
In #147 @Bushuo already improved the error message, but it still has several problems:

[ ] useless header "error" (duplicate information)
[ ] too technical
[ ] no context
[ ] unclear what to retry (no context)
[ ] proposes possibly wrong solution (could be also Proxy error etc.)
[ ] no personification
[ ] no colors/formatting etc.

An improvement, but still not perfect is:
"Sorry, I cannot communicate with my server, there is probably some network problem. Please check your Internet connection."
As first step, we should write error message guidelines, so that the next error messages better consider state-of-the-art UX of error messages.

I added the info above in f6d97cca071ebdb993cbbf7694d6bc966f42dc0f #425.


Security of running node as root

Dear Dave,
I would encourage you to take a quick look at this post:
http://syskall.com/dont-run-node-dot-js-as-root/
Running node as root ("sudo") is probably a serious security hole, especially with a quick-and-dirty webserver. However, it looks like you could either a) within your code or b) from without give yourself the ability to run on port 80 without allowing anyone who hacks your server to gain instant root privs.
http://technosophos.com/2012/12/17/run-nodejs-apps-low-ports-without-running-root.html
https://www.digitalocean.com/community/tutorials/how-to-use-pm2-to-setup-a-node-js-production-environment-on-an-ubuntu-vps
http://syskall.com/dont-run-node-dot-js-as-root/
Your mileage may vary, but it feels like running servers as root is an insecure solution.

Thanks for the tip, I just tried your suggestion, and am running pagepark on port 80 without doing it as root. I'll post a link to the mail list.


[#122114497] Bump content loader to 1.2.0 and frameworks to 2.0.0

This story is for the top of the 'apply for this opportunity' page, add content for specialists only that says you can only put one specialist forward for each role.
Now that pull requests for the copy changes in the frameworks repo and the ability to filter descriptions in the content loader repo have been merged we are able to update our dependencies to bring the new content in to the supplier app.
Not a digital specialist

Digital specialist

:+1: Looks all good after a rebase!


Bug: multiple sequential spaces are loaded from URL as spaces followed by underscores

Fixed in 1.3.1


TransMac 14.5 Crack + License Key Free Download Latest

TransMac 15.6 Crack is a unique program that allows users to copy any type of document to and from X formatted hard drives, Mac OS. This version provides an easy-to-use interface with highly practical software that anyone can understand and operate. Transmac Pro 15 Portable offers users a system to utilize the MAC operating software. This primary option for viewing files allows you to record the contents of open files and devices across all kinds of devices.
///


Update alert design

It now pops up rather than slides in. This is part of the work
begun in #332

In #332, I intended for the modal to register its height in the redux store. Then, the modal would push itself down accordingly.
Given the new flex behavior of the alerts (they move up to fill the space between their default position and the top of the screen), this may need to change.
Do I want that flex behavior? I'll have to look the designs over and see what I prefer.


Refine some details for IKS deployment

Add more details for multi-user deployment
and correct some out-dated commands.
Also update the started page to 1.4 and add
a link to IBM manifest repo.
Signed-off-by: Yihong Wang<EMAIL_ADDRESS>

/cc @Tomcli

/approve

/lgtm
/approve

/lgtm


[AIRFLOW-537] WiseBanyan added to README.md

Dear Airflow Maintainers,
Please accept this PR that addresses the following issues:

AIRFLOW-537 Add WiseBanyan to README

Testing Done:

n/a

Changes:

Line 132, Added "[WiseBanyan](https://wisebanyan.com/)"

Current coverage is 65.48% (diff: 100%)

Merging #1815 into master will increase coverage by 0.03%

@@             master      #1815   diff @@
==========================================
  Files           127        127
  Lines          9650       9650
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           6316       6319     +3
+ Misses         3334       3331     -3
  Partials          0          0

Powered by Codecov. Last update 8ca8f66...e99dab9

@kevinjmullen Welcome to the community! To keep abreast of contributor guidelines, remember to check https://cwiki.apache.org/confluence/display/AIRFLOW/Contributors'+Guide


Help

i play on the community server and there is anit flash on the server but when osiris is on they can flash me

b776fbb40080f8862fd356b43302904c7b024c66 should fix it. Please try the latest source.


Opening system menu using Alt+Space stops a content dialog responding to mouse clicks

Describe the bug
Opening the system menu using Alt+Space stops a content dialog responding to mouse clicks. Fortunately it still responds to the keyboard. Opening the system menu by right clicking on the caption seems to work ok.
Steps to reproduce the bug

Build and run the attached repro project
Click on the "Open content dialog" button
Type Alt+Space to open the system menu
Click in the window to dismiss the system menu
Attempt to close the content dialog by clicking it's OK button

AltSpaceIssue.zip
Expected behavior
The mouse should work.
Screenshots
https://github.com/microsoft/microsoft-ui-xaml/assets/28826959/4be4e49a-ad55-4f12-a84b-efa62f34cbf8
NuGet package version
WinUI 3 - Windows App SDK 1.4.1: 1.4.230913002
Windows version
Windows 11 (22H2): Build 22621
Additional context
The repro project also contains a work around which involves subclassing the window, but it shouldn't be necessary.

Thank you, I can repro this.  I notice that if I press ALT again after the menu is gone, I can click the "OK" button again.  I wonder if we have code somewhere that misses the key-up for ALT and gets into a bad state.

Reopening. (A tooling issue resulted in incorrectly closing as duplicate.)


Add ‘textKey’ parse object

there are some bugs in the code. so i revert the PR @trazyn

update my demo and it work well
https://trazyn.github.io/react-mobile-picker/


Clean up MFA

Clean up MFA and run pretty code from VS

Sure can.
Thanks Allen :)
On Fri, Feb 9, 2024 at 9:18 AM Harrison Goscenski @.***>
wrote:

@jfarmer08 https://github.com/jfarmer08 would you like me to merge?
—
Reply to this email directly, view it on GitHub
https://github.com/jfarmer08/wyze-api/pull/8#issuecomment-1936113395,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEKHFB7NZVWHSCWTMK5HYS3YSY43FAVCNFSM6AAAAABDAMCKUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZWGEYTGMZZGU
.
You are receiving this because you were mentioned.Message ID:
@.***>


Application Gateway v1 applications not working

bash script throwing error on command not found
/home/vscode/.terraform.cache/modules/solution/modules/networking/application_gateway_application/scripts/delete_resource.sh: line 6: execute_with_backoff: command not found

Closing as in 5.4.6


softban global rayon thread pool

Problem

Global thread pool in rayon is difficult to trace to particular bits of code that might be using it. This makes figuring out implications of priorities and thread counts in that pool harder to predict. To that end, the idea is to soft-ban its usage by setting it to only run one thread. There is, unfortunately, no mechanism to permanently disable it short of forking rayon.

Summary of Changes

Use one of accountsdB existing thread pools (solAccounts) instead of global pool
Set global pool to 1 thread to discourage its use

Discussion is welcome! Forking/patching rayon could be considered, for example.

We did something like this before and it caused crashes because of the thread overflowing its stack:
https://github.com/solana-labs/solana/pull/24954
https://github.com/solana-labs/solana/issues/25481
https://github.com/solana-labs/solana/pull/25053

We did something like this before and it caused crashes because of the thread overflowing its stack: solana-labs#24954 solana-labs#25481 solana-labs#25053

Something like this what? The accountsdb code is already using dedicated pools in master today, there are only a couple of things that run almost never that seem to have been accidentally left in the global pool.

We did something like this before and it caused crashes because of the thread overflowing its stack: solana-labs#24954 solana-labs#25481 solana-labs#25053

Something like this what? The accountsdb code is already using dedicated pools in master today, there are only a couple of things that run almost never that seem to have been accidentally left in the global pool.

It looks like the issue is https://github.com/solana-labs/solana/pull/25053, which unfortunately doesn't include the panic.
If moving something from pool A to pool B causes a panic, it sounds like that's the thing that should be investigated and fixed?

I have this version running on an unstaked mainnet validator for several hours with no observable problems. Issues mentioned be Behzad did not materialize. Which additiinal tests are needed to make sure this will not blow up in prod?


Update for the mdast -> remark rename

The hound service is being updated to use remark, which is mdast's new name, in https://github.com/thoughtbot/hound-mdast/pull/7. This change brings that name change into Hound so everything is consistent.
https://trello.com/c/vFLTg8IQ

Kinda makes me miss when we supported one linter per language. That way code didn't need to change if we switched linters or it was rename. In reality, I think JS is the only language so far that has two different leading linters.
Looks good though.

I think @gylaz brings up a great point, for languages that are only backed by one linter - should we expose the linter or the language in the config level?

My vote would be no, because it would create more of a maintenance burden when that linter is no longer the only one or we decide to switch to another. If the key is the linter name, there's no migration that has to happen: the old stays around for a bit as legacy and we point people to the new one.

If the key is the linter name, there's no migration that has to happen...

That's a good point as far as configuration is concerned.

:+1:


add Puntland State University

Puntland State University is located in Somalia and have several Faculties including Computer Science

@MustafaWIthA I am sorry for a delay with processing your request.
Pull request merged. Thank you!

@MustafaWIthA I am sorry for a delay with processing your request.
Pull request merged. Thank you!

Busan Digital Highschool is located in The South Korea and there are department of electonic including the programming
curriculum.

Busan Digital Highschool is located in The South Korea and there are department of electonic including the programming
curriculum.

@hong0405 Please make a separate pull request with a file representing an email domain of Busan Digital Highschool. If you are in doubt how to make the request, please send an email to<EMAIL_ADDRESS>

@hong0405 Please make a separate pull request with a file representing an email domain of Busan Digital Highschool. If you are in doubt how to make the request, please send an email to<EMAIL_ADDRESS>


Bug in speech to text button

That button is enable even when it is processing...However it should be disabled.

Completed on commit ab4233b54576b1524ce94188ad9ebb293d045683


[Bug] [Release] List image flicker after copy/paste of list widget

Important Details

Version: [Cloud / Self-Hosted vx.x]
OS: [e.g.MacOSX]
Browser [e.g. chrome, safari]
Environment Release

@vivekverma2312 cannot see this flicker in chrome firefox or safari. need more details. can u share me the particular application.


chore: Bump golangci-lint from v1.45.2 → v1.55.2

Fixes broken lint CI step: https://github.com/furiko-io/furiko/actions/runs/7629655551/job/20783547238

Bumps golangci-lint from v1.45.2 → v1.55.2
Support versioned golangci-lint in ./bin in case the version is updated
Remove deprecated linters
Fix lint errors with stricter linter checks, remove a bunch of unused code
Add several lint exclusions in case of false positives

Tests will be fixed in the next PR, because we need more debugging to find out why it fails only in CI.


Fix email templates snakecase

/cc @cachethq/owners

:+1:

Tests failing?

Looks like travis is just down.


Version 1.2.6 on maven central ?

Hello,
It would be nice to have access to this library on Android, do you plan to release the next snapshot soon?
Thanks. :)

I'm hoping to see 1.2.6 coming out soon too.
Really would like to use it in my project.

For those interested, I uploaded the 1.2.6 artifact under another group id while waiting for the official release: https://search.maven.org/#search|ga|1|io.apisense.jdeferred

Hiya! apologies for the delay here. Thanx @aveuiller! I'll get this out soon :)

thanks patiently waiting! @saturnism

apologies for the delays. :) it's been pushed to bintray, and sync'ing w/ maven central.

it should be there now, cheers!  @aveuiller thnx again for jumping in to help as well! really appreciate it.

thanks @saturnism


AppFinder asks me to login too often

Wen AppFinder can't make an authenticated request to retrieve entitlements (apps you can launch) it redirects you to the WS1 login page.
This behavior is fine, but  sometimes happens more frequently than it should. More than once a day is probably too much!

Consider using a local storage cache or similar with > 24 hours expiry

Hi 👋
When mentioning a local storage cache, do you mean caching the entitlements ? That could also help with slooow initial load (sometimes up to several seconds). Do you know if the app launch URLs are stable day-over-day ?

Yeah, I believe the URLs are stable.
This is similar to the approach that the Okta extension uses, and I think it's where we should head with this.


(Question) Is this an alternative to Lutris and Bottles?

Currently Bottles and Lutris are the most complete Wine managers, with many options for customization.

Hey, this project in no way competes with Lutris and serves somewhat goals.

It is similar to Bottles in the sense that both have a notion of a "unit" (bottle) and manage your wine prefix, isolated per unit, and can install some hardcoded components for gaming (vkd3d-proton, dxvk). The main difference is Bottles is a GUI tool, and brie is a CLI tool in which the configuration of your units is stored in a YAML text file. This tool also has some additional features - it can monitor your YAML file and add "units" to Steam as non-steam Games, and manage them in Sunshine config for game-streaming
Lutris is substantially more though, it has a notion of different runners which aren't necessarily wine. Also in my opinion Lutrises main selling point is the database which instructs Lutris to automatically install things with winetricks into your wine prefix, configures registry keys etc, to make running well-known software as seamless as possible. Also IIRC it integrates with some shops for downloading games. brie on the other hand is much simpler - "units" are either wine or just native executables, all configuration of your prefix is done by you (declaratively in the YAML file), no integration with shops (for that I would suggest heroic)


Remove transition from failed to in-progress

From all the gateways written so far, this case is as
rare as the walking dead. So remove the transition
before someone uses the case

Coverage remained the same at 73.56% when pulling 7e9419cae4ef2d737f8dec0635eee046fba02958 on aroraumang:develop into 79bf8890ea07016354838b9622bd293d4b7b6708 on openlabs:develop.


[Bug][web]batch upload problem.

Search before asking

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

Description
在知识库上传多个文档时，上传文件后点击切片处理，提示以下消息：Please select chunk strategy for ...

Use case
希望每个文档默认是自动切片，不必手动展开每个节点选择
Related issues
无
Feature Priority
None
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

sorry about that , it looks like web problem, we will fix that soon.

其实把下面的都展开就可以了，看起来是不展开不会默认填参数信息


[TS] Refactor common pattern

This pattern is used quite a bit in designer-peer.ts. This should be factored into a helper method (or otherwise resolved).
        let defaultValue = addLabelAndInput(card, "Default value:", Adaptive.TextInput);
        defaultValue.input.placeholder = "(not set)";
        defaultValue.input.defaultValue = this.cardElement.defaultValue;
        defaultValue.input.onValueChanged = () => {
            this.cardElement.defaultValue = defaultValue.input.value;

            this.changed(false);
        }

Thanks for opening this.

@dclaux is already ready with this in the templating topic branch. Should be coming in by EOW.

This has been done.


Scipy python>3.6 Windows wheels don't ship msvcp*.dll

Scipy wheels for Python > 3.6 don't ship msvcp*.dll:
https://github.com/MacPython/scipy-wheels/blob/925d24f0ce5a86dd1452afefbce2263866f3d1fa/appveyor.yml#L169-L185
This is the C++ part of the msvc runtime. Python.org python ships the vcruntime140.dll (C runtime), but not the C++ one. I guess in most cases on desktop machines, the c++ runtime is already installed as many software probably needs it.
I think the omission may have been accidental --- if so, here's an issue ticket. I'm not sure whether the DLL should be shipped in the end, given that this is a corner case.
Reproducing code example:
E.g. new windows VM, install Python from Python.org, and install scipy via pip install scipy.
Then, import scipy.sparse fails with DLL error. This is fixed by downloading and installing the latest msvcrt package.
Scipy/Numpy/Python version information:
Scipy Python Windows wheels for Python > 3.6

I wonder if the language of the wheels PEP(s) would guide us in deciding on this.

Another case of this issue: https://github.com/scipy/scipy/issues/9230#issuecomment-540477379

I think the omission may have been accidental --- if so, here's an issue ticket.

You mean on our side, or on Python's side?
If we should be shipping it, that means that all projects using C++ should be shipping it right?

On our side, yes. I think pypi binaries should target the minimal Python.org Windows installation, which means no MSVCRT installed apart from what Python brings with it.
On October 11, 2019 9:24:37 AM UTC, Ralf Gommers<EMAIL_ADDRESS>wrote:

I think the omission may have been accidental --- if so, here's an
issue ticket.

You mean on our side, or on Python's side?
If we should be shipping it, that means that all projects using C++
should be shipping it right?

... implying they should ship whatever compiler RT libraries relevant. We did this up to py3.6, and I think just forgot to update that part of the appveyor build script for 3.7.
On October 11, 2019 9:24:37 AM UTC, Ralf Gommers<EMAIL_ADDRESS>wrote:

I think the omission may have been accidental --- if so, here's an
issue ticket.

You mean on our side, or on Python's side?
If we should be shipping it, that means that all projects using C++
should be shipping it right?

Ah, I didn't realize/remember that we did that. Makes sense now, thanks @pv


setup rustup via install_crate for fmt check

Part of issue #119

pushed as part of 0.15.2
@D4nte only now i saw that you wanted to do a PR for this, as I by mistake thought it was already in cargo-make. Anyhow feel free to contribute any other useful tasks via PRs directly


#4683: Support tracing

In this PR, we support the ability to make a trace (capturing a sequence of programs and replaying them).
We only support adding EnqueueProgram to the trace. Once you create a trace, it is undefined behaviour to continue using the EnqueueProgram APIs. You must call EnqueueTrace to get predictable behaviour.
If you would like to EnqueuePrograms and WriteBuffers, for now, you must use two command queues. One command queue to run the programs, and another to store and load the buffer data.

In this PR, we support the ability to make a trace (capturing a sequence of programs and replaying them).
We only support adding EnqueueProgram to the trace. Once you create a trace, it is undefined behaviour to continue using the EnqueueProgram APIs. You must call EnqueueTrace to get predictable behaviour.
If you would like to EnqueuePrograms and WriteBuffers, for now, you must use two command queues. One command queue to run the programs, and another to store and load the buffer data.

is it possible to protect against enqueue program apis being mixed with tracing mode


Constructor inject not working

Hei, i'm experiencing weird behaviour in my tests with constructor injects
//..
import {Container} from 'typedi';
import {AccessTokenService} from 'src/authentication/services/access-token-service';
import * as cfg from 'src/application/config';
Container.set('cfg.auth.jwt',cfg.auth.jwt);
const accessTokenService = Container.get(AccessTokenService);
accessTokenService.makeAccessToken(user);
//..

Dependecies are undefined when i configure them in the constructor

import {Service, Inject, Require} from 'typedi';
// ..
@Service('AccessTokenService')
export class AccessTokenService {

    constructor(
        @Require('moment') private moment,
        @Require('jsonwebtoken') private jsonwebtoken,
        @Inject('cfg.auth.jwt') private jwt
    ) {}

    makeAccessToken(user: User) {
        console.log(typeof this.jsonwebtoken); //undefined
        console.log(typeof this.jwt); //undefined
        console.log(typeof this.moment); //undefined
        // ...
    }
}

But this works

import {Service, Inject, Require} from 'typedi';
// ..
@Service('AccessTokenService')
export class AccessTokenService {

    @Require('moment') private moment;
    @Require('jsonwebtoken') private jsonwebtoken;
    @Inject('cfg.auth.jwt') private jwt;

    makeAccessToken(user: User) {
        console.log(typeof this.jsonwebtoken); //object
        console.log(typeof this.jwt); //object
        console.log(typeof this.moment); //function
        // ...
    }
}

Its strange that second is case is working  it shall not work as well. Probably second case is a bug.
Your problem is that you mark service with a label, you need to call:
const accessTokenService = Container.get<AccessTokenService>('AccessTokenService'); // string here is a name of the service you provided in the decorator
accessTokenService.makeAccessToken(user);

instead of what you are doing right now. If you want to get service by a class then you need to remove service's label.

Thank you. As i see the type variable must be supplied when using get with string aliases.

I'm afraid this solution Container.get<AccessTokenService>('AccessTokenService') still does not inject the services into the constructor. I even removed the Require decorator and replaced it with Inject.
What am i missing here?
import {Container} from 'typedi';
import {AccessTokenService} from 'src/authentication/services/access-token-service';
import * as cfg from 'src/application/config';
import * as moment from 'moment';
import * as jsonwebtoken from 'jsonwebtoken';

Container.set('cfg.auth.jwt', cfg.auth.jwt);
Container.set('moment', moment)
Container.set('jsonwebtoken', jsonwebtoken);
const accessTokenService = Container.get<AccessTokenService>('AccessTokenService');

Again, this does not work
import {Service, Inject} from 'typedi';
//..

@Service('AccessTokenService')
export class AccessTokenService {

    public constructor(
        @Inject('moment') private moment,
        @Inject('jsonwebtoken') private jsonwebtoken,
        @Inject('cfg.auth.jwt') private jwt
    ) {
        console.log(moment); //undefined
        console.log(jsonwebtoken);  //undefined
        console.log(jwt);  //undefined
    }
   //..
}

but this does
import {Service, Inject} from 'typedi';
//..

@Service('AccessTokenService')
export class AccessTokenService {

      @Inject('moment')
      private moment;

      @Inject('jsonwebtoken')
      private jsonwebtoken;

      @Inject('cfg.auth.jwt')
      private jwt;

   //..
}

When using classes, you don't need to use @Inject when injecting in the constructor. You simply write:
constructor(
    private userService: UserService,
    private loyaltyService: LoyaltyService,
    private timerService: TimerService,
  ) { }

I don't know about using them with default exports for other modules, but why do you want to inject them at all? You can just start using them right away.
import * as moment from 'moment';
// ....

@Service('AccessTokenService')
export class AccessTokenService {
   //...
   public myMethod() {
      return moment().format();
   }
}

When using classes, you don't need to use @Inject when injecting in the constructor. You simply write:

In your example you are using concrete class implementations. But sometimes i also want my dependencies to be interface binded. That would not work, because there is now way to know which implementation to load. That is also why i use the service name in the @Service @Inject decorators.

I don't know about using them with default exports for other modules, but why do you want to inject them at all? You can just start using them right away.

I do this to make testing easier. If i want to mock out moment, it is a lot easier this way. In plain javascript i could also use rewire but this does not work well with a typescript setup.

I do this to make testing easier

That makes sense, but then cannot you do this?
constructor(
    private momment: moment = moment,
  ) { }

No need for dependency injections, you still can mock it.

I could to that way.
Actually for testing this also works for me, because i can set the dependcies manually in the container
@Service('AccessTokenService')
export class AccessTokenService {

      @Inject('moment')
      private moment;

      @Inject('jsonwebtoken')
      private jsonwebtoken;

      @Inject('cfg.auth.jwt')
      private jwt;

   //..
}

My only problem is  why it works on the properties but not in the constructor. This seems like an inconsistency. It should either work with both or work with neither.

@ibox4real can you please provide a demo git repo with minimal reproduction of this problem? I added test (see commit above) and it does not reproduce your issue

ping @ibox4real

Yes, i will try to reproduce it in a simplified setup within the next few days.

Did you add import "reflect-metadata"; ?

yeah, probably he forgot to import reflect-metadata. Closing.


video.reports only: [:viewer_percentage] doesn't work. Deprecated?

https://github.com/Fullscreen/yt/blob/master/lib/yt/models/video.rb#L393
video.reports only: [:viewer_percentage] doesn't work.. seems like it's deprecated by YouTube?

viewerPercentage (core metric)
The percentage of viewers who were logged in when watching the video or playlist. This is a core metric and is subject to the Deprecation Policy.
https://developers.google.com/youtube/analytics/v1/dimsmets/mets

Something like dimension=gender should be added to the request.


Jasmine's First Meetup Reflection

Great!  Sounds like you've found a supportive space outside class, which is exactly what I hoped might happen :)


Cannot destructure property login of 'undefined' or 'null'.

Seeing the same.

same issue

Yeah, same. Here's a publicly available GitHub Actions run with the error:
{
  error: TypeError: Cannot destructure property `login` of 'undefined' or 'null'.
      at /home/runner/work/_actions/cleartax/jira-lint/master/lib/index.js:1:21210
      at Generator.next (<anonymous>)
      at /home/runner/work/_actions/cleartax/jira-lint/master/lib/index.js:1:19906
      at new Promise (<anonymous>)
      at n (/home/runner/work/_actions/cleartax/jira-lint/master/lib/index.js:1:19654)
      at run (/home/runner/work/_actions/cleartax/jira-lint/master/lib/index.js:1:20939)
      at Object.131 (/home/runner/work/_actions/cleartax/jira-lint/master/lib/index.js:1:23551)
      at __webpack_require__ (/home/runner/work/_actions/cleartax/jira-lint/master/lib/index.js:1:154)
      at startup (/home/runner/work/_actions/cleartax/jira-lint/master/lib/index.js:1:291)
      at module.exports.0 (/home/runner/work/_actions/cleartax/jira-lint/master/lib/index.js:1:323)
}
Error: Cannot destructure property `login` of 'undefined' or 'null'.

It would be a lot easier to debug this problem if a non-minimized version of the action was provided, somehow. If one can be provided (in a separate branch, for instance), I can run against it and give you a new and much more informative stack trace.

I'm not sure, but I believe that this would fix the problem:
diff --git a/src/main.ts b/src/main.ts
index 10d28e9..4b55e79 100755
--- a/src/main.ts
+++ b/src/main.ts
@@ -64,7 +64,6 @@ async function run(): Promise<void> {
     const {
       payload: {
         repository,
-        organization: { login: owner },
         pull_request: pullRequest,
       },
     } = github.context;
@@ -73,7 +72,7 @@ async function run(): Promise<void> {
       throw new Error(`Missing 'repository' from github action context.`);
     }

-    const { name: repo } = repository;
+    const { name: repo, owner: { login: owner } }  = repository;

     const {
       base: { ref: baseBranch },

I submitted #24 to fix this problem.

As suggested by @maddhruv in https://github.com/ClearTax/jira-lint/pull/56#issuecomment-1119238816, I've forked and fixed this and a lot of other issues in action-jira-linter.


Update gaze to v1.0.0

This stops the warning messages about lodash and graceful-fs old versions being no longer maintained at installation:
npm WARN deprecated<EMAIL_ADDRESS><EMAIL_ADDRESS>is no longer maintained. Upgrade to<EMAIL_ADDRESS>npm WARN deprecated<EMAIL_ADDRESS>graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to<EMAIL_ADDRESS>as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.

Released as 1.0.2

Thanks!


check errors

please fix error reported at
https://github.com/cybertraining-dsc/fa20-523-328/runs/1525238260?check_suite_focus=true
please remember the check may take a while to complete. Also because you switched from project to report the check has been rerun

Thank you, I fixed my errors and now the status is passing

On Dec 9, 2020, at 11:30 AM, Gregor von Laszewski<EMAIL_ADDRESS>wrote:
please fix error reported at
https://github.com/cybertraining-dsc/fa20-523-328/runs/1525238260?check_suite_focus=true https://github.com/cybertraining-dsc/fa20-523-328/runs/1525238260?check_suite_focus=true
please remember the check may take a while to complete. Also because you switched from project to report the check has been rerun
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub https://github.com/cybertraining-dsc/fa20-523-328/issues/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQ4TWUD5GKCUYNDBJXF2FRDST6Q3DANCNFSM4UTXPJUA.

caption of figure is below the figure
than you must say somewhere
Figure 1 shows ....


In the tree view, show whether or not a report is still in progress

After creating this issue, I observed a difference between reports-in-progress and finished reports. The last node of a finished report has an arrow pointing to the left. This is not the case with a report-in-progress. Is this enough visual information or do we want to make this difference more clear?


drivers: mdio: add Xilinx AXI Enet MDIO driver

The Xilinx AXI Ethernet subsystem is commonly found in FPGA designs. This patch adds a driver and device tree bindings for the MDIO of the Ethernet MAC core.
The driver was tested on a RISC-V softcore in an FPGA design, with an RGMII phy and the AXI Ethernet subsystem version 7.2 Rev. 14. Device tree bindings match the device tree generated by Vitis hsi.

@WorldofJARcraft some of the checks didn't return. can you please rebase to kick CI?
@decsny can you take a look at this PR?

@WorldofJARcraft Is it on purpose that zephyr_library_sources_ifdef(CONFIG_MDIO_XILINX_AXI_ENET mdio_xilinx_ethernet.c) is not included in zephyr/drivers/mdio/CMakeLists.txt ?
I'm fairly new to zephyr so forgive if I am missing something.

it did also occur to me that this driver appears to be being added as dead code that is not being tested by ci

@WorldofJARcraft Is it on purpose that zephyr_library_sources_ifdef(CONFIG_MDIO_XILINX_AXI_ENET mdio_xilinx_ethernet.c) is not included in zephyr/drivers/mdio/CMakeLists.txt ?
I'm fairly new to zephyr so forgive if I am missing something.

You are right, I somehow forgot to check this file in when I made the branch for the PR.

you have merge conflicts

you have merge conflicts

Resolved

It seems like this should be in the same PR as the ethernet driver, is there a reason they are split up

I am happy to merge both PRs into one if you prefer. I thought the changes would be easier to review in individual PRs, which is why I split them up originally.

Merged into https://github.com/zephyrproject-rtos/zephyr/pull/73986

I am happy to merge both PRs into one if you prefer. I thought the changes would be easier to review in individual PRs, which is why I split them up originally.

most important for reviewing is separate commits, but if it doesnt make sense at all to merge something to the tree without another something, as in this case, then makes sense to put them in the same PR


Framework

Migrated from https://github.com/mesg-foundation/js-sdk/issues/189
Originally created by @NicolasMahe on Tue, 17 Mar 2020 07:24:01 GMT

Improve the CLI for local development

[x] Simplify the management on the local engine (https://github.com/mesg-foundation/js-sdk/pull/188)

[x] start and stop engine automatically in dev commands (https://github.com/mesg-foundation/js-sdk/pull/188)
[x] inject account in the engine (https://github.com/mesg-foundation/js-sdk/pull/188)

[x] Remove confusing commands (list, detail, create, compile, delete, daemon) (https://github.com/mesg-foundation/js-sdk/pull/188)
[x] MESG framework (https://github.com/mesg-foundation/js-sdk/pull/198)
[ ] update docs.mesg.com once done (https://github.com/mesg-foundation/docs/pull/121)

done


Refactored Code & New Classes

Here's a list of what I changed

4 different utility functions for each type of HTTP request
Quick Expense object can only be created internally by Concur client after calling a request, values are read only
Native flow authentication in separate file
Access Token is separate object
Get request for Quick Expense (and future endpoints) does not have separate functions for get all & get by ID. Instead, the utility function will look for the ID in the options and if it sees it, it will append to the end of the URL. Then in the quickExpensesGet function, it searches for the "Items" key in the JSON response and if it doesn't find it, it just returns one object.
Post request returns Quick Expense object with ID & URI values filled in

:shipit:


Potential memory leak with each call inside runBlocking

It looks like there is memory leak in kroto+ when many unary calls are made inside a runBlocking-block, reproduced here: https://github.com/blachris/kroto-plus/commit/223417b1a05294a0387d13f421c0fa8aec4c477d
When you take a heap dump before exiting the runBlocking-block, you will see a number of instances that scale exactly with the number of calls made, for example here after 10000 completed, sequential calls:

It seems there is an unbroken chain of references with InvokeOnCompletion through every single call made.
After the runBlocking-block, the entire clutter is cleaned up so as a workaround, one can regularly exit and enter runBlocking. However I often see this pattern in main-functions with runBlocking which will reliably encounter this problem over time:
fun main(args: Array<String>) = runBlocking {
  while (true) {
    // make unary calls with kroto+ here and run out of memory eventually
    delay(50)
  }
}

Could you please check if you can avoid this issue in kroto+ or if this is caused by kotlin's runBlocking?

After some trial and error I found out that the problem is probably linked to the invokeOnCompletion handler in bindScopeCancellationToCall in CallExts.kt because the memory leak disappears if it is commented out:
internal fun CoroutineScope.bindScopeCancellationToCall(call: ClientCall<*, *>) {
    val job = coroutineContext[Job]
        ?: error("Unable to bind cancellation to call because scope does not have a job: $this")
    //job.invokeOnCompletion { error ->
    //    if (job.isCancelled) {
    //        call.cancel(error?.message, error)
    //    }
    //}
}

According to the documentation of invokeOnCompletion:

The resulting DisposableHandle can be used to dispose the registration of this handler and release its memory if its invocation is no longer needed. There is no need to dispose the handler after completion of this job. The references to all the handlers are released when this job completes.

Since the job can last a lot longer than a kroto+ call, I think the invokeOnCompletion-Handler must be disposed by kroto+ after the gRPC call is completed to avoid this memory leak. This handler is used in all gRPC call types in kroto+ and none are cleaned up.
@marcoferrer This means this leak could affect all kroto+ call types in any long running coroutine job.

First I want to give a big thanks for opening this issue and providing so much detail.
After looking everything over I think the scope of impact is limited to clients executing many calls in a single long-lived coroutine. As you stated, specifically because we do not have a check after call completion to dispose of the invokeOnCompletion callback. Testing locally I tried wrapping each client call in a launch or async block and confirmed that I wasn't seeing the increase in memory utilization. I think this confirms that once the coroutine job associated with the call is allowed to complete we see everything behave as expected.
It looks like the solution for this will involve updating the client exts to add a call completion callback to that will check if the scopes job has completed yet and dispose of the invokeOnCompletionwhen appropriate.
Thoughts?


希望大牛能更新一下。适配最新的系统谢谢

Translate for issue reporter, same concern with issue reporter.
Do you have a plan to update to fit Swift 4?


onChanged is fired 2 times

The event onChanged is fired 2 times when a value is changed.
FormBuilderTextField(
name: "name",
onChanged: (value) => print(value),
),
If I write the text "123" on field, the printed log is:
I/flutter (16823): 1
I/flutter (16823): 1
I/flutter (16823): 12
I/flutter (16823): 12
I/flutter (16823): 123
I/flutter (16823): 123
V. 4.2.0
Android Emulator

Might be related;
I found that typedef ValueChanged<T> and typedef ValueSetter<T> share the same signature and are probably both being called.
There is a delay between the first and second call.
Found in flutter\packages\flutter\lib\src\foundation\basic_types.dart,
or just follow the code by using Ctrl+LMB on onChanged -> ValueChange

Might be related;
I found that typedef ValueChanged<T> and typedef ValueSetter<T> share the same signature and are probably both being called.
There is a delay between the first and second call.
Found in flutter\packages\flutter\lib\src\foundation\basic_types.dart,
or just follow the code by using Ctrl+LMB on onChanged -> ValueChange

Hi .. I confirm the issue, still exists.. Its calling twice. May I know if the fix has been applied?
Thanks

Hi .. I confirm the issue, still exists.. Its calling twice. May I know if the fix has been applied?
Thanks

This issue is resolved?

Closing due to inactivity


Security Team Budget Request v3

Scope
This budget request is for the security team comprised currently of two core contributors and one internship slot to continue contributing with security-related work in the yearn ecosystem. It will keep the main plan, and scope of the previous version.
The list of updates published in the previous (v2) budget request:

August 2023
September 2023
October 2023 (wip)

Presentation: link
This request will cover one quarter (3 months) and continue the team's work on security reviews for all contracts under development in the yearn teams as capability allows. Over the following period, these budget requests should develop and provide a detail of work attempted and achieved.
This request also will detail an overview of the team's goals and objectives for the period.
Note that this budget request includes no revenue share.
Plan
Note that there are no clawbacks based on the below performance targets. But performance should impact future budget requests.
Security Reviews
The security team will continue to work on the following:

Internal security reviews for all contracts develop by yTeams and changes or updates in the current ones in production.
Internal security reviews for the Core Protocol, including v2/v3 vaults, v3, yCRV, yETH and any other Yearn's product as required.
Management of the Risk Framework and internal security review process for v2 and v3 strategies.
Review scores and allocations frequently in the Risk Framework to ensure risk information is properly presented to users.
Coordinate with infrastructure team on support for risk framework updates, bugs and issues for off chain data. (see on chain risk framework section for details)
Help, guidance and coordination with auditors and external security reviewers for engagements with protocol-related contracts. (Each team needs to request their own audit security budget.)
Review and triage bounty reports through our multiple pre-established channels, such as Immunefi, vyper disclosures or any other source.

External Security Reviews & Audits Coordination
The security team will guide and coordinate all the external security reviews and audits when requested by yteams.
The process for coordinating audits and external security reviews is the following:

The yTeam that needs an audit/external security review will request coordination/help.
The security team will coordinate the slot/s with the audit firms or external reviewers.
Once and agreement with audit firm is reached, security team will create a group so yTeam and auditors can ask/answer questions. Coordination of payment and budget is managed by each yTeam.
Once the audit/review finishes, the security team will review the report and coordinate with yTeam to help review issues to ensure they are fixed or acknowledge.

Note that this process might change based on the team's needs.
Ad hoc
The security team will also continue working with existing Yearn teams (or new ones) to provide ad-hoc support. Including but not limited to offering:

War room support
Smart contract development
Product design
Protocol and Security related tooling development
Multisig coordination for emergency transactions
Security related events support e.g war room games, conferences talks, etc.

Risk Framework On-chain
As part of concerted plan of improving on yearn's current risk framework and overall security to support the upcoming launch of v3 and also integrating into it yETH and other yearn's core contracts, we developed and executed the plan to launch the risk framework protocol, which consists of a suite of contracts to manage yearn's risk framework.
In order to migrate the Risk Framework off-chain to on-chain, the security team has already deployed the initial smart contracts for a pilot phase on Polygon. In that direction, we also created this multi-sig (multichain) that will manage the configuration (scores).
We also have developed and published the subgraph to make it easier to query data from the contracts.
Both items have been tested successfully (set scores and tags) with some strategies/vaults from v2/v3 on Polygon.
Links:

Risk Framework.
Risk Framework Subgraph.
Subgraph. (you can query the scores already sent)

The migration phase will follow after our initial pilot. We plan to back up all the current strategies and scores (342 strategies in 5 networks) from yDaemon. Verify and update each score as needed and publish in the on-chain version -only active strategies- gradually during pilot phase to test integrations.
Detailed Phases:

Pilot phase: initial deployment and testing, protocol, subgraph and CLI alpha version. (current phase)
Migration phase: migrate and load off chain information into on chain protocol.
Testing phase: test contracts for parity with off chain scoring.
Feature support: Add support for v3 and yETH to have risk score. Integrate with v3 debtmanager modules.
Multichain: Research design to support risk framework on different chains.

Last cycle we started the first phase of the onchain framework, feedback and changes are expected as we adjust the new Risk framework to be capable of supporting yearn's important core contracts. Continous development and improvement will happen during the upcoming cycles.
As a key integration, ySecurity plans to closely work with v3 strategist group to detailed an overall process for maintaning and showing in the UI and other tooling the appropiate risk information to yearn's contract users. This may entail combining external risk data (defi safety and llamarisk being in discussion) with our internal DD and risk process to have an aggregate and consistent risk profile to present to users.
Risk Framework - CLI
As part of our launch of the pilot phase onchain risk framework, we are providing additional tooling to interface with the core functionality of the protocol, the CLI is planned to be the primary interface to interact with yearn's risk framework.
This CLI will be in development but already supports the key functionality of providing the graph for the risk heatmap which is no longer active on the deprecated yearn.watch/risk page and is a key input for v2 allocations decisions (currently not showing the heatmap).
pyrisk CLI

Planned functionality for this cycle:

yDaemon full support and parity for off chain risk framework support (for migration phase)
v3 support
Full on chain framework integration with subgraph
Strategy and vaults information
Caching layer
Rich Terminal UI
Exporting data (useful for war rooms, scripting input, etc)

We believe this tooling is key for both yearn's normal operations and more so during exceptional times like in war rooms, where we need quick information of specific vaults and strategies to integrate with our other scripting tooling. Our goal for the CLI is to be a tool used by all yTeams.
Internal Simulation Attacks
As part of the team that provided information to the SEAL team for the Simulation Attack on Yearn, we considered these simulations an imperative experience and tool for improving processes, understanding our weaknesses, and testing our response time.
That being said, our goal is to build the foundations in terms of tools, scripts, and bots to simulate attacks internally on a regular basis. Considering we don't have anything built yet, we plan to start building (or reusing) these tools in this BR period to create simulated attacks on v3, yETH, etc.
Goals
The security team plans to:

Security

Help create and review Due Dilligence documents on new protocols used by yearn's strategies, when applicable. This item will consider external risk data providers to coordinate new v3 risk scoring process.
Each security review differs in time and scope but we are estimating it based on normal strategy reviews.
Create an internal checklist with the common issues in the v3 strategies to help the strategists to improve the development.
Start/continue reviewing new strategies for v3.
Continue reviewing updates/new strategies for v2.
Improve Github issues to make easier the security process.

Risk Framework On-chain:

Testing of all use cases to achieve parity with off chain data.
Incorporating feedback to improve the current design.
Migrating the active v2 strategies.
Integrate v3, yETH and other core contracts as needed.
Keeping it up to date with the scores.

Risk Framework - CLI

Launching the CLI v1 for all members with the basic commands
Integrating with telegram bots to send notifications.
Displaying the risk framework heatmap.

Filter vaults/strategies by tags/scores.
List the strategies that are not in the risk framework (created by factories).

Internal Simulation Attacks

Researching the required tools for these types of simulations.
Building any other required/specific tool/app for the simulations.
Coordinate with SEAL Attack simulation team for access to their forked tooling (block explorer, etc)
Analyze multiple attack vectors to consider in a simulation.
Plan the internal simulation attack.

Period
It will cover 3 months:

From: 2023-11-01
To: 2024-01-31

People

Storm0x
Rare Weasel
Tapir

Money
This budget request includes the following concepts:

2 core contributor grants.
1 internship slots.

Funds to be streamed over three months, starting 1st November 2023.
Total:
136,740.00 DAI
Any funds not spent at the end of the period will be transferred back to the yBudget team or considered for the next period.
Funds Details
The previous YFI amount was converted into DAI at 5500 DAI as an average price during the last 3 months.
YFI Conversion

Wallet address
0x4851C7C7163bdF04A22C9e12Ab77e184a5dB8F0E
Reporting
Monthly in this issue.

Security Team December Updates

DDs & Security reviews

Prisma Convex Farmer: https://github.com/yearn/yearn-strategies/issues/606
Updated Prisma prod card and created the recurring review.

https://github.com/yearn/yearn-strategies/issues/612
https://github.com/yearn/yearn-strategies/issues/613

Stargate Staker (V3 strategy, finished): https://github.com/yearn/yearn-strategies/issues/535
yETH Governance (finished): https://github.com/yearn/yearn-strategies/issues/596
Gamma Factory Strategies (V3 strategy): https://github.com/yearn/yearn-strategies/issues/569
veYFI Recurring Review (ongoing): https://github.com/yearn/yearn-strategies/issues/610

Bug bounty report

Triaged veYFI bounty report.
Coordinated security review for veYFI with bounty reporter deadrossxyz

Risk Framework On-chain

Updated the scores for v3 strategies and updated the issues with the score transaction links.
Added tags for some v3 strategies.

Incident Retros

Help guide and lead veYFI bug bounty report retro.
Help guide and lead LP YCRV retro and root cause actions.

NOTE: some of the links for internal gh repos are access restricted for security purposes.


dataflow error handling

When running the cypress tests I got warnings around these lines.
I'm not sure if this approach is OK.

This PR has failing tests, but they are about the Chat. So I'm pretty sure they are just randoming failing.

@bacalj Thanks!


Add GPU video encoder, rankers and segmenters

There are still some GPU-supporting executors missing. This issue finishes the GPU support for the executors.
If there are more executors which are missing GPU support, add them to the list.
Video Encoders:

[x] VideoTorchEncoder (complete)

Segmenters:

[ ] TorchObjectDetectionSegmenter (in review)
[ ] VADSpeechSegmenter (not possible)
[ ] YoloV5Segmenter

Rankers:

[ ] DPRReaderRanker (in review)

I dont think YoloV5Segmenter is actually missing GPU support. It can already be run on GPU, but there is no distinction between cpu/gpu image. We could add it, by forcing CPU version of Pytorch, but I think its not a good idea as it is only an indirect dependency added by YoloV5. As far as I see Yolov5 does not support cpu only

Why does it not support CPU only? Can you not do model.to('cpu')?

sure, I mean dependency wise. There is no yolov5[cpu] or so.
yolov5 always uses the full torch version with gpu support. So if we want to split into cpu/gpu versions, we would need to override pytorch in our requirements. We can certainty do so, but the issue is that we need to change also our requirements then if they change the upstream requirements which is a bit annoying?

Since we pin our requirements to an exact version, we won't have this problem unless we are changing our requirements intentionally, so I think this is managable. I would still go ahead and create a CPU-only version

VADSpeechSegmenter can not run on GPU actually. I tried to add support and the inference fails with this message
RuntimeError: Could not run 'quantized::linear_dynamic' with arguments from the 'CUDA' backend. This could be because the operator doesn't exist for this backend, or was omitted during the selective/custom build process (if using custom build). If you are a Facebook employee using PyTorch on mobile, please visit https://fburl.com/ptmfixes for possible resolutions. 'quantized::linear_dynamic' is only available for these backends: [CPU, BackendSelect, Named, ADInplaceOrView, AutogradOther, AutogradCPU, AutogradCUDA, AutogradXLA, UNKNOWN_TENSOR_TYPE_ID, AutogradMLC, Tracer, Autocast, Batched, VmapMode]
Also there is https://github.com/pytorch/pytorch/issues/42288

DPRReaderRanker: https://github.com/jina-ai/executors/pull/198
TorchObjectDetectionSegmenter: https://github.com/jina-ai/executors/pull/199
VideoTorchEncoder: https://github.com/jina-ai/executors/pull/180

I suggest to remove the Yolov5Segenter from the scope of this ticket and close it once the related PRs are merged.
For yolov5 I've created a separate issue here https://github.com/jina-ai/executors/issues/200


Guzzle Client - Proxy

Hi,
maybe you can change the constructor or add a method to pass Guzzle parameters. Especially in enterprise environments, there might be a proxy needed for outgoing connections. Guzzle reads environment variables, but that's not always possible to set them.
public function __construct($key, $secret, $url = self::DEFAULT_URL, $guzzleArgs)
    {
        $this->client = new Client([
            'base_uri' => $url,
            'verify' => CaBundle::getBundledCaBundlePath(),
            'http_errors' => false,
            'connect_timeout' => 20,
            'proxy' => @$guzzleArgs['proxyConfig'],
        ]);

        $this->consumer = new OAuthConsumer($key, $secret);
    }

Or maybe you can just add a method to set parameters on the private client variable, or any other possibility to set a proxy server for the API client.

Hello,
thank you for the issue. It's true, previously there was no way to set additional guzzle options.
As for now, we will add an additional optional parameter within the constructor to solve the problem.
public function __construct($key, $secret, $url = self::DEFAULT_URL, $options = [])
    {
        $defaults = [
            "base_uri" => $url,
            "verify" => CaBundle::getBundledCaBundlePath(),
            "http_errors" => false,
            "connect_timeout" => 20,
        ];

        // append options to config array
        $config = $defaults + $options;

        $this->client = new Client($config);
        $this->consumer = new OAuthConsumer($key, $secret);
    }

Futher options should can now be passed as an array. In your case, the additional proxy settings can be added like this:
$api = new API($NIMBUSEC_KEY, $NIMBUSEC_SECRET, API::DEFAULT_URL, [
    'proxy' => [
        'http'  => 'tcp://localhost:8125', // Use this proxy with "http"
        'https' => 'tcp://localhost:9124', // Use this proxy with "https",
        'no' => ['.mit.edu', 'foo.com']    // Don't use a proxy with these
    ]
]);

The newest version will be availabile within the day.

Perfect, thanks a lot...


Adding general map field for configuring AEE

New config map holding data for additional AEE configuration. By it's nature it's open ended and all the fields will require checking. Normally we would could use verification in schema for this. But since we don't want to change signature of resources too much conditionals are a way to go.

I like the overall idea here, but I would like to see this proposed as a feature in Jira, aligned against the next FR (FR2), so we can properly scope and plan with QE and docs.


Unable to login to App

The  app has been deployed and added to the team, but when I hit the login button, a prompt that says "almost there" pops up, I then hit continue, and then nothing happens.  Any help is appreciated. Thanks.

@idavis162 , , Thank you for reporting this.
Please open teams in browser, then open the app and share console logs and network trace which will help us troubleshoot the issue.
Also request you to share the manifest files with us.

Teams Info.zip

@idavis162 ,
Thank you for sharing the Logs.
As per the Shared logs you are getting SSO token error.
Manifest file which you have shared is from Azure App Registration, we need Manifest file where you generated TEOC App zip as per this link.
Kindly verify the Client Id and Client Secret which you have added in Apps Manifest JSON file and in App Registration either it could be mismatched, or Permission is mismatched.

Manifest.txt

@idavis162 ,
Thanks for sharing Manifest file.
Client Id seems to be correct. Kindly confirm whether Client Secret which you've added while creating the app is correct or not.
To do this kindly navigate to your resource group and then navigate to App Service which ends with simple Auth then click on Environment Variables there you can find Client Secret verify whether it is correct or not.
Once confirmed, kindly let us know.

So would I use this ID? or the client secret? And where would I input that value?

@idavis162 ,
Please ensure that the Client ID and Client Secret correspond with the App Registration you have created as per the below link.
https://github.com/OfficeDev/microsoft-teams-emergency-operations-center/wiki/Deployment-Guide#2-register-azure-ad-application

So I have the correct Client ID. Where do I need to update that to try and get it to work?

@idavis162 ,
If your client ID is incorrect, you should delete the Resource Group and attempt the process again with the correct client ID value.

Just to confirm, the base resource name and app domain is the one ending in simpleauth correct? As in reference to step 4.

@idavis162 ,
Yes, that is correct. That's the base resource name.

Which is the right app service to use for the app domain and the base resource name? I rebuilt the app but now when trying to add it, it won't allow me to add it to the team.

This is all that pops up when trying to add the app

@idavis162 ,
First App service name which has the base resource name.
Instead of adding to teams Channel, can you try to open the app directly and confirm here?

I have confirmed the client secret is showing the correct value under the simpleauth app service. I have also made sure the base resource name is the lbbdomeoc. But now when logging this is what the console shows
Uncaught (in promise) h.InternalError: Failed to get access token with error: Get SSO token failed with error: Error: 500011 - [2024-05-16 16:26:56Z]: AADSTS500011: The resource principal named api://lbbdomeoc.azurewebsites.net/eb8db36d-0feb-4fe0-8dd7-68aed6b2aa38/access_as_user was not found in the tenant named City of Lubbock. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant. Trace ID: 936a398f-5a20-43c4-b7d4-4fe6dab06400 Correlation ID: d1b007e2-60f7-442e-bb70-281582811da1 Timestamp: 2024-05-16 16:26:56Z - Correlation ID: d1b007e2-60f7-442e-bb70-281582811da1 - Trace ID: 936a398f-5a20-43c4-b7d4-4fe6dab06400

@idavis162 ,
Please share your email address and your availability so that we can schedule a MS Teams Call to troubleshoot this issue.

I am free today from 1-5 CST or anytime Monday-Friday 9-5 CST
My email is @.***
Get Outlook for iOShttps://aka.ms/o0ukef

From: v-ajaysahu @.>
Sent: Friday, May 17, 2024 12:45:01 AM
To: OfficeDev/microsoft-teams-emergency-operations-center @.>
Cc: idavis162 @.>; Mention @.>
Subject: Re: [OfficeDev/microsoft-teams-emergency-operations-center] Unable to login to App (Issue #192)
WARNING: This message was sent from outside the City of Lubbock's email system.
It could contain harmful attachments or links to harmful web pages.

@idavis162https://github.com/idavis162 ,
Please share your email address and your availability so that we can schedule a MS Teams Call to troubleshoot this issue.
—
Reply to this email directly, view it on GitHubhttps://github.com/OfficeDev/microsoft-teams-emergency-operations-center/issues/192#issuecomment-2116731553, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BH6RDEZMNFDUU3KY3FFLCNLZCWKN3AVCNFSM6AAAAABGPZULROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJWG4ZTCNJVGM.
You are receiving this because you were mentioned.Message ID: @.***>

@idavis162 ,
Please share your email address through GitHub. You've shared the email address through email which will not be visible to us.

<EMAIL_ADDRESS>

@idavis162 ,
I have scheduled a meeting for the 21st of May at 9:30 AM CST to address the issue.
I hope this proposed time is suitable for you.

Got it now. Thanks!

@idavis162 ,
As your issue has been resolved, I am closing this request. Please feel free to comment if you require further assistance.


feat(forkJoin): accept array of observable as parameter

relates to #594
This PR enables forkJoin accepts array of observable.
Creating overloads of function having array parameter to rest parameter requires some explicit unfolds due to behaviors of typescript (bit more explanation can be found here, way I used can be found in this PR as well.)
Performance wise, I haven't noticed big impact for general usecases of using rest parameters.
(numbers may vary). Checking typeof array for single observable, or array might impact bit more though.
before
     RxJS 4.0.6 |            RxJS 5.0.0-alpha.10 |          factor |      % improved
------------------------------------------------------------------------------------
38,677 (±4.83%) |               411,112 (±4.14%) |          10.63x |          962.9%

after
     RxJS 4.0.6 |            RxJS 5.0.0-alpha.10 |          factor |      % improved
------------------------------------------------------------------------------------
40,614 (±4.33%) |               406,452 (±4.23%) |          10.01x |          900.8%

Updating code lint-friendly makes one comment goes away :( I should buy mac.
Comment was

removed overload signature, after code update overloaded signature actually doesn't do much thing, simplified into single signature and let it does polymorphics

Updated perf shows quite similar to original code
      RxJS 4.0.6 |            RxJS 5.0.0-alpha.10 |          factor |      % improved
-------------------------------------------------------------------------------------
40,950 (±19.35%) |               437,477 (±4.65%) |          10.68x |          968.3%

Merged with 7f892ad after minor lint fix.


Chore/combine examples

Description of change
Combining several Rust examples that are on the same topic to make the examples folder a bit more compact and ready for more examples on other features.
How the change has been tested
Describe the tests that you ran to verify your changes.
Make sure to provide instructions for the maintainer as well as any relevant configurations.
Run the tests locally
Change checklist
Add an x to the boxes that are relevant to your changes.

[ ] I have followed the contribution guidelines for this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

Github Actions is being annoying but it really does Build and Run on Windows as well ;)


[BREAKING CHANGE] Remove goneovim's statusline features

I think no one uses this feature.

Note that if ext_statusline is supported by an external UI feature on the Neovim core, there are plans to support that feature on the Goneovim.


KAFKA-15309: Add custom error handler to Producer

More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Hi @aliehsaeedii thanks for the PoC and the KIP. Can you please mark this PoC as draft PR as the KIP still under discussion?


GC fixes for hanging delete in SharedString and SharedMatrix

Cherry-pick of the commits from PRs ##6235 and #6252.

@vladsud @anthony-murphy @wes-carlson Can you please take a look. We would want to do a patch release of 0.39 with these changes :-).


Avoid planning channels to nodes with similar IP addresses

If possible we should channel to nodes with different geographical locations based on published IP address, in order to avoid having all our channels going to various LNBIG nodes.
This requires a map of autonomous system numbers to IP addresses.
LNBIG is known to host multiple nodes in various locations but hopefully this reduces the probability of having all our channels to LNBIG.
For .onion:

Give each unique .onion its own bucket?
Put all .onion in a single unique bucket, but allow drawing more than one from that bucket?

Equivalently, create N buckets for .onions and throw onions randomly in one of the onion buckets.

Not sure at what point to implement this.  Probably best is to have the ChannelCandidateInvestigator add this as an investigation as well, and to penalize candidates that happen to have IPs similar to higher-scored candidates.
IRC discussion with @willcl-ark and @darosior :
<willcl_ark> zmnscpxj_: CLBOSS seemed to cope ok even during that crazy fee market. It did open two channels (when I had zero) at a rate of 250s/vB (two in one transaction), but then seemed to "wait" until fees were lower again to open a further 5. I suppose because of how agnositc it is, 5 out of 7 channels are to various LNBIG nodes which is probably not ideal, but difficult to automatically bucket peers by "likely same
<willcl_ark> owner"
<zmnscpxj_> Yes, if a majority of your funds is outside of channels, CLBOSS will put as much as possible into channels even if feerates are high
<zmnscpxj_> but it tries to hold off as much as it can until feerates go low
<willcl_ark> That is pretty much exactly what I saw
<zmnscpxj_> works as designed then
<willcl_ark> :)
<zmnscpxj_> TheBlueMatt has suggested IP binning before (in the context of routing, but still...) so it might be useful to consider that as well
<zmnscpxj_> in order to avoid the "everryone is LNBIG in purgatory"
<willcl_ark> TBH, looks like the LNBIG nodes are hosted in different locations (on 1ML) so not sure that will help
<zmnscpxj_> awww crap
<willcl_ark> you could base it on Alias, but that's easy to break too
<zmnscpxj_> yes
<zmnscpxj_> and using IP binning does not help with .onion as well
<willcl_ark> actually I am not correct, all the LNBIG nodes I partnered with appear to be (Ashburn, VA, United States)
<willcl_ark> might be worth to have it "just in case", even if it's not perfect, I don't think it would make anything worse
<zmnscpxj_> okay, looks like IP binning might be useful at least to *reduce* the possibility
<willcl_ark> exactly
<zmnscpxj_> Dunno what to do about .onion though, oh well
<zmnscpxj_> And I have to wonder about IPv6 as well
<darosior> asmap ?
<zmnscpxj_> what is asmap?
<darosior> bitcoind's new technique to make sybil connections more costy but that may be nonsensical for your matter
<zmnscpxj_> references?
<darosior> https://github.com/bitcoin/bitcoin/issues/16599
<zmnscpxj_> yes, TheBlueMatt has also suggested this for LN routing as well
<zmnscpxj_> though he suggests all .onion should go into a single bin, which worries me
<willcl_ark> You could allow more from the tor bin, than other bins?
<zmnscpxj_> could be done as well.

FWIW here is an example of what my CLBOSS test set up for me -- very nicely balanced etc., but I think would be much improved by some simple bucketing logic:
<EMAIL_ADDRESS>num_utxos=1
utxo_amount=x.xxxxxxxxbtc (USD $x.xx)
num_channels=7
num_connected=7
num_gossipers=3
avail_out=xx.xxbtc (USD $xx.xx)
avail_in=xx.xxbtc (USD $xx.xx)
channels_flags=P:private O:offline
channels=

├x.xxxxbtc    OUT/OURS ┼ IN/THEIRS   x.xxxxbtc┤ SCID           FLAG AVAIL ALIAS
           ├───────────┼───────────────┤        YYYYYYxYYYYxY  [__] 100%  LNBIG.com [lnd-25]
├──────────────────────┼────┤                   YYYYYYxYYYYxY  [__] 100%  LNBIG.com [lnd-13]
                    ├──╢                        YYYYYYxYYYYxY  [__] 100%  rompert.com🔵
              ├────────┼──┤                     YYYYYYxYYYYxY  [__] 100%  LNBIG.com [lnd-05]
                     ├─┼┤                       YYYYYYxYYYYxY  [__] 100%  LNBIG.com [lnd-11]
                    ├──┼─┤                      YYYYYYxYYYYxY  [__] 100%  Leetning.com #1 SWE
                    ├──┼┤                       YYYYYYxYYYYxY  [__] 100%  LNBIG.com [lnd-17]

Hey @ZmnSCPxj do you have plans to try and implement some IP (or similar) bucketing?
I closed all my channels during low on-chain fee market just to take advantage of it, but have to say that even with an "uneven" channel distribution CLBOSS just worked™ very well without any management. I didn't have that many forwards, but to be fair it was more than I had when I manually opened channels previously and I was well setup for general personal usage.
If you're not planning to implement this feature in the near future, I'll be happy to re-run latest master without bucketing and with a bit more balance and see how it gets on again...

Certainly, though not quite sure how to go about it yet.  Sorry for the delay in reply, things have been hectic in my non-Bitcoin activities, including a broken server whose parts I am finding difficult to find, bleah.

https://bitcoincore.reviews/16702.html#erebus-attack for reference.
Important points:

Bitcoin core supports an ASMAP, but does not come bundled with one yet.  Users are supposed to either create an ASMAP of their own somehow (instructions are unclear even to the reviewers) or just download from sipa, who is always 100% trustable and has never made a mistake, not even in bech32: https://github.com/sipa/asmap/demo.map
Bitcoin ASMAP format is based on a video codec.  This means we have to reimplement or copy the Bitcoin ASMAP loading code.  Copying it is somewhat difficult as it might be dependent on other Bitcoin code.
Tor .onions are hard to unsybil, as .onions are "free".  Suggestion is to reduce the number of buckets that .onions use, which makes them very unlikely to be channeled with.

Here is the correct link to demo.map: https://github.com/sipa/asmap/raw/master/demo.map
I am uncertain as to what is the ultimate source of demo.map.  Geolite2 database has a CC-BY-SA license, the /sipa/asmap repo has no license information, not sure whether the demo.map comes from the Geolite2 database.
Given an ASMap object that maps IP addresses to ASNs, what do we do?
So let us describe how CLBOSS decides channel creation.    Then the nodes go through ChannelCandidateInvestigator, which over time checks for uptime of the candidate nodes.
When we notice we have onchain funds that need to go into channels, we get the list of "good" nodes from ChannelCandidateInvestigator, which puts high-uptime, earlier-found nodes first in the list.
Currently, we prioritize assigning channels according to the order of this list.  The ChannelCreator::Planner module takes this list of nodes.
What we could do instead:

Get ASNs of our current peers and put into a mapping from ASN to number-of-nodes-with-that-ASN.
Initialize an empty mapping from number-of-nodes-in-ASN to an ordered list-of-nodes.
For each node in the ChannelCandidateInvestigator list:

Get its ASN.
Look up the number-of-nodes-with-this-ASN (0 if not found).
Look up the appropriate list-of-nodes from the number-of-nodes-in-ASN.
Append the node to the found list-of-nodes.
Increment the number-of-nodes-with-this-ASN.

Initialize an empty ordered list-of-nodes
For each list-of-nodes in the number-of-nodes-in-ASN to list-of-nodes mapping:

Append the list-of-nodes to the current list-of-nodes.

Return the list-of-nodes.

The returned list-of-nodes will then prioritize nodes that do not have the same ASN as current peers or higher-ranked candidates, and de-prioritzes nodes that have the same ASN as current peers or higher-ranked candidates.  This list of nodes is then what we pass to ChannelCreator::Planner.

https://bitcoincore.reviews/16702.html for reference.
Important points:

Bitcoin core supports an ASMAP, but does not come bundled with one yet.  Users are supposed to either create an ASMAP of their own somehow (instructions are unclear even to the reviewers) or just download from sipa, who is always 100% trustable and has never made a mistake, not even in bech32: https://github.com/sipa/asmap/demo.map
Bitcoin ASMAP format is based on a video codec.  This means we have to reimplement or copy the Bitcoin ASMAP loading code.  Copying it is somewhat difficult as it might be dependent on other Bitcoin code.
Tor .onions are hard to unsybil, as .onions are "free".  Suggestion is to reduce the number of buckets that .onions use, which makes them very unlikely to be channeled with.

I think the raw ASMAP file requires asking your ISP for a BGP dump which, as you allude to, is possible but certainly pretty unlikely for people to do...
As #bitcoin-core-dev is logged, I presume posting logs as a snippet here is also OK (query simply asmap w/ 5 lines of context):
asmap.txt. I might suggest parsing from the bottom upwards...
Perhaps asmap is overkill for this situation -- as you say, even asmap can be trivially overcome by using tor, so perhaps some simpler bucketing by IP address CIDR range might be preferable?
It would certainly help with LNBIG as they operate today; they have been kind enough to host all nodes on 46.229.xxx.xxx and 213.174.xxx.xxx from what I can roughly see. Having two connections to them would not be of great concern.
I do think asmap buckets are the most technically-correct solution that exists today, but I can't tell if the work required by the developer (and users?) of an asmap filter would be worth it if an adversary could trivially defeat it...

My understanding is that by BlueMatt it is better.  From what little I understand it seems to be feasible for somebody to generate an ASMAP that is then distributed to multiple users, much like how we have a set of hardcoded nodes in ConnectFinderByHardcode.

https://github.com/ZmnSCPxj/clboss/issues/18#issuecomment-745229067
To me, a solution of this sort seems to make the most sense for CLBOSS ^

For now, I plan to make an abstract interface to an IPBinner object:
class IPBinner {
public:
    virtual ~IPBinner() { }
    virtual
    IPBin get_bin_of(IPAddr const&) =0;
};

IPBin would be a 128-bitvector that is LessThanComparable and Hashable (so it can be used with std::map/std::set/std::unordered_map/std::unordered_set), and IPAddr would have variant types for IPv4, IPv6, and Onion.  A "true" ASMAP would use the ASN for the IPBin, filling upper bits with 0s.
Until then, we can make do with a submask /16 for IPv4, some kind of submask for IPv6 (dunno, /48? /64? go dig the bitcoind code?) and maybe set a high bit somewhere in the IPBin to separate IPv4 from IPv6.
For Tor, we could do hashing of .onion addresses and extracting 1 or 2 bits so that it maps to an IPBin of 0xFFFFFFFFFFFFFFFC to 0xFFFFFFFFFFFFFFFF, so we allow up to 4 onions.  The hashing would be a keyed hash to reduce the ability of targeted attacks by onion-users; we already have a keys.clboss file that we use for interacting with Boltz, we can reuse that as the key in the hash, and we even have Secp256k1::SignerIF::get_privkey_salted_hash to allow a signer holding keys.clboss to provide a keyed hash --- we hash the .onion, then hash the hash with get_privkey_salted_hash then get 2 bits from the first byte of the result.  Thus as long as our keys.clboss file is private to us (it is stored right next to the hsm_secret, which has to be even more private anyway), targeted attacks would not be possible, onion-users would have to spam the .onion space, which would not be cheap on LN since LN public nodes have to commit some amount of channel space.  CLBOSS also does some filtering based on how much a node has locked in channels, so an onion-using attacker would need to commit something like 50 mBTC (LOL hahahaha) in various channels to have multiple nodes it controls pass that test, so I guess that helps somewhat against the ".onions are free!" problem.
Then at some point while constructing objects we just bind a concrete IPBinner that uses submasks as desribed above for now, and we can update it later to replace the IPBinner with a true ASMAP once bitcoind has settled on how to distribute the map files and we can steal their work easily.  The ASMAP concrete IPBinner would have to use the same treatment for Tor, though.
When checking a node, we would need to do a listnodes query, which returns a set of "addresses".  We prefer IPv4, then IPv6, then finally Torv3 or Torv2.  Then we call into the IPBinner interface we got.

Looks like the first 3 or 4 bytes for IPv6 (/24 or /32 prefix length) would be a good bin, roughly comparable to /16 on IPv4.  Could not grok the bitcoind code enough to figure out what it uses.
Looks to me we can use typedef std::uint64_t IPBin; rather than invent a 128-bit number.  ASNs are 32-bit anyway, and if 32 bits is enough to naively bin IPv6, that may be good enough for now.


RH is considered not connected

In some cases agent can send heartbeat where there is no management container.
SS considers this situation as No RH (with MH) connected.
We must rerequest heartbeat form agent in this case

FIxed


Add Eclipse IDE files to gitignore file

Issue # (if available):
Description of changes:
Adds Eclipse IDE project files to .gitignore file
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

:exclamation: No coverage uploaded for pull request head (update_gitignore@51ec16b). Click here to learn what that means.
The diff coverage is n/a.

Isn't this what global gitignore is for https://gist.github.com/subfuzion/db7f57fff2fb6998a16c ?


feat: Update versions for generators

#minor
Description
This PR includes the generators' templates to be updated by the update-versions script by including them in the workspaces list.
It also updates the versions in the package.json file to match the one used in the libraries (4.1.6) and upgrades some dependencies in the TS bots to fix errors found when building the generated bots.
Specific Changes

Changed botbuilder dependencies' version to 4.1.6 in all bots' templates.
Updated TS bots by adding the types/node package and upgrading typescript dependency to version 4.9.3. Also, updated tsconfig files updating the module and adding moduleResolution and esModuleInterop properties.
Added the 'generators/generator-botbuilder/generators/app/templates/' path to workspaces in the package.json file.
Updated updateVersions, workspace, and package files to include the new projects in the script.

Testing
These images show the updated version in the bots and the bots working with the changes.

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

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.3%) to 84.355%

Totals

Change from base Build<PHONE_NUMBER>2:
-0.3%

Covered Lines:
20433

Relevant Lines:
23064

💛  - Coveralls

/promoted 4796


Add serialization using serde and bincode as well as macros

As described in #666, I added an automatic serialization using serde and bincode.
The simple option is the macro be_value_serialize! after activating the feature serialize. This, however, does not feature the same level of comfort as the derive macro in the feature serialize-derive. Derive macros require a second crate, though, so I create it. You would probably have to add it to crates.io yourself.

Types should be fixed width if all values of that type can be serialized to a slice of the same width.
More broadly though, I'll need to think a bit about whether allowing people to derive this is a good idea. A couple concerns I have: changing the name of a struct that uses this macro will now be a breaking change, due to the stringify use. And adding or removing a field will be also

So width should return None? For a convenience functionality like this I think it's the safest route. A type_name should be provided by an argument to macro? What are these type names for anyway?
I don't think redb should be treating bincode in any special way. serialize and deserialize from bincode should not be re-exported as some default, I think.

So width should return None? For a convenience functionality like this I think it's the safest route. A type_name should be provided by an argument to macro? What are these type names for anyway?
I don't think redb should be treating bincode in any special way. serialize and deserialize from bincode should not be re-exported as some default, I think.

The type names are for type safety. If you try to open a table using a different key or value type that that with which it was created, it will fail

I see. Hmmm...
What if ... I lie? Change the type without changing the name?
Does it technically need to be unsafe as it must uphold a contract or otherwise risk undefined behavior?
E.g store a u8 key with a value 0, then change the type to NonZeroU8` yet keep the name the same?

So width should return None? For a convenience functionality like this I think it's the safest route. A type_name should be provided by an argument to macro? What are these type names for anyway?

width is currently set to None unless a macro argument is added. The type name by argument is a good idea. I'm new to procedural macros, but I can look into it.

I don't think redb should be treating bincode in any special way. serialize and deserialize from bincode should not be re-exported as some default, I think.

I just added that because the procedural macro inserts the literal code, so without it, the user has to import bincode manually. I just thought it inconvenient, but I see your point.

BTW. I have went with the same path in my code, and I wonder if the macros should be more generic, serde ones (with = ..., serialize_with = , deserialize_with = ).
My code:
impl RedbValue for ItemValue {
    type SelfType<'a> = ItemValue;

    type AsBytes<'a> = Vec<u8>;

    fn fixed_width() -> Option<usize> {
        None
    }

    fn from_bytes<'a>(data: &'a [u8]) -> Self::SelfType<'a>
    where
        Self: 'a,
    {
        bincode::deserialize(data).expect("bincode deserialization error")
    }

    fn as_bytes<'a, 'b: 'a>(value: &'a Self::SelfType<'b>) -> Self::AsBytes<'a>
    where
        Self: 'a,
        Self: 'b,
    {
        bincode::serialize(value).expect("bincode serialization error")
    }

    fn type_name() -> redb::TypeName {
        redb::TypeName::new("item-data")
    }
}

could be just:
#[derive(RedbValue(serialize_with=bincode::serialize, deserialize_with=bincode::deserialize, name="item-value"))]
struct ItemValue { /* ... */ }

So far I have 2 structs using bincode, and two newtypes (that just delegate to inner-value), so I was planning to macro_rules-them as it's easy. But derive macro would be even better.

So the arguments to derive macros the way you wrote them are apparently not possible. That's why I added those additional arguments like
#[derive(Clone, Debug, PartialEq, Deserialize, Serialize, RedbValue)]
#[fixed_width]
#[type_name("test-type")]
struct Test(usize);

I'd love if someone could prove me otherwise, as I'm worried if too many arguments would get crowded. Especially if I added serialize_with arguments as you mentioned.

serde does it similiarly so you're probably right.
Though like serde I'd do #[redb(fixed_with)], etc. instead of "naked" versions.

#[derive(Clone, Debug, PartialEq, Deserialize, Serialize, RedbValue)]
#[redb(fixed_width, type_name = "test-type", with="bincode")]
struct Test(usize);

Is the destiny. ;)

So one concern I have with this is that users who use this macro may expect it to handle schema changes for them, and I'm guessing it doesn't.

That is not something I would personally expect. Also not something I would necessarily waste bytes on.
One application I immediately see for redb is involving billions of tiny records, where every byte adds up.

Ah, to clarify, I don't think it should support schema changes. But I do
think there should be an error if the user tries to change the schema
Sent from my phone
On Thu, Oct 12, 2023, 7:09 PM Dawid Ciężarkiewicz @.***>
wrote:

So one concern I have with this is that users who use this macro may
expect it to handle schema changes for them, and I'm guessing it doesn't.
That is not something I would personally expect. Also not something I
would necessarily waste bytes on.
One application I immediately see for redb is involving billions of tiny
records, where every byte adds up.
—
Reply to this email directly, view it on GitHub
https://github.com/cberner/redb/pull/667#issuecomment-1760658692, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGNXQBMEHKR4Z24WWRV5PDX7CPENAVCNFSM6AAAAAA4DPGYLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRQGY2TQNRZGI
.
You are receiving this because you commented.Message ID:
@.***>

I left some comments. Also, this needs tests :)

I'm going to be honest, it seems like I vastly underestimated the implications of this PR. I'd love for these changes to somehow be implemented, but I neither have the time nor the required skill level. Therefore, I will close this PR for now.
Sorry if I wasted your time, I'm fairly new to contributing to open source code.


Add Profiler annotation logger

The logger adds timers for all important Ginkgo events based on the perfstubs library, nvTX and rocTX. To make it work, we also need to forward all logger events to the executor. This is meant to show how we can annotate a profile with Ginkgo-specific information.
An example profile from 10000 iterations in preconditioned-solver.cpp.
Not sure what's going on with spmv#3, but this may be related to inclusive vs. exclusive timing.

Below, you can see the same example running with NSight Systems and NVTX ranges.

format-rebase!

I'm very open to other solutions to the global initialization problem - we have a similar issue with things like MPI_Init/Finalize, where users may or may not want us to take care of initialization. I do like your suggestion a lot, I didn't consider letting the Executor decide whether to receive propagated events. We could potentially also extend that to handle the split between host and device executor, making the workaround for the benchmarks unnecessary? But that would make the host executor the destination for all events, which is usually not that easy to access compared to the device executor, which is used everywhere.

On the global object question: I didn't realize until now, in case somebody were to run some kind of weird hybrid solve, it might actually make sense to have multiple different loggers with different properties all providing NVTX ranges. I'll add a bit of color to the nvtx example :)

Not using singletons for nvtx and roctx definitely makes sense: We can assign different colors to different executors that way (with a bit of corporate branding 😄 ): Yellow is GPU, gray is CPU

Random thought: A future feature that would work especially well for NVTX would be allowing users to give names to objects: profiler_set_name(linop.get(), "mass_matrix") would probably make the profile much more readable, and very cheap to implemented

ROCm profiling also seems to work :)

For future reference, here's how to do the same thing with Intel vTune
https://www.intel.com/content/www/us/en/develop/documentation/vtune-help/top/api-support/instrumentation-and-tracing-technology-apis/basic-usage-and-configuration.html#basic-usage-and-configuration
https://www.intel.com/content/www/us/en/develop/documentation/vtune-help/top/api-support/instrumentation-and-tracing-technology-apis/basic-usage-and-configuration/configuring-your-build-system.html
https://www.intel.com/content/www/us/en/develop/documentation/vtune-help/top/api-support/instrumentation-and-tracing-technology-apis/instrumentation-tracing-technology-api-reference/task-api.html

VTune now also works

I set it as the default profiler for DPC++, but not for other backends. Any opinions on that?


Decode the most frequent undocumented expn_code values on the ExpnCd table

Discovered as part of #1007. Several undocumented codes appear in the database frequently enough that we should try to figure out what they mean.
For instance, the "IKD" value appears more than 150,000 times.
Here the ones I think we need to puzzle out.
expn_code,COUNT(*)
"FIL";7641
"IKD";163055
"LEG";996
"LON";765
"MBR";13416
"MON";929096

Some of these same codes can be found in the expn_code field of the DebtCd table.

There are a couple clues in the .CAL documentation.
It says at the bottom here: 'For Schedule D "Type of payment", codes "MON, "IKD" and "IND are the only valid codes. IKD and IND require an explanation.'

Here are some more clues from another section of the .CAL documentation. Check the bottom of the page here.

IKD, MON and LON values have been added to the choices options on RcptCd and DebtCd based on the documentation above.

The three most common undefined values are now:
expn_code,COUNT(*)
"FIL";7641
"LEG";996
"MBR";13416

Referring back to the documents above, I can see that those three codes are not defined in the ASCII text version that was my original reference but are in the slicker looking page that appears deeper down in the .CAL documentation. So it seems that we have two different versions of the documentation and will need to refer to both in the future when working out problems like this.

Alrighty. FIL, LET and MBR are now defined on both tables. There are still dozens of undefined codes but I think we've netted the ones that occur frequently (though that is obviously a debatable conclusion). Thinking maybe we can close this ticket, but I'd like to have some way to record the fact that our work is not 100% complete. Open to ideas from others here so please chime in with any opinions.

Has been consolidated into #1194