Additional fixes/tests for irreversible mode

PR #6624 made changes to enable irreversible mode to work.
However, that code does not support various corner cases of irreversible mode and particular switching to and from different modes.
-) Replaying in irreversible mode does not work properly. Duplicate blocks problems are encountered in the fork database if there are reversible blocks available to replay.
-) Even without reversible blocks, replay does not end with the latest irreversible considered as the last_irreversible_block.
There are also likely issues with switching between irreversible mode and speculative mode without a replay.
-) It should be possible to cleanly shutdown nodeos running in speculative, head, or read-only mode, and then start nodeos up again without a replay in irreversible mode.
-) It should also be possible to cleanly shutdown nodeos running in irreversible mode, and then start nodeos up again without a replay in speculative, head, or read-only mode.
The code changes supporting the above behaviors should also be accompanies by additional automated tests:

A test that shuts down a controller in speculative mode and then restarts it in irreversible mode. After startup, the fork DB pending head should be the same as before and the state should be at the irreversible block height which should be the same as what it was when the controller was originally shut down.

A test that shuts down a controller in irreversible mode and then restarts it in speculative mode. After startup, the fork DB pending head should be the same as before and the start should have automatically replayed the reversible blocks that were available in the saved fork database.

A test that shuts down a controller in speculative mode and then restarts with a forced replay in irreversible mode. The replay should only go up to the last irreversible block. However, the reversible blocks should still be added to the fork database. The pending fork DB head should end up being the same as what it was before the controller was originally shutdown. The state should remain at the irreversible block height which should be the same as what it was when the controller was originally shut down.

A variant of test 3 in which after shutdown but prior to restarting the reversible blocks database is removed. In this case after resuming the controller with a forced replay, it should replay up to the last irreversible block, which should be the same as what it was when the controller was originally shut down. However, this time the pending fork DB head should just be pointing to the root, which represent the last irreversible block.

The tests above should first change producers from eosio to at least four producers and producer enough blocks for the active schedule to switch over and then some more so that the blocks of the new producer round become irreversible, prior to shutting down the controller.
These combinations should also then be tested with actual nodeos instances rather than only building tests using the unit testing framework.

I played a bit with the irreversible mode, especially with replaying blocklog. Besides other issues it seems that nodeos in irreversible mode leaks GBs of memory.

when would the irreversible mode feature be available? suppose replaying in irreversible mode would in crease the replaying speed, right?

Based on the above description, 8 test cases are added in #6843

Additional test case:

Generate some blocks with a multiple producer schedule (its fine if all producers are on the same node). Backup the blocks directory.
Switch to irreversible mode successfully. Make sure the head block is correctly pointing to the LIB. Take a portable snapshot.
Switch to a clean data directory and copy over the backup blocks directory. Then start nodeos from the portable snapshot in speculative mode. Ensure it automatically replays the reversible blocks.
Allow more blocks to be generated for the nodeos from step 3 such that LIB advances. Then cleanly shut down that nodeos.
Restart the nodeos once again from the same portable snapshot that was taken earlier. Ensure it automatically replays some of the irreversible blocks as well as the reversible blocks.

Resolved by #6842 and #6843.


[feature] Parse Full Name in Profile Settings for Citations Preview [OSF-8237]

Purpose

Generate a citation preview with the full name (if possible) when a user hasn't filled in their first name, middle name, last name, or suffix.
Changes

Changes to website/static/js/profile.js:
-- Added a parseName function to osfHelpers
-- Added conditions to citeApa and citeMla that use parseName as a last resort for generating a citation preview
Before:

After:

Side effects

None known.
QA Considerations
Parsing data from an open input field into a structure is interesting.
What if the person has more than a single first, middle, and last name?
What if the person has special characters in their name?
What if the person has a suffix, but no middle name?
What if the person has a suffix and a middle name?
This implementation will seperate out names by spaces. The first item it finds will always become the first name. If the second item it finds looks like a suffix (contains a period or is in a list of common suffixes) it will become a suffix. If it doesn't look like a suffix it will become a last name. Any names found after that are assigned to be a middle name.
Current list of suffixes:
'jr','jnr','sr','snr','dr','phd','i','ii','iii','iv','v','md','esq'
Ticket

https://openscience.atlassian.net/browse/OSF-8237

Drive-by: since osfHelpers.js is already using ES5, and the new code isn't using ES6 features other than let and const, let's keep the file consistent in ES5 and remove the extension. No need to add extra compilation work if it's not providing a lot of value.


[pybind11] Triton compilation fails with Clang due to old pybind11

Problem
Compiling Triton with Clang fails (the following error).
$ cd python
$ clang --version
clang version 14.0.0 (Red Hat 14.0.0-1.module_el8.7.0+1142+5343df54)
...
$ CC=clang CXX=clang++ pip3 install -e '.[tests]'
...
    triton/python/src/pybind11/pybind11.h:1146:5: error: no matching function for call to 'operator delete'
        ::operator delete(p, s, std::align_val_t(a));
        ^~~~~~~~~~~~~~~~~
    /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/new:149:6: note: candidate function not viable: no known conversion from 'pybind11::size_t' (aka 'unsigned long') to 'std::align_val_t' for 2nd argument
    void operator delete(void*, std::align_val_t, const std::nothrow_t&)
         ^
    /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/new:147:6: note: candidate function not viable: requires 2 arguments, but 3 were provided
    void operator delete(void*, std::align_val_t)
         ^
    /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/new:138:6: note: candidate function not viable: requires 2 arguments, but 3 were provided
    void operator delete(void*, const std::nothrow_t&) _GLIBCXX_USE_NOEXCEPT
         ^
    /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/new:174:13: note: candidate function not viable: requires 2 arguments, but 3 were provided
    inline void operator delete  (void*, void*) _GLIBCXX_USE_NOEXCEPT { }
                ^
    /tmp/clang+llvm-14.0.0-x86_64-linux-gnu-ubuntu-18.04/include/llvm/Support/Allocator.h:441:6: note: candidate function template not viable: requires 2 arguments, but 3 were provided
    void operator delete(void *,
         ^
    /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/new:124:6: note: candidate function not viable: requires 1 argument, but 3 were provided
    void operator delete(void*) _GLIBCXX_USE_NOEXCEPT

The problem is in pybind11. More specifically, I guess I am hitting this issue: https://github.com/pybind/pybind11/pull/1957. I encountered this issue while compiling Triton-MLIR, but I believe I will have the same problem in the master Triton (https://github.com/openai/triton/blob/master/python/src/pybind11/pybind11.h#L1007)
Solution
I am happy to patch or upgrade pybind11, but I would like to know how to address the issue properly from the Triton maintainers.

Mark Clang as not supported?
Adding -fsized-deallocation to the flag if Clang is used?
Patch triton/python/src/pybind11/pybind11.h?
Upgrade pybind11?

Use git-submodule?
Copy-paste the source code of the latest pybind11 (like what the Triton repo currently does)?

It's probably because you are using a slightly newer version of clang than us. I think you can try to upgrade pybind11 by copying the latest source code (or the latest release).

Thanks. I got it. I will create a PR.

Created #691. I would appreciate your reviews!


Please consider leaving politics out of documentation websites

This is Support
I would like to politely and respectfully propose we keep politics out of our work environments. I'm all for showing support for what you believe in, but it would be nice if we could keep code docs about code docs and not politics. Not everyone agrees with the principles or political views of BLM and it's a bit annoying / triggering / distracting to see my favorite tools constantly spamming me political messages while I am working. Please consider removing political messages from site's banner.

It's easily removed by adding a rule for #announcement to your adblocker. No more huge political banners taking up a third of the screen on entry.

Please join the wg-naming and discuss there:
https://github.com/kubernetes/community/blob/master/wg-naming/README.md
/close

/committee steering


error while decoding MB

Hi,
sometimes (after hours) these error is shown:
[h264 @ 0x7fa5f4d5eb40] error while decoding MB 66 35, bytestream -11
I read https://stackoverflow.com/questions/64464169/error-while-decoding-mb-171-1-bytestream-27 and think, that the camera has a single fault image....
Can you add the workaround to doods? (link) or do you have another idea?
Thanks for doods!
more infos: https://www.anycodings.com/1questions/2653121/opencv-read-errorh264-0x8f915e0-error-while-decoding-mb-53-20-bytestream-7
This problem is created when you use the captured frames in the further processing and you create a delay in the pipeline while the rtsp is still streaming.

The solution is to put the capture on a different thread and the frames you use on another thread.

But my python is very bad....

Closing this... I am not sure how i would fix it. Whatever you are using may need to retry.


prevent decompress cache from overwriting existing or deleting folders

currently, the Decompress Cache action will happily delete/overwrite whatever it finds in R_LIBS_WORKFLOW.
This isn't usually a problem, and actually kind of intended (we don't want to carry around old/unintended dependencies in the cache), but to be safe, it should error out when an folder is overwritten.
Not really urgent, because we're waiting for native caching from github #48 anyway, but still should be safer than it currently is.

obsolete or done in the new yml-based GitHub actions.


Add instructions for running tests

I suggest that brief instructions to install pytest and run it on CometTS/tests be added to either the README or CONTRIBUTING documents. It's not in requirements.txt so won't necessarily be in the development environment.
This will help contributors verify their changes don't break your codebase and help users determine what works if they install from a development branch.

[x] Add testing instructions

(JOSS review thread)

Instructions have been added in CONTRIBUTING.md


Update for fast first target master to main

Instances where master branch should be changed to main were implemented. Not all were directly related to the Fast First Target/customer repos; links and references to meta-lmp were also updated to main.
QA steps: built html and linkcheck. As the focus was on keeping things atomic, linter warnings were ignored, as difficult as it was.
This commit addresses FFTK-2430
This commit addresses FFTK-860
Readiness

[x] Merge (pending reviews)
[ ] Merge after date or event
[ ] Draft

Overview
Why merge this PR? What does it solve?
Checklist
Optional. Add a 'x' to steps taken.
You can fill this out after opening the PR. "Did I..."

[ ] Run spelling and grammar check, preferably with linter.
[x] Avoid changing any header associated with a link/reference.
[ ] Step through instructions (or ask someone to do so).
[ ] Review for wordiness
[x] Match tone and style of page/section.
[x] Run make linkcheck.
[ ] View HTML in a browser to check rendering.
[ ] Use semantic newlines.
[x] follow best practices for commits.

[x] Descriptive title written in the imperative.
[x] Include brief overview of QA steps taken.
[x] Mention any related issues numbers.
[x] End message with sign off/DCO line (-s, --signoff).
[x] Sign commit with your gpg key (-S, --gpg-sign).
[x] Squash commits if needed.

[x] Request PR review by a technical writer and at least one peer.

Comments
Any thing else that a maintainer/reviewer should know.
This could include potential issues, rational for approach, etc.

Docs for cf06c30fac5a3c15b6c89501660a6282953efa94 are browsable at: https://ci.foundries.io/projects/fio-docs/builds/2256/docs/artifacts/html/index.html

I want to make sure I did not change any links which should not have been changed regarding master -> main in our repos


Update jquery

We don't have jquery 2.1.4 anymore, apparently
To elaborate a bit more, we used to host a 2.1.4 version here https://play.pokemonshowdown.com/js/lib/ but now that one is updated and the reference in this file is stale

Really this is more evidence we should find some way to integrate this repo back into the client repo.


Improve braindecode.signalproc

Functions exponential_running_standardize and exponential_running_demean should be adapted to accept data input as n_channels x n_times.
highpass_cnt, low_pass_cnt, bandpass_cnt, and filter_is_stable should be removed and usages be replaced with mne functions and follwoing transform API (https://github.com/braindecode/braindecode/blob/master/braindecode/datautil/transforms.py#L18).

I believe something went wrong here. Neither #77 nor #79 implement the changes suggested in this issue.

closed by #80


no attribute 'create_index'

I'm getting this error when trying to use this. AttributeError: 'function' object has no attribute 'create_index'

oh, that makes sense

That fixed it. Is there a way that you can set where the msearch folder goes? Other than the root directory where the script is.

You can set MSEARCH_INDEX_NAME="/tmp/anyfolder"

Ok, thanks


Dev

Description
added benchmarks and logging into our server endpoints
How did you test the changes?
we created test files to test each endpoint manually as well our circleci setup

we still need to add more API testing


bug: Meltano calls Hub during stages other than add and discover

Meltano Version
2.11.1
Python Version
NA
Bug scope
CLI (options, error messages, logging, etc.)
Operating System
NA
Description
With the recent switch to API Gateway and Netlify redirects, users that had whitelisted the now legacy Hub API (https://hub.meltano.com/meltano/api/v1/) are seeing failures because of the redirect to the Gateway endpoint.
See https://meltano.slack.com/archives/C01TCRBBJD7/p1671112207278089.

Back when I implemented meltano add from Hub, I decided to allow calls outside of add and discover, so users not yet onboarded to lockfiles would still be able to use their plugins without having to add those to a custom discovery.yml.
At this point, we should probably disable that behavior and have Meltano fail when a plugin is not custom and doesn't have a lockfile.
Code
No response

Relates to:

https://github.com/meltano/meltano/issues/6754

Back when I implemented meltano add from Hub, I decided to allow calls outside of add and discover, so users not yet onboarded to lockfiles would still be able to use their plugins without having to add those to a custom discovery.yml.
At this point, we should probably disable that behavior and have Meltano fail when a plugin is not custom and doesn't have a lockfile.

@edgarrmondragon - I think we have to hold this until 3.0, if it would break existing users (and there are a lot) who have not yet locked their plugin files. Can you confirm?
I think there was a decision at some point to allow plugins to get their definitions from the hub (if not locked) vs getting from discovery.yml. But reverting to a check against the bundled or web-served discovery.yml would also be a breaking change at this point, since there's likely been significant drift and bug fixes on the Hub that users have already adapted to.


feeds.json: add filter for entries on feed

why? https://changelog.com/podcast has a entries of different type of podcasts on the same feed

$ xmlstarlet sel --template --value-of /rss/channel/item/title -nl feed | shuf -n10
Useful Vim commands, bad first ideas, PETS config manager, Kaizen shirts for sale & infinite canvas tools (News)
With great power comes great responsibility (Interview)
More BMC goodness (Friends)
The foundations of Continuous Delivery (Interview)
An open platform for LLMs, speed matters, imaginary problems, Val Town & how to finish your projects (News)
GunDB, Venture Backed and Decentralized (Interview)
State of the "log" 2023 (Interview)
The I in LLM stands for intelligence (News)
From WeWork to upskilling at Wilco (Interview)
Running functions anywhere with OpenFaaS (Interview)

added blacklist support in b059eef and whitelist in b29d868


CAMEL-17110: camel-aws: s3 consumer should have in-progress repo to a…

…void processing duplicate files.
Description

Target

[ ] I checked that the commit is targeting the correct branch (note that Camel 3 uses camel-3.x, whereas Camel 4 uses the main branch)

Tracking

[ ] If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

[ ] I checked that each commit in the pull request has a meaningful subject line and body.

[ ] I have run mvn clean install -DskipTests locally and I have committed all auto-generated changes

/component-test camel-aws


textwrap panics on a string containing the '–' character

Here's an example program that causes the panic:
extern crate textwrap;

fn main() {
    let problematic_string = "osts: – https://knowledgetester.org/2016/09/20/generalist-specialist-t-and-pi-shaped-testers/ – http://www.dataminingblog.com/the-5-most-common-data-relationships-shown-through-visualization/";
    textwrap::fill(problematic_string, 86);
}

and here's the panic:
thread 'main' panicked at 'byte index 97 is not a char boundary; it is inside '–' (bytes 96..99) of `osts: – https://knowledgetester.org/2016/09/20/generalist-specialist-t-and-pi-shaped-testers/ – http://www.dataminingblog.com/the-5-most-common-data-relationships-shown-through-visualization/`', libcore/str/mod.rs:2257:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:207
   3: std::panicking::default_hook
             at libstd/panicking.rs:223
   4: std::panicking::begin_panic
             at libstd/panicking.rs:402
   5: std::panicking::try::do_call
             at libstd/panicking.rs:349
   6: std::panicking::try::do_call
             at libstd/panicking.rs:325
   7: core::ptr::drop_in_place
             at libcore/panicking.rs:72
   8: core::str::run_utf8_validation
             at libcore/str/mod.rs:0
   9: core::str::traits::<impl core::ops::index::Index<core::ops::range::RangeFrom<usize>> for str>::index
             at /Users/travis/build/rust-lang/rust/src/libcore/str/mod.rs:2010
  10: <core::str::CharIndices<'a> as core::iter::iterator::Iterator>::next
             at /Users/travis/build/rust-lang/rust/src/libcore/option.rs:376
  11: core::str::traits::<impl core::slice::SliceIndex<str> for core::ops::range::RangeFrom<usize>>::index
             at /Users/travis/build/rust-lang/rust/src/libcore/str/mod.rs:2010
  12: core::str::traits::<impl core::ops::index::Index<core::ops::range::RangeFrom<usize>> for str>::index
             at /Users/travis/build/rust-lang/rust/src/libcore/str/mod.rs:1765
  13: textwrap_fail::main
             at /Users/rkd/.cargo/registry/src/github.com-1ecc6299db9ec823/textwrap-0.9.0/src/lib.rs:634
  14: textwrap_fail::main
             at /Users/rkd/.cargo/registry/src/github.com-1ecc6299db9ec823/textwrap-0.9.0/src/lib.rs:544
  15: alloc::string::<impl core::convert::From<&'a str> for alloc::borrow::Cow<'a, str>>::from
             at /Users/travis/build/rust-lang/rust/src/libcore/iter/mod.rs:1701
  16: textwrap_fail::main
             at /Users/rkd/.cargo/registry/src/github.com-1ecc6299db9ec823/textwrap-0.9.0/src/lib.rs:370
  17: textwrap::WrapIterImpl::impl_next::{{closure}}
             at /Users/rkd/.cargo/registry/src/github.com-1ecc6299db9ec823/textwrap-0.9.0/src/lib.rs:749
  18: textwrap_fail::main
             at src/main.rs:5
  19: std::rt::lang_start::{{closure}}
             at /Users/travis/build/rust-lang/rust/src/libstd/rt.rs:74
  20: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:306
  21: panic_unwind::dwarf::eh::read_encoded_pointer
             at libpanic_unwind/lib.rs:102
  22: std::sys_common::at_exit_imp::cleanup
             at libstd/panicking.rs:285
             at libstd/panic.rs:361
             at libstd/rt.rs:58
  23: std::rt::lang_start
             at /Users/travis/build/rust-lang/rust/src/libstd/rt.rs:74
  24: textwrap_fail::main

This is with textwrap 0.9.

The character in the error message is the Unicode em-dash (https://www.fileformat.info/info/unicode/char/2013/index.htm).
However, both these programs compile and run fine:
extern crate textwrap;

fn main() {
    let problematic_string = "–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––";
    textwrap::fill(problematic_string, 86);
}

extern crate textwrap;

fn main() {
    let problematic_string = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa –––––––––––––– bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––";
    textwrap::fill(problematic_string, 86);
}

so it's not just a problem with breaking on that character, or that character following a long string...

Looks like this is fixed in master - using textwrap =  { git = "https://github.com/mgeisler/textwrap", rev = "80da77456c23b9f587c09d3657c932b3dbd51e95" } in Cargo.toml means I no longer hit this crash.

Bisecting points to #113 as the PR that fixed this bug.

Thanks for supplying a failing test case -- I was able to shorten it to:
    #[test]
    fn issue_129() {
        // The dash is an em-dash which takes up four bytes. We used
        // to panic since we tried to index into the character.
        assert_eq!(wrap("x – x", 2), vec!["x", "–", "x"]);
    }


test: alpine, a decent into madness

A investigation into why the parent of https://github.com/codecov/uploader/commit/11b7bcc133187e51034080e2e45e6a871e97ace3 causes Alpine to fail to execute the binary.

See #243

#243

What about it?

A few thoughts:

Bytecode compilation through ncc is not deterministic.
Some non-working binary may have been cached.

It might be ideal to perform simple checksums to determine if a file matches up between CI runs.

I'm suspecting https://github.com/codecov/uploader/pull/244/commits/1e08a55b9367c5ff8b31200a16a2332bc6ac7ddf will break it, personally.

#243

What about it?

It reverts the commit that made the other PR work; however, it does not cause any of the previous issues.

Some non-working binary may have been cached.

The binaries are not cached. I even rolled the cache keys to cover all bases there.

#243

What about it?

It reverts the commit that made the other PR work; however, it does not cause any issues with the CI that we were seeing before (which is unexpected).

I believe you reverted the wrong commit. The fix was to revert all changes to bin/codecov

I believe you reverted the wrong commit.

Good catch.

I'm suspecting 1e08a55 will break it, personally.

🤔 The hunt marches on :)

Completely unrelated, I discovered last night that building a Windows for Node is hard
Makes me want to tackle that as my next project, I want my app (not work-related) to install it's settings on Windows. It needs needs registry, certificate , and file access. Fun times.

[2021-07-23T11:45:06.179Z] ['error'] Error!: TypeError: boolean true is not a function
🤔

I'm almost positive at this point I'm hitting a issue with the snapshot filesystem. I think this is the last thing left to test.

Completely unrelated, I discovered last night that building a Windows installer in Node is hard

I can imagine. I had the pleasure of creating a Java-based installer for Windows many moons ago and even the heavy abstractions were an annoyance. The Windows API was not in a great shape then either—I believe it was during the awkward transition between 7 and 8.

Here is the diff between the broken commit, and https://github.com/codecov/uploader/pull/244/commits/7bb4d4d54038255477aaa69aa345b096fb13a409. At this it's a 🤷♀ and I think I've spent enough time on it. If you get any breakthroughs , let me know :D
--- bad.txt	2021-07-23 07:52:22.000000000 -0400
+++ bin/codecov	2021-07-23 08:09:08.000000000 -0400
@@ -1,6 +1,6 @@
 #!/usr/bin/env node

-const { error, main, verbose} = require('../src')
+const { logError, logVerbose, main } = require('../src')

 var argv = require('yargs') // eslint-disable-line
   .usage('Usage: $0 <command> [options]')
@@ -106,7 +106,7 @@
       alias: 'Q',
       type: 'string',
       description: `Used internally by Codecov, this argument helps track wrappers
-        of the uploader (e.g. GitHub Action, CircleCI Orb)`
+        of the uploader (e.g. GitHub Action, CircleCI Orb)`,
     },
   })
   .version()
@@ -115,15 +115,15 @@

 const start = Date.now()

-verbose(`Start of uploader: ${start}...`, argv.verbose)
+logVerbose(`Start of uploader: ${start}...`, argv.verbose)
 main(argv)
   .then(() => {
     const end = Date.now()
-    verbose(`End of uploader: ${end - start} milliseconds`, argv.verbose)
+    logVerbose(`End of uploader: ${end - start} milliseconds`, argv.verbose)
   })
-  .catch(err => {
-    error(`Error!: ${err}`)
+  .catch(error => {
+    logError(`Error!: ${error}`)
     const end = Date.now()
-    verbose(`End of uploader: ${end - start} milliseconds`, argv.verbose)
+    logVerbose(`End of uploader: ${end - start} milliseconds`, argv.verbose)
     process.exit(argv.nonZero ? -1 : 0)
-  })
\ No newline at end of file
+  })


syntax error [Axios instance]

https://github.com/vuex-orm/plugin-axios/blob/2ed5dcd21a5178d68acecad7bdf087dc4f829a72/src/orm/axios.js#L18

https://github.com/vuex-orm/plugin-axios/releases/tag/v0.5.1


Spectator mode

The ability to join a game without having control over any country.

This was kind of added already: if you add enough players, eventually, all the countries are taken and players are created as spectators. But there still isn't a way to spectate a game that has no humans in it. When a game only has AI in it, an infinite loop occurs and the game freezes.

It might be better to only introduce this after the settings menu is added, because you'll want to adjust the animation playback speed (among other things)

Now that the AI runs its code in a separate thread (#250), we can actually spectate an AI-only game without the game freezing!
But the AI still plays its moves very quickly.


Initial Rust binding

This adds initial Rust binding for Themis.
The code comes from here, version 0.0.2:
https://github.com/ilammy/rust-themis
I could have transferred the whole git history, but that's too much of a bother and I don't think anybody would be interested in it that much. If you wish to read the older commit messages you can always look into the original repo. Not very convenient but that's at least something.
The core repository layout is a bit different from a traditional one for Rust projects. I have moved the files into appropriate places and adapted the Cargo.toml file to that. Importantly, it now requires an include directive so that published crates include only Rust code.
Here's the current layout of Rust code:
.
├─ Cargo.toml           -  root Cargo.toml file
├─ docs/examples
│  └─ rust              -  Rust wrapper examples
├─ src/wrappers/themis
│  └─ rust              -  root of the "themis" crate
│     ├─ libthemis-sys  -  root of the "libthemis-sys" crate
│     └─ src            -  Rust wrapper source code
└─ tests
   └─ rust              -  Rust wrapper tests

The Cargo.toml file is placed in the root directory so that all usual Cargo commands work from there after a fresh checkout. They do work indeed, but the Rust binding is not integrated into the core build system. We'll improve that later.
The links throughout the docs and Cargo.toml files have been updated to point to Cossack Labs repo. I have also removed TravisCI badges because Rust wrapper is going to use CircleCI just like the other bindings.
I have kept the original README files. These are used when publishing on crates.io and contain Rust-specific instructions. The LICENSE files in Rust wrappers are also kept intact in accordance with item 4.a of the Apache 2.0 license.
As for licensing of this contribution, I'm not a lawyer, but Apache license gives the same rights to the original licensor as well as any future contributors. That's why I did not bother updating all the boilerplate comments all over the code. They still assign copyright of Rust code to "rust-themis developers". By submitting this code to the core repository the developers agree to keep the Apache 2.0 license for it, as per item 5 of the license. There are no separate prior agreements other than that.

Yey, themis will have rust binding, that's incredible!
Thank you @ilammy, you're doing great things!
Please don't be irritated while we're reading code and asking simple questions – rust is still very new for us.

Apache 2.0 license
That's right, having Apache 2.0 license makes total sense, as you said, it gives the same rights to the original licensor as well as any future contributors.


Added Polish person titles.

Added few commonly used Polish person titles.

No news for a year, closing.


Fix/deploy bugs

Codecov Report

Merging #72 (a18312e) into master (827f0a3) will decrease coverage by 0.15%.
The diff coverage is 55.55%.

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

@@            Coverage Diff             @@
##           master      #72      +/-   ##
==========================================
- Coverage   86.06%   85.90%   -0.16%
==========================================
  Files          34       34
  Lines        2483     2491       +8
  Branches      675      678       +3
==========================================
+ Hits         2137     2140       +3
- Misses        313      317       +4
- Partials       33       34       +1

Impacted Files
Coverage Δ

packages/cli-plugin-package/src/index.ts
82.05% <55.55%> (-0.56%)
:arrow_down:

packages/cli-plugin-dev/src/index.ts
81.25% <0.00%> (-0.57%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 827f0a3...e7273f6. Read the comment docs.


[Cirrus] Add IsExpired status to Poll

See https://app.clickup.com/t/a11fjz,

The BIP9 activation would just make the upgrade a bit smoother. Otherwise, if only a few nodes upgrade straight away then they will be faced with errors due to federations that differ from what is expected by the non-upgraded majority. If use BIP9 then it will only be the non-upgraded 10% that will face errors that will require them to upgrade as well. WDYT?

@fassadlr , The BIP9 activation would just make the upgrade a bit smoother. Otherwise, if only a few nodes upgrade straight away then they will be faced with errors due to federations that differ from what is expected by the non-upgraded majority. If we use BIP9 then it will eventually only be the non-upgraded 10% that will face errors that will require them to upgrade as well. That said, it may still depend a lot on how the upgrade is managed. WDYT?
BTW we could add the activation height stuff as a separate PR and remove a few files from this one. See #713.

The masternode users are generally very active with regards to keeping their nodes upgraded and like I said, we control the upgrade by indirectly forcing them to upgrade when they restart their node. This can be due to Windows updates etc. If we set an activation height 2 weeks from release and announce in the channel daily, 99% of the guys will be upgraded by the time activation happens. I know that the other guys prefer activation heights as well, so perhaps lets move it to that? WDYT?

Otherwise, the PR looks 👍

@fassadlr , Sounds good. I've made the change.


API: add SliceRecordABC.plus_start and plus_stop

[NEW] these return start and stop in plus strand coordinates,
irrespective of whether reversed or not. This is most critical
in SeqDataView where previous code was passing just parent_start
and parent_stop. The latter use the offset, which should be
employed only for feature querying. Adding comments to that effect
to the docstrings.
Summary by Sourcery
Add plus_start and plus_stop properties to SliceRecordABC to provide start and stop positions in plus strand coordinates, enhancing sequence retrieval consistency in SeqDataView.
New Features:

Introduce plus_start and plus_stop properties to return start and stop in plus strand coordinates, regardless of sequence orientation.

Enhancements:

Refactor SeqDataView to use plus_start and plus_stop for sequence retrieval, ensuring consistent handling of sequence orientation.

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

23 of 23 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.001%) to 92.259%

Totals

Change from base Build<PHONE_NUMBER>5:
0.001%

Covered Lines:
33860

Relevant Lines:
36701

💛  - Coveralls


SNI Issue in Elixir

Steps to reproduce
Hi team,I couldn't get my Elixir app working with Neon tech. I have found several resources belowhttps://neon.tech/docs/connect/connectivity-issues

Postgrex
Elixir
✓ (configure ssl_opts with server_name_indication)

But the option doesn't work for me. I have triedpostgres://<USERNAME>:<PASSWORD>@ep-plain-262670.us-east-2.aws.neon.tech/neondb?sslmode=requirepostgres://<USERNAME>:<PASSWORD>@ep-plain-262670.us-east-2.aws.neon.tech/neondbpostgres://<USERNAME>:<PASSWORD>@ep-plain-262670.us-east-2.aws.neon.tech/neondb?sslmode=require&options=endpoint%3Dep-plain-262670postgres://<USERNAME>:<PASSWORD>@ep-plain-262670.us-east-2.aws.neon.tech/neondb?sslmode=verify-full&options=endpoint%3Dep-plain-262670But I saw the same result
Error saw
11:10:38.916 [error] GenServer #PID<0.317.0> terminating ** (Postgrex.Error) ERROR XX000 (internal_error) Endpoint ID is not specified. Either please upgrade the postgres client library (libpq) for SNI support or pass the endpoint ID (first part of the domain name) as a parameter: '?options=endpoint%3D<endpoint-id>'. See more at https://neon.tech/sni (db_connection 2.2.2) lib/db_connection/connection.ex:87: DBConnection.Connection.connect/2 (connection 1.0.4) lib/connection.ex:622: Connection.enter_connect/5 (stdlib <IP_ADDRESS>) proc_lib.erl:226: :proc_lib.init_p_do_apply/3 Last message: nil State: Postgrex.Protocol

11:19:16.854 [error] GenServer #PID<0.1887.0> terminating ** (DBConnection.ConnectionError) tcp connect (ep-plain-262670.us-east-2.aws.neon.tech:5432): non-existing domain - :nxdomain (db_connection 2.2.2) lib/db_connection/connection.ex:87: DBConnection.Connection.connect/2 (connection 1.0.4) lib/connection.ex:622: Connection.enter_connect/5 (stdlib <IP_ADDRESS>) proc_lib.erl:226: :proc_lib.init_p_do_apply/3 Last message: nil State: Postgrex.Protocol

Environment

MacOS M1

elixir -v
Erlang/OTP 23 [erts-<IP_ADDRESS>] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [dtrace]

Elixir 1.11.1 (compiled with Erlang/OTP 23)

"postgrex": {:hex, :postgrex, "0.15.5",

Logs, links

@datduyng I hope you got it working. We have a new Elixir guide, here:
https://neon.tech/docs/guides/elixir-ecto
Also, there are a couple of posts in the Community forum on Elixir/Ecto.
https://community.neon.tech/t/elixir-phoenix-connection-failed/596
https://community.neon.tech/t/guide-on-connecting-via-ecto/75


PagedMasonryGridView Indicator NOT CENTERED, instead it's inserted inside grid

I want to customize the footer of PagedMasonryGridView by specify it's noItemsFoundIndicatorBuilder &
noMoreItemsIndicatorBuilder.
But lookslike the footer is inserted together with grid children.

i tried give top padding, but not works.
noMoreItemsIndicatorBuilder: (_) => Padding(
  padding: const EdgeInsets.only(top: 100),
  child: const ListFooter(),
),

I was expect that footer is centered in the middle, like the figma design below.

I really hope for your help, many thanks.
infinite_scroll_pagination: ^4.0.0
flutter v3.13.3 (stable)

Usually, the paged widgets have these parmaters:
    this.showNewPageProgressIndicatorAsGridChild = true,
    this.showNewPageErrorIndicatorAsGridChild = true,
    this.showNoMoreItemsIndicatorAsGridChild = true,

to specify the behaviour you desire.
This is not the case for the PagedMasonryGridView right now.
You can follow the PR at #252 which would address this as well.

i haven't try that but i found PagedMasonryGridView cannot be combined with CustomScrollView. Because it will create 2 different scroll view port. if set physics to NeverScrollableScrollPhysics then the PagedMasonryGridView cannot be scroll to the end of the list. And NestedScrollView also can't make PagedMasonryGridView work properly. So i switched to https://pub.dev/packages/pull_to_refresh_flutter3.
did you get my point, i hope so because my english too poor.

Yes. PagedMasonryGridView is currently lacking the PagedMasonryGrid version which works with CustomScrollView.
The PR I mentioned adds that and allows centering the loading indicators.
However, we must wait for mr edson bueno to merge and release it.

I am not sure what you mean by that.
If you are experiencing an unrelated issue, please open a new issue with detailed instructions, screenshots and code instead.
thank you.


[5.10] Build the stage0 with optimizations

Swift is a tad slow when it's not built with optimizations.

@swift-ci please test


vscode cpptools extensions not working

Issue description
The vscode cpptools extension is linked to /lib64/ld-linux-x86-64.so.2.
$ file ~/.vscode/extensions/ms-vscode.cpptools-0.15.0/bin/Microsoft.VSCode.CPP.Extension.linux
/home/dehos/.vscode/extensions/ms-vscode.cpptools-0.15.0/bin/Microsoft.VSCode.CPP.Extension.linux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=4ab2b1c13cd195245e581b35901048f97acd1dda, not stripped

So the extension fails when editing a C++ file with vscode:
[Error - 10:41:56 AM] Starting client failed Launching server using command /home/.../.vscode/extensions/ms-vscode.cpptools-0.15.0/bin/Microsoft.VSCode.CPP.Extension.linux failed.

This issue has been reported in the vscode repo (https://github.com/Microsoft/vscode-cpptools/issues/1345) but I think it is more a packaging problem.

I had this problem on Raspbian Desktop and, I solved it by installing AMD64 version of libc (sudo apt-get install libc6-dev:amd64), because uname -r returned 4.9.0-4-amd64, but libc was i386, VS Code was i386 and cpptools extension is amd64.
Before I only had /lib/ld-linux.so.2 and now I have /lib64/ld-linux-x85-64.so.2

If you use vscode-with-extensions and https://github.com/NixOS/nixpkgs/blob/master/pkgs/misc/vscode-extensions/cpptools/default.nix then you can get it to work. Still haven't figured out if this means that I need to manage all my vscode extensions in nix tho.
I have this in my packageOverrides (pinnedPkgs is my thing):
      vscodeCpp = pinnedPkgs.vscode-with-extensions.override {
        vscodeExtensions = with vscode-extensions; [ ms-vscode.cpptools ];
      };

Alternative solution - https://discourse.nixos.org/t/vscode-extensions-setup/1801
This issue should be closed, as cpptools works in NixOS


tile-load-failed event not getting called

I'm trying to implement a workaround for when a user wants to render an image which is not yet done tiling.  I would expect to get a callback when I add a handler for the 'tile-load-failed' event, but I never do.
Further, for some reason the method signature for tile load failed does not include a userData field, which I really need so that I can execute my function with the relevant data when this event happens.
this.viewer.addHandler('open-failed', function(inputDict) {
// This gets called if there are absolutely no tiles at all, ie 500 error
console.log(inputDict.userData);
		}, context);

		this.viewer.addHandler('tile-load-failed', function(inputDict) {
// This never ever gets called.
console.log(inputDict);
		}, context);

Interesting... are you seeing errors in your console? It should be working... can you make a codepen or jsbin with it happening?
When you do get the event, the userData should come through just fine... looks like we just forgot to document it on that event.

After further sleuthing, it turned out that we were initializing openseadragon with no path at all to an image tile set.  We were working on handling the case where the tiling was not yet complete.
So in fact I have not had a problem with this.
Thanks for the prompt response.

Good to hear!
I'll leave this issue open in case someone wants to address the missing  userData documentation for tile-load-failed.


pip install torchdata

Is the pypi package torchdata associated with this project? I naively ran pip install torchdata when trying to install this package and got some unexpectedly unrelated project.
https://pypi.org/project/torchdata/
That doesn't seem to have any github sources corresponding to it so wondering what's going on with that package.

Is the pypi package torchdata associated with this project? I naively ran pip install torchdata when trying to install this package and got some unexpectedly unrelated project.

Simply speaking, we plan to upload wheel pypi in the short future. We plan to release against PyTorch 1.11.
That package is from a community repo. We have asked the writer to transfer it to us. Stay tuned for our first release. It should be held on both PyPi and conda.

@ejguan got it, thanks for the clarification! Excited to try this stuff out :)

Closing this issue as our package is now on PyPI


CredSweeper not detecting google_multi

I just installed CredSweeper, and I tested
python -m credsweeper --path google_multi
And google_multi has the contents of
012-GiReoGiGiReoGiGiReoGiGiReoGi1230.apps.googleusercontent.com

4L2QMyTm6Rr0o46ytGiReoG1

But when I run it, I get
Detected Credentials: 0
Time Elapsed: 0.11600160598754883s

But if I run the password test sample I get the expected output
python -m credsweeper --path password
rule: Password / severity: medium / line_data_list: [line: 'password = "cackle!"' / line_num: 1 / path: password / value: 'cackle!' / entropy_validation: False] / api_validation: NOT_AVAILABLE / ml_validation: VALIDATED_KEY
Detected Credentials: 1
Time Elapsed: 0.11830568313598633s

Perhaps i'm doing something wrong?

Hello.
Thank you for question.
I tried it too and i got same result as you saw..
$ python -m credsweeper --path tests/samples/google_multi
Detected Credentials: 0
Time Elapsed: 0.12809443473815918s

So I checked why it filtered and found out the reason.
2023-02-13 11:21:32,397 | DEBUG | ml_validator:160 | ML decision: False with prediction: 0.001 for value: 012-GiReoGiGiReoGiGiReoGiGiReoGi1230.apps.googleusercontent.com

CredSweeper has ML validation logic and it filtered the line.
Actually google multi sample was added before ML validation feature, so it can be filtered.
And you can check expected result with --ml_threshold 0 option.
$ python -m credsweeper --path tests/samples/google_multi --ml_threshold 0
rule: Google Multi / severity: high / line_data_list: [line: '012-GiReoGiGiReoGiGiReoGiGiReoGi1230.apps.googleusercontent.com' / line_num: 2 / path: tests/samples/google_multi / value: '012-GiReoGiGiReoGiGiReoGiGiReoGi1230.apps.googleusercontent.com' / entropy_validation: True, line: '4L2QMyTm6Rr0o46ytGiReoG1' / line_num: 4 / path: tests/samples/google_multi / value: '4L2QMyTm6Rr0o46ytGiReoG1' / entropy_validation: False] / api_validation: NOT_AVAILABLE / ml_validation: NOT_AVAILABLE
Detected Credentials: 1
Time Elapsed: 0.07845592498779297s

Hello.
Thank you for question.
I tried it too and i got same result as you saw..
$ python -m credsweeper --path tests/samples/google_multi
Detected Credentials: 0
Time Elapsed: 0.12809443473815918s

So I checked why it filtered and found out the reason.
2023-02-13 11:21:32,397 | DEBUG | ml_validator:160 | ML decision: False with prediction: 0.001 for value: 012-GiReoGiGiReoGiGiReoGiGiReoGi1230.apps.googleusercontent.com

CredSweeper has ML validation logic and it filtered the line. Actually google multi sample was added before ML validation feature, so it can be filtered.
And you can check expected result with --ml_threshold 0 option.
$ python -m credsweeper --path tests/samples/google_multi --ml_threshold 0
rule: Google Multi / severity: high / line_data_list: [line: '012-GiReoGiGiReoGiGiReoGiGiReoGi1230.apps.googleusercontent.com' / line_num: 2 / path: tests/samples/google_multi / value: '012-GiReoGiGiReoGiGiReoGiGiReoGi1230.apps.googleusercontent.com' / entropy_validation: True, line: '4L2QMyTm6Rr0o46ytGiReoG1' / line_num: 4 / path: tests/samples/google_multi / value: '4L2QMyTm6Rr0o46ytGiReoG1' / entropy_validation: False] / api_validation: NOT_AVAILABLE / ml_validation: NOT_AVAILABLE
Detected Credentials: 1
Time Elapsed: 0.07845592498779297s

Ah okay, I understand, that makes sense. Thanks for the quick reply and clearing it up for me.


Feature/issue 855 log inv logit diff

Submission Checklist

[x] Run unit tests: ./runTests.py test/unit
[x] Run cpplint: make cpplint
[x] Declare copyright holder and open-source license: see below

Summary:
Address #855, adding a standalone function (log_inv_logit_diff) with gradients for the log of the difference between two inverse logits. This replaces the function declared in prim/mat/prob/ordered_logistic_lpmf.
Intended Effect:
Improve the speed and efficiency of calculating the log difference between two inverse logits.
How to Verify:
Tests are included for prim/rev/fwd/mix
Side Effects:
N/A
Documentation:
As doxygen
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company): Andrew Johnson
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

@andrjohns  Is this ready for final approval?

Yes, changes are all in and passing tests so should be good to go

From: Bob Carpenter<EMAIL_ADDRESS>Sent: Thursday, June 14, 2018 5:03:54 AM
To: stan-dev/math
Cc: Andrew Johnson; Mention
Subject: Re: [stan-dev/math] Feature/issue 855 log inv logit diff (#856)
@andrjohnshttps://github.com/andrjohns Is this ready for final approval?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/stan-dev/math/pull/856#issuecomment-397086174, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AabxCGVs9-V1PpKUXGOtHONs7P2mYwSyks5t8X46gaJpZM4TxQXH.


Various improvements/refactoring to modernize the project

added an .editorconfig file to help with consistent file formatting (developers can install a plugin for their respective IDE if desired)
ignore MacOS thumbnail files
added ESLint as a linter with rules (I chose my favorites as a starting place, but they can, of course, change)

NOTE: many of the changes in this PR were actually done via ESLint's Auto-Fix command after setting a given rule - this helps to prevent human error in refactoring

checked in package-lock.json as is recommended by npm
built dist within its own folder (and updated README and test/index.html)

NOTE: this impacts #19 (@psvenk)

remove unnecessary qunit git submodule since we are bringing it in via npm with our package.json file
switched entirely over to const/let rather than var (modern ES6 syntax, also allows for block-scoped variables and prevents unintentional logic errors)

All tests continue to pass both when running test/index.html as well as when running npm run test.

By the way, I had actually kept an .editorconfig file (ignored by Git) while I was working on the other two PRs just so that I didn't need to change my Vim indentation settings every time I opened a file.

Outputting the generated file into its own directory makes for a nicer directory hierarchy, but it makes an avoidable breaking change and means that anyone using Sanscript.js via npm will need to change their include path, and the dist directory would also only contain one file.

Thanks for the review, @psvenk ! @rramphal Let's not go for the breaking change mentioned above.

By the way, another comment I forgot to mention earlier (sorry):

The output of npm run test is extremely verbose (though there is a summary at the end) — I suspect this is due to the console.log statements. Maybe we should make these only run in the browser or remove these entirely to make the test output easier to read.

Thank you @psvenk and @vvasuki for reviewing so quickly!

By the way, I had actually kept an .editorconfig file (ignored by Git) while I was working on the other two PRs just so that I didn't need to change my Vim indentation settings every time I opened a file. Thanks for adding an .editorconfig.

You're very welcome about the EditorConfig. It makes things so much easier, especially across a team. Also, thank you for your improvements to the .editorconfig file!

Outputting the generated file into its own directory makes for a nicer directory hierarchy, but it makes an avoidable breaking change and means that anyone using Sanscript.js via npm will need to change their include path, and the dist directory would also only contain one file.

@rramphal Let's not go for the breaking change mentioned above.

I actually decided to split out a dist folder because I thought that #19 implied that @vvasuki was only concerned that the documentation was updated. I've restored sanscript.js to its original location as requested.

Using let and const affects browser compatibility. 95.56% of browsers do have some support for let (and 97.83% for const), but I am noting this because I am not sure how much of an issue this is for Sanscript.js.

I added a step to let Babel transpile ES6 code to ES5. This is mainly to allow us to use const and let, which has become the best practice in the JavaScript community, but also because we can not target specific environments (browsers, node versions) to ensure compatibility. That said, if @vvasuki isn't worried about the 4.44% of browsers that don't support let and the 2.17% that don't support const, I'd be glad to strip Babel out.

ESLint seems like a little bit overkill, but I see the benefit of having consistent and correct code, we have a build step anyway, and it is only a devDependency.

I agree that ESLint, and now Babel, might be a bit of overkill, but now that we have at least six developers who will have contributed to the codebase, tools like these allow us to use the latest, most powerful features of JavaScript while maintaining backward compatibility and a consistent style. Not to mention that some of the things that ESLint caught while linting this codebase are objective improvements (not reusing function-scoped counter variables, for example). My hope is that moving forward, developers will be able to contribute solid, modern, readable code without having to worry about whitespace style consistency, team conventions, and backward compatibility. Both Babel and ESLint are industry norms, and if we are providing an npm module, we should follow industry best practices. This seems like a good middle-ground to me. At least I'm not suggesting adding webpack and converting the whole repo to TypeScript 😋 !

The output of npm run test is extremely verbose (though there is a summary at the end) — I suspect this is due to the console.log statements. Maybe we should make these only run in the browser or remove these entirely to make the test output easier to read. We could alternatively replace all instances of console.log with log, a function that could be defined to call console.log conditionally (maybe if a variable is set for debugging).

YES — over 16,000 lines of logging! In an effort to debug this, I ended up removing the console.log lines from tests.js themselves and instead opted to added a button to test/index.html called "log schemes to console" for users to manually log the data. I also removed the devanagari-kannada lines because I can't figure out why whose calls are so special. I think they might have been remnants of some debugging. The real culprit was console.debug(map); in src/sanscript.js itself, which I ended up removing. I also added a lint rule to help us keep console.log statements out of the code we check in.

Because Sanscript.js is fairly simple, there probably won't be any need for minification or other things that would cause us to ship more than one file. I'm not opposed to this change in principle, but I don't see the specific benefits here.

If we decide to keep Babel, minification does become pretty easy to implement. I agree that there probably isn't much need for minification, but given that minification is also a best practice, do we want to consider it?

@rramphal Thanks for the changes! Some comments:

If we decide to keep Babel, minification does become pretty easy to implement. I agree that there probably isn't much need for minification, but given that minification is also a best practice, do we want to consider it?

While I am not opposed to adding ESLint and Babel in this case, I would argue that something being a "best practice" does not necessarily mean that it is a good idea. For example, I gather that usage of JSON for configuration is considered a best practice in the JS world (and I do believe in this particular case that the benefits outweigh the costs) but JSON is not very well suited for configuration. Windows is an "industry standard" in many companies but that is more out of convenience than out of a belief that Windows is architecturally superior to the alternatives.
As I see it, the benefits of Webpack and minification are reducing code size, which is mainly relevant for libraries and web apps with many large dependencies (particularly multi-megabyte bundles, which IMO are usually a bad practice) and not for small and focused libraries like Sanscript (which is 84K transpiled ES5).
I see that there is some merging and that the commit count is now at 26. Could you or I do a rebase to make for a cleaner history? For example, merging master into improvements to bring improvements up to date will make git log output and any history visualization look needlessly convoluted. Some details, such as that the .editorconfig file was revised, that the generated sanscript.js was moved to dist and back again, and that this branch was originally based on an older commit, are IMO not important enough for inclusion in the commit log and make the commit log harder to read — these details are still captured in the pull request discussion (which can be exported). I would be happy to perform the rebase if you prefer.

... I would argue that something being a "best practice" does not necessarily mean that it is a good idea.

I totally agree. That's what I was trying to get at with: "Both Babel and ESLint are industry norms, and if we are providing an npm module, we should follow industry best practices. This seems like a good middle-ground to me. At least I'm not suggesting adding webpack and converting the whole repo to TypeScript". In this case, I think Babel and ESLint are good additions for what we are trying to get done. Because this project is called sanscript.js and because it is being published as an NPM module, the industry practices I am referencing are those of the target consumers as well as any potential contributors. Another reason that I'd be the first to agree with you is that more than any other tech field, the JavaScript field is changing so fast that we must be prudent before blindly following "best-practices," which is exactly what I think your point is.

As I see it, the benefits of Webpack and minification are reducing code size, which is mainly relevant for libraries and web apps with many large dependencies (particularly multi-megabyte bundles, which IMO are usually a bad practice) and not for small and focused libraries like Sanscript (which is 84K transpiled ES5).

I really could go either way. Once a library is released as a npm package, who knows how it will be composed and with how many other packages. It's a slippery slope to draw the line as to when minification is necessary, and since minification is a very good industry convention, I think we're doing the right thing by at least thinking about it. JS devs are moving towards code-splitting and tree shaking, but not everyone is doing that, and so any little bit helps. I quite like the convention that CDNs have where they offer both uncompressed and minified versions and you can make the choice yourself, which is definitely something we could do here and I would be in support of.

I see that there is some merging and that the commit count is now at 26. Could you or I do a rebase to make for a cleaner history?

It is my general process to commit often and fairly neatly for feature branches, which also helps with code-reviewing large PRs. Then once the PR is ready to be merged, I use GitHub's "Squash and merge" feature which combines the numerous commits into one commit with a rollup of all the commit messages as its singular commit message. I don't use rebasing much because it feels like rewriting history to me, but I most likely have a flawed understanding. I noticed that in #13, you rebased and force-pushed, and I also don't like force-pushing. I use "Squash and merge" regularly and it has been good enough for what you're concerned with. There is also the "Rebase and merge" option which I have never used that might also work? All this to say that I don't think we need to do anything other than pick the right choice under the green button.
Hubmail is pretty cool, by the way!

It is my general process to commit often and fairly neatly for feature
branches, which also helps with code-reviewing large PRs. [...] All
this to say that I don't think we need to do anything other than pick
the right choice under the green button.

@rramphal Interesting. The workflow I use is to use "squash and merge"
when it makes sense to keep everything in one commit, and a regular
merge when it does not (in which case there is some value in seeing the
commit history). The "rebase and merge" option just rebases the branch
and does a fast-forward merge, so there is no delineation saying that
the commits come from a certain pull request.
I like rebasing (and force-pushing) because I don't think rewriting
history (in feature branches) is necessarily a bad thing. I see the
commit log as an organizational tool, and rewriting history is like
refactoring in that it makes the commit log easier for oneself and other
contributors to read later on (more information at
https://git-rebase.io/). I did use "squash and merge" in the other two
pull requests (after manually squashing the commits with an interactive
rebase).
I think there is value in keeping separate commits in this case because
the changes, while individually small, are of many different natures and
it would be beneficial to group the diffs by topic. Squashing and
merging is one extreme, simplifying the commit history into one commit
(internally using the same plumbing commands as git rebase), and
merging without rebasing at all is the other extreme, keeping the entire
commit history including things that would not be very useful. Most Git
commands, including rebase and force push, do not permanently lose data
but merely hide the data so that the surface commit log is cleaner. The
history remains in the pull request thread but the specific commits are
lost to people who were not directly involved in the discussion (but
this is a fault of GitHub and not of Git; in the mailing list workflow
older versions of patches or patchsets would be accessible in the
mailing list archives).
Nonetheless I believe that in this case the benefits of rebasing
outweigh the costs. The discussion captures the changes that were made
and reverted pretty well.

@psvenk, let me think about this. In the mean time, did you get a chance to review the new commits since your last review? Is there anything you want me to change code-wise?

@psvenk, I think I see what you're saying now. I haven't ever rewritten history within a feature branch, but if it isn't a shared branch, there should be no problem with that. It really does boil down to the fact that I'm still unfamiliar with git rebase, but there's no better time to learn than the present!
I agree that there would be value in grouping related commits together thematically while reducing the number of commits. I have learned that merging master into my feature branch is really the old-school way of doing it and I definitely have had annoying bugs come from code changes being introduced via a merge conflict resolution. I have also noticed that we never really lose commits unless we prune them out, so we can still reference them if need be.
With #13, I noticed as a reviewer that I didn't like what happened to the conversation history itself after a rebase and force-push, so rather than do that, I'll branch off of this branch, rebase the new branch, and submit a new PR from the new branch. I'll close this PR and link back to it from the new PR when I'm done. For ease, I'll wait until the current PR is reviewed for code content, and then I'll take this course of action. How does that sound?

@psvenk, let me think about this. In the mean time, did you get a chance to review the new commits since your last review? Is there anything you want me to change code-wise?

@rramphal Ok, that's fine. I saw the new commits and they look good, but I have two comments:

I see that path.join(__dirname, "..", ...) is used in the build script. We could have const rootdir = path.dirname(__dirname); near the beginning of the file and just use path.join(rootdir, ...). This would solve portability issues (if any) with Windows.

I noticed that the prepare script is run when I run npm install — from reading the NPM docs this seems like standard behavior, but I just wanted to check that this is intentional and standard.

With #13, I noticed as a reviewer that I didn't like what happened to the conversation history itself after a rebase and force-push, so rather than do that, I'll branch off of this branch, rebase the new branch, and submit a new PR from the new branch. I'll close this PR and link back to it from the new PR when I'm done. For ease, I'll wait until the current PR is reviewed for code content, and then I'll take this course of action. How does that sound?

Ok, that sounds good. When you say that you don't like what happened to the conversation history, do you mean GitHub putting the new commits below all of the existing messages? By the way, for what it's worth I don't think code review comments are discarded upon a force-push.

I see that path.join(__dirname, "..", ...) is used in the build script. We could have const rootdir = path.dirname(__dirname); near the beginning of the file and just use path.join(rootdir, ...). This would solve portability issues (if any) with Windows.

I'll make that change now. It'll also dry up our code, which is good.

I noticed that the prepare script is run when I run npm install — from reading the NPM docs this seems like standard behavior, but I just wanted to check that this is intentional and standard.

I did choose the prepare script intentionally, but honestly I don't know if it is standard at all. Do you have any suggestions?

When you say that you don't like what happened to the conversation history, do you mean GitHub putting the new commits below all of the existing messages?

The new commits at the bottom is fine — I think it was the unlinking of the comments to the commits that I didn't like.

By the way, @psvenk, do you do your rebasing via the terminal or via a GUI? I'd appreciate any suggestions (I'd email you, but you don't have your email listed on GitHub haha)!

I did choose the prepare script intentionally, but honestly I don't know if it is standard at all. Do you have any suggestions?

It seems that prepare and prepublish both have this behavior, so I would guess that this behavior is standard.

By the way, @psvenk, do you do your rebasing via the terminal or via a GUI? I'd appreciate any suggestions (I'd email you, but you don't have your email listed on GitHub haha)!

I use the terminal for rebasing as with most git operations (though I do use Fugitive.vim sometimes for committing). https://git-rebase.io/ explains rebasing better than I possibly can, but if you have any specific questions I would be happy to clarify for you.

New PR #22 created, so I'm closing this PR.


chore: create initial db for postgres

Signed-off-by: Firas Qutishat<EMAIL_ADDRESS>

Codecov Report

Merging #97 (0ee8b82) into main (222452d) will decrease coverage by 0.37%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main      #97      +/-   ##
==========================================
- Coverage   85.02%   84.64%   -0.38%
==========================================
  Files          13       13
  Lines        2270     2280      +10
==========================================
  Hits         1930     1930
- Misses        205      215      +10
  Partials      135      135

Impacted Files
Coverage Δ

cmd/vct/startcmd/start.go
79.33% <0.00%> (-1.42%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 222452d...0ee8b82. Read the comment docs.

Any reason not to add a test around valid/invalid postgres connection string?
With this change, the database specified in the connection string will be a "jump-db" (basically empty), after which the rest of the databases (createStore) will be created?

Any reason not to add a test around valid/invalid postgres connection string?
With this change, the database specified in the connection string will be a "jump-db" (basically empty), after which the rest of the databases (createStore) will be created?

@alialkhalidi I add bdd test to show using vct config in db url


Add explicit URL property in LinkButton node

This PR adds a url property to LinkButton that points to a resource (most likely a webpage) to be opened when the button is clicked. Such value will be used as the visible text of the button when the text property isn't set.
The idea is to have something simpler than a RichTextLabel, which requires figuring out the BBCode syntax for a link and manually writing a script to actually open the URL when clicking. At the same time, LinkButtons right now (in Godot 3.x at least) are simply flat buttons with some underlined text which isn't actually treated as a link to anything (the dev is supposed to again manually write a script that opens the url when the button is pressed).
This PR aims at clarifying this system, where RichTextLabels may be used for complex text with multiple links (which could need to be treated separately in code) and where LinkButtons are a simple and quick way of displaying a single URL to (e.g.) one's GitHub profile.

The idea is to have something simpler than a RichTextLabel, which requires figuring out the BBCode syntax for a link and manually writing a script to actually open the URL when clicking. At the same time, LinkButtons right now (in Godot 3.x at least) are simply flat buttons with some underlined text which isn't actually treated as a link to anything (the dev is supposed to again manually write a script that opens the url when the button is pressed).
This PR aims at clarifying this system, where RichTextLabels may be used for complex text with multiple links (which could need to be treated separately in code) and where LinkButtons are a simple and quick way of displaying a single URL to (e.g.) one's GitHub profile.

Note that there's already a pull request implementing this feature in master: https://github.com/godotengine/godot/pull/30675

@Calinou I admit I didn't see it, but it seems to me that that PR opens the link by having the button listen to its own pressed signal and the connection is made with the G4.0 API (aka with callables). This would clearly not work in G3.x.
My solution, on the other hand, doesn't use signals at all and instead directly overrides the BaseButton::pressed() method - which already "listens" to the pressed signal and is compatible with G4.0. I think this solution could be copy-pasted into G4, but I didn't wanna create duplicate PRs for the same code.

I didn't wanna create duplicate PRs for the same code.

As a rule, we first accept features to the master branch, and only then can they be backported/cherrypicked to the maintenance branches. We now have 3 PRs that add this feature, 2 for master (https://github.com/godotengine/godot/pull/30675, https://github.com/godotengine/godot/pull/59810), and this one for 3.x. So it's better that we focus the discussion on one of them, stabilize the implementation, and then decide on backporting. Feel free to cross-review https://github.com/godotengine/godot/pull/30675, your approach does indeed seem to be better, regarding the method override.


robustness to old EEGLAB versions

Old EEGLAB versions seemingly allow integer event codes.
See #3264
Not sure how to test - we probably don't want to add another test file just for this.

[Current coverage][cc-pull] is 91.96%

Merging [#3279][cc-pull] into [master][cc-base-branch] will increase coverage by <.01%

@@             master      #3279   diff @@
==========================================
  Files           336        336
  Lines         56745      56745
  Methods           0          0
  Messages          0          0
  Branches       8619       8619
==========================================
+ Hits          52180      52183     +3
+ Misses         4565       4562     -3
  Partials          0          0

[][cc-pull]

Powered by Codecov. Last updated by [0fff718...da63764][cc-compare]
[cc-base-branch]: https://codecov.io/gh/mne-tools/mne-python/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/mne-tools/mne-python/compare/0fff718f956ad86fb8b9154f87e6414c64c758c4...da63764bd7f305954bc98cce780d2aef0fff6e40
[cc-pull]: https://codecov.io/gh/mne-tools/mne-python/pull/3279?src=pr

Some of the tests for reading eeglab files copy and modify existing eeglab test data. Take a look here. You could do the same - for example substituting event names with numpy.random.randint, saving and then loading with relevant eeglab reader.

Yeah, that did give me an idea @mmagnuski !

LGTM +1 for merge
@pbrusco do you confirm it works for you?


VG-3859: support for defaultTask

VG-3859: support for defaultTask

Can one of the admins verify this patch?

Current coverage is 72.19%

Merging #23 into master will decrease coverage by -0.13% as of 53b39da

@@            master     #23   diff @@
======================================
  Files          111     111
  Stmts         6949    6955     +6
  Branches       978     981     +3
  Methods          0       0
======================================
- Hit           5026    5021     -5
  Partial        512     512
- Missed        1411    1422    +11

Review entire Coverage Diff as of 53b39da

Uncovered Suggestions

+0.20% via ...ters/tree-service.js#103...116
+0.13% via ...-scroll-directive.js#151...159
+0.13% via ...ters/tree-service.js#285...293
See 7 more...

Powered by Codecov. Updated on successful CI builds.


scrollIntoView scrolls the whole page instead of just the scrollable area

Hi there,
It looks like when invoking scrollIntoView on an element inside the scrollable area the whole page is being scrolled, not just the scrollable area itself.
This issue affects test automation frameworks (such as Serenity/JS https://github.com/serenity-js/serenity-js/issues/1104) trying to interact with Perfect Scrollbar.
JSFiddle reproducing the issue:
https://jsfiddle.net/L7vfqa9x/
Recording:
https://user-images.githubusercontent.com/1089173/151190274-9e7898cd-e643-47db-8a06-733600e1779a.mp4

Did anyone found any work-around ? I am facing same issue!

Did anyone found any work-around ? I am facing same issue!

As for the fiddle above I prevent whole page scroll by just passing an object with desired behaviour parameters as documentation says.
{
behavior: 'smooth',
block: 'center',
inline: 'center',
}


Rename mapE and run

I'd like to rename mapE and run on Enumerator.
mapE is an inheritance from Scalaz, and I just don't like it much—if you already know what it means it's clear that it's about mapping an enumeratee, but something like through (which I've chosen here) or transform makes it clearer that you're attaching a pipe to a source.
run is borrowed from Play (and kind of from scalaz-stream), and I've found it potentially confusing when explaining the library to people, since for most interesting contexts it doesn't actually run anything. I've replaced it with into here (I think I'd prefer to if that weren't widely used in other libraries to indicate a conversion).
If either mapE or run were standard terms here, I'd be much more reluctant to replace them, but they're not really, and I think we can do a little better.

I think these names are much better.

@johnynek Great, glad you agree! I'll go ahead and merge this in the morning and release 0.6.0 unless anyone else is opposed.


Remove unnecessary "esnext": true

Deleted the esnext option in the xo configuration in the _package.json template file, since it’s true by default, as stated in the readme of xo.

The XO readme is reflecting master, which is not released yet.


Review and fix find references/index using domainmodel example

Adds local references to the indexed reference descriptions
Solves the problem described in  #214

Something is still not working properly with the Find References service. I changed the type of the posts attribute of Blog to E1 and started Find References on E1. The number of results (3) is correct, but the last result in the list is corrupt:

Yes, I noticed that, still had no time to look into it. :(

@spoenemann
Reference range is fixed now:

type parameter <T = AstNode> to LangiumDocument

Should I open a feature request for?


Test against an actual network

I tested the first time against itself in two containers. Apply it against a real network.

Also add commands to
git submodule init
git submodule update
# (it didn't name it right from the build)
finch tag X cyphal-tools

finch build cyphal-tools --tag cyphal-tools


More guidance on k3s ha with embedded db

I run a small mixed architecture cluster at home, armv7, armv8, x86_64. I tend to use raspberry pis for the master node and wanted to try a HA (embedded db) deployment as sometimes they just go pop.
At first I didn't realise its critical for an odd number of nodes, I understand this now.
 I was using haproxy in tcp mode to load balance across the three nodes on port 6443, eg;
k3s HA Master
frontend f_k3s_ha_master_6443
bind <IP_ADDRESS>:6443
mode tcp
default_backend b_k3s_ha_master_6443
frontend http-internal
backend b_k3s_ha_master_6443
mode tcp
server pi2node02 <IP_ADDRESS>:6443
server pi2node01 <IP_ADDRESS>:6443
server pi3node01 <IP_ADDRESS>:6443
I have since stopped doing this as simple commands would fail, eg
$ kubectl get pods --all-namespaces -o wide
Error from server (ServiceUnavailable): the server is currently unable to handle the request
I have since replaced by kube config to point to the first master node i setup
So my question;
should I be load balancing across the master nodes as it seams with my setup everything hangs off of the first master.
thanks for your help with this, k3s is really awesome

+1, it seems like the masters make no use of K3S_URL (what I was specifying as lb) after initial configuration to get the set of master URLs. I didn't see this spelled out anywhere.
I was expecting the k3s.yaml server path to point to the lb, but I guess the masters need to know the state of every other masters in order to reach consensus, so it wouldn't make sense to have masters behind an LB except in the context of N agent nodes distributed across the masters.


update main README file

@nimasmi I just realised the links to the other pages aren't set correctly. I think they don't need the package folder name. I will change them and resubmit it.

Links are fixed now.

Hi @nimasmi , I realise there's a couple of steps I missed in the initial setup, when I tried a fresh install earlier, is it ok if I add them in now.

Hi @nimasmi , I realise there's a couple of steps I missed in the initial setup, when I tried a fresh install earlier, is it ok if I add them in now.

Yep, just shout when you're ready.


Fails to install

Describe the bug
fails to install
To Reproduce
npm ci
Expected behavior
install
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: Ubuntu 18.04.3 LTS
Browser chrome

2020-01-06T06_49_50_644Z-debug.log

Try setting your dependencies to fixed versions, and try again with node v8.12.0
Be sure to remove your node_modules and package-lock.json before reinstalling node_modules.
Be sure not to update your Typescript versions in the project, as this will cause a lot of issues.

The project was originally developed with Node 10.  Try using node 10.x and run npm ci to remove and re-install all dependencies.
If you are intending to run VoTT out of the box I would recommend just installing our latest release.
To install on Ubuntu run snap install --dangerous vott-2.2.0-linux.snap


FR: mocking for request.tracer.fetch

Is it possible to mock request.tracer.fetch?
Related miniflare issue:

Currently, I think the best option for jest-environment-miniflare is to use Jest's function mocks to mock the global fetch function.
https://github.com/cloudflare/miniflare/issues/162#issuecomment-1059549646

Hey Erwin!
Circling back to this (had forgotten I raised it!), as I had a workaround, but it doesn't work since updating to latest miniflare, which provides getMiniflareFetchMock.
import { Span } from '@cloudflare/workers-honeycomb-logger/dist/logging'

export const honeycombRequestTracer = {
  addData: () => {},
  log: () => {},
  fetch: global.fetch, // ❌ now undefined...
} as unknown as Span

export const createHoneycombRequest = (request: Request, fetch?: any) => {
  request.tracer = honeycombRequestTracer
  // ❌ (getMinflareFetchMock returns a MockAgent, not fetch)
  if (fetch) request.tracer.fetch = fetch
  // ❌ and global.fetch is now undefined for some reason
  if (typeof request.tracer.fetch !== 'function') throw new Error('fetch is not a function!')
  return request
}

This is a bit of an FYI, as I plan to remove Honeycomb (which is ace!) to simplify.

ah.. I think global.fetch might have been provided by my previous workaround: https://github.com/jefflau/jest-fetch-mock
The following seems to be working:
import { Span } from '@cloudflare/workers-honeycomb-logger/dist/logging'

export const honeycombRequestTracer = {
  addData: () => {},
  log: () => {},
} as unknown as Span

export const createHoneycombRequest = (
  request: Request,
  _fetch?: () => Promise<Response>,
) => {
  request.tracer = honeycombRequestTracer
  request.tracer.fetch = _fetch ?? fetch
  return request
}

Posting as a recipe / as invitation for feedback 😊
It's used in my helper createTestContext in the context of a Sunder project:
type CreateTestContextOptions = {
  request?: Request
  env?: Env
  fetch?: () => Promise<Response>
}
/**
 * Helper that returns a `ctx` object that satisfies middlewares.
 *
 * Optionally takes a Request or Env, useful when you need to access bindings
 *
  ``ts
  const ctx = createTestContext()

  const ctx = createTestContext({ request: new Request('http://localhost/') })

  const env = createTestEnv()
  const ctx = createTestContext({ env })

  const ctx = createTestContext({ env: { MODE: 'production' } as Env })
  ``
 *
 * @see https://github.com/SunderJS/sunder/blob/master/test/helpers.ts#L9
 */
export function createTestContext(
  options: CreateTestContextOptions = {},
): MyContext {
  const event = createFetchEvent(
    options.request || new Request('http://localhost/'),
  )
  const env = options.env || createTestEnv()

  const ctx = new Context({
    event: event,
    env,
    request: createHoneycombRequest(event.request, options.fetch),
  }) as MyContext

  ctx.data.sentry = createSentryMock(ctx)
  return ctx
}


(SIMP-3290) Configure Travis to release upon tag

This commit configures Travis CI to publish a release to the PUppet
Forge and GitHub when the GitHub repo is tagged with the same version as
metadata.json.
SIMP-3290 #comment Updated simp-haveged

This PR is against the wrong branch.

Wrong branch, re-opening PR on simp-master


isinstance checks no longer appear to narrow types

 Environment data

Language Server version: 2021.5.5-pre.1
OS and version: win32 x64
Python version (and distribution if applicable, e.g. Anaconda):  3.9.5 x64
python.analysis.indexing: undefined
python.analysis.typeCheckingMode: basic

 Expected behaviour
assert isinstance(x, y) should narrow the type for x to y
 Actual behaviour
This does not appear to work anymore.
I'm confused because this is pretty core, so I even went through and uninstalled/reinstalled pylance, and hit the prompt to reactivate it just to be sure.
 Code Snippet / Additional information

pin1 = J1['1']
assert isinstance(pin1, ConnectorPin)
print(pin1)

if isinstance(pin1, ConnectorPin):
    print(pin1)

What I get when I hover over all three instances of pin1 is always this, and it freely hints and colorizes properties which do not apply (for example a property that only exists on ItemBase shows up even though a ConnectorPin is not part of the same hierarchy as ItemBase).

Again, I realize this seems absurd but I did reinstall and I know its worked in the past, so pretty confused.
Thanks

I don't have a minimal example, but thanks for your questions -- it looks like the Unknown may have been a key factor. I now have it identifying the type right, so its definitely not the isinstance directly, but instead appears to be something to do with overriding __getitem__ and the unknown.
The change I did was replace the source for the pin variable with the actual method. in other words from this:
pin1 = J1['1']
to this:
pin1 = J1.getPin('1')
In this case the code of __getitem__ is:
    def __getitem__(self, value: str) -> Optional[ConnectorPin]:
        return self.getPin(value)

In the first case (__getitem__), the pin1 variable is marked as: ConnectorPin | Unknown | None
In the second case (getPin) the pin1 variable is marked as ConnectorPin | None
So it looks like two things are happening:

Overriding __getitem__ does not have the same type implications as the underlying method, and an Unknown option is added to a method which claims to return a specific Optional class.
Asserting an item marked with Unknown type is in fact a specific type does not seem to force the type

Does this seem reasonable? I don't understand why these things would interact but I'm assuming there is something about the [ ] syntax that I'm missing?

Overriding __getitem__ should work without generating an Unknown. There must be additional circumstances at play here. If you're able to produce a minimal, self-contained repro, I can look into it further.
The type narrowing logic for isinstance does not narrow the type of an expression if the unnarrowed type is a union that contains an Any or Unknown but also includes known types. It will narrow the type if it is an Any or Unknown by itself (not part of a union). This behavior is the result of feedback and bug reports we received in the past. We could consider changing it, but such changes will likely make other pyright users unhappy.

Ok, makes sense. I will work towards trying to get a more representative sample. Thank you for your assistance.

I can't get this to reproduce anymore, with the same code, so I'm going to go ahead and close this. Thanks for the explanation :)


Camelize type for dasherized model names

#1076 - Dasherized model names throws model unregistered error.  All tests pass. @samselikoff Do see any issues surrounding this request?

Thanks!
Could you add a failing test? Also in general I like these methods to take hyphenated named - the convention throughout the codebase has been when passing model names as string to hyphenate. This would suggest to use camelize within the methods (as factoryFor already does).

I'm running into the same issue using the association helper for dasherized factories. This PR will fix, but is currently blocking me. Any updates?

@darylalexjohnson  I made a new pull request for this, based on the changes requested, that was merged yesterday (https://github.com/samselikoff/ember-cli-mirage/pull/1170).  Can we close this pull request?
cc @mfeltz

Closed by #1170


The FIFSRegistrar has the wrong ABI/jsoninterface

https://github.com/ensdomains/ens/blob/4dfe72135186fe3179b43170c1910c24f7f4e859/ensutils.js#L924
If you look at the FIFSRegistrar it doesn't have a mapping of expiryTimes so when you're debugging and use expiryTimes because you see it in the ABI, it will always return 0. That can make you think registering a domain didn't work when it did.
If you run into this issue, you can validate it worked by doing ens.owner(namehash('<your_domain>')) and hopefully it returns the owner's address.

expiryTimes is used because the same ABI is used to access the test registrar. Deleting it here would cause the examples that use the test registrar to fail.


Update label without animation?

Example: You animate the label with the initial text, after that you need to append some text to the label, but this time you don't want the animation to start all over. Is there anyway to ignore the animation and just append the text as on a regular label. Ideally it would be very helpful for the text to start animating right from the point where the animation ended but i'm assuming that would be more work.

We will just need to create a wrapper around text and move all the logic up there, so that setting the text won't trigger the animation to start over. Feel free to open a pull request.


allowIn property with classnames or id

Nice to have, allowIn property allows classnames and id's instead of only tags

I'm just exposing mousetrap's API, which I do not believe is capable of this.  If you'd like that functionality, I'd put in a request in that repo.  Thanks!


[BUG] DECENT DOCUMENTATIONS

Describe the bug
A clear and concise description of the bug.
BUG:
You want A clear and concise description of the bug.
I want A clear and concise description of the promptflow and how to deploy it.
I want to add a qdrant connection and there is no way to understand how to configure the azure openay yaml or wherever else put the damn connections
How To Reproduce the bug
Use prompt flow,
get stuck with useless docs.
Expected behavior
A documentation made for devs that guide you to deploy something that actually works

Hi @Porkechebure , thanks for reaching us, as the doc https://microsoft.github.io/promptflow/how-to-guides/deploy-a-flow/deploy-using-docker.html#connections mentioned, when build as an image, promptflow will export the connection used in your flow, that azure openai yaml is just an example, your qdrant connection yaml could be find in the build result folder.
To make it work, just config the relevant environment variable when running the image, for example, if you see
api_key: ${env:MY_CONNECTION_API_KEY}  in the qdrant connection yaml exported, then run the image with env var set via below command should work:
docker run -p 8080:8080 -e MY_CONNECTION_API_KEY=<secret-value> <image>

Those docs sucks and the docs are uncomplete.
It's the same as here:
https://github.com/microsoft/chat-copilot/issues/880
You build stuff and put up a superficial quick documentation. It doesn't work like this


Seraphis wallet workgroup meeting #1 - Monday, 2022-11-14, 18:00 UTC

On Monday, November 14, we start with regular weekly meetings of the Seraphis wallet workgroup, and all interested parties from the community that want to join. Time is 18:00 UTC on each Monday. "Location" is the Matrix room No Wallet Left Behind, #no-wallet-left-behind:haveno.network (Matrix.to link).
Following the pattern of the MRL meetings, there will be an issue to announce each meeting (like this here for the next such MRL meeting), to list possible things to discuss, and to finally post a meeting log.
For this first meeting I propose we discuss the following subjects that will help dev work to start in earnest if we can reach consensus and decide things. Feel free to comment, propose other subjects, declare some as "too early to discuss", etc.:

Confirm Seraphis wallet as our project name (see issue #15) which may influence naming, e.g. leading to a folder name of seraphis_wallet, namespace letters sw,  maybe also class names
Discuss how we name and how we may nest folders that we add to the Monero project (see issue #29); right now there is single, big new folder simply called seraphis in @UkoeHB 's development branch
Discuss and decide terminology questions:
3.1 enote (#1)
3.2 transaction id (#14)
3.3 Jamtis (#24)
3.4 transfer (#18)
3.5 type names (#13)

Note that we try a bottom-up approach for the first modules that will get coded, as discussed in an ad-hoc meeting we had recently (voice, no log available). While we certainly have a lot of important issues to discuss regarding architecture, design, and general implementation approaches, I feel that most of them are not yet ready because the project is still in a very early phase. Hopefully, things will become progressively clearer with that bottom-up work progressing, and that in turn will enable those discussions.

Re-posted here: https://github.com/monero-project/meta/issues/751


adding web testing projects

Add Web testing projects.

Done.
@MichaelSimons this PR contains all test projects.   I have verified each DockerFile and made sure that they work properly.

@HongGit - Can you summarize the next steps?  I am assuming it is to implement some automation.

@MichaelSimons and @richlander I am done integrating web testing projects into the main project.
Feel free to let me know if anything is missing.

@MichaelSimons it seems that 4.6.2 Build directory is missing in the build branch, is that by design?
In addition, please let me know once you have 4.7.2 added, I will add the corrsponding web projects as well.

@HongGit - I updated the aspnet-build branch with the latest changes from master.  There is no 4.6.2 or 4.7 sdk images.  4.7.2 is the preferred sdk to use to build these projects.

@MichaelSimons  please review the latest update.  Will you please merge and approve this PR so we could get this done?


Sign new releases

Is your feature request related to a problem? Please describe.
According to the Debian guidelines, it is a good practice to sign all releases made by a project: git tags and tarballs.

Of course, not all upstreams provide such signatures but you could request them as a way of verifying that no third party has modified the code after its release (projects such as phpmyadmin, unrealircd, and proftpd have suffered from this kind of attack).

Source: https://lintian.debian.org/tags/debian-watch-does-not-check-gpg-signature
Describe the solution you'd like
Sign git tags and tarballs.
For the tarballs, please ideally use the same name + .sig or .sign (or similar).
Describe alternatives you've considered
It is a recommendation that seems to make sense, up to you ;-)
Additional context
It is common to see .sig or .sign files for projects strongly linked to the Linux kernel, e.g. iproute2, iwd, libnl, etc.

Additional Notes
GitHub Documentation: Signing tags
Debian Wiki: Creating signed GitHub releases

@ossama-othman : I see that the v0.10 release has been signed (there is a .sig file), thank you for that!
I'm just confused now because this task is planned for v0.11. Do you still need to do more?
What is probably missing is to publish the public key somewhere, e.g. wiki, doc, keyserver.ubuntu.com :-)
(and maybe have this key signed by others :) )
$ gpg --verify mptcpd-0.10.tar.gz.sig
gpg: assuming signed data in 'mptcpd-0.10.tar.gz'
gpg: Signature made Fri 24 Jun 2022 22:43:05 CEST
gpg:                using RSA key CFD26ABD50BEDF3FC7E018403EF2B8C1B2BD215A
gpg: Can't check signature: No public key

I'm just confused now because this task is planned for v0.11. Do you still need to do more? What is probably missing is to publish the public key somewhere, e.g. wiki, doc, keyserver.ubuntu.com :-) (and maybe have this key signed by others :) )

@matttbe I was planning on adding a Makefile target to generate the .sig file, but I didn't get around to doing that for the v0.11 release.  I also uploaded my public key to keyserver.ubuntu.com, but it hasn't been signed by anyone else yet.


Description for gulpfile

Now in gulp v4 it's possible to specify descriptions for tasks.
What do you think about ability to specify a short description for the whole gulpfile?
E.g. if this short description would contain a project name, it'd be convenient to see the project name when running the task (currently all gulpfiles are usually named the same for easier cli usage).
Looks like both tools (gulp-cli and IDEs) would benefit.

Not sure how something like this would work.  I really dislike adding APIs to the main gulp package/namespace to support display things.

Reluctance to extend API is understandable. Actually, the issues came from https://youtrack.jetbrains.com/issue/WEB-19115.
For instance, some other build tools allow to specify description, e.g. Ant
https://ant.apache.org/manual/using.html
<project name="MyProject" default="dist" basedir=".">
  <description>
    simple example build file
  </description>
  ...
</project>

I was thinking of exporting description via module.exports as a possible solution.

Give the default task a description and use that?

I think that's a decent compromise but I think people might already be using descriptions on default tasks (not sure).

Didn't think about it. Indeed, it's a good compromise. However, as a long-term solution, seems a task's description and a gulpfile's description have different goals. A task's description provides information about what this particular task does (likely, starting with a verb) and a gulpfile's description is just a common description of the gulpfile (likely, a project name).
Please feel free to close this issue if there are no plans to support this feature.

Would be a hack, but I think it then compromises the semantic value of the description. Especially if the tasks then have their descriptions used in an IDE, say for instance if you had 'build debug version on localhost' as a description for the default 'build' task that would conflict with what you might want to name the file for instance 'my awesome project'.
Then in an IDE your gulpfile would either be labeled 'build debug version on localhost', semantically incorrect/confusing. Or it's labeled 'my awesome project', but your default 'build' task that 'build[s your] debug version on localhost' would then be called 'my awesome project' too. Which means that descriptions end up exhibiting less semantic value than original names, undermining the description concept.
You could have a dummy/empty default task and give it a description, but then that undermines the concept of a default task.

@segrey we wouldn't be able to use module.exports because we now load tasks from that if they are exported (to support babel's export-to-commonjs transform).

@phated right, actually module.exports was not a great option because of mixing different styles (gulp.task(...) and module.exports). Maybe just gulp.description('My project') or something else.

I really don't want to expose an API for this.  Maybe if we get the .gulprc stuff wrapped up, we can put it as a property in there.

Moved to gulpjs/gulp-cli#70 so I'll close this here.

@segrey Great news!  We will soon support custom top-level descriptions through the use of a .gulp.* file.  Please review https://github.com/gulpjs/gulp-cli#configuration and let me know if that works for you.  You will be able to read the description from the JSON object returned from --tasks-json as the top-level .label property.

@phated Great! It works for me.


use dumb-init as PID1 process for containers

What is the purpose of this change? What does it change?
adds dumb-init to fix the issue with orphaned processes, because there was no init process in a container to clean it
more at https://github.com/redhat-developer/odo/issues/1076#issuecomment-444642582
Was the change discussed in an issue?
fixes #1076
How to test changes?
it requires a new version of initContainer image with this PR https://github.com/redhat-developer/odo-supervisord-image/pull/8
build new odo-supervisord-image inside minishift instance
eval $(minishift docker-env)
docker build -t quay.io/openshiftdo/supervisord:0.5.0 .

now you can build odo with this patch and run it as usual
Tests will be failing until quay.io/openshiftdo/supervisord:0.5.0(with https://github.com/redhat-developer/odo-supervisord-image/pull/8)  is released

:white_check_mark: odo build 723 completed and artifacts can be found here (for commit https://github.com/redhat-developer/odo/commit/4a782e0729 by @kadel)

Merging based on 3 acks


Set 1.12 branch as default

Maybe we should do this. There's still confusion over the package name.

Not a real issue. Closing.
1.12 was released at night, I just had no power to announce it or switch the branch at night.