text:
mocking error: "No module named 'setuptools_rust'"

[nix-shell:~/Documents/nixpkgs/pkgs/development/python-modules]$ python-package-init safetensors --nixpkgs-root=~/Documents/nixpkgs/
Fetching package="safetensors" version="stable"
mocking setup.py::setup(...) failed thus dependency information is likely incomplete
mocking error: "No module named 'setuptools_rust'"
inserting package before safety in python-modules.nix

the library does use rust to build. how do i fix this?

Hi! to be honest i am  unsure what the problem is, normally for setuptools_rust to be available it is enough to add setuptools and setuptools-rust to propagatedBuildInputs.
i also checked nix-init (https://github.com/nix-community/nix-init) but it seems to have the same issue:
nix run --extra-experimental-features "flakes nix-command" github:nix-community/nix-init -- --url https://pypi.org/project/safetensors/ with 7 - buildPythonPackage - setuptools input mode also creates a derivation which is missing setuptools_rust

authors: lizelive makefu

repo: nix-community/nixpkgs-pytools


text:
plugins/lsp: add slint_lsp

Added configuration for slint_lsp.

Done, all checks passing.

Perfect, thanks !

source: gharchive/pull-request

authors: Bodleum GaetanLepage

repo: nix-community/nixvim

license: MIT

license_type: permissive

license_source: github-api


text:
Update sources

:robot_face: Updating sources to the latest version.
Commits touching OCaml packages:

ocamlPackages.findlib: detect conflicts of version early

just like pythonCatchConflictHook

ocamlPackages.javalib: 3.2.1 → 3.2.2
ocamlPackages.sawja: 1.5.11 → 1.5.12
Merge pull request #205646 from symphorien/ocamlconflict

ocamlPackages.findlib: detect conflicts of version early

Merge pull request #212910 from vbgl/ocaml-javalib-3.2.2

ocamlPackages.javalib: 3.2.1 → 3.2.2; sawja: 1.5.11 → 1.5.12

ocamlPackages.mdx: 2.1.0 → 2.2.1
Merge pull request #213102 from vbgl/ocaml-mdx-2.2.1

ocamlPackages.mdx: 2.1.0 → 2.2.1

Merge pull request #212407 from NobbZ/hledger-utils

hledger-utils: init at 1.12.1 (also init so far unpackaged dependencies)

Merge pull request #212407 from NobbZ/hledger-utils

hledger-utils: init at 1.12.1 (also init so far unpackaged dependencies)

Merge pull request #212407 from NobbZ/hledger-utils

hledger-utils: init at 1.12.1 (also init so far unpackaged dependencies)

Merge pull request #212407 from NobbZ/hledger-utils

hledger-utils: init at 1.12.1 (also init so far unpackaged dependencies)

Merge pull request #212407 from NobbZ/hledger-utils

hledger-utils: init at 1.12.1 (also init so far unpackaged dependencies)
Diff URL: https://github.com/NixOS/nixpkgs/compare/3875a3e3e1ca2fa7e17fc45a1dbf92551f1b9db7...4c4b377a23282b516bc991f0bc928d91dc28994a

I will try to upstream the last patch, I think those libraries are the ones that are OK to be in both right?

OK let's land this until upstream makes up their mind.

authors: anmonteiro ulrikstrid

repo: nix-ocaml/nix-overlays


text:
Declare the MSRV in Cargo.toml

This is a new feature in Cargo 1.56.0, currently in beta.  Once Nix's
MSRV is >= 1.56.0, this feature will prevent future problems like the
bitflags 1.3.0 fiasco.
Issue #1491
Issue #1510
Issue #1548
Issue #1555

bors r+

I'll look into the failure, but at first glance it's coming from within rustc. I'm tempted to say we should skip the check for this PR/until it's fixed, since DragonFly is a tier 3 target.

bors retry

authors: asomers rtzoeller

repo: nix-rust/nix

license: mit

license_source: bigquery


text:
Use with actions/cache

Hi @blaggacao, @stephank, @rickynils! Thanks a lot for your work!
actions/cache
Because your action makes /nix/store owned by an unpriviliged user, actions/cache can restore and save /nix/store without intermediate stores.
As a PoC, I made the deemp/cache-nix-too action to close https://github.com/DeterminateSystems/magic-nix-cache-action/issues/16.
cache-nix-too is actions/cache, but also caches several Nix directories as suggested by @blaggacao in https://github.com/DeterminateSystems/magic-nix-cache-action/issues/11#issuecomment-1610001962.
README
I suggest you write in the README that nix-quick-install-action can be used together with actions/cache so that people can benefit from your action even more.
nix-cache-too open problems
Directoris
I'm not sure I cache the right directories in deemp/cache-nix-too.

It was suggested to exclude some of them in https://github.com/cachix/install-nix-action/issues/56#issuecomment-1059878362, but I don't know why
I don't know about the implications of restoring the whole /nix/

Cache eviction
I can't find a good policy for cache eviction. Say, I build a docker image in each job run. Next, I cache the whole store. In the next run, I restore the whole store with that old image. If I don't remove that image, it'll be cached and restored indefinitely.
Possible solutions

I tried caching only paths accessed during a run by consulting their atime. I used install-nix-action. However, I observed unstable cache sizes on macOS (issue) runners.
It may be enough to run an installable, nix profile install installable, do other steps, collect garbage, rm -rf /nix/var/nix/profiles, save cache, run a job again.
Start direnv in background.
Use nix-heuristic-gc
Somehow keep inputs (https://github.com/NixOS/nix/issues/4250, https://github.com/NixOS/nix/issues/6895)

New action
I believe you can make a new nix-quick-cache-action action that caches the right directories and has a reasonable paths eviction policy.

I don't know about the implications of restoring the whole /nix/

It may painstaikingly slow down the system on unrelated store entries that need to be compressed, transported and decompressed. Either due to cache growth or due to multiple packages / builds.

It was suggested to exclude some of them in

Looks mostly like runtime nix data.

it'll be cached and restored indefinitely

GH evicts about every 7 days or after ~10GB. But that's no solution to cache growth in a sprint.
Imo, the best design would be a background upload by magic cache and the cache unit would be best individual store paths.
This makes the system as efficient as it can get and using (slow) bandwidth on only the bits and pieces that are needed.

Imo, the best design would be a background upload by magic cache and the cache unit would be best individual store paths.

Well, I ran into rate limit with magic-nix-cache on the second job run (https://github.com/DeterminateSystems/magic-nix-cache-action/issues/16).
With nix-quick-install-action and cache-nix-too, I restored a 1.5 GB /nix in under a minute (see workflow) and got a single entry for each job. I was impressed and decided to share with you.

I ran into rate limit

I wonder if that's something that the NixOS Foundation could touch upon in their sync-up meeting with GH engineers. :shrug:
My bet is that this may eventually happen due to the vested interests of DetSys and their representation across the nixos governance structure.
Btw, we've been using something similar in the past.
But indeed the ~1 - 2 min penalty for cache creation & restore was critical cycle time for us.
It's not 100% related, but here we've taken an approach to evaluate in a persistent "Discovery" host which brought down discovery of buildable targets from 20mins to 40s on IFD-heavy projects.
The building is then offloaded onto nixbuild from the GH worker build matrix, or alternatively the magic cache action.

It looks like https://github.com/nix-community/cache-nix-action is usable with nix-quick-install. I will look into using it inside the workflows for nix-quick-install too.

source: gharchive/issue

authors: blaggacao deemp rickynils

repo: nixbuild/nix-quick-install-action


text:
Question about Vision-Language Adapter

Hello, thanks for sharing your interesting research!
May I ask about the  the structure of the Vision-Language Adapter mentioned in this paper and how it works during fine-tuning.
Is this adapter introduced to address a semantic gap between the embeddings of images obtained through ViT and instructions, which leads to poor performance when directly concatenated?

Hi,
Do you mean the Vision-Language Adapter shown in Figure 2 (a)? Sorry for the possible misunderstanding, Figure 2 (a) is just a schematic. This adapter is introduced by our baseline model Qwen-VL itself for connecting ViT and LLM, SeeClick did not modify the model structure of Qwen-VL.
Introducing an adapter to connect ViT and LLM is a common practice in current Large Vision-Language Models, e.g. the MLP layers in LLaVA and the Q-former in our case. These adapters are considered to contribute to vision language alignment.

I got it!
Thanks for your prompt response.

repo: njucckevin/SeeClick


text:
Tag descriptions are not treated as markdown

Tag descriptions are currently not treated as markdown and therefore not converted to HTML. But this should be the case

Closed in 8d9abe18e147606228a1c3962eeffa8c198debfd

repo: nknapp/bootprint-swagger


text:
Fix link in README.md

See #5

For some reason, the link checks pass fine when I run them locally (except for the relative link, can be ignored):
% ./markdown-link-check https://raw.githubusercontent.com/nlesc-sigs/nlp-sig/master/README.md

FILE: https://raw.githubusercontent.com/nlesc-sigs/nlp-sig/master/README.md
  [✖] #upcoming-meetings
  [✓] https://www.esciencecenter.nl/team/carsten-schnober/
  [✓] https://www.esciencecenter.nl/team/dr-laura-ootes/
  [✓] https://www.esciencecenter.nl/team/dr-ir-erik-tjong-kim-sang/
  [✓] https://www.esciencecenter.nl/fellowship-programme/claudiu-forgaci/
  [✓] https://github.com/UD3-Lab/mintEMU
  [✓] https://github.com/nlesc-sigs/nlp-sig/blob/master/meetings.md
  [✓] nlp-conferences.md
  [✓] nlp-literature.md
  [✓] https://www.aclweb.org/portal/
  [✓] https://www.let.rug.nl/vannoord/Clin/
  [✓] https://www.clinjournal.org/clinj
  [✓] https://notas.nl/
  [✓] https://www.let.rug.nl/vannoord/TST-Geschiedenis/

  14 links checked.

  ERROR: 1 dead links found!
  [✖] #upcoming-meetings → Status: 404

repo: nlesc-sigs/nlp-sig


text:
g++ (11) -Wuseless-cast gives lots of warnings

What is the issue you have?
When I compile the 'single include' file on g++ v11 on my Fedora 34 machine with the '-Wuseless-cast' flags enabled then I get lots of warnings.
Please describe the steps to reproduce the issue.

enable the -Wuseless-cast compiler flag and compile

Can you provide a small but working code example?

What is the expected behavior?

And what is the actual behavior instead?

Which compiler and operating system are you using?

Compiler: gnu g++ v11
Operating system: Fedora 34 x64

g++ (GCC) 11.1.1 20210531 (Red Hat 11.1.1-3)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Which version of the library did you use?

[ ] latest release version 3.9.1
[x] other release - please state the version: commit a563338039346c9ed722e09547419190b1eeddbe
[ ] the develop branch

If you experience a compilation error: can you compile and run the unit tests?

[ ] yes
[ ] no - please copy/paste the error message below

Can you provide the warnings?

So it turns out 'lots' is 2. I just saw lots bacause we include it in lots of places. oops.
xxx/json.hpp: In member function ‘bool nlohmann::detail::binary_reader<BasicJsonType, InputAdapterType, SAX>::parse_cbor_internal(bool, nlohmann::detail::cbor_tag_handler_t)’:
xxx/json.hpp:8856:80: warning: useless cast to type ‘std::size_t’ {aka ‘long unsigned int’} [-Wuseless-cast]
 8856 |                 return get_number(input_format_t::cbor, len) && get_cbor_array(static_cast<std::size_t>(len), tag_handler);
      |                                                                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
xxx/json.hpp:8910:81: warning: useless cast to type ‘std::size_t’ {aka ‘long unsigned int’} [-Wuseless-cast]
 8910 |                 return get_number(input_format_t::cbor, len) && get_cbor_object(static_cast<std::size_t>(len), tag_handler);
      |                                                                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

These are hard to fix, because not all architectures have the same definitions for size_t.

I double checked. In both cases, there is a cast from std::uint64_t to std::size_t:
std::uint64_t len{};
return get_number(input_format_t::cbor, len) && get_cbor_object(static_cast<std::size_t>(len), tag_handler);

I case these types are the same, your reported warning makes sense. However, the types do not necessarily need to be the same.
Does anyone has an idea how to silence this warning?

I guess one could use something like the following
#include <type_traits>

template<typename T, typename U, std::enable_if_t<!std::is_same<T, U>::value, int> = 0>
T conditional_static_cast(U value)
{
return static_cast<T>(value);
}

template<typename T, typename U, std::enable_if_t<std::is_same<T, U>::value, int> = 0>
T conditional_static_cast(U value)
{
return value;
}

void func()
{
    int a = conditional_static_cast<int>(0);
    int b = static_cast<int>(0);

}

The first line in func gives no warning the second does.

I think I've dealt with this before, need to look it up.
Solution was something with ifdef's and type sizes

Thanks @t-b - I was thinking of preprocessor magic before, but this is much cleaner. I'll give it a try, see #2902.

tnx!

Wouldn't it be easier to just disable the warning instead making a workaround for it?
It seems like a pretty useless warning anyways, and disabling it is pretty straight forward.

authors: Pirulax fhuberts nlohmann t-b

repo: nlohmann/json


text:
VS 2022 latest version on win 10 latest version don't compile any recent version of JSON...

Description
VS 2022 latest version on win 10 latest version don't compile any recent version of JSON ( I'm a recent user of this classes )

Reproduction steps
Don't compile...
Expected vs. actual results
Don't compile... error number on image sent
Minimal code example
Don't compile...

Error messages
look image sent...

Compiler and operating system
VS 2022 latest version win 10 latest version
Library version
3.11.x
Validation

[X] The bug also occurs if the latest version from the develop branch is used.
[ ] I can successfully compile and run the unit tests.

It's Compile if I comment the line in question....
I can use this librairy so....
(I don't use serialisation/deserialiation)

It's because of the option /sdl of MSVC I think....


text:
Use project_urls key to show additional PyPI links

Reference:
https://packaging.python.org/guides/distributing-packages-using-setuptools/#project-urls
Example (from requests):

Thanks @bsolomon1124

repo: nltk/nltk


text:
win10，python3，certifi 不能卸载 导致安装meteva失败

ERROR: Cannot uninstall 'certifi'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall。

pip install --user meteva --ignore-installed.
虽然报错，但是可以import。

repo: nmcdev/meteva


text:
tag-recapture: create user filter to set min number of recaptures for inclusion of a tag-group

some tag groups may have many releases, but few recaptures.  It seems useful to allow a user to set a filter such that that number of recaptures in time >= mixperiod exist.
This could be implemented in ss_readdata330.tpl to create a "use" flag for each tag group.
The value could be read in ss_readdata330.tpl right after the input of the value for mixperiod.
The total number of recaps is currently not counted, but easily could be in ss_readdata330.tpl.
Note: remember to only count those that are >=mixperiod.
Probably should make this a conditional input:
if(mixperiod>=0){
min_tag_recap=0.0;}
else{
mixperiod=-mixperiod;
ad_comm:  min_tag_recap;}

1 # do tags (0/1)
121 # N tag groups
769 # N recap events
-4 # TG_mixperiod (latency) is the first period in which logL is calculated for this tag group (0 = release period)
(use negative value for TG_mixperiod to invoke reading TG_min_recap after TG_maxperiods
16 # max periods (seasons) to track recoveries, after which tags are still read into this accumulator period
2 # TG_min_recap:  N recaps >= mixperiod must be >= min_recap to include tag group in logL
Release data for each tag group.  Tags are considered to be released at the beginning of a season (period)
ALSO*****
In compreport.sso, I now output the time in periods since release, which seems more useful for plotting and comparisons than real time, which is still there in another column

The final output looks like this:
2 # do tags (0/1/2). 2 means include TG_min_recap input
121 # N tag groups
769 # N recap events
4 # TG_mixperiod (latency) is the first period in which logL is calculated for this tag group (0 = release period)
16 # max periods (seasons) to track recoveries, after which tags are still read into this accumulator period
2 # Cond on Do Tags 2: TG_min_recap:  N recaps >= mixperiod must be >= min_recap to include tag group in logL
# Release data for each tag group.  Tags are considered to be released at the beginning of a season (period)

authors: Rick-Methot-NOAA k-doering-NOAA

repo: nmfs-stock-synthesis/stock-synthesis


text:
Feature - Base services

[x] App icon
[x] Base service
[x] Services:

[x] Authentication
[x] Surveys

[x] Models

:+1: There are no linter violations.


text:
Cron Jobs - which are run on boot - should be retriable

Currently, they are not. Given they can break the booting up of the cowj system, it is better to allow for retries. For the actual cron jobs they will be retried anyways - because of .. periodicity.

This is done now.
Reference: https://github.com/nmondal/cowj/blob/main/app/src/test/java/cowj/CronTest.java#L139

repo: nmondal/cowj


text:
Personalized Tokens

Readiness checklist

[X] I added/updated tests.
[X] I ensured that the PR title is good enough for the changelog.
[X] I labeled the PR.

I don't see tests for tokens for relationship templates. Was this added in the other PR?

I don't see tests for tokens for relationship templates. Was this added in the other PR?

The scenario of a personalized token for a non-personalized template was not there - I'm adding it in

repo: nmshd/connector


text:
WIP: nm: use interface name instead of UUID

Current nmstate code is using UUID when referring the controller/parent in
NM profile, this cause problem when the controller/parent is in-memory
profile which change UUID after reboot. The OpenShift is using in-memory
profile for br-ex and will recreate it after reboot. This prevent us from
modifying the ports of br-ex.
Using interface name for controller/parent reference would fix this
problem.
Existing test cases are enough to test this change.

Waiting NetworkManager fix: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1878

repo: nmstate/nmstate


text:
schema: Add interface subconfig: VLAN

Add VLAN class to libnmstate.schmea with these constants:
* VLAN.TYPE
* VLAN.CONFIG_SUBTREE
* VLAN.ID
* VLAN.BASE_IFACE

Coverage remained the same at ?% when pulling bd7ce0486c46e001c40c00fac6e454731cba48da on cathay4t:schema_vlan into e88a7d2a70f7eb241e6ff5e6633f8dbfce3cc6d6 on nmstate:master.

Coverage remained the same at ?% when pulling bd7ce0486c46e001c40c00fac6e454731cba48da on cathay4t:schema_vlan into e88a7d2a70f7eb241e6ff5e6633f8dbfce3cc6d6 on nmstate:master.

Coverage remained the same at ?% when pulling bd7ce0486c46e001c40c00fac6e454731cba48da on cathay4t:schema_vlan into e88a7d2a70f7eb241e6ff5e6633f8dbfce3cc6d6 on nmstate:master.

Coverage remained the same at ?% when pulling bd7ce0486c46e001c40c00fac6e454731cba48da on cathay4t:schema_vlan into e88a7d2a70f7eb241e6ff5e6633f8dbfce3cc6d6 on nmstate:master.


text:
Mentions and hashtags support

Are you planning to support mentions and hashtags? I mean fire event when user start typing word starting @ or # symbol or change caret position to such word and ability to replace(or insert) autocompleted mention or tag

No, I really don't have time to work on this library right now. Feel free to submit a pull request!

@Deliany I will work on adding a feature that fires an event when a word that starts with @ or # is typed.

@Deliany I have added this feature, you can receive these events using the following methods in your subclassed ZSSRichTextEditor:
- (void)hashtagRecognizedWithWord:(NSString *)word {

    NSLog(@"Hashtag has been recognized: %@", word);

}

- (void)mentionRecognizedWithWord:(NSString *)word {

    NSLog(@"Mention has been recognized: %@", word);

}

authors: Deliany nnhubbard william205

repo: nnhubbard/ZSSRichTextEditor


text:
Improve calculation of y-axis maximum value

I felt the y-axis maximum value was often too large.
Now a maximum data value of 1431 gives a maximum y-axis value of 1500
instead of 2000.
https://github.com/airblade/Chart.js/commit/3cdecb11dc9d1c7cc3e07d7a277fc8e5ba4ee137

I think this is a good candidate for fixing in 1.1

Moved to milestone Axis. Not saying this won't be completed for 1.1, just trying to keep those issues closely associated

Huzzah! The first alpha of Chart.js 2.0 has landed and should fix this issue. Check out the release and try it out! We've got a lot of momentum right now, so please help us test so we can launch 2.0 Gold by the end of the month.
https://github.com/nnnick/Chart.js/releases/tag/v2.0-alpha

authors: airblade derekperkins etimberg fulldecent


text:
[ NNSTREAMER ] Add nnstreamer filter for nntrainer

In this PR,
. NNStreamer filter subplugin is implemented.
. Test Cases for subplugin
Self evaluation:

Build test:	 [X]Passed [ ]Failed [ ]Skipped
Run test:	 [X]Passed [ ]Failed [ ]Skipped

Signed-off-by: jijoong.moon jijoong.moon@samsung.com

:memo: TAOS-CI Version: 1.4.20191203. Thank you for submitting PR #531. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnsuite.mooo.com/.

:octocat: cibot: @jijoongmoon, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnsuite.mooo.com/nntrainer/ci/repo-workers/pr-checker/531-202009111405060.309494972229-40b1c676dbbf36110a4cf172573b5582d00e7462/.

:octocat: cibot: @jijoongmoon, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnsuite.mooo.com/nntrainer/ci/repo-workers/pr-checker/531-202009111413500.12005400657654-ee8cfea1e0ae2787dd05789a71f09e4d5f0de380/.

:octocat: cibot: @jijoongmoon, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnsuite.mooo.com/nntrainer/ci/repo-workers/pr-checker/531-202009111440430.24328398704529-73c43213058ef00d09420a9692d6d43825bc0935/.

authors: jijoongmoon taos-ci

repo: nnstreamer/nntrainer


text:
升级到 0.06 后报错

执行 npm run dev 后提示
This dependency was not found:

miment in ./node_modules/cache-loader/dist/cjs.js?{"cacheDirectory":"/Users/zaxlct1/Desktop/vvv/tracker/pc/node_modules/.cache/cache-loader"}!./node_modules/babel-loader/lib!./node_modules/vue-loader/lib/selector.js?
type=script&index=0!./src/components/OrderCard.vue, ../public/directive.js

修复了, 发布v0.0.7了
npm i miment@0.0.7

authors: noahlam zaxlct

repo: noahlam/Miment


text:
model reproduction

I followed your experiments for training, but the generalisability experiments on the Make3D dataset could not achieve the original paper results.

Hi, I cannot give you any advice if you don't tell me more information.
You can check some previous issues related to the results on make3d
https://github.com/noahzn/Lite-Mono/issues/73
https://github.com/noahzn/Lite-Mono/issues/128

The prediction code I used is shown below, in that the weights you posted can be tested out of the same results in the paper, but I couldn't come up with the same results with my own training.
from layers import disp_to_depth
import networks
import cv2
import os
import torch
from scipy import io
import numpy as np
from options import LiteMonoOptions
cv2.setNumThreads(0)  # This speeds up evaluation 5x on our unix systems (OpenCV 3.3.1)
Path
load_weights_folder = 'pre_tmp/pre-litemono8m-real-Shift5-LGMaSA/models/weights_26'
load_weights_folder = 'lite-mono_640x192'
main_path = 'make3d'
encoder_path = os.path.join(load_weights_folder, "encoder.pth")
decoder_path = os.path.join(load_weights_folder, "depth.pth")
def compute_errors(gt, pred):
rmse = (gt - pred) ** 2
rmse = np.sqrt(rmse.mean())
rmse_log = (np.log10(gt) - np.log10(pred)) ** 2
rmse_log = np.sqrt(rmse_log.mean())

abs_rel = np.mean(np.abs(gt - pred) / gt)

sq_rel = np.mean(((gt - pred) ** 2) / gt)

return abs_rel, sq_rel, rmse, rmse_log

def evaluate(opt):
print("-> Loading weights from {}".format(load_weights_folder))
encoder_path = os.path.join(load_weights_folder, "encoder.pth")
decoder_path = os.path.join(load_weights_folder, "depth.pth")

encoder_dict = torch.load(encoder_path)
decoder_dict = torch.load(decoder_path)

# Load Model (Encoder & Decoder)
encoder = networks.LiteMono(model=opt.model,
                            height=encoder_dict['height'],
                            width=encoder_dict['width'])
depth_decoder = networks.DepthDecoder(encoder.num_ch_enc, scales=range(3))
model_dict = encoder.state_dict()
depth_model_dict = depth_decoder.state_dict()
encoder.load_state_dict({k: v for k, v in encoder_dict.items() if k in model_dict})
depth_decoder.load_state_dict({k: v for k, v in decoder_dict.items() if k in depth_model_dict})

# CUDA
encoder.cuda()
encoder.eval()
depth_decoder.cuda()
depth_decoder.eval()

# Load Dataset
with open(os.path.join(main_path, "make3d_test_files.txt")) as f:
    test_filenames = f.read().splitlines()
test_filenames = map(lambda x: x[4:], test_filenames)

depths_gt = []
images = []
ratio = 2  # 2
h_ratio = 1 / (1.33333 * ratio)
color_new_height = int(1704 / 2)  # 2
depth_new_height = 21
for filename in test_filenames:
    mat = io.loadmat(os.path.join(main_path, "Gridlaserdata", "depth_sph_corr-{}.mat".format(filename)))
    depths_gt.append(mat["Position3DGrid"][:, :, 3])

    image = cv2.imread(os.path.join(main_path, "Test134", "img-{}.jpg".format(filename)))
    image = image[int((2272 - color_new_height) / 2):int((2272 + color_new_height) / 2), :, :]
    images.append(image[:, :, ::-1])
depths_gt_resized = map(lambda x: cv2.resize(x, (305, 407), interpolation=cv2.INTER_NEAREST), depths_gt)
depths_gt_cropped = map(lambda x: x[int((55 - 21) / 2):int((55 + 21) / 2), :], depths_gt)

depths_gt_cropped = list(depths_gt_cropped)
print("-> Computing predictions with size {}x{}".format(
    encoder_dict['width'], encoder_dict['height']))
errors = []
with torch.no_grad():
    for i in range(len(images)):
        input_color = images[i]
        input_color = cv2.resize(input_color / 255.0, (640, 192), interpolation=cv2.INTER_NEAREST)  # <----1
        # input_color = (lambda x: x[int((55 - 21) / 2):int((55 + 21) / 2), :], input_color)
        input_color = torch.tensor(input_color, dtype=torch.float).permute(2, 0, 1)[None, :, :, :]
        input_color = input_color.cuda()
        output = depth_decoder(encoder(input_color))
        pred_disp, _ = disp_to_depth(output[("disp", 2)], 1, 60)  # <=---2   [0.1, 100]
        pred_disp = pred_disp.squeeze().cpu().numpy()
        depth_gt = depths_gt_cropped[i]
        depth_pred = 1 / pred_disp
        depth_pred = cv2.resize(depth_pred, depth_gt.shape[::-1], interpolation=cv2.INTER_NEAREST)
        mask = np.logical_and(depth_gt > 1, depth_gt < 60)  # 0, 70
        depth_gt = depth_gt[mask]
        depth_pred = depth_pred[mask]
        depth_pred *= np.median(depth_gt) / np.median(depth_pred)
        depth_pred[depth_pred > 70] = 70
        errors.append(compute_errors(depth_gt, depth_pred))
        # if errors[i][3] > 0.2:
        #     print(errors[i][3])
        #     print(i)
    mean_errors = np.mean(errors, 0)

print(("{:>8} | " * 4).format("abs_rel", "sq_rel", "rmse", "rmse_log"))
print(("{: 8.3f} , " * 4).format(*mean_errors.tolist()))

if name == "main":
options = LiteMonoOptions()
evaluate(options.parse())
I trained with the following parameter settings:

Hi, does your trained model achieve a similar result on the evaluation set of KITTI as mine?

not having reached:
a1 0.7713, a2 0.966, a3 0.9878, abs_rel 0.1666 , log_rms 0.2153 , rme 4.603, sq_rel 0.9125
{
"data_path": "/sdb1/YJ/Lite-Mono-main/kitti",
"log_dir": "./pretrain-tmp-refine",
"model_name": "pre-litemono-predictmask_nothing",
"split": "eigen",
"model": "lite-mono",
"weight_decay": 0.01,
"drop_path": 0.2,
"num_layers": 18,
"dataset": "kitti",
"png": false,
"height": 192,
"width": 640,
"disparity_smoothness": 0.001,
"scales": [
0,
1,
2
],
"min_depth": 0.1,
"max_depth": 80.0,
"use_stereo": false,
"frame_ids": [
0,
-1,
1
],
"profile": true,
"batch_size": 1,
"lr": [
0.0001,
5e-06,
31,
0.0001,
1e-05,
31
],
"num_epochs": 30,
"scheduler_step_size": 15,
"v1_multiscale": false,
"avg_reprojection": false,
"disable_automasking": false,
"predictive_mask": false,
"no_ssim": false,
"mypretrain": null,
"weights_init": "pretrained",
"pose_model_input": "pairs",
"pose_model_type": "separate_resnet",
"no_cuda": false,
"num_workers": 12,
"load_weights_folder": "pretrain-tmp-refine/pre-litemono-predictmask_nothing/models/weights_29",
"models_to_load": [
"encoder",
"depth",
"pose_encoder"
],
"log_frequency": 250,
"save_frequency": 1,
"disable_median_scaling": true,
"pred_depth_scale_factor": 1,
"ext_disp_to_eval": null,
"eval_split": "eigen_zhou",
"save_pred_disps": true,
"no_eval": false,
"eval_out_dir": "eval_cs",
"post_process": false
}

Hi, you didn't use the pretrained weights. You need to set --mypretrain

I'm very sorry to bother you so late, but I can't really confirm why I can't reproduce it during training.

If I need to change the model, I can't use pre-training when training.

Then you can directly change the model architecture, and make your own pre-training weights for training. All the checkpoints are included in this repo. If you don't use the ImageNet pretrained weights, then it's meaningless to compare the results.

I am now closing this issue due to no response.

repo: noahzn/Lite-Mono


text:
Export IUniverseDriver and UniverseData

Export the IUniverseDriver and UniverseData to the user as their types are used (see e.g. examples where universe.updateAll(0);)

solves #3
(did the code changes in web editor, hope I made no mistake)

Yes indeed, thanks @pfried !

authors: Granjow pfried

repo: node-dmx/dmx-ts


text:
Variadic function argument in C/C++

This isn't an issue but maybe lack of documentation on the subject.
I have a C function like the below, which has a variadic argument ... as last argument.
int message  (void *Interface, int code, char *format, ...)

I know the syntax in node ffi for this is { varargs: true } and tried emulating that with:
message: [ 'int', [ 'pointer', 'int', 'pointer', { varargs: true } ] ],

But I get the following error:
TypeError: could not determine a proper "type" from: {"varargs":true}

I saw this example here but there's no info in the docs about this.

The solution is as simple as moving the first ']' right after the last argument:
message: [ 'int', [ 'pointer', 'int', 'pointer' ], { varargs: true } ],

@ConPac thanks for the suggestion, I haven't looked at this since.

repo: node-ffi/node-ffi


text:
Support for async JS

Since launching my article on HTML5Rocks on Debugging Asynchronous JavaScript with Chrome DevTools, I've had more than a few people ask me if node-inspector will support it.
So a heads up about this new feature in Canary. I poked around node-inspector code and it looks like if you update from upstream that Node folks may also benefit from full async call stacks.
Let me know if you have an answer on whether it'll work or not.

There is a $200 open bounty on this issue. Add to the bounty at Bountysource.

Hey, guys, I was just wondering what was going on with this feature?
If this is not going to be implemented soon, does anyone know how I could get node-debugger to work with q? Would I just have to set a break point at every line of code, or is there an easier way? And would that way even work?

Bump. Any news on this?

+1, this would be awesome!

Is this already implemented? we can see the 'async' in debugger in node-inspector, but that doesn't seem to work

FWIW, if you are using a recent Node v6 versions, you can run node --inspect to launch a new built-in debugger based on DevTools-backend from Chromium. I think that one supports async stack traces.

authors: AnandNidamanuru Chris911 aogriffiths bajtos pearlchen-old zwhitchcox

repo: node-inspector/node-inspector


text:
Memory leak in takeSnapshot

I am seeing that snapshot.delete() does not release the memory back. Running this on node 5.1.0 and 4.2.4
console.log('before', process.memoryUsage());

var snapshot = profiler.takeSnapshot();

console.log('after', process.memoryUsage());

snapshot.delete();
snapshot = null

console.log('deleted', process.memoryUsage());

global.gc();
console.log('after gc', process.memoryUsage());

I got,
before { rss: 24580096, heapTotal: 11327232, heapUsed: 6567320 }
after { rss: 54214656, heapTotal: 16486912, heapUsed: 5287968 }
deleted { rss: 54108160, heapTotal: 16486912, heapUsed: 5347984 }
after gc { rss: 54116352, heapTotal: 16486912, heapUsed: 5234008 }

I got the same issues.

Are you trying node-heapdump, is there same problem?

I think I interpreted the output of process.memoryUsage() wrong. The heapUsed does not grow when snapshots are taken and deleted in a sequence. So I think there is no memory leak. Sorry about the trouble.
the same is with node-heapdump

@3y3 Why RSS has been increasing after each takeSnapshot() call, the effect that I used in an real application is that after several takeSnapshot() manual trigger, physical memory will surge to 1.5G+. :(

@PaulGuo Make sure you don't have a reference to each of the snapshots taken. Like if you store them in an array or so. Then even if you delete the snapshot taken the reference you keep will not release the snapshot object for garbage collection.
The leak I was seeing was in my application code.

@roonyh I'm sure, because I direct debugging the v8-profiler code, as long as this line of code has been executed, the rss increasing problem will happen.

@roonyh What's the reason might it be?

@PaulGuo I don't really know :(
We eventually gave up the idea of taking heap dumps in production because it takes a lot of memory during the process (~10times the memory at the time), even if it comes back to the value at the beginning. We were using node-heapdump
@3y3 Even when using node-heapdump am seeing the rss increase @PaulGuo describes.
Heres the observations with node-heapdump. This code,
var heapdump = require('heapdump');

console.log('before', process.memoryUsage());

heapdump.writeSnapshot('/tmp/heapdump.heapsnapshot', function (err, filename) {
  console.log('after', process.memoryUsage());

  global.gc();
  console.log('after gc', process.memoryUsage());
});

produeced,
before { rss: 19857408, heapTotal: 7408736, heapUsed: 3741568 }
after { rss: 40144896, heapTotal: 9472608, heapUsed: 3334488 }
after gc { rss: 40161280, heapTotal: 9472608, heapUsed: 3332176 }

@PaulGuo , do you call snapshot.delete()?

Thanks for your reply, I tried to call delete() after takeSnapshot() and the situation has improved, this will release part of increased memory, but still has memory leaks (in the real application, after trigger 10 times takeSnapshot() without delete(), memory will soon soar to 550M+ from 70M. If add delete() call after each takeSnapshot(), it helps, but it looks like there are still a memory leak, the same with 10 times trigger, the memory will be increased 150M+)
By the way, another question, when executed startProfiling() and not execute stopProfiling(), it will result the CPU > 100%, once stopProfiling() call, the CPU is right, What is the reason?

I too am noticing an increase in the heap size each time I generate a snapshot. I'm using node 8.7.0 and v8-profiler-node8@5.7.7.
I'd be glad to provide any additional info on the matter to help the investigation.

authors: 3y3 PaulGuo mlarcher roonyh shanegxxiao


text:
Cannot show subflow on touch devices

i.e. on iPad long-press on subflow (either nodes pane or flow editor) does not bring up any option to show the subflow contents.

I have the dame issuebon my android tablet

Lots of touch-related issues with subflows were fixed in 1.1.0 (and earlier). You can dbl click a subflow instance node and then click the 'edit subflow template' button in the edit dialog to access the subflow template.

authors: andig knolleary nielsnl68

repo: node-red/node-red


text:
0.20 zip release packaging & install documentation

Related to the getting-started/installation documentation, using the release file in the Alternative methods :
https://nodered.org/docs/getting-started/installation
0.19.x releases were packaged like specified in the documentation. For example, 0.19.6 has a single directory at the first level in the zip archive, and everything required by node-red is under the said directory.
0.20 releases use a different structure, the zip archive currently contains 2 directories :

node-red
@node-red

For what I saw, there's no information in the documentation about the @node-red directory.
After installing only the node-red directory and checking how nodejs/npm managed the modules, it seems the @node-red directory in the zip archive is not at the right place and/or completely skipped due to the node-red/package.json .
Please tell us about your environment:

[ ] Node-RED version: v0.20.5
[ ] node.js version: v8.15.1
[ ] npm version: 6.4.1
[ ] Platform/OS: Ubuntu 18.04.2
[ ] Browser: Firefox 64.0.2

Yes the zip layout has changed and the docs need to update to reflect this fact.
However, as we have now split node-red into multiple modules (which has been mentioned at length in the release blog post and other posts) it makes much less sense to download the zip when running npm install node-red will get you everything you need properly installed.
Did you have a particular dependency on the zip file?
Also, please use the issue template in the future.

I don't use npm install <module>, nor a global install. I'm having npm working directly on the zip content as a source.
This allow me to control the installed version and the location : node-red is self-contained with all the dependencies under a release/vX.XX.XX directory with a symlink targeting the lastest version.
A little grease is required for the first installation, but this allows, amongst other things, to roll back to another version with just a change to the symlink (assuming there weren't any modification to the data structure).
The only problem was to know what to do with the @node-red directory, and if it was required or not.   Given the package.json file has enough information, npm is happy without this directory, or if moved under node-red/node_modules/
Sorry for the template, given it was specific to the new packaging, I didn't think it was required.
I've added at least the version information.

authors: Daryes knolleary


text:
Incorrect syntax highlighting in the JSONata Expression editor in the change node.

What are the steps to reproduce?
[{"id":"e9e09a72.fc9348","type":"change","z":"bfd23e84.79e77","name":"bad syntax highlighting","rules":[{"t":"set","p":"cases","pt":"msg","to":"/* returns an array of\t     { \"x\" : date_in_ms,\t       \"y\" : average_number_of_cases }\t*/\t( $subset := COVID19BE_CASES_AGESEX[     PROVINCE = $$.PROVINCE \t                                      and AGEGROUP = $$.AGEGROUP\t                                      and SEX      = $$.SEX].{ \"date_int\" : $toMillis(DATE)/(24*60*60*1000),\t                                                               \"cases\"  : CASES};\t  $first_day := $subset.date_int~>$min();\t  $last_day := $subset.date_int~>$max();\t  [ $first_day ..  ( $last_day -AVERAGE_PERIOD+1)].(\t      $start_period :=$;\t      $end_period   :=$start_period + $$.AVERAGE_PERIOD -1;\t      $sum_cases    := $subset[ date_int >= $start_period and date_int <= $end_period].cases~>$sum();\t      {\t     \"x\" : ($start_period + $end_period )*24*60*60*1000/2,\t     \"y\" :$sum_cases~>$exists()?$sum_cases/($$.AVERAGE_PERIOD): 0\t     })\t)","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":350,"y":520,"wires":[[]]}]

What happens?

What do you expect to happen?
From the end of line 7 up to the end of line 16 is highlighted as comment.  This is not correct.
The / is apparently interpreted as the start or end of the comment.  Which is not always correct.  / can also mean the "division operator".  Only /* and */should be considered the start and end of a comment.
Please tell us about your environment:

[x] Node-RED version: v1.1.3
[x] Node.js version: v12.18.3
[x] npm version: 6.14.6
[x] Platform/OS: Linux 4.18.0-193.6.3.el8_2.x86_64 x64 LE
[x] Browser: chrome

Have pushed a fix to the dev branch.
The syntax highlighting mode had no support for comments at all (as its a relatively new addition to JSONata). What you were seeing was an issue with the regular expression highlighting - any section starting with a / was being identified as a regex - including the comment block at the start.
It needed some additional logic to prevent it mistaking a divide for the start of a regex. Thankfully the existing JavaScript highlight mode showed me the way to disambiguate the two.
I've also added support for /* ... */ comments, and fixed up some highlighting of variables that contain a known function name (eg $sum_cases was getting $sum highlighted as a known function).
Here's what it looks like with the fixes:

authors: janvda knolleary


text:
translation error

Current Behavior
到处到库
Expected Behavior
导出到库
Steps To Reproduce
node-red\packages\node_modules@node-red\editor-client\locales\zh-CN\editor.json
Example flow
paste your flow here

Environment

Node-RED version:
Node.js version:
npm version:
Platform/OS:
Browser:

Google Translate agrees with this proposal. Will apply this fix for the next release.


text:
Update message catalog

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)

Proposed changes
I added Japanese translation and fixed typo in the Japanese message catalog.
I also removed unnecessary lines from English message catalog.
Checklist

[x] I have read the contribution guidelines
[ ] For non-bugfix PRs, I have discussed this change on the mailing list/slack team.
[x] I have run grunt to verify the unit tests pass
[ ] I have added suitable unit tests to cover the new/changed functionality

Coverage remained the same at 76.484% when pulling b80d1af3d711bb7a85ae0874980625123ad2315d on kazuhitoyokoi:dev-updatemessagecatalog into c0837ead0ec1364116a23378c143e5cbd4b45134 on node-red:dev.

Thank you!

authors: coveralls kazuhitoyokoi


text:
Updated autoprefixer call for version >= 5.2

Starting from autoprefixer-core 5.2, the ap.process() is obsolete (Ref: postcss/autoprefixer-core@d35c9321e2ca956fafc82e443e3b2cd06c21aaab). This PR aims to fix this by updating the call to the newer recommended way.
Please advise. Thanks.

Thanks for PR! It's ok in general, but i think it's not save to rely on postcss availability in version check.
I could merge PR as useful enougth, but it needs more fixes for release.

more safe version check
probably, the same fixes in css_wring plugins

Thanks for the feedback! In our case here, it seems better to sniff for postcss 4.1 instead of 4.0, using postcss.plugin. I have updated the PR to address this. Also updated is the CsswringCompressor to cope with the upcoming API change introduced by hail2u/node-csswring@4921ad316bd72aea5428fdc3d799322465923e93.

Looks good. I'll bump version to 1.3.0 for sure.
@ixti , take a look please.

LGTM. Ok to be merged once wring function initialization will be moved out of evaluate

Sure, I will update the PR right away to move that to initialiser.

A bit OT, but as working on the PR, it seems that there are dependencies that are specified by '*', but actually have minimum working version in the actual implementation, like sass (requires >= 0.5) and uglify (requires > 1). Do you think it is a good idea to update the dependencies in package.json, while releasing the 1.3.0 build? Thanks.

@netsgnut i don't see reasons to overcomplicate. Those deps are for developpers only anyway.

@puzrin Indeed

@netsgnut Can you squash it to a single commit, please?

@ixti Sure, rebased as f8e0906.

Thanks!

Released with you commit. Thanks!

Saw that on NPM as well. Thanks! <3

authors: ixti netsgnut puzrin

repo: nodeca/mincer


text:
Re-creating official secretary role

At one point in the past, we had an official secretary role. With our previous election for CommComm chair, the role got folded due to lack of individuals to hold it. At the time, it wasn't a massive issue to not to have an official secretary, but as time has proceeded our workload has increased with the addition of new projects/initiatives and more observers and members engaging in the Committee.
I'd like to propose that we reinstate an official Secretary role. The individual(s) who take on this role would be tasked with:

Taking meeting minutes for each CommComm meeting
Submitting a PR with those meeting minutes into the CommComm repo once the meeting is over

Something that we probably need clarity on before electing a secretary is whether or not they need to be an existing CommComm member or not. I don't particularly mind one way or the other, but I do see it as a way to significantly contribute to the Committee - but it is certainly also a non-trivial commitment in terms of time.

This does look like a good idea. I hear you typing every time, it must be pretty hard chairing and writing at the same time. I don't know how exactly it will be done, and I don't know if I'm sufficiently fluent in English to understand everyone properly, but if no native speak wants to do it, I'll apply. But I'd prefer if someone else with better abilities would do it.

Awesome!! what are the criteria for the position?

I'm always happy to help take the notes during the meetings, it's one small way I've been able to contribute a bit. (But I won't stop anyone else who might be eager too.) Just one or two quick thoughts...
I've noticed it can be tough to both take notes and also handle the roll-call / attendance, so anything we can do to cue up the names of attendees/observers/etc ahead of time is helpful (especially since we're doing introductions a little quicker now). I'll try to get in there at least a couple minutes early next time and start jotting down some of the names on the call right away.
Also: the fact that we ultimately output the notes on github as markdown makes using google docs a little awkward. Would love to hear if there's a collaborative markdown solution that's easy to use, but I acknowledge that docs is at least free and accessible. No matter who is on notes, there's always a little awkwardness while trying to format bullet items or links.
@bnb I hung out near your Twitch stream one night as you were getting the note template all put together. Seems mostly straightforward, though you were still doing some work manually adding issue links. Would you still be the one putting the agenda together?

I agree that the formatting of google docs does make it harder to keep it in markdown but don't have a better suggestion.

@JemBijoux so, @mhdawson has mostly automated the issue, agenda, and doc creation - it's super convenient now. Basically little/no effort on our end.
I will also suggest trying out this Google Apps script - I use it almost daily for my own work to convert a properly formatted Google Doc into Markdown. @mhdawson we may want to investigate its usefulness to us.
https://gist.github.com/bnb/a02712c3f65d18d4ff2c55fc8bab7ace

I'm definitely +1 on this, even if only for the timely PRing of meeting notes.

My approach has been to try to capture the meeting minutes in markdown in the google doc, but it does sometimes fight you so finding a better easier way could make sense.

I am not a member of CommComm, but would love to help.

This was discussed in #261. @JemBijoux has kindly accepted taking on this role! 🎉 The door is open to anyone, members and observers alike, who wants to help out.

@chowdhurian will love to help too.

authors: JemBijoux Tiriel bnb chowdhurian codeekage maddhruv mhdawson oe

repo: nodejs/community-committee


text:
Use * instead of _ as em tags in markdown

In this page,
_node_modules_ compiled to a wrong result: _nodemodules
Problem solved when using * instead of _ as  tags in markdown.

Thanks! :+1:

authors: phillipj xcatliu


text:
add social media links to the readme

should be easy enough.

@yoshuawuyts can we close this?

repo: nodejs/nodejs-nl


text:
Better unsafe regex detector

Hi all,
I'm a systems/security researcher at Virginia Tech and have been studying the incidence of vulnerable regexes in the wild.
This plugin's unsafe regex detector relies on safe-regex, which uses star height (nested quantifiers) to identify unsafe regexes.
Pros:

safe-regex is fast.
safe-regex is an npm module which makes it easy to work with.
safe-regex has no non-JS dependencies.

As a result, safe-regex is great for CI use cases.
Cons:

safe-regex is incorrectly implemented and substack is not maintaining it.
safe-regex has lots of false positives (e.g. (ab+)+).
safe-regex will only identify one type of exponential-time vulnerability, and ignores all polynomial-time vulnerabilities. In my research I found that, in the wild, polynomial-time vulnerabilities are far more common than exp-time vulnerabilities.

There are some alternatives to safe-regex that report exploit strings so you can tell if they're correct or not.

Rathnayake's rxxr2. Like safe-regex, this only checks for star height-style vulnerabilities. But it doesn't have false positives as far as I can tell.
Wustholz's REXPLOITER. This tests star height and other exp-time vulnerabilities, plus poly-time vulnerabilities.
Weideman's RegexStaticAnalysis.  Like Wustholz's REXPLOITER, but open-source and it works better.

Unfortunately:

These alternatives all have non-JS dependencies (e.g. OCaml or Java) and have inconsistent interfaces.
Some (especially Weideman) can take minutes to test a single regex.

My project vuln-regex-detector provides a convenient wrapper for these alternatives, and enforces time and memory limits to get results or fail relatively quickly.
However, I'd be surprised if developers were willing to wait even 30 seconds for linting. To address that, I'm nearly done implementing a server side so queries can be answered by hitting the server for a pre-computed answer instead of doing the expensive computation locally. The server processes not-seen-before queries in the background so subsequent queries will get a real answer.
Once that's done, would you folks be interested in hitting my server first and falling back to safe-regex if my server hasn't seen the query before? I've got a sample client that can be used with a one-line tweak for this use case.

I'm happy to submit a PR with a demonstration if desired.

@davisjam You've updated safe-regex since submitting this and I plan to bring in that change.
For something that hits an external source I'd like it to be configurable or a different rule and clear as to what is sent to the remote server etc. A lot of people get nervous when code they are scanning starts to get sent to a remote destination, but having this capability would be nice. Would the server side be something that others could also run themselves?

@evilpacket the gist of it is probably all at https://github.com/davisjam/vuln-regex-detector/

Yeah I think best bet here is to not be sending anything to a remote server, and instead implement the caching stuff locally....
At least ask the person running this tool for permission when a new regex is being sent out

The server-side code is available, but would have to be run on the user's side.
Unfortunately the existing advanced analyses are written in Java and OCaml, not JS.
I have half a million labeled regexes, so I suppose another option is to ship this database in safe-regex in compressed form as a "cache" of sorts.

@davisjam is there a technical reason preventing the tools from being written in JS, or has that work just not been done by anyone?

@davisjam I will introduce my research MakeNowJust-Labo/redos.
This is a hybrid ReDoS detection library. "Hybrid" means, it combines automaton based detector and fuzzing based detector. When the RegExp pattern is hard to be checked by the automaton based, it switches to use the fuzzing based. This allows checking many patterns in the real world.
This library is written in Scala, but it is compiled to JavaScript by Scala.js. So, you can use this from JavaScript easily. In addition, I published eslint-plugin-redos for easy use. Feel free to try it!

@MakeNowJust Thanks for letting me know about it! Looks cool.
I looked over the documentation (not the implementation) but I'm not sure exactly what you've made. Are you building on the academic research on the topic (e.g. Shen for fuzzing, Weideman/Wustholz/Rathnayake for NFA analysis)? What guarantees does the library offer?

@davisjam I'm not sure the below may be an answer to you. Sorry that my English is poor.

Automaton based detector: It checks whether the pattern potentially causes catastrophic backtracking (exponential, and 2nd or higher degree polynomial matching time) or not. This detector is built on automata theory, like Weideman's RegexStaticAnalysis.
Fuzzing based detector: It finds a string in a limited size whose VM execution steps exceeds the specified limit by using the fuzzing technique. The VM is based on the QuickJS implementation, which is the simple and naive implementation of JS standard (ECMA-262).

More discussions are needed to conclude "what they detect are same.", but I believe both of them can find a vulnerability. And, each of them has pros and cons. For example, automaton based detector can find vulnerability precisely, however it is very slow on several patterns, and hard to support some syntax. On the other hand, fuzzing based detector can support all syntax, and we can control analyzing time easily, however it is hard to avoid false-negative. So, I think it is better to combine both.
Fuzzing based detector refers Shen's ReScue, but my implementation is very extended. In fact, ReScue cannot find a polynomial order case, but my implementation can in many cases.
I'm preparing a paper about this now. And, I'm going to talk about this at the 62nd programming symposium in Japan (I'll talk in Japanese, sorry). I'm planning to explain detailed ideas (detector selection algorithm, and fuzzing improvements) here.

@MakeNowJust Happy to discuss more over email -- I sent you a note a few days ago.

@nzakas would it make sense to replace https://www.npmjs.com/package/safe-regex with https://github.com/makenowjust-labs/recheck? ReCheck seems better maintained, but I am in no position to gauge if it is better or not nor if it is a smart choice to switch.

(I own safe-regex. It's very simple, not much to maintain).
ReCheck is employing a more sophisticated algorithm that, based on the docs, should have more true positives and fewer false positives compared to safe-regex.
ReCheck will be more time consuming to run.
One potential check is how ReCheck would perform on a regex heavy codebase (say, the marked project for markdown). Based on my experience with similar tools, a local cache might be helpful for on-workstation use. I'm not sure if ReCheck has one.
Get Outlook for iOShttps://aka.ms/o0ukef

From: Tobias Hernstig @.>
Sent: Monday, January 30, 2023 4:11:47 AM
To: eslint-community/eslint-plugin-security @.>
Cc: Davis, James C @.>; Mention @.>
Subject: Re: [eslint-community/eslint-plugin-security] Better unsafe regex detector (#28)
---- External Email: Use caution with attachments, links, or sharing data ----
@nzakashttps://github.com/nzakas would it make sense to replace https://www.npmjs.com/package/safe-regex with https://github.com/makenowjust-labs/recheck? ReCheck seems better maintained, but I am in no position to gauge if it is better or not nor if it is a smart choice to switch.
—
Reply to this email directly, view it on GitHubhttps://github.com/eslint-community/eslint-plugin-security/issues/28#issuecomment-1408232698, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFOD3L5BIMOYH2KTYM7KN7TWU6AVFANCNFSM4EYDDY7A.
You are receiving this because you were mentioned.Message ID: @.***>

@davisjam your original post indicated that https://github.com/davisjam/vuln-regex-detector would be a better choice than https://github.com/davisjam/safe-regex, that you are both maintainer of.
Your last post in this thread indicated you reached out to @makenowjust but that seem to never have concluded something in this thread at least.
The question is then, are both projects worthy replacements and the option should be on the user, or what would be the best fit for eslint-plugin-security?
I think most code bases uses very few regexes that the extra time needed should be low enough so that the one with the most true positives and fewest false positives would be the best one to use, but that is my subjective opinion. We benchmarked safe-regex vs recheck and we are only talking milliseconds for some of the more complex regexes in our tests, but they were not exhaustive.

The goal of the plugin is to try to catch as many problems as possible with as few false positives and false negatives as possible. Anything that moves us further in that direction is worthwhile to investigate.
That said, I'm not a security researcher, so I'd lean on the recommendations of folks like @davisjam to decide how to move forward here.

@nzakas neither are we, but we tested all of them and found the one by @makenowjust to have the least false positives, but granted we just tested a few regexes.

If you could share your findings in this thread, maybe we can get some folks to review them and verify.

Updated. @davisjam and @makenowjust can you double-confirm the above results?

We've seen false positives with the unsafe regex rule and named capture groups. Would it be possible to add a row to that table for regular expressions with named capture group(s)? E.g. ^(?<foo>(?:Foo|Bar))$ or maybe ^(?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})$

@jgeurts I tried to update the table a few days ago, but ran into bugs with both of the packages when trying again:
See:
https://github.com/makenowjust-labs/recheck/issues/758
https://github.com/davisjam/vuln-regex-detector/issues/81
I expect @makenowjust to fix the recheck problem, but I am not sure about vuln-regex-detector as the repository has very low activity.
Once I get some fixes, I plan to add a script in this issue that can be used to compare them. I will then add your regexes @jgeurts.

Thanks @thernstig! We will wait to move forward for that update.

Looks like @makenowjust has been able to resolve the issue in recheck 🥳 . I do not think I have time to resolve the issue in vuln-regex-detector.
FWIW The table of results ("expected result") in https://github.com/eslint-community/eslint-plugin-security/issues/28#issuecomment-1420883328 looks correct to me.

@nzakas @makenowjust @jgeurts I have updated the table. Scrutinize the code used to test if you have time.

Thanks so much! It does look like recheck is more accurate, but to get a true apples-to-apples comparison, I think we need to run checkSync instead of check for recheck. The check method is running asynchronously so the timing information isn't accurate.

check and checkSync are quite different: check forks the native recheck binary and uses it, but checkSync uses the pure JS implementation compiled by Scala.js. Thus, checkSync is often slower than check in the long term. However, since ESLint limitation, we cannot use check in ESLint plugin.

@nzakas @makenowjust updated the table with checkSync. Definitely the results became worse. Great if ESLint in the future can allow for async calls.
So changing will suffer quite a bit of performance, but be more correct.
@nzakas I assume it is up to you to decide now what to do with this information. Let me know if there are other packages and/or regexes you want added.

If asynchronous processing is a bottleneck for us, I think we might be able to use synckit.
https://github.com/un-ts/synckit

I assume that ESLint intends to allow for asynchronous processing sooner or later? Maybe better focus on fixing that?

Async rules in ESLint are still in the future, so we can't wait for that.
Unfortunately, I don't think we can use recheck right now considering how much slower it is. If it were just a little slower, that would be one thing, but in some cases it's an order of magnitude slower, and I don't think the tradeoff is worth it.

Let's see if @makenowjust can solve this as he is implementing synckit. If that improves the numbers using synckit is that acceptable @nzakas ?

If that can bring the numbers closer to safe-regex, then definitely. Although it might be worth the effort to see if we can improve safe-regex to be more accurate.

Looks like there is now also https://github.com/tjenkinson/eslint-plugin-redos-detector, using https://github.com/tjenkinson/redos-detector in case anyone is curious (or looking for alternatives). I haven't measured how redos-detector compares to recheck though.

authors: MakeNowJust MatthewHerbst davisjam devinrhode2 evilpacket jgeurts kurtextrem lirantal makenowjust nzakas ota-meshi thernstig

repo: nodesecurity/eslint-plugin-security


text:
Incorrect log when creating a WML model

2021-09-25 16:49:24,145 This model doesn't exist yet. Creating it...
2021-09-25 16:49:29,568 Model created.
2021-09-25 16:49:29,568 Model id: {model_id}

Fixed with f6959dd.

repo: nodet/dowml


text:
Only handle top-level expressions

This is more for discussion than anything – I couldn't spend long on it so no tests yet, sorry!
@stefanpenner has been doing some research on this topic and found that the lazy parse heuristic only applies at the top level. I wondered if we could exploit that here and avoid having to walk the entire AST. As a bonus, we'd save a few bytes on parens that would (in theory) have no effect.
To do so I swapped out walk-ast for estree-walker (full disclosure, it's one of mine) which makes it possible to skip subgraphs. We get a little speed bump just from doing that, because estree-walker doesn't mutate the AST in any way (i.e. adding the parentNode property), but the real boost is from doing less work. (It would also fix #3.)
Example results:
➜  optimize-js git:(master) time lib/bin.js benchmarks/ember.js > /dev/null
lib/bin.js benchmarks/ember.js > /dev/null  0.65s user 0.08s system 106% cpu 0.689 total
➜  optimize-js git:(master) git checkout speedup
Switched to branch 'speedup'
Your branch is up-to-date with 'origin/speedup'.
➜  optimize-js git:(speedup) time lib/bin.js benchmarks/ember.js > /dev/null
lib/bin.js benchmarks/ember.js > /dev/null  0.47s user 0.05s system 117% cpu 0.437 total

So optimisation is ~25% quicker in Ember's case with this PR.
I ran the benchmarks on Chrome, and the improvement went from 55.75% to 53.62%. So it looks like there's a slight drop in parse time but I don't know if it's significant. More investigation needed probably!

Awesome, thanks! My hunch is that this PR is great, no preference for walk-ast or estree-walker on my part (side note: does it fix #3 ?). Only thing is:

we need to bench more, obviously. the benchmark itself has a margin of error (up to 5% or so), needs to be run a couple times to be sure (or maybe I need to up the median in the bench)
we need to bench in more than one browser, assumptions based on V8 do not necessarily apply to Chakra or SpiderMonkey or JSC

So optimisation is ~25% quicker in Ember's case with this PR.

Just re-read this, you mean optimize-js itself is 25% faster? TBH I care less about the amount of time it saves for the developer than the time it saves for the user... If we lose ~2% perf then should we really only manipulate at the top level? Unless there's another example of a library that causes perverse perf problems with the deep wrapping (in which case it should be added to the bench btw :)).

@stefanpenner has been doing some research on this topic and found that the lazy parse heuristic

The vernacular is nuanced, let me clear it up (or at-least to my current understanding)lazyParse in v8 land, is more or on-demand parse. So when v8 encounters code it has not yet parsed (or maybe needs to parse again) i believe it is a lazyParse.
What I spoke to @Rich-Harris about last night, was specifically  about v8's pre-parse (Although I may have mis-spoke) , which I believe to be top-level only concern only. When first parsing a file, V8 appears to attempt to more quickly "skim" parts of the js file, it believes to not be required for initial evaluation.

@stefanpenner is this newer than what I did?  Last time I looked, there were 2 kinds of lazy parsing, and yes, one of them is only at the toplevel, and pretty much just using leading paren but there is a laziness at deeper levels, it has more heuristics though but still uses leading paren as an initial hint, and is more about whether to compile the function.

@krisselden nope nothing new.

So LazyParse and preParse interact with each other. If a code segment does not have the heuristics which implies it is required immediately, it will be quickly skimmed via the preParse phase. Then later when it is actually encountered via execution it will be lazy parsed + lazy compiled.
I am most likely still getting the various names in-correct. So give me the benefit of the doubt ;). But I believe what I described to be more or less accurate.
But we should likely pull in someone like @bmeurer who actually knows what he is talking about.

Just re-read this, you mean optimize-js itself is 25% faster?

Yep. Totally agree with your priorities – this PR was predicated on the heuristic being top-level only. If that's not the case then this.skip() shouldn't be used. (It'll still be a little bit quicker, just not as much.)
Re #3 – yeah, just checked, it fixes it. estree-walker doesn't know anything about node types, so it's resistant to changes in the language (e.g. async/await/whatever's in ES2019/20/21).

I'd suggest to ping @verwaest about this, he's clearly the expert in this particular V8 area currently.

@Rich-Harris @nolanlawson The left paren is still a heuristic used for lazy compile but I'm not sure this is as slow as the lazy parse but could make a difference.  https://cs.chromium.org/chromium/src/v8/src/parsing/parser-base.h?sq=package:chromium&rcl=1474312969&l=3138
I'm pretty sure that the biggest win is avoiding the fast function body skip at the top level for something eager (though this is the biggest win for a define() that isn't used).

more detail in this comment https://cs.chromium.org/chromium/src/v8/src/parsing/parser.cc?q=eagercompile&sq=package:chromium&dr=C&l=2880

To clarify more, the left paren is a hint to parse eager but it doesn't mean it will compile it eager.
The top level uses the preparser  https://cs.chromium.org/chromium/src/v8/src/parsing/preparser.cc?q=LPAREN&sq=package:chromium&dr=C&l=336

Hey folks, I'm a bit swamped this week due to TPAC, but just some quick thoughts:

Whether the top-level or mid-level is different or not in V8, I would like to bench it and see the improvement/regression for the scripts in the benchmark. If someone thinks the benchmark isn't representative, then let's add more scripts to the benchmark; I basically just grabbed libraries at random (for those wondering why PouchDB is in there ;))
As always, let's test multiple browsers. Haven't heard anything from Chakra folks suggesting that top-level is any different from elsewhere, but will follow-up. For those interested in how this looks in the Chakra stacktraces (and maybe wants to dig deeper), here's a high-level analysis I did.
My suspicion is that top-level may natural be a better optimization because inner-level is more likely to contain things we don't want to paren-wrap, such as addEventListener(), on(), etc.

We're working on fixing this performance difference and additionally making the top-level heuristic mostly unnecessary, and the nested heuristic completely unnecessary.
What's going on here? V8 has a preparser and a parser. The former is roughly 2x the speed of the latter. Unfortunately the preparser doesn't at this time support scope resolution, so we can only really use the preparser when parsing top-level functions. When we fully parse anything else then the top-level script, we need to fully parse nested functions. That's 2x slower than would be preparsing. Ouch. Additionally, we don't keep info around about functions we have ever parsed or preparsed. Hence whenever we parse a nested function, we have to fully parse deeper nested functions again. O(n) ouch!
We're working on fixing both issues, which will take a bit of time however.
Once we're done, we can skip over nested functions essentially for free, so an eager compile heuristic at that level makes little sense. No heuristic means we can't be wrong, yay. At the top-level we might still want it, but it's less relevant, especially since all nested functions will be skipped anyway.
I hope this sheds some light on the issues and what we're planning on doing about it.

authors: Rich-Harris bmeurer krisselden nolanlawson stefanpenner verwaest

repo: nolanlawson/optimize-js


text:
Swiper autoplay flicker on breakpoints

Check that this is really a bug

[X] I confirm

Reproduction link
https://codesandbox.io/s/bug-autoplay-responsive-c7hqly
Bug description
I have an app that wants to have different autoplay behavior on mobile and in desktop. In desktop, I want it to be disabled, but on mobile, I want it to be autoplay.
But, there is a catch where if I change my (simulated) phone from potrait to landscape, or just swiftly change breakpoints from autoplay:true to autoplay: false, the autoplay behavior start to break(?)
Here's the demo of how it breaks:
https://github.com/nolimits4web/swiper/assets/144311627/b920cb61-8b9c-4c2a-9527-2cc70765dc1f
Expected Behavior
The autoplay is not broken when I change from autoplay: true to autoplay: false
Actual Behavior
The autoplay is broken when I change from autoplay: true to autoplay: false
Swiper version
10.3.1
Platform/Target and Browser Versions
macOS Chrome 117.0.5938.132
Validations

[X] Follow our Code of Conduct
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
[X] Make sure this is a Swiper issue and not a framework-specific issue

Would you like to open a PR for this bug?

[ ] I'm willing to open a PR

Autoplay can't be enabled/disabled in breakpoints, use autoplay.start/stop methods instead


text:
Suggestions for API additions

Hello sir,
Good job on crop!
I was considering using it in my toy editor, however I found out looking around in the API that some things I like in ropey are missing here:

Rope::is_instance
Rope::from_reader and Rope::write_to
RopeSlice::as_str and From<RopeSlice> for Cow<str>
design.md

Things not in ropey I'd love to use:

Iterators (esp. Chunks) with offsets (see this)
byte <-> (line, col) (see this)

What are your thoughts about those API additions? Would you be open to PRs?
Thanks

Thanks!
Rope::is_instance: I'm open to adding this. What's your use case?
Rope::from_reader: No, this is usually highly custom to the editor (e.g. Helix doesn't use this) and Ropey's implementation is really just a placeholder;
Rope::write_to: No because a) I'd be weird to have this without having its read_from counterpart, and b) it's 4 lines long;
RopeSlice::as_str: what's your use case? In general you should just assume that a Rope{Slice} has multiple chunks, I don't see the benefit in special casing that logic. Also, unlike Ropey, crop uses gap buffers instead of contiguous strings so your Rope could literally have 2 characters and it could still return a None;
design.md: this is something that I'd like to write but probably won't have the time to any time soon (never?). The memory layout of crop's B-tree is very similar to Ropey's, except the internal nodes use a Vec to store their children instead of a fixed size array (turns out using an array is not any faster and just introduces some more unsafe).
The B-tree's invariants are also identical, except in crop CRLFs can be split across chunks.
complex iterators: I could be open to add something like a ChunksInfos iterator that returns (bytes, lines, chunk): (usize, usize, &str) but I'm not sure it's worth the increased surface area in the API.
byte <-> (line, col) (where by col I'm assuming the byte offset in that line): No, you can easily implement an extension trait on crop::Rope that does this using Rope::line_of_byte and Rope::byte_of_line.

Hello

Rope::is_instance: it is part of my checks to skip rendering.
Rope::from_reader, Rope::write_to: I'll look into Helix then.
RopeSlice::as_str: my st*pid shaping code requires contiguous strs (for ligatures), segmentation algorithms may as well. Maybe one can implement this with the public API, without much overhead.
ChunksInfos: maybe I'm the only one to like this idea...
byte <-> (line, col) (yes): an internal implementation wouldn't be ~twice as pretty fast?

Thank you!

is_instance: I'm accepting a PR for this if you want to have a go at it, It should be simple to implement;

as_str: the segmentation algorithms in unicode-segmentation don't require contiguous strings. If you still want that functionality you can use the Chunks iterator: if it returns 1 chunk it's contiguous, if it returns more it isn't.
In the second case, if you need to get a contiguous string around a chunk boundary (and you know the byte offsets) you
can do rope.byte_slice(start..end).to_string();

byte <-> (line, col): yes but those methods are fast enough that it doesn't matter, it's not worth the increased API surface.

CharIndicies would be nice, given this is what we are left to support Nom: https://doc.rust-lang.org/beta/core/str/struct.CharIndices.html

@stevefan1999-personal what is the use case for CharIndices? It could easily be implemented by 3rd parties by wrapping Chars.

@stevefan1999-personal what is the use case for CharIndices? It could easily be implemented by 3rd parties by wrapping Chars.

I'm trying to implement nom traits for crop but I guess I will try around it

Author of Ropey here.  I just want to chime in about a couple of things.
@noib3 wrote:

Rope::from_reader: No, this is usually highly custom to the editor (e.g. Helix doesn't use this) and Ropey's implementation is really just a placeholder;
Rope::write_to: No because a) I'd be weird to have this without having its read_from counterpart, and b) it's 4 lines long;

Even in Ropey, Rope::from_reader and Rope::write_to are only intended as convenience methods for people who are knocking something out quick in less serious or throw-away projects.  Neither of them are intended for serious usage, and it's expected that any serious editor project will instead roll their own solutions based on RopeBuilder and the Chunks iterator, respectively.
In particular, both of those methods are opaque, which means (among other things):

You can't query how much data has been read/written so far, so you can't provide any kind of progress bar for the end user with large files.
You can't abort them (e.g. if you're in the middle of a read/save, and the user cancels).
You can't process the text data as its read/written, for e.g. converting text encoding on the fly.  This is critical for supporting reading/writing non-utf8 text files.

So I think it's perfectly sensible for crop to not support these methods.

RopeSlice::as_str what's your use case?

This one actually is useful.  There are various situations where if it is a contiguous string, you can do something more efficient, and otherwise you fall back to less efficient code that doesn't rely on it being contiguous.  This especially comes up in rendering/shaping code.
From<RopeSlice> for Cow<str> is similarly useful, but ensures that the string data is contiguous for the client code by copying it into a contiguous buffer if its not.  So it's more ergonomic, but may not be ideal if you have a fallback for split text that doesn't require copying.
Having said that, both of these can essentially be implemented by client code (though perhaps slightly less efficiently).  So it's certainly not a critical API.  But unlike certainly other APIs in Ropey, I actually do think these two have really pulled their weight.

Can we get non-panicking variants of the functions?

What about replace with other ropes without having to turn it into a string, i.e. rope merge?

Can we get non-panicking variants of the functions?

Yes, there's a PR open for it that I've yet to review, but I'm open to the idea.

What about replace with other ropes [..] i.e. rope merge?

Probably not, like Rope::append(&Self) this is something people very rarely (never?) need, but I'd be interested in hearing your use case.

without having to turn it into a string

You don't have to allocate to do this, you can call Rope::chunks() and call Rope::replace() multiple times.

@noib3 but what is a chunk? I need to know this because I'm implementing a preprocessor and I have some #ifdef blocks which might overwrite contents.

repo: nomad/crop


text:
fix unchecked block by upgrading @solidity-parser/parser

fix #77

@alcuadrado can we merge this please?

@alcuadrado
This hasn't been merged yet. Please it is necessary as I'm having a hard time flattening my smart contracts

@kingsley-einstein this works
  npx github:fedeb95/truffle-flattener ./myContract.sol > ./flattened.sol

npx github:fedeb95/truffle-flattener ./myContract.sol > ./flattened.sol

thank you so much you just saved my hours of scrating head

Please merge this. This would be a life saver

authors: ashishmjn edTheGuy00 fedeb95 jplew kingsley-einstein sanchitdawarsd

repo: nomiclabs/truffle-flattener


text:
Remove MONGO_RS_URL related code

Remove MONGO_RS_URL related code

MONGO_RS_URL is related to the old HA implementation. It affects a lot more than just connecting to mongo, and is not relevant anymore. It should not be used, and we should ignore it in the code

authors: dannyzaken liranmauda

repo: noobaa/noobaa-core


text:
Symfony Yaml::parse File input deprecated

Deprecated: The ability to pass file names to the Symfony\Component\Yaml\Yaml::parse method is deprecated since version 2.2 and will be removed in 3.0. Pass the YAML contents of the file instead

Recommend just adding a file_get_contents for the file and feed the returned text into the method.

Thank you very much for bringing this to our attention :+1:

authors: hassankhan jenolan

repo: noodlehaus/config


text:
Update README.md

This is only for Hackertobest competition.

Please help me to win the competition.

repo: norbsoft/android-typeface-helper


text:
Cannot read properties of null (reading 'scrollToIndex')

Hi how are you?
I'm using "@nosferatu500/react-sortable-tree": "^4.4.0",
with react & react-dom version ^18.2.0
TypeError Cannot read properties of null (reading 'scrollToIndex') in
node_modules/@nosferatu500/react-sortable-tree/index.js
Can you help us with this error.

Hello! I just checked it on my end and I don't have any issues.
Can you provide a sandbox example with the issue reproduced?

When the react sortable tree is mounted and when clicked on tree node, thats when the issue occurs.
Also we havent passed virtuosoRef to react sortable tree.
As we havent passed virtuosoRef  prop, there should not be any need of scrollToIndex from this.listRef.
This issue doesnt occur frequently but once in 5 times.
We have attached video demonstrating the  occurence of issue.
if (searchFocusTreeIndex !== undefined) {
this.listRef.current.scrollToIndex({
index: searchFocusTreeIndex,
align: 'center'
});
}
can u add scrollToIndex check in the above if condition.
https://github.com/nosferatu500/react-sortable-tree/assets/63661306/1da5cacb-59b6-48af-bd3b-ad7959fc8456

Should be fixed in v5, but it's still in alpha.
npm i @nosferatu500/react-sortable-tree@5.0.0-alpha.5


text:
一个url引发的问题

http://miniwing.com/UserCentralSystemApi/api/user/avatar/download/7bc1dd305a6b4defb4a14a07d7b8af46/8ac63c9d2404fae0ba52e96da2cd0220  这个url 可以再浏览器打开，自己写的下载程序也能正常下载到图片文件 但是在使用框架的时候始终无法正常显示 跟踪源码发现打开这个链接的时候读取不到流

8798-24497/com.nostra13.universalimageloader E/ImageLoader﹕ failed to connect to lh6.googleusercontent.com/216.58.197.97 (port 443) after 5000ms
java.net.SocketTimeoutException: failed to connect to lh6.googleusercontent.com/216.58.197.97 (port 443) after 5000ms
at libcore.io.IoBridge.connectErrno(IoBridge.java:159)
at libcore.io.IoBridge.connect(IoBridge.java:112)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:192)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:459)
at java.net.Socket.connect(Socket.java:842)
at libcore.net.http.HttpConnection.(HttpConnection.java:76)
at libcore.net.http.HttpConnection.(HttpConnection.java:50)
at libcore.net.http.HttpConnection$Address.connect(HttpConnection.java:340)
at libcore.net.http.HttpConnectionPool.get(HttpConnectionPool.java:87)
at libcore.net.http.HttpConnection.connect(HttpConnection.java:128)
at libcore.net.http.HttpEngine.openSocketConnection(HttpEngine.java:315)
at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.makeSslConnection(HttpsURLConnectionImpl.java:461)
at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:442)
at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:289)
at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:239)
at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:273)
at libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
at libcore.net.http.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:134)
at com.nostra13.universalimageloader.core.download.BaseImageDownloader.getStreamFromNetwork(BaseImageDownloader.java:117)
at com.nostra13.universalimageloader.core.download.BaseImageDownloader.getStream(BaseImageDownloader.java:88)
at com.nostra13.universalimageloader.core.LoadAndDisplayImageTask.downloadImage(LoadAndDisplayImageTask.java:291)
at com.nostra13.universalimageloader.core.LoadAndDisplayImageTask.tryCacheImageOnDisk(LoadAndDisplayImageTask.java:274)
at com.nostra13.universalimageloader.core.LoadAndDisplayImageTask.tryLoadBitmap(LoadAndDisplayImageTask.java:230)
at com.nostra13.universalimageloader.core.LoadAndDisplayImageTask.run(LoadAndDisplayImageTask.java:136)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
at java.lang.Thread.run(Thread.java:856)
官方demo 也会超时

访问超时了，这是网页那头的错误，你可以考虑设置一下超时时间。
ImageLoaderConfiguration的imageDownloader

我也遇到这个问题，设置超时时间也没有用

@channel
Anybody found solution now for above issue?
I faced same issue on following URL.
https://i1.sndcdn.com/avatars-000118160419-u2ii1a-large.jpg
https://i1.sndcdn.com/artworks-000096618343-fgxk04-large.jpg
Specially, this issue was occurred on Android 5.0+, I think there is some issue on HTTPS images.


text:
Outbox tracker (positive interoperability)

Overview: outbox refers to the technical implementation of finding events of interest not found on the relays user is subscribed to.
Benefit:

non-💩 user experience (missing events; missed opportunitues for excellent, positive interactions
improved censorship resistance

app
Outbox
inbox
comment

damus
❌
❌
planned

amethyst
?
?
?

coracle
✅
✅
?

nostrudel
?
?
partially implemented. Nostriga hzrd & elsat outbox workshop to be posted soon

nostur
?
?
?

primal
?
?
unique/first to nostr indexer approach used today

voyage
✅
✅
?

gossip
?
?
?

openvibe
?
?
?

lume
?
?
?

ditto
?
?
?

nostter
?
?
?

nosotros
✅
✅
?

highlighter
?
?
?

yana
?
?
?

nostrmo
?
?
?

comingle
?
?
@tyiu

nostrSDK
?
?
@tyiu

Iris
?
?
@mmalmi

wikifreedia
?
?
?

wikistr
?
?
?

yakihonne
?
?
?

snort
?
?
?

zap.stream
?
?
?

nostr,nests
?
?
?

dtan.xyz
?
?
?

fountain
?
?
?

wavlake
?
?
?

NDK
✅
✅
?

shopstr
✅
✅
?

Also see https://github.com/nostrability/nostrability/issues/42
https://github.com/nostrability/nostrability/issues/21

@staab do you have a singular place where you have described your approach to, philosophy of, and learnings from outbox implementation?
Based on discussion at nostriga, such a resource will be useful to hear about the tradeoffs of various implementations and philosophies.
I have volunteered @pablof7z to share his approach in a future call (and ideally discussion with devs yet to implement) on the topic, in continued discussion with @hzrd149 from Riga.

Future placeholder question: is it technically possible to measure the effectiveness of various outbox implementations, as measured by notes not found?

@tyiu if you were to conjure outbox implementation on nostrSDK tomorrow, which / how many apps from the list could consider adding your approach?

@pablof7z does NDK have outbox? If yes, which apps are candidates to add?

@mikedilger what is your approach to outbox?

Voyage yes ✅

@pablof7z does NDK have outbox? If yes, which apps are candidates to add?

Yes. Outbox support was why I released NDK in the first place.
Highlighter, nutsack, wikifreedia, etc, anything I've built and anything that uses NDK has outbox support

Shopstr supports this!

Nosotros supports, you can also enable/disable it on the UI

@mikedilger what is your approach to outbox?

https://mikedilger.com/gossip-model/
Via il_lost_ on nostr

Gossip keeps track of a score for each relay as associated to each person and ranks them whenever it needs to select a relay for fetching posts from one person:
fiatjaf, [7/12/24 12:42 PM]
I remember gossip had an sqlite table mapping all relays to all pubkeys
fiatjaf, [7/12/24 12:43 PM]
and the latest timestamp in which each had been seen in relay lists, hints and nip05
fiatjaf, [7/12/24 12:43 PM]
something like that, right?
Mike Dilger, [7/12/24 4:36 PM]
The table is called person_relay.  https://github.com/mikedilger/gossip/blob/unstable/gossip-lib/src/storage/types/person_relay2.rs
Mike Dilger, [7/12/24 4:42 PM]
It has been simplified though.  Gossip now considers kind 10002, kind 3 contents, and nip05 relays as equivalent authoritative statements so they aren't separate fields.  And if the association was some other lesser way we remember when it got associated, and also when we last fetched an event from them off of that relay.  These are used to score the relay.  When we need a read or write relay for them we pick starting from the highest score.

This is similar to the approach used in https://github.com/nbd-wtf/nostr-sdk -- although for now I only keep these scores in memory and they die when the app is restarted (it's being used by njump.me only for now).
In both cases the scores are given by stuff like the following (in order):

seeing the relay listed in an authoritative kind:10002 event
having received an event from that person from that relay (weighted by last time when that was attempted and event created_at)
having seen the relay associated with a person's pubkey in a NIP-05 response, NIP-19 code or relay hint

I'm curious about how exactly Nosotros and Voyage do it.

Voyage stores kind:10002 and event relays to determine which relays to select. In this case event relay just means the relay an event has first been seen on. When fetching the feed, each pubkey gets mapped to a max of 2 relays: one from kind:10002 and the other is the most used event relay by that pubkey.

Nosotros also have a similar person_relay table that I put relays that I found from kind 10002, kind 3 and nip05, the client will always use the logged user relays as the fixed relays and will search each pubkey relays that doesn't intersect with the fixed_relays.
I treat relays as observables, therefor I can start a subscription without even knowing which relays will be used, and discover new relays on the fly as the subscription goes.
const sub = new NostrSubscription({ kinds: [0], authors: ['1', '2', '3', '4', '5'] }, {
  relays: of(['wss://relay1.com', 'wss://relay2.com']), // fixed relays
  outbox: () => {
    // pseudo-code, this actually fetches the userRelay table.
    return from([
      of(['wss://relay3.com', [{ kinds: [0], authors: ['3'] }]]).pipe(delay(500)),
      of(['wss://relay3.com', [{ kinds: [0], authors: ['4'] }]]).pipe(delay(500)),

      of(['wss://relay4.com', [{ kinds: [0], authors: ['4'] }]]).pipe(delay(1000)),
      of(['wss://relay4.com', [{ kinds: [0], authors: ['5'] }]]).pipe(delay(1000)),

      of(['wss://relay5.com', [{ kinds: [0], authors: ['5'] }]]).pipe(delay(2000)),
      of(['wss://relay6.com', [{ kinds: [0], authors: ['5'] }]]).pipe(delay(3000)),
    ]).pipe(mergeAll())
  },
})

of(sub).pipe(start(pool)).subscribe()

// wss://relay1.com { kinds: [0], authors: ['1', '2', '3', '4'] }
// wss://relay2.com { kinds: [0], authors: ['1', '2', '3', '4'] }
// 500ms
// wss://relay3.com { kinds: [0], authors: ['3', '4'] }
// 1000s
// wss://relay4.com { kinds: [0], authors: ['4', '5'] }
// 2000s
// wss://relay5.com { kinds: [0], authors: ['5'] }
// 3000s
// wss://relay6.com { kinds: [0], authors: ['5'] }

The stream is closed when all the relays emit a EOSE event and the relay stream is also closed, this is also very easy to unit test too.

For those who have implemented, in what conditions does your algo fail in finding an event?
Has anyone measured and compared the success/failure to find rate across different implementations?

Which of yall ping a relay service like purplepag.es in the event search process?

@staab do you have a singular place where you have described your approach to, philosophy of, and learnings from outbox implementation?

Not exactly, but here are a few related blog posts:

https://habla.news/u/hodlbod@coracle.social/1700155417145
https://habla.news/u/hodlbod@coracle.social/sfwV1rNaoQXd65PbIMYgm

The "Outbox" model is really a subset of "relay selection". Most scenarios people talk about are centered around pubkey-based feeds, but there are a lot of different scenarios detailed here, many of which don't yet have first-class support. There are also relay selections based on NIP 72/87 group configuration and NIP 29 home relays. You can find the majority of my code for relay selection here.
Some gotchas I've run into:

Large follow lists get rejected by a single relay. This is ok when using outbox, because you can split up requests and route them to users' NIP 65 relay lists. The downside of this is that you end up making a lot of connections, many of which are to defunct relays, or stale relay selections. To mitigate this, I use a max connections per request setting, which takes the long tail and adds those pubkeys back into the top 10 or so relays. This reduces the utility of personal relays unfortunately, since they won't often be selected by Coracle. Ideally, this distribution would be handled by users picking 1 hub relay and 1 edge relay. Hubs can be trusted to get most people's content. People who are deplatformed would choose another hub, or in extremis only personal relays. This would leave room for thin clients to select the correct relay for all pubkeys.
Keeping stats is essential for good relay selection, because many relays are defunct and simply won't connect. There's no point continuing to try connecting to relays that won't respond, or have denied client authentication. Coracle doesn't currently go beyond this, but it would also be helpful to catalog which relays respond to requests for particular scenarios, and stop connecting to ones that don't return any data. You could also monitor relays for bad behavior, like returning events with an invalid signature, and stop connecting to those.
Another thing that would help manage this would be for clients to maintain black/white lists for relays that users have explicitly allowed their client to connect to, or AUTH with. When connecting to a new relay, clients would ask users if that url is ok. The user can then choose to approve or deny the connection. However, I think this is probably an unworkable UX, and clients will have to rely on more heuristics to avoid nagging users.
One major omission of outbox right now is that relay selection changes aren't handled, in any case that I know of. When selecting new relays, clients should perform some sanity checks, like successful connect/auth/publish/req or listen for any NOTIFY or NOTICE messages, and notify users if their access to the given relay is limited. This would reduce the number of broken relay selections. When migrating, client should also copy a user's events from their old selections to the new relay, which is especially important if the user is removing old relays from their list (in which case we should probably have a way to request soft delete on a given relay for a user's content so users can avoid leaving a mess behind them). Otherwise, people asking the new relay for the user's content will be missing historical content.

Future placeholder question: is it technically possible to measure the effectiveness of various outbox implementations, as measured by notes not found?

Yes, but it would be very complex, and would require a driver for each implementation.
One other thing on this topic is that I think relays should exercise some agency in what use cases they support, and it's important that they be able to signal this somehow. This could be via the supported_nips field, NIP 66, or just in their nip11 description field. But this stuff should be surfaced for users so they they can know what particular relays are good for and how to get access. User relay selection is upstream from client relay selection, but is really important if we want clients to be able to make meaningful relay selections. If you choose 140.f7z.id for long-form posts (for example), you're going to have a bad time.

Just wrote this up partly in response to your question. It's a little more of an explainer, but it might be helpful. https://coracle.social/nostr:naddr1qvzqqqr4gupzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqq2nskt2w9vx6dznfdvj64rpw4mk5nmxf3v9xsd0gdy

@mikedilger what is your approach to outbox?

Sorry my head has been deep inside of a compiler.  But I think the others answered for me pretty well.
If a user doesn't publish a kind-10002, we fallback to other guesses that are ranked, finally falling back to the gossip user's read relays (you can configure very popular read relays as a fallback, e.g. the damus relay, etc).
Gossip follows people at 2 or 3 (configurable) relays that they use, not at all the relays that they use, so that not too many events come flooding in.  It has to assign people to relays and tries to minimize relay connections when making that assignment.

Nostur currently supports outbox + inbox, but connecting to random relays is limited to people you follow or included relay hints.

@yukibtc let us know when outbox on rust-nostr is ready 💪💪

trimmed down app list, and added outbox visual explainer https://how-nostr-works.pages.dev/#/outbox

https://njump.me/note1rxek06r7nrd4g329uvffmnx2gpcl50kuqv37h7nkpfjy3gmevqcsgduug8
@arkin0x asks what "outbox bootstrapping relays" yall used

outbox model meme dropped by @ser-sleepy
https://github.com/user-attachments/assets/ffc898b9-a549-4337-81b0-322c4ae4efc4

@pablof7z on relay hints:

relay hints are what ties a decentralized nostr together

if I reply to your note that I found on relayA, I can publish my response to relayA but also to my outbox relay relayB; people that follow me and ask for content on relayB see a response from me to an event NOT present on relayB, but because of the relay hint, they know they can get the OP from relayA.
Now

https://njump.me/note1827hwhk5ctwd6033fkcw5s67w9u2uffmxgrhlzvs0lmvuhay9r6qwmh8nr

Added yakihonne

https://pub.dev/packages/ndk
https://github.com/relaystr/ndk/tree/master/packages/ndk
Dart NDK also has outbox gossip support.
It is used by:
https://github.com/frnandu/yana
https://github.com/leo-lox/camelus

authors: alltheseas calvadev cesardeazevedo dluvian fabianfabian fiatjaf frnandu mikedilger pablof7z staab

repo: nostrability/nostrability


text:
Coffee script bare and no-prompt option

Will be used in  https://github.com/willwhitney/hydrogen

looks great

authors: jaredly terraqout

repo: notablemind/jupyter-nodejs


text:
Add Feynman Zhou as notaryproject maintainer

Add Feynman Zhou (@FeynmanZhou) as a seed maintainer of notaryproject based on their activity as per - https://github.com/notaryproject/notaryproject/issues/224
Signed-off-by: Yi Zha yizha1@microsoft.com

LGTM but IANAM

LGTM but IANAM

Close as aggregated PR https://github.com/notaryproject/notaryproject/pull/240 was merged.

repo: notaryproject/notaryproject


text:
feat: Implement Blob Verify

This PR Implement Blob Verify.
**Note: Blob PR/Code is ready for review; will continue to work on adding more UTs **

Codecov Report
Attention: Patch coverage is 62.42038% with 118 lines in your changes are missing coverage. Please review.

Project coverage is 73.32%. Comparing base (9ff1891) to head (165867b).
Report is 12 commits behind head on main.

Files
Patch %
Lines

verifier/verifier.go
45.37%
57 Missing and 2 partials :warning:

verifier/trustpolicy/blob.go
0.00%
43 Missing :warning:

verifier/trustpolicy/oci.go
90.69%
4 Missing and 4 partials :warning:

notation.go
87.50%
2 Missing and 2 partials :warning:

verifier/trustpolicy/trustpolicy.go
90.47%
4 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #394      +/-   ##
==========================================
- Coverage   73.43%   73.32%   -0.11%
==========================================
  Files          24       32       +8
  Lines        2507     2298     -209
==========================================
- Hits         1841     1685     -156
+ Misses        526      465      -61
- Partials      140      148       +8

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

authors: codecov-commenter priteshbandi

repo: notaryproject/notation-go