[ZEPPELIN-4948] Update Neo4j Driver

What is this PR for?
This PR adds the support to Neo4j 4.x
What type of PR is it?
[Improvement]
Todos

[x] - Bumbed driver version
[x] - Added support to neo4j databases via neo4j.database property
[x] - Updated documentation
[x] - Switched tests to Testcontainer as the Neo4j test harness is packaged for Java 11

What is the Jira issue?
ZEPPELIN-4948
How should this be tested?
You can use the provided dataset into the test and run the same Cypher queries via the Zeppelin UI
Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No (the driver has packages&class renaming but support the same Neo4j version)
Does this needs documentation? Yes (provided)

I understand what your intention is. I think your case is so limited but I believe that keeping current rule is one of the most important things to keep the style of code. Could you please do it?

@jongyoul most of the interpreters define dependencies that are specific for them in their local pom.xml, like, here - this artifact is only for Neo4j, and I think it makes no sense to pollute the top level pom.xml with interpreter-specific dependency.   If we want to enforce that, we need to do this for all interpeters
But It makes sense to have common dependencies moved out...

Hello,
It feels quite difficult to make the rule that which are located in common
and particular. I personally like to locate in one place because any
dependency can be added in another pom.xml after it’s added in one specific
place. it might not be a problem but it can make multiple version issues.
We already had the issue related to multiple version and it’s too difficult
to solve it.
I understand this dependency would be only in Neo4j but I think it would be
better to define in common place with the version information and add it on
a specific sub module until we decide the exact rule.
WDYT?
2020년 7월 19일 (일) 16:22, Alex Ott<EMAIL_ADDRESS>작성:

@jongyoul https://github.com/jongyoul most of the interpreters define
dependencies that are specific for them in their local pom.xml, like, here

this artifact is only for Neo4j, and I think it makes no sense to pollute
the top level pom.xml with interpreter-specific dependency. If we want to
enforce that, we need to do this for all interpeters
But It makes sense to have common dependencies moved out...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/zeppelin/pull/3851#issuecomment-660601344, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AA3R7FU5SANIU3D2OOPZEGLR4KNJ3ANCNFSM4OX6AIVA
.

--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

@alexott Moreover, I, entirely, know that it’s really difficult to enforce something in opensource project and Zeppelin doesn’t has done like it. But I believe that we could guide as much as we can.

@jongyoul done

@conker84
Please remove the zeppelin-web/package-lock.json out of this PR. This changes aren't related to this PR.

@conker84
Please remove the zeppelin-web/package-lock.json out of this PR. This changes aren't related to this PR.

I guess that there is something broken in the build process of zeppelin-web, and definitely it should be gitignored...

@conker84
Please remove the zeppelin-web/package-lock.json out of this PR. This changes aren't related to this PR.

I guess that there is something broken in the build process of zeppelin-web, and definitely it should be gitignored...

According to npm help package-lock.json is intended to be checked into source control.

@conker84
Please remove the zeppelin-web/package-lock.json out of this PR. This changes aren't related to this PR.

I guess that there is something broken in the build process of zeppelin-web, and definitely it should be gitignored...

According to npm help package-lock.json is intended to be checked into source control.

@Reamer can you explain what happened here?
Why buy just building the project it created these differences? I'm not so good at FE so I want to understand what I did wrong.
The package-lock.json in the master branch is not the correct version?

@conker84
Please remove the zeppelin-web/package-lock.json out of this PR. This changes aren't related to this PR.

I guess that there is something broken in the build process of zeppelin-web, and definitely it should be gitignored...

According to npm help package-lock.json is intended to be checked into source control.

Yes I know but in my experience, I think that it's better to have it ignored as then it generates a lot of these situations where the user just builds the project and generate the file with the same content but shuffled.

@conker84
Please remove the zeppelin-web/package-lock.json out of this PR. This changes aren't related to this PR.

I guess that there is something broken in the build process of zeppelin-web, and definitely it should be gitignored...

According to npm help package-lock.json is intended to be checked into source control.

@Reamer can you explain what happened here?
Why buy just building the project it created these differences? I'm not so good at FE so I want to understand what I did wrong.
The package-lock.json in the master branch is not the correct version?

@conker84
Please remove the zeppelin-web/package-lock.json out of this PR. This changes aren't related to this PR.

I guess that there is something broken in the build process of zeppelin-web, and definitely it should be gitignored...

According to npm help package-lock.json is intended to be checked into source control.

@Reamer can you explain what happened here?
Why buy just building the project it created these differences? I'm not so good at FE so I want to understand what I did wrong.
The package-lock.json in the master branch is not the correct version?

I think this occurs because of the --no-lockfile option at https://github.com/apache/zeppelin/blob/master/zeppelin-web/pom.xml#L86.
I think the dependency versions in package-lock.json are not taken into account and npm tries to resolve all dependencies based on package.json.

@conker84
Please remove the zeppelin-web/package-lock.json out of this PR. This changes aren't related to this PR.

I guess that there is something broken in the build process of zeppelin-web, and definitely it should be gitignored...

According to npm help package-lock.json is intended to be checked into source control.

@Reamer can you explain what happened here?
Why buy just building the project it created these differences? I'm not so good at FE so I want to understand what I did wrong.
The package-lock.json in the master branch is not the correct version?

I think this occurs because of the --no-lockfile option at https://github.com/apache/zeppelin/blob/master/zeppelin-web/pom.xml#L86.
I think the dependency versions in package-lock.json are not taken into account and npm tries to resolve all dependencies based on package.json.

So basically, correct me if I'm wrong, the reason for the package-lock.json exists, resolve the same dependencies for everyone in order to guarantee the that everyone tests the application in the same scenario, is completely ignored. Am I right?

@conker84
Please remove the zeppelin-web/package-lock.json out of this PR. This changes aren't related to this PR.

I guess that there is something broken in the build process of zeppelin-web, and definitely it should be gitignored...

According to npm help package-lock.json is intended to be checked into source control.

@Reamer can you explain what happened here?
Why buy just building the project it created these differences? I'm not so good at FE so I want to understand what I did wrong.
The package-lock.json in the master branch is not the correct version?

I think this occurs because of the --no-lockfile option at https://github.com/apache/zeppelin/blob/master/zeppelin-web/pom.xml#L86.
I think the dependency versions in package-lock.json are not taken into account and npm tries to resolve all dependencies based on package.json.

So basically, correct me if I'm wrong, the reason for the package-lock.json exists, resolve the same dependencies for everyone in order to guarantee the that everyone tests the application in the same scenario, is completely ignored. Am I right?

I think that you are right. But I'm no frontend nor JavaScript developer.

@jongyoul any more comments?

Will merge it. BTW, @zjffdu I didn’t catch it up yet but will this PR be included in 0.9.0?

Will merge it. BTW, @zjffdu I didn’t catch it up yet but will this PR be included in 0.9.0?
@jongyoul @zjffdu
Please it would be very important having it in 0.9.0

Lemme know if I can do something to facilitate the process.

@jongyoul @zjffdu ping

@jongyoul @zjffdu please lemme know if there is any blocking issue, we also need it in 0.9 can you please explain to me what I need to do in order to have in it?

@conker84 Could you please rebase your branch.

@Reamer done.
@jongyoul @zjffdu can someone update me about the status of this? It's been awaile since the approval but is still not merged.
Moreover what I need to do in order to have it into v0.9.0 release?

@jongyoul @zjffdu ping

hi guys it would be great have feedback here!

LGTM, any more comment ? @jongyoul

@zjffdu I also approved it but I didn't set up merge-tool yet;;; Could you please merge it

@jongyoul @zjffdu can you please tell me if this will be included in v 0.9.0?

@conker84 Please update your PR discribtion and add a Travis-CI link.

@conker84 Please post a travis-ci link so that this PR can be merged into Master and Branch-0.9

@Reamer here: https://travis-ci.org/github/conker84/zeppelin/jobs/741334639

@conker84 Thanks for the link. As you can see in Travis, many tests fail.
A quick look shows that most failures are not due to your changes.
I recommend that you migrate your Zeppelin fork to the CI platform travis-ci.com

Migration-Guide for OpenSource projects
travis-ci.org will be officially closed down completely on December 31st, 2020 -> Newsletter

@Reamer I migrated but the tests still fail:
https://www.travis-ci.com/github/conker84/zeppelin/builds/199728088
please lemme know if you need any further action from my side

Please rebase your branch to current apache/zeppelin master branch.

Done

Last Travis-CI-Link: https://www.travis-ci.com/github/conker84/zeppelin/builds/199987328
Test selenium with spark module for spark 2.3 contains some flapping tests.
I'll merge this PR into master and branch-0.9.

Thank you so much @Reamer

Thank for handling it.
2020년 11월 12일 (목) 00:13, Andrea Santurbano<EMAIL_ADDRESS>작성:

Thank you so much @Reamer https://github.com/Reamer
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/zeppelin/pull/3851#issuecomment-725473544, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AA3R7FUWLSPBSL4KUPXCLSLSPKSVPANCNFSM4OX6AIVA
.

--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net


Allow cells with TRISTATE_CELL_PREFIX in SYNTH_CHECKS_ALLOW_TRISTATE

Allow cells with TRISTATE_CELL_PREFIX in SYNTH_CHECKS_ALLOW_TRISTATE

Fixes #285

Listing the variables like this has the pleasant side effect of showing that this is the odd one out--

I think I'll just turn it into TRISTATE_CELLS and add a migration function


Rendering with PIXI does not seem to work

Hi !
When i set the controller to RenderPixi, an error occur that say 'Common is not defined' (line 8601).
I forgotten something ?
I guess my problem is isolated, but if you can help me, thanks !

I've just updated the master build with this fix, can you try it?

It works ! Thanks dude


Failed test with Firefox 33 (global failure)

Error: assertion outside test context, was tests</<.success/<.success/<.success@http://localhost:8000/tests/test.js:797:33 .save/i.success@http://localhost:8000/lib/backbone-min.js:1:5387 sync/options.success@http://localhost:8000/backbone-indexeddb.js:590:26 Driver.prototype.update/writeTransaction.oncomplete@http://localhost:8000/backbone-indexeddb.js:293:17
Source:

http://localhost:8000/lib/qunit.js:431

With  Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0

Ok, closing this time until we have a fix.


llama2 support?

is this possible? or have to redo training? or ?

It does! We've tested on a custom fine-tuned llama2-7b model (remyxai/ffmperative-7b hosted on huggingface). Both models (llama 1 & 2) use the same HF code.
guidance.llm = guidance.llms.transformers.LLaMA("remyxai/ffmperative-7b", device_map="auto")

https://github.com/QuangBK/localLLM_guidance

Let me try updating, unsure if repo is still active

Any update on using LLama2 chat models with guidance ??

expect something maybe friday

it looks like @iiis-ai has a working example with llama 1 / maybe working with llama2?
https://github.com/iiis-ai/cumulative-reasoning/blob/6c8632577699a8b3f8eee88671ee83c677fa4aea/AutoTNLI/autotnli-direct.py#L22
guidance.llm = guidance.llms.transformers.LLaMA(args.model, device_map="auto", token_healing=True, torch_dtype=torch.bfloat16)
https://github.com/yifanzhang-pro/cumulative-reasoning-anonymous/blob/07bcc6b21aedbee7c82f44b52aa3c0fc123e4d03/AutoTNLI/autotnli-cr.py#L27

LLama2 works fine in the new release, both with HF transformers and with llama.cpp. Please check this out


Support for Boost Future

There should be a way to use boost::future<T> and boost::promise<T> for zk::future<T> and zk::promise<T>. Something along the lines of cmake -DZKPP_BUILD_SETTING_FUTURE=BOOST_THREAD ... While we're here, better documentation for how to use alternative future implementations.
This will help give a better answer to #107.

Hey,
We would also like to test boost::future for zk::future implementation and I was poking around looking how difficult it is to add support for it.
Unfortunately boost's exception handling in promises/futures is somewhat different than std's, which causes exceptions to be thrown with wrong types when boost::current_exception() is used.
I was looking at boost::enable_current_exception() which can fix this issue, but internally it derives a new type. This might be a solution (although not the prettiest), but all error types are declared final.
So I wanted to ask, is there any reason to mark classes final?

I use final to mark that either (1) the class shouldn't be derived from because it would break something or (2) I haven't thought about what deriving means yet. I suspect the exception classes are an example of case 2, as there usually isn't a problem with doing that.
IIRC, Boost's implementation of this stuff is supposed to resemble the Standard Library fairly closely. What version of Boost are you using that you see the problems?

What version of Boost are you using that you see the problems?

I use version from ubuntu 18.04 repos (which is 1.65.1), and I believe I did a quick test with debian 10 (1.67)
On the other hand they do mention this behaviour in their documentation
Correct implementation of current_exception may require compiler support, unless enable_current_exception was used at the time the currently handled exception object was passed to throw. Whenever current_exception fails to properly copy the current exception object, it returns an exception_ptr to an object of type that is as close as possible to the original exception type, using unknown_exception as a final fallback.

I am not sure what compilers do implement what is needed, but gcc 7.4.0 from ubuntu 18.04 repos did throw mentioned unknown_exception. This, of course, might mean, that some compiler configuration is required, but I was unable to find something related to this.

Bit of guesswork here: Boost's "as close as possible" might be pretty bad in this situation because the exception classes are marked final.

The suggestion on that to be to see if removing final from the exception types makes boost::current_exception just work (sorry if that was unclear).

While I was trying to understand this issue, I have written myself a quick, small program to test boost exception handling. Notice struct my_error does not have final specifier.
I tested that on ubuntu:18.04 and debian:10 docker containers with installed build-essential and libboost-all-dev packages, and compiled with:
g++ -std=c++17 boostExceptions.cpp -lboost_system -lboost_thread -pthread

I got output:
root@c4704b9302a9:~/source/test# ./a.out
WRONG (boost::unknown_exception)
Throw location unknown (consider using BOOST_THROW_EXCEPTION)
Dynamic exception type: boost::exception_detail::clone_impl<boost::unknown_exception>
std::exception::what: std::exception

So it seems like final is not the culprit here.

That's a good, simple test case with a rather surprising output...I suspect my understanding of boost::current_exception is off. Even simpler version has the same output:
#include <iostream>

#include <boost/thread/future.hpp>
#include <boost/throw_exception.hpp>

struct my_error {};

int main(void)
{
    boost::exception_ptr ex_ptr;

    try
    {
        throw my_error{};
    }
    catch (...)
    {
        ex_ptr = boost::current_exception();
    }

    try
    {
        boost::rethrow_exception(ex_ptr);
    }
    catch (const my_error & e)
    {
        std::cout << "CORRECT" << std::endl;
    }
    catch (boost::unknown_exception & e)
    {
        std::cout << "WRONG (boost::unknown_exception)" << std::endl;
        std::cout << boost::diagnostic_information(e);
    }

    return 0;
}

Perhaps it needs boost::enable_current_exception to be used in order to work. I'm a bit concerned over this, as cases where zkpp would call some other code that doesn't use boost::enable_current_exception.

So I decided to dig a little bit deeper.
When boost::current_exception() is called, internally it maps to boost::current_exception_impl(), which in turn calls boost::exception_detail::clone_current_exception() this function returns exception_detail::clone_current_exception_result::not_supported (more on this later).
When not_supported is returned from clone_current_exception() it does still fallback to handle most of (maybe all of) the std exception types and some boost types. But in our case - none of the handlers managed to pickup the exception, so catch-all case, which maps to boost::unknown_exception takes over.
Looking at declaration of boost::exception_detail::clone_current_exception() it is obvious, that without BOOST_ENABLE_NON_INTRUSIVE_EXCEPTION_PTR define previously mentioned not_supported is returned always. I did miss this define, but, unfortunately, after adding it the behaviour did not change. Looking at the implementation of the boost::exception_detail::clone_current_exception() it turns out, that when internal variable exception_info_offset is negative, the same not_supported is returned always. And looking at its definition it turns out, that the only compiler which is in fact supported is MSVC :( .
When boost::enable_current_exception() is used we can see that the type is wrapped in exception_detail::clone_impl, which is one of the types handled in boost::current_exception_impl() when not_supported is returned by boost::exception_detail::clone_current_exception().
So it seems that, for gcc or clang or any other non-msvc compiler boost::enable_current_exception() is required. Good news (which was worrying me before), that std exceptions are handled correctly. And I did test this, it worked.


cmake format

ENH: Add cmake-format config and script
STYLE: Apply ./Utilities/Maintenance/cmake-format.bash --tracked

Beautiful @thewtex :100:. A few questions/comments:

Will this format any change made to the CMake files locally prior to a commit? If not, do you think it can be done within the scope of this PR?
Will this trigger a GHA linter workflow for CMake files? If not, do you think it can be done within the scope of this PR?
IIRC, in the early days we adopted/CMake used to use uppercases for its commands, but then switched to lowercases. Will this change them to lowercases as well ? If not, can that be done through the config file.
Can we add a short description to the body of both commit messages?

Will this format any change made to the CMake files locally prior to a commit? If not, do you think it can be done within the scope of this PR?
Will this trigger a GHA linter workflow for CMake files? If not, do you think it can be done within the scope of this PR?

I will look at adding it to pre-commit hooks and GitHub Actions in follow-up work.

It has support for pre-commit. I think we should consider adopting it, but that is a bigger effort.

Thanks Matt. I'll open the corresponding issue to keep track of it.

IIRC, in the early days we adopted/CMake used to use uppercases for its commands, but then switched to lowercases. Will this change them to lowercases as well ? If not, can that be done through the config file.

Yes, it takes care of the command case, in addition to many other nagging items! 💅

Beautiful :100:.

Can we add a short description to the body of both commit messages?

Yes, done. I also added our *.wrap for formatting.

Thanks Matt. You rock.


Add qualified_code option to all impl and test tags

What is the change?
Adding an option to all impl and test tags to denote whether or not the requirement it's attached to applies to Pylot or Nala.
Why is the change being made?
So we know if a change affects the baseline of either project and who to include on SCRs.

Checklist

[x] This PR has only one purpose or idea.
[x] Tests have been added/updated to verify any new/changed code.

[x] The code style follows good practices.
[x] The commit message(s) follow good practices.

[x] The release notes have been updated if necessary.
[x] The documentation is still up-to-date in the doc folder.
[x] The dependencies are still up-to-date in pyproject.toml.

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

We'll leave this closed for now and reopen it if something happens and ARMI doesn't get its own requirements.


Misc updts

@jbech-linaro fyi sgdisk patch in 3rd commit

Reviewed-by: Joakim Bech<EMAIL_ADDRESS>

You could even add a "Fixes #18" to the commit message if you want to, no strong opinion however.

You could even add a "Fixes #18" to the commit message if you want to, no strong opinion however.

I thought about it, but realized #18 is a PR. Can a PR fix another PR?

You could even add a "Fixes #18" to the commit message if you want to, no strong opinion however.

I thought about it, but realized #18 is a PR. Can a PR fix another PR?

The PR is closed already, I was more thinking about an indication as a reference in the commit message.

You could even add a "Fixes #18" to the commit message if you want to, no strong opinion however.

I thought about it, but realized #18 is a PR. Can a PR fix another PR?

The PR is closed already, I was more thinking about an indication as a reference in the commit message.

Ok. Both tag and reference added.
@hzhuang1 @fboudra Please merge if ok. Thanks!


Use standard lib errors to replace most uses of github.com/pkg/errors

What this PR does / why we need it:
This PR refs #11994 and removes the package github.com/pkg/errors from many parts of the code base, aside from the instances of errors.Wrap, errors.Wrapf, and errors.Cause from github.com/pkg/errors. I'm unsure how the Helm team might want to solve the replacement of Wrap(f), so maybe we can discuss that in another issue.
Special notes for your reviewer:

Replaced githubErrors.Errorf with fmt.Errorf
Replaced githubErrors.New with errors.New
Replaced githubErrors.Is with errors.Is

If applicable:

[ ] this PR contains documentation
[x] this PR contains unit tests
[ ] this PR has been tested for backwards compatibility

Phew. Thanks for the comprehensive PR @jgsheppa . Due to the sheer size of the changes here (thanks again), I think the best way to get this reviewed and merged is:
a) clearly understand what is the behavioural differences between the new and old libraries (e.g. https://github.com/helm/helm/issues/11994#issuecomment-1537540745)
b) confirm that the PR only does a mechanical substitution for the above
Overall, yes, helm needs to move from the now long deprecated github.com/pkg/errors package. But the project needs to ensure compatibility with existing usecases.
I will raise this with the helm maintainers, and try and get traction for review.

@gjenkins Thanks for the update! After creating this PR I set it to draft because the problem seemed more complex than I originally anticipated. I look forward to hearing what the team has to say!


Deselection

Depends on #53
This allows for clearing the current selection
Please review @Jogan or @ireneduke

Can this please be merged @Jogan @ireneduke


Set message type for ros topic display

Set message type for ros topic display to show topic name candidates with combo box.

@clalancette could you review this, please?

@jacobperron @clalancette friendly ping

The change looks okay to me, but should we expect any difference in behavior when running rviz? I couldn't notice any difference making wonder if there is just some dead code lying around.

Ah, I see. We were already setting the message type in MessageFilterDisplay:
https://github.com/ros2/rviz/blob/31380f8fe65695d4f92dc2846c29a2f0a982787f/rviz_common/include/rviz_common/message_filter_display.hpp#L63-L64
This PR does the same of the few default displays that are not using MessageFilterDisplay.

@jacobperron Yes, this shows topic candidates whose type is the target topic type in combo box.


Hidden dependency on Sexperience

I got the following report on Discord:
[...] i ran into a thing where loading the mod throws up an
error about not being able to add sex trait and references vanilla genes expanded (which i dont use)
- so i added that mod but still got the error, regardless of load order,
and showed log to someone else and it might be
something to do with not finding sexperience mod
(which i dont use and dont plan on using)

HugsLog Link
Error Message:
Could not resolve cross-reference: No RimWorld.SkillDef named Sex found to give to VanillaGenesExpanded.GeneExtension VanillaGenesExpanded.GeneExtension
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 39)

Could not resolve cross-reference: No RimWorld.SkillDef named Sex found to give to VanillaGenesExpanded.GeneExtension VanillaGenesExpanded.GeneExtension
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 39)

I asked Ameravashi and he pointed me to this Genie patch. It should be fixable with just a MayRequire


Use defineConfig from vitest/config inside vite.config.ts in doc

Describe the bug
https://vitest.dev/config/#globals this doc says you use defineConfig form vitest/config inside a vite.config.ts, I'm not certain if this is intentional or a mistake.

Reproduction
Just visit the link above.
System Info
Not related

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

It is intentional. The Vitest Config Reference says that you have two options for the vitest.config.ts file. You can import defineConfig from either 'vite' or 'vitest/config'.

However, I have problems in both cases if I import defineConfig from 'vite' because I get the following type error at the test property.

I'm running vite v2.9.16 and vitest v0.32.0.


Update intro.md with links to documentation of main components.

Added links to the documentation of main components in the intro.md
See Issue https://github.com/scaffold-eth/se2-docs/issues/27

Thanks @OwlWilderness 🙌, I think this makes sense to me!
@OwlWilderness could you please resolve the conflicts, also let's see what others have to say

Lgtm!

Hardhat for running local networks, deploying and testing smart contracts.

Should we add Foundry here? Like «Hardhat or Foundry for running local networks, deploying and testing smart contracts.»
Or should we wait until CLI branch is merged?

lol, never mind. It'll be there when fixing the conflicts :)

lgtm as well w/conflicts fixed! Thank you @OwlWilderness!!

Thank you all.

Looks good, Thanks @OwlWilderness merging this 🙌


Using gedcomq: 2019/12/23 12:39:36 expected expression

I downloaded v37.0.3 for Windows, and am trying to run gedcomq. I keep getting the error "2019/12/23 12:39:36 expected expression" without any context. When I enter only a gedcom filepath, I get the following:
-format string
Output format, can be one of the following: "json", "pretty-json", "gedcom" or
"csv". (default "json")
-gedcom value
Path to the GEDCOM file. You may specify more than one document by providing
-gedcom with an argument multiple times. You must provide at least one document.
A few examples of this command on the main README.md would be great

Can you please provide the complete command that is failing?


Could not get all channel names, received: Failed to connect before the deadline on Endorser

Loaded 0.0.11 version image in IBM-Blockchain/blockchain-vscode-extension. Ubuntu 20.04.
Error connecting to environment 1 Org Local Fabric: Error querying channels: Could not get all channel names, received: Failed to connect before the deadline on Endorser- name: Org1 Peer, url:grpc://org1peer-api.127-0-0-1.nip.io:8080, connected:false, connectAttempted:true
Ran the docker image 0.0.11 and all other higher versions in VS Code (v 1.79) Docker extension interactive mode as well as in terminal, log shows same error.
29/06/2023 21:18:30] [INFO] connecting to fabric environment
[29/06/2023 21:18:30] [INFO] startFabricRuntime
[29/06/2023 21:18:31] [INFO] CUSTOM_IMAGE=$@
[29/06/2023 21:18:31] [INFO] if [ -z "$CUSTOM_IMAGE" ]
[29/06/2023 21:18:31] [INFO] then
[29/06/2023 21:18:31] [INFO]     START_IMAGE="ibmcom/ibp-microfab:0.0.11"
[29/06/2023 21:18:31] [INFO] else
[29/06/2023 21:18:31] [INFO]     START_IMAGE=$CUSTOM_IMAGE
[29/06/2023 21:18:31] [INFO] fi
[29/06/2023 21:18:31] [INFO] echo "Using image: $START_IMAGE"
[29/06/2023 21:18:31] [INFO] CONTAINER=$(docker ps -f label=fabric-environment-name="1 Org Local Fabric Microfab" -q -a)
[29/06/2023 21:18:31] [INFO] Using image: ibmcom/ibp-microfab:0.0.11
[29/06/2023 21:18:31] [INFO] if [ -z "$CONTAINER" ]
[29/06/2023 21:18:31] [INFO] then
[29/06/2023 21:18:31] [INFO]     export MICROFAB_CONFIG='{"port":8080,  "endorsing_organizations": [{"name": "Org1"}],"channels": [{"name": "mychannel","endorsing_organizations": ["Org1"]}]}'
[29/06/2023 21:18:31] [INFO]     docker run -e MICROFAB_CONFIG --label fabric-environment-name="1 Org Local Fabric Microfab" -d -p 8080:8080 $START_IMAGE
[29/06/2023 21:18:31] [INFO] else
[29/06/2023 21:18:31] [INFO]     docker start ${CONTAINER}
[29/06/2023 21:18:31] [INFO] fi
[29/06/2023 21:18:31] [INFO] 7d78679f884fad5949bc7b8fff21cf52be146de4f20a7ea4c7fd52421ce37061
[29/06/2023 21:18:32] [INFO] sleep 2
[29/06/2023 21:18:34] [INFO] exit 0
[29/06/2023 21:19:09] [ERROR] Error connecting to environment 1 Org Local Fabric: Error: Error querying channels: Could not get all channel names, received: Failed to connect before the deadline on Endorser- name: Org1 Peer, url:grpc://org1peer-api.127-0-0-1.nip.io:8080, connected:false, connectAttempted:true

$ ping server.127-0-0-1.nip.io
PING server.127-0-0-1.nip.io (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from localhost (<IP_ADDRESS>): icmp_seq=1 ttl=64 time=0.064 ms
64 bytes from localhost (<IP_ADDRESS>): icmp_seq=2 ttl=64 time=0.077 ms
64 bytes from localhost (<IP_ADDRESS>): icmp_seq=3 ttl=64 time=0.052 ms
64 bytes from localhost (<IP_ADDRESS>): icmp_seq=4 ttl=64 time=0.056 ms
64 bytes from localhost (<IP_ADDRESS>): icmp_seq=5 ttl=64 time=0.049 ms
64 bytes from localhost (<IP_ADDRESS>): icmp_seq=6 ttl=64 time=0.050 ms
64 bytes from localhost (<IP_ADDRESS>): icmp_seq=7 ttl=64 time=0.032 ms
^C
--- server.127-0-0-1.nip.io ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6141ms
rtt min/avg/max/mdev = 0.032/0.054/0.077/0.012 ms


Relax regression script to run on more bugs

I guess @Archaeopteryx is aware of this ?

I guess @Archaeopteryx is aware of this ?

I hadn't mentioned it. Basically, this is going to add the "regression" keywords also on intermittent-related bugs which are clearly regressions, so in the end it should help bring more attention to those bugs.


Android uninstall 31

Objective

Related to #2514 - not sure if it's a proper fix long term
CI was complaining Error: Path "/usr/local/lib/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang" was not found
A lot of questions started popping up 10 days ago about "android build tools 31 corrupted"

https://stackoverflow.com/questions/68387270/android-studio-error-installed-build-tools-revision-31-0-0-is-corrupted

Uninstalling "build-tools;31.0.0" doesn't seem to work, as it removes other components even though "build-tools;30.0.3" are available

Solution

Uninstalling "platforms;android-31" seems to do the trick and cargo-apk stops trying to target ...31

Android is not my thing, this solution was found with a lot of trials and errors. I am not sure how long term it is, I don't know the release schedule of android build tools, or if we need to target this 31 thing. I just wanted to stop all those failed ci everywhere...

bors r+


Cache random suggested content

The state gets executed again when user sends their response, this sops us from getting a different set of random articles

+1


Not working with imageSource

Any idea whats going on here?
The error I get is:
Argument of type '{ image: ImageSource; }' is not assignable to parameter of type 'RetrieveTextOptions'.
  Types of property 'image' are incompatible.
    Type 'ImageSource' is not assignable to type 'string'.

        let img = imageSource.fromFile('~/ocrtest.png');

        ocr.retrieveText({
            image: img
        }).then(result => {
                dialogs.alert({
                    title: "Scan OK",
                    message: result.text,
                    okButtonText: "Sweet"
                });
        }, error => {
            dialogs.alert({
                title: "Scan NOT OK",
                message: error,
                okButtonText: "Mmkay"
            });
        });

@EddyVerbruggen any ideas on this?

Sorry for the slow reply. Easter and a birthday happened.
I just released 0.2.0 to npm which fixes this TypeScript issue.

I'm on {N} 3 at the moment and it seems like fromFile is async these days. Can you make sure that is or is not the case for you as well? My code:
        let img: ImageSource = new ImageSource();
        img.fromFile("~/myfile.png").then((success: boolean) => {
          if (success) {
            ocr.retrieveText({
              image: img
            }).then(result => {
              console.log(`Result: ${result.text}`);
            })
          }
        });

Yea, it is async. But I still get the same exact error. My code:
let img: ImageSource = new ImageSource();

        img.fromFile("~/ocrtest.png").then((success: boolean) => {
            console.log(success);
            if (success) {
                ocr.retrieveText({
                    image: img
                }).then(result => {
                    console.log(`Result: ${result.text}`);
                })
            }
        });

The console outputs true (result of success), but then dies with the same error when I try to call retreiveText

I stepped through the plugin and the error occurs at this line:
var tesseract = G8Tesseract.alloc().initWithLanguage(lang);

Took me a while to get it up and running again, I will post a sample project (hopefully tomorrow).
Main takeaways: add this folder to App_Resources/iOS/tessdata, download this repo and copy all eng* files to the tessdata folder (assuming you're recognizing "eng").

Including all the "cube" files? For some reason when I clone the repo it only downloads eng.traineddata, not all the other eng* files. Are those other files necessary?

Make sure you use the correct branch (really important). So press the download button at the top right of the repo and copy ALL those eng* files.
If you clone it you'll need to checkout the correct branch afterwards.

Ok I grabbed those files and added them to both the App_Resources folder and the tessdata folder I had created in xcode based on the instructions noted in the readme, but it still crashes my app. I will patiently await your sample project, thanks!

The weird thing is I never have a crash, even if I leave out the tessdata folder (it jsut complains in the log Tesseract hasn't been configured properly). So I'm not entirely sure your crash will be fixed by an example that "works on my machine". Anyway, we'll soon find out 😉

What version of Nativescript are you on? And Xcode? Thats the only thing I can think of

I randomly removed my ios platform to address a different issue and added it back, and it works! Amazing! Eddy you rock.

Sadly removing and re-adding the platform folders is sometimes required. Glad that worked for you!
I'm in the process of adding some small features to this plugin and will release an update (with the demo project) soon.


Uncaught TypeError: Cannot read property 'queu' of undefined

Fixed https://github.com/joseluisq/prelodr/commit/6959591d49bd3a75a0c68bf5feaadcc028bd1959


Configure load test environment

Context
Apply requires a TTAPI env to use for its load testing.
Changes proposed in this pull request
Config for deploying a load test environment.
It is deployed manually using make loadtest commands.
Deployed and available at https://teacher-training-api-loadtest.london.cloudapps.digital
Checklist

[x] Make sure all information from the Trello card is in here
[x] Attach to Trello card
[x] Rebased master
[x] Cleaned commit history
[x] Tested by running locally

 Create TTAPI load test environment for Apply load testing


Importing pyfftw and diplib in the same process can lead to segfaults

Component
PyDIP 3.4.0.
Describe the bug
Importing pyfftw and diplib in the same process, and having diplib try to access its own internal fftw library, can lead to segfaults.
To Reproduce
$ python -c 'import pyfftw, numpy as np, diplib as dip; dip.GaussFT(np.zeros((139, 217)), 3, [1, 1])'
Fatal Python error: Segmentation fault

(the array size above is just some awkward numbers to trigger the use of fftw)
System information:

What OS do you have? macSO 13.4.1
If PyDIP, what version of Python do you have? 3.11
If DIPimage, what version of MATLAB do you have? (type ver at the MATLAB command prompt, and copy-paste the result here). N/A
If compiled from sources, what compiler and version did you use? N/A

Note: pyFFTW was installed from their git HEAD (pip install git+https://github.com/pyFFTW/pyFFTW) as their latest release does not support py3.11 AFAICT.
I suspect we end up with two copies of fftw with incompatible ABIs which step onto another...

This is interesting. You're using the version of DIPlib on PyPI? It doesn't use FFTW at all! I don't understand what could be causing this. I would expect things like this if they both dynamically link to a different version of FFTW, which you could fix by ensuring that both use the same dynamic library.
I will have to build pyFFTW myself to test this, since there's no version for Mac aarch64 on PyPI.

Yes, this is with pypi's diplib.  For example, I can repro this by creating a clean conda environment conda create -n testenv python=3.11 fftw (configured to use conda-forge), activating it, and then installing everything from pypi (pip install diplib git+https://github.com/pyFFTW/pyFFTW).

I just came across this thread at random, but wanted to share: even if not both are using FFTW, there can be incompatibilities with libraries that emulate FFTW. This is done, for example, by MKL (using the FFTW-Wrappers) and CUDA (to some extent). Does this help?

@emmenlau Thanks! If DIPlib doesn't link to FFTW, it uses PocketFFT, which is linked statically and is written in C++, so cannot have name clashes with C functions in FFTW.

@anntzer Just to be sure, if you don't import pyfftw, it all works as expected?

Yes, even importing pyfftw after diplib makes the issue go away.

doing this with homebrew's python 3.11 make the problem go away.

The plot thickens!
I will have to find some time to install Conda and seeing if I can reproduce this issue on my end.
Are you using the Conda version of DIPlib? Could that fix the incompatibility?
Someone here claims that it's not recommended to use pip install in a Conda environment, but doesn't explain why.

Are you using the Conda version of DIPlib?

AFAICT it is not available for M1 macs(?)

I installed miniconda, and tried installing pyFFTW in a conda environment. Nothing I tried has worked.
Anyway, if you have an FFTW that uses OpenMP, it might be a problem with two different OpenMP libraries loaded. DIPlib is distributed with its own copy of libomp.dylib.
Your example code, it loads FFTW first, meaning it loads whatever version of OpenMP it uses. DIPlib is loaded later and crashes when trying to use a function that uses OpenMP.
If you load the packages on the other order, it's DIPlib's version of OpenMP that is loaded, and the DIPlib function works fine. But does a pyFFTW function work in this case?

I installed miniconda, and tried installing pyFFTW in a conda environment. Nothing I tried has worked. Homebrew's FFTW is the wrong OS version (?), and it wouldn't find Conda's FFTW.

The following works for me:
C_INCLUDE_PATH=/opt/homebrew/include LIBRARY_PATH=/opt/homebrew/lib pip install git+https://github.com/rmorshea/pyFFTW@patch-1

(Normally C_INCLUDE_PATH=... LIBRARY_PATH=... pip install git+https://github.com/pyFFTW/pyFFTW would be enough (only pyFFTW HEAD is compatible with python 3.11 hence the install from git) but the very recent release of Cython 3 broke even that so you need to install from https://github.com/pyFFTW/pyFFTW/pull/359.)
If it doesn't (and you have homebrew fftw installed), can you post the error message?
Good point re: openmp, I haven't actually extensively tried running pyfftw after that (incl. trying to trigger some openmp-related code); I'll report once I get a chance to try.

Thank you! That worked.
Indeed, pyFFTW now links to 6 different FFTW libraries: for single, double and long floats, and for each of those, a serial and an OpenMP version. The OpenMP versions link to GGC's OpenMP library (/opt/homebrew/opt/gcc/lib/gcc/current/libgomp.1.dylib). DIPlib links against CLang's OpenMP library (/opt/homebrew/opt/libomp/lib/libomp.dylib, which was copied into the wheel for distribution).
I'm fairly certain that this is what you are running into.
Unfortunately, it seems I'm having no trouble using both of these at the same time. I still cannot reproduce the crash!
Is it possible that these two OpenMP libraries don't interfere with each other at all, and you're seeing a different problem?
I'm on macOS 12, maybe that makes a difference?

(I am on macos 13.4.1.)
Indeed, building pyfftw with PYFFTW_USE_PTHREADS (pthreads instead of openmp) fixes the issue.  https://pypackaging-native.github.io/key-issues/native-dependencies/blas_openmp/ looks like an interesting read; I guess there isn't really any solution except perhaps for diplib to also provide an option (not necessarily to change the default) to be built without openmp either.

You can build DIPlib without OpenMP by setting DIP_ENABLE_MULTITHREADING to off in CMake (see https://diplib.org/diplib-docs/building_cmake.html). DIPlib doesn’t offer different multithreading methods like FFTW does, the point of using OpenMP is that it makes multithreading easier.
But we can’t really offer no-OpenMP wheels on PyPI. That would double the number of builds to make and complicate deployment. And I’m guessing few people would want to install a slower version of purpose.
For people willing to build it themselves, it is possible to ensure all packages use the same OpenMP version.
It does however make sense to add some warnings regarding vendored OpenMP and potential incompatibilities between packages because of that. Just because you’re the first to bring this to our attention doesn’t mean you’re the first to run into this issue — thank you for reporting!

Thanks for your patience and helpfulness in investigating what is a rather obscure situation!
Actually I remembered that threadpoolctl (https://pypi.org/project/threadpoolctl/) is very useful in these situations; upon further investigation I realized that I had things even more messed up in my conda environment: I had (some time ago) also installed fftw via conda; my build of pyfftw did not actually link it but (as shown by python -mthreadpoolctl -i pyfftw) it still picked up conda's llvm-openmp (which comes with conda's fftw) and I now suspect that the bad collision was between conda's llvm-openmp and diplib's vendored openmp (python -mthreadpoolctl -i diplib).  Indeed, even just uninstalling conda's fftw and llvm-openmp and rebuilding pyfftw without disabling openmp leads to pyfftw using homebrew's libgomp, which does not cause problems with diplib's libomp.  (https://github.com/joblib/threadpoolctl/blob/master/multiple_openmp.md is also useful.)
So I guess if you want to be extra-safe one option would be to add a dependency on threadpoolctl (which is pure python and has no extra dependencies) and check before importing the main library that there isn't already "another" libomp loaded (and I guess pyfftw could do something similar), but I'd totally also understand if you just close this as "too obscure".

From the page linked above, copied here for future reference:

The only unrecoverable incompatibility we encountered happens when loading a mix of compiled extensions linked with libomp (LLVM/Clang) and libiomp (ICC), on Linux and macOS, manifested by crashes or deadlocks. It can happen even with the simplest OpenMP calls like getting the maximum number of threads that will be used in a subsequent parallel region. A possible explanation is that libomp is actually a fork of libiomp causing name colliding for instance. Using threadpoolctl may crash your program in such a setting.
Fortunately this problem is very rare: at the time of writing, all major binary distributions of Python packages for Linux use either GCC or ICC to build the Python scientific packages. Therefore this problem would only happen if some packagers decide to start shipping Python packages built with LLVM/Clang instead of GCC (this is the case for instance with conda's default channel).

I made a note on the DIPlib home page, and (see the commit referenced above) on the README file that will be shown on PyPI with the next release.
I think that is all we can do for now. threadpoolctl is a useful tool, but I'm not sure it would help us. Detecting there's another OpenMP library running won't tell us if the combined use could lead to issues. Would we, only on macOS, try to detect an already loaded libiomp? (since on Linux we use libgomp, and on Windows it's whatever MS library comes with the system). And what do we do if we detect the library? There's no way to not load the OpenMP library for a DIPlib that was compiled with OpenMP...

I think the note is good enough; at least it gives something to google at, and I think most people running into these weird incompatibilities are somewhat likely to be building at least some of the packages themselves and more likely to be able to figure out the problem based on your writeup.
Thanks!

And what do we do if we detect the library? There's no way to not load the OpenMP library for a DIPlib that was compiled with OpenMP...

Assuming we could really pre-detect the incompatibility (which I agree seems to complex to be worth it), I guess you could just refuse to import diplib at all (and throw an ImportError with a suitable descriptive error message).

If this becomes a more common issue, I will put in the effort for a better error message. It's a good idea. Thanks!


Hello from the GitHub Docs team! @gracevor here.

Hello from the GitHub Docs team! @gracevor here.
We’re looking to learn more about your experience with GitHub Docs and will be holding feedback sessions next week, January 25-27. These will be one-hour interview sessions, and we'll provide you with a gratuity as a thank you for your time!
Qualifications:

Must be a GitHub user (beginners are welcome!)
Must have used GitHub Docs in the past two weeks

To participate, fill out our quick survey here. We’ll reach out if you’re a fit for the study. Thank you!
Originally posted by @gracevor in https://github.com/github/docs/discussions/3005

@Close GitHub

Hi @gracevor https://github.com/gracevor,
*I’m getting this error while trying to take the survey *
[image: Screenshot 2021-02-12 at 08.03.27.png]
On Fri, Feb 12, 2021 at 3:33 AM Derar1986<EMAIL_ADDRESS>wrote:

@close https://github.com/close GitHub
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/github/opensource.guide/issues/2194#issuecomment-777928915,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADZEQ4PFGP55EDPNT4EA35LS6SHQLANCNFSM4XPMYHBQ
.

Thanks @devifeoma - this project has ended, I'll close this discussion. We'll post again when we have a new study going on. Thank you!


Groundnut

Can anyone share crop parameters for the groundnut crop to be used in Aquacropos-py? Thank you.

@prasvenk83 At the moment, there is not an official groundnut parameter file for AquaCrop provided by FAO. You could check the literature to see if others have applied and tested the model for groundnut as a starting point, but we don't have a default parameter set at this point for this crop (although would definitely be interesting to look into in the future)


Only one letter of stone name in transcript and other windows

at least I think it's the first letter, since it's an s and the stone name is stone3215
e.g.
Jadeite version [Oscar] 1 (SystemUser) - Transcript on s

This is what I see using the exe which is different than you describe. Could you upload a picture?
Note - I'm happy to put whatever text you'd like in the transcript window header but Dale has some strong feelings about this. So, I'd ask first that you and he coordinate on exactly what's desired.

You have an "on l" that looks suspicious... but I'll send a picture when I can run oscar again.

Much improved.  But I've looked at rowan issues 110 (me) and 130 (dale) and will file a new request for changes...


Julia changes related to the release of 1.7.0

Motivation for this change
Julia 1.7.0 is the new stable and 1.6.4 the new LTS, with support for 1.0.5 being dropped. Reflect this in Nixpkgs.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

On Wed 01 Dec 2021, 7c6f434c wrote:

@7c6f434c commented on this pull request.

@@ -62,19 +61,11 @@ stdenv.mkDerivation rec {
'';

meta = {

description = "High-level, high-performance dynamic language for technical computing";

description = "High-level, high-performance dynamic language for technical computing.";

https://nixos.org/manual/nixpkgs/stable/#var-meta-description

Don’t include a period at the end.

Well spotted, correcting for both julia_16-bin and julia_17-bin.

I wonder what are the chances that aarch64-linux will just work (say, at least build on ofborg)

On Wed 01 Dec 2021, 7c6f434c wrote:

I wonder what are the chances that aarch64-linux will just work (say, at least build on ofborg)

Nearly 100% I would say, but I would either need to take the time to get my PINE64 up and running or have my PR merged for access to the community build box 1 to be able to debug. Still, I am a bit strapped for time at the moment, so I would greatly appreciate if this could be handled separately from this PR.

Well, if there is need to debug beyond checking the build outcome on OfBorg, it would not be «just»


Integration with procedural dungeon creator

I saw https://watabou.itch.io/one-page-dungeon and thought it was interesting. I'm not sure how much integration is really needed, since you can just right click and save the image and use it (apps that work well together without direct integrations are supposed to be a good thing), but might be interesting to use it or mention in docs or guidance.

Wow, that's nicely done!
I think the main benefit of integration would be setting the grid automatically. If the token area description pull request gets added it could automatically generate those too.

Currently focusing on other things, will consider this once I got more time, in the meantime contributions from other people are welcome 😇


Add Documentation for the Project

Description:
It is recommended to add documentation to provide information about the project's usage, setup, and key features. This will help users and contributors understand the project and work with it more effectively.
Acceptance Criteria:

[ ] Documentation includes instructions on how to install and configure the project.
[ ] Key features and usage are clearly documented.
[ ] The documentation is accessible and easy to understand.

I agree with the recommendation to add documentation to the project to improve its usability and contribution. Another day I will be uploading the doc and its operation.


Block session('', () =>{}) -> screenshots are taken incorrectly.

Details
Running tests takes place in one session. We have one block of code - which, for example, goes to google.com. There is a second block of code that uses the session() feature, for example, in this block we go to jenkins.io. We make a launch, in the first session we go to the Google website, then a new session starts at the expense of features session().
A bug - for example, in the session() block of code, we expect that there will be something on the page, for example, text - it is missing, a screenshot will be taken - but unfortunately a screenshot of our first session is taken - in the screenshot, you will see a google page and not Jenkins page.

CodeceptJS version: ^2.5.0
NodeJS Version: v12.13.1
Operating System: MacOS

Given('I am go to google page', () => {
    I.amOnPage('https://google.com')
})

Given('I am go to jenkins page', () => {
session('example', () => {
    I.openNewTab()
    I.amOnPage('https://jenkins.io/')
    I.see('ewioiewo')
})
})

Dear All, we also face same issue while using codeceptjs with protractor. Where as same code works fine while using puppeteer. Any help would be appreciated.

Hi, can anyone help on this issue as we are also facing similar issue, when we are trying to take screenshot using I.saveScreenshot api it takes most of the time one step behind screenshot, for example if we are on one screen and navigated to other then on taking screenshot it takes screenshot of last screen rather than current one.
CodeceptJS version: 2.6.3
"protractor": "5.4.4",
Operating System: Windows10


Add sepolia network

Would be useful to migrate this to our util-contracts, or at least install this as a dependency there and move the deployment for ease of use


Option to enable/disable extraction round robin

Issue Description:
While creating a build to automate the Empowerer from Actually Additions I'm having issues extracting the correct items when trying to craft multiple different items at the same time.
What happens:
When extracting different items from an inventory they are extracted in a round robin mode. First some items from the first slot, then some from the second slot and so on.
What you expected to happen:
I would like an option for this to be toggled on/off
Steps to reproduce:

Place multiple different items into chest
Extract from chest
...

Affected Versions (Do not use "latest"):

EnderIO: EnderIO-1.12.2-5.1.55
EnderCore: EnderCore-1.12.2-0.5.73
Minecraft: 1.12.2
Forge: 1.12.2-<IP_ADDRESS>47
SpongeForge? no?
Optifine? no
Server

Your most recent log file where the issue was present:
[pastebin/gist/etc link here]

you can toggle it on or off

You missed my point. That option changes the destination of the extract operation. It makes it so that when multiple inventories have the same priority it cycles between them.
My issues is that the extraction is cycling through the slots in the inventory that's being extracted from.

once sec i'm talking in discord one of the devs

Why not just put filters on the imput of the display stand?

The chests containing the items are filtered. I'm trying to automate multiple recipes. That's why different items are in the chest

by filtering the display stands it will do what you want

It will not. I have 5 chests. 1 for each display stand and 1 for the empowerer. Each chest is filtered for that specific display stand. There is no point in placing a filter onto a display stand if the chest that the items are in is being filtered.

I fail to see the issue here then? if you have 5 chests and each chest is set to only get one type of item what's the issue?

I'm trying to automate 10-12 different recipes. So each chest actually allows 10-12 items.

In case I wasn't clear enough earlier, my problem is that the item conduit is extracting in such a way that it first takes items from the first slot of the chest, then the second slot and so on, even if the first slot still has items in it

No, it doesn't...

I just investigated my setup more thoroughly and concluded that my problem is that when new items enter the chest while the first slot is empty, the conduit keeps extracting from the other slots in order instead of going from the first slot again.

I'm wondering if it would be possible to add an option on the conduits themselves that would toggle between the current behaviour and always extracting from the first slot that has items

I was wondering if it would be possible to add an option, to the item conduit, that toggles between the current behaviour and always pulling from the first slot that has items.


Update action/upload-artifact Version

🗣 Description
Update the actions/upload-artifact version we use to @v2.

💭 Motivation and Context
It's good to keep up-to-date with packages/tools we use. This version adds support for uploading a single file or wildcard pattern which may be of use to derived projects.

🧪 Testing
Automated tests pass.

🚥 Types of Changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (causes existing functionality to change)

✅ Checklist

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Closing language resulted in an inadvertent closure of this PR.


Add of PostgresPathTask class

What does this PR do?
Add a PostgresPathTask class to the Postgres part of the lib to be able to require a load.
Motivation
This class is needed in a new job
(https://github.com/mortarcode/dd-analytics/tree/antoine.protard/daily_export_billing_master_terms)
Testing Guidelines
This class has been tested with the new job needing it already
and it worked well both when the Posgres load was missing or not.

@AntoinePr Could you put this in dd-analytics instead? Updating our Luigi fork is painful, we should try to limit the changes we make there. You can probably put this in luigiscripts/utils/postgres.py.

@QuentinFra Sure 👍


empty index use 100-200mb of heap?

When i set some field type with langfield in mappings, the created index
make the heap increase over 100-200m per node, soon the heap is full and  can't GC.
Dose the cost is necessary?

Can i config the support language? I haven‘t find any code for this.

I think it depends on the number of open indices.

I think it depends on the number of open indices.

Thanks for the reply.
I start a new sample with default config, and create two indexes that config same to the fess.20190219.
I have 1G for this sample.

You can see that, the heap from 500m + up to 800m +, this part can't GC.
I think the index with langfield cost to much.
Any idea about this?
Thanks


Feature request: Ability to set default nodeSelector for all of Moon

Hello,
We are currently running Moon in a cluster with mixed architecture: linux amd64 and arm64. Setting the moon.nodeSelector only sets the nodeSelector for the Moon pod (ui/api) and not any subsequent pods created by Moon. To go around this, I had to add a nodeSelector to every single browser defined in the values file. Also, it seems that the playwright urls don't work properly as well because they do not get assigned to the proper arch.
If there isn't already a way to assign a sort of global nodeSelector for Moon, could one be added so that doesn't have to be so manual?

Fixed in https://github.com/aerokube/charts/pull/59. Already available in unstable chart. Will be available during the next days in stable chart with Moon 1.9.1 release.


[Automation] Generate Fluent Lite from networkanalytics#

[Automation] Generate Fluent Lite from networkanalytics#

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-resourcemanager-networkanalytics


Remove the trailing comma if singleFile.

lodash.union will be added only when there are multiple services
in the API, but the template is wrong so that the trailing comma
is included in the dependency list if single service API, which
leads to an invalid JSON.

Current coverage is 91.23% (diff: 100%)

Merging #131 into master will not change coverage

@@             master       #131   diff @@
==========================================
  Files             3          3
  Lines           719        719
  Methods         150        150
  Messages          0          0
  Branches        116        116
==========================================
  Hits            656        656
  Misses           63         63
  Partials          0          0

Powered by Codecov. Last update 8ef5ca9...e956861


Gazebo integration

Looks fantastic. Very well done guys. Is Gazebo integration planned anytime soon?
Seems that this could add tons of value in top of ODE or Bullet.
Thanks,

Thanks for your interest. Gazebo integration is not in our plan in the near future. But in the future versions we plan to abstract away the physical simulator so you can swap bullet to for example ODE or nvidia Flex according to your need. It should be easier to integrate gazebo then.


Update eval_metric validation to support list of strings

Hey guys, I find that SparkXGB estimators do not support multiple evaluation metric because of param validation.
In this PR, I deleted the param validation for eval_metrics.

Did you test this pull request on your machine?

Did you test this pull request on your machine?

Yes, I have tested it. It works well. After deleting these three lines, I am able to train a SparkXGB model with multiple eval_metrics.

@mzzhang95 Seems eval_metric can accept str or list[str], could you add the list[str] support instead of getting rid of the validation?

@mzzhang95 Seems eval_metric can accept str or list[str], could you add the list[str] support instead of getting rid of the validation?

I added the check back. Now it will check both str and List[str] for eval_metric.

I added two unit tests for string type and list type eval_metric with ``SparkXGBoostClassifier`. Do you also wanna include regressor and ranker?
And when could this PR be merged? Will there be a release in recent? Thank!

And when could this PR be merged?

I should be able to merge it once all tests pass.

Will there be a release in recent? Thank!

Patch release for critical bug fixes only. The next major release will take some time.


feat(ios)!: upgrade facebook-ios-sdk to v12

Upgrade FBSDK to v12.1.0.  This fixes #55.
BREAKING CHANGE:

For iOS, getAdvertiserID will always return null, as the upstream FBSDK no longer provides the advertiserID
iOS minimum deployment target changes from 9 to 10, due to upstream FBSDK change
setAdvertiserTrackingEnabled always returns true now, as it will never fail; no function change from previous implementation

Here is a summary of the changes:

Updated react-native-fbsdk-next.podspec to specify FBSCK v12.1.0
Fixed compiler warnings and deprecations for iOS builds
Updated README to add additional instructions for running the example
Updated refresh-example.sh to extract the Facebook App ID into a variable
Updated example folder artifacts based on latest changes

I tested these changes by running the example and substituting my own local Facebook App ID and verified I could log in and log out with the test app.
Note: My editor trimmed some whitespace from the ends of a few lines in the README.md file, so the changes look larger than they actually are.  All the content changes I made are near the end of the file.

Thanks. Re comments:

Yes, iOS 9 to 10 is a breaking change. Sorry I missed that one in the PR notes
Yes, getAdvertiserID always returns null for iOS. I think I mentioned that in the PR notes under breaking changes
setAdvertiserTrackingEnabled returns true; it used to always return YES on success, so this mimics the same behavior.

Thanks...Gerry
On Nov 12, 2021, at 7:35 PM, Mike Hardy @.***> wrote:

@mikehardy approved this pull request.
This looks fantastic, thank you thank you
Things I saw:

iOS/tvOS 9 -> 10 is breaking
iOS always returns nil from from getAdvertiserId now
setAdvertiserTrackingEnabled always returns true now (may not be a change but easy to note with an asterisk)

...I think that's it?
The changes to the docs and making the facebook app id dynamic is a nice touch
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/thebergamo/react-native-fbsdk-next/pull/132#pullrequestreview-805314215, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD63X4D7Y5CF226SBI3UY3DULWXG3ANCNFSM5H5VFOZQ.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

No need to apologize, this is truly great. The notes were great. I should have prefaced that with a statement that I was more just "active listening" to make sure I got everything. I'll get this packed up and out the door

Alright @thebergamo - one more big ol' breaking change queued up, I always like a second set of :eyes: on them :-), specifically the commit so you can see the message here: https://github.com/thebergamo/react-native-fbsdk-next/commit/d81315358b69d0e0f87aa460bec21150a0259aeb
It worked perfectly last time for v5 and should work this time too. I considered (before releasing v5) packing them together since this was already in progress, but just in case there are still people on iOS v9 I split it so the breaking changes are in two steps, and with the previous one they get close to current on the native SDKs but maintain iOS v9. Maybe that's useful? Anyway, I never fear major versions and don't mind them coming quickly as long as the breaking changes notes are written clearly
Let me know what you think, and if it's good :rocket: :rocket:  :-)

Alright, going to go ahead and launch this after a second look myself. If I break it, I'll try to pick up the pieces :-) but hopefully it just goes. Thanks again @NiwotSmitty


How to get detailed result with java sdk

With java SDK, I found I can set output format to detail. But I didn't find to Detailed, when I create SpeechConfig. But I didn't find any way to get the detailed result like C# (with SpeechRecognitionResultExtensions).

You can read the SpeechServiceResponse_JsonResult property for the JSON output that contains details. Example:
SpeechConfig config = SpeechConfig.fromSubscription("YourSubscriptionKey", "YourRegion");
config.setOutputFormat(OutputFormat.Detailed);
SpeechRecognizer recognizer = new SpeechRecognizer(config);
SpeechRecognitionResult result = recognizer.recognizeOnceAsync().get();
String detailedResult = result.getProperties().getProperty(PropertyId.SpeechServiceResponse_JsonResult);
System.out.println("Detailed result:" + detailedResult);

Closed as answered.

Thank you!


Pressure improvement

You could get updates (even if the touch doesn't move) by listening to the 'touchforcechange' event. https://twitter.com/dasilvacontin/status/936675998246014976

Indeed. The need for it might not be there yet.
I'm closing for now.
Feel free to re-open if you really need this.


chore(agent): Delete forever daemon

copilot:all

Current dependencies on/for this PR:

main

PR #4212   👈

This comment was auto-generated by Graphite.


Apply DataZipper to FERC / EIA Plant Mapping

Once the FERC plants time series are being reliably generated automatically (#144) and the DataZipper has been implemented in a general way that works for integration of EIA and EPA CEMS data (#208), it can be applied to the more difficult marriage of the FERC plants and EIA generation units.

How much more needs to be done on this issue? I'm looking at using PUDL for a project over the summer and would like to use the FERC/EIA connections. Let me know if there's something I can help with.

We've actually put the FERC/EIA generation unit connection on the back burner. The main reason we wanted this in the first place is to connect non-fuel variable operational expenses in FERC to EIA. Most FERC plant records are reported by plant, not by generator... but enough are reported by generator that we wanted the generator level connection. We already have the plant level connection with the plant_id_pudl. It was done by hand, but we've used them a fair amount and they seem pretty good.
All that being said, upon further look into the operational expenses reported in FERC, we realized there is not enough data or consistency for us to actual decide which expenses are variable and which are fixed, so we decided to get at the same info through a different method (Issue 204), which obviated the need for generation unit connections between FERC and EIA.
If you need the unit connections instead of plant level connections then let's figure out how to make that happen. @zaneselvans has been the one working on the zipper largely speaking and has yet to implement it for the EIA/CEMS connection but has made a lot of good progress.

Good to know that plant matching is done and this is about generator level. The regression method in #204 is probably along the lines of what I'm looking for. And the PJM report might even be enough.
I'm still a couple months away from doing any work but am starting to scope out the LOE and where I'll be getting data from. My plan is to fork PUDL, use the EIA (and maybe FERC) portions for generator data, and then add data of my own. Hopefully I can then offer some of the new data back for other ppl to take advantage of.

Oh great! I hope (fingers crossed) that the regressions will be done and incorporated with a couple of months... @alanawlsn and @zaneselvans have been exploring methods for a while now.

The plant_id_pudl breaks things down by physical facility, but doesn't differentiate between different fuels or owners.  However, we have additional information from the fuel table, which allows us to identify plant records that pertain to coal vs. gas plants (e.g. more than 90% or whatever threshold you want of the overall heat content came from one or the other fuel), and we have the utility_id_ferc1 that tells you who owns the plant. Adding up all the ownership slices within each fuel type, and treating that as a "generator" yields a believable distribution of fuel costs and heat rates. Really this almost certainly groups multiple coal units together, and multiple gas units together.  However, it may be possible to differentiate those units from each other based on the plant_id_ferc1... but we haven't gotten that far yet.
Glad you're finding it all useful, and I hope we get to merge some of your work in! After spending way too much time on grant writing we've finally gotten back to the code in the last week or two.

Here's what the heat rates look like right now, weighted by net_generation_mwh -- pretty clean! This is cumulative from 2004-2017.

And here's a comparison of "generator" level heat rate distributions (i.e. plants chopped up by major fuel) for coal and gas plants across the years that we have data from both FERC & EIA, normalized so they have the same scales. Pretty darned similar!

Interestingly, the correspondence for fuel costs on a $/MWh basis is not nearly as good, at least for natural gas, where FERC appears to report that gas is systematically more expensive than EIA. I wonder if this is because co-ops and public power companies and some IOUs in competitive markets don't report to FERC? What else could it be?


Update build_rocgdb.sh to set rpath

This looks like the correct way to do it, but it doesn't work. Possible that's related to the specific configure script.

Fixed by Greg via export LDPATH


Improve and add detail to deployment instructions

Improve deployment instructions, adding information about newer configurations/annotations necessary for the application to function.
Include at least:

OIDC configuration and OAuth
console-listener annotation
UI deployment alongside API
Comment console-specific options in example resources/YAML
How to enable/disable operations or make read-only (#58)

Completed in #422 based on feature set supported at the time.


L&S - "Gray" flora art asset

Idea to go with the "card suit color" flora blocks - an "unclaimed" version of the suit flowers that the player could tag with a tool of some sort to turn into flowers following their side, yielding some sort of benefit like territory claim / regeneration for nearby friendly.
Edit: There are existing faction-specific versions at https://github.com/Terasology/LightAndShadowResources/tree/master/assets/blockTiles/flora

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1359759-l-s-gray-flora-art-asset?utm_campaign=plugin&utm_content=tracker%2F5279&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F5279&utm_medium=issues&utm_source=github).

Moved to https://github.com/Terasology/LightAndShadow/issues/43.


Updated the Wrong source code link in api doc

update the wrong link of source of LudwigModel class in api doc

Hi @Praneet460 thanks for your PR.
It seems like you updated the links correctly, but there are a bunch of other changes (like dataset_csv and the lack of the skip_* parameters) that look like they are from previous version of the api.py file. Please merge master into your branch to override those changes and keep only the ones related to the wrong link, so that i can then merge it.
Cheers.

Most of the suggested edts have already been made on master. Thank you anyway.


Android Status Bar properties being overwritten

The status bar for Android is being set to a solid blue/purple background colour. This is a known issue that I have subscribed to on Expo's Github page here. The contributors of this discussion have experienced what we see in our app and what I have seen while tackling this issue.
What I tried (also the recommended configuration suggested by Expo here ):
In app.json:
"androidStatusBar": {
    "barStyle": "light-content", // default value
    "backgroundColor": "#00000088" // semi-transparent black for `light-content`
  },

and in src/components/main/main_component.tsx
export const MainComponent = (props: Props): JSX.Element => {
...
StatusBar.setBarStyle('light-content');
StatusBar.setBackgroundColor('#00000088');

What I saw:

When loading the JS Bundle, the StatusBar aligned correctly with what was set in app.json.
On initial mount of the homepage, the StatusBar still shows as being solid blue/purple.
The StatusBar changes background colour to be consistent with the configuration only once I do an action on the i.e switch screens, bookmark a topic.

Acceptance Criteria
The following StatusBar properties are consistent throughout usage:

[ ]  translucent: true
[ ] barStyle: 'light-content'
[ ] backgroundColor: '#00000088'

Steps for QA:

Load the app:

[ ] ensure the status bar has the properties found in Acceptance Criteria

Once the app loads:

[ ] ensure the status bar has the properties found in Acceptance Criteria

Upon navigating to different screens:

[ ] ensure the status bar has the properties found in Acceptance Criteria

Waiting for Expo to fix an issue on their end, then we can proceed to fix it on our

I believe I can fix this once Expo SDK 38 is merged into our codebase. They have released a new expo-status-bar that we can use that works well with the expo-cli.

From what I observe the blue header is no longer present, adding screenshots of three different screens that have status bar that blends in with the header colour.

I still see the purple header in Expo. This seems like a low risk change, so I'd be fine to merge it and see if it's fixed in a real build, in case you think that might be the issue.

Native-bases optional androidStatusBarColor property for their Header component was overwriting our StatusBar colour.

Here are the screenshots from the latest PR which shows a darker gradient on the main color.

QA passed 1.43.0, status bar is teal by default.


Annotate 5xx client calls with an error tag

We could add error tag to client spans for returned 5xx codes.
Related issue for async server API #91

The MP-OT spec defines that error tag SHOULD be added only for 4xx (client codes). If the server side is not traced and 5xx is returned I would also consider that operation as failed or errored.

Reported in MP-OT https://github.com/eclipse/microprofile-opentracing/issues/114


[Storage] Merge hotfix branch into main

Merge the recent hotfix branch for the Storage patch releases back to main.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-storage-blob

/azp run python - storage - ci

/check-enforcer override


unable to resolve class groovyx.net.http.RESTClient

I have the following error with the latest version of helloworld
/Users/i303937/SAPDevelop/easy-extensions/helloworld/src/test/groovy/com/sap/cx/boosters/easy/extension/helloworld/controller/HelloWorldControllerSpockIntegrationTest.groovy: 8: unable to resolve class groovyx.net.http.RESTClient
 @ line 8, column 1.
   import groovyx.net.http.RESTClient
   ^

1 error

This class comes from /hybris/bin/modules/commerce-services/commercewebservicestests/lib/http-builder-0.7.1.jar so if you do not have commercewebservicestests in your list of extensions, Groovy will not be able to resolve.

As a workaround, I temporary added http-builder-0.7.1.jar to easyrest/lib.


Use CollectionProxy interface for has_many association

It seems that the rbs_rails gem assumes the use of ActiveRecord_Associations_CollectionProxy rather than ActiveRecord_Relation.
https://github.com/pocke/rbs_rails/blob/master/lib/rbs_rails/active_record.rb#L125-L141

I also checked Rails' actual behavior, and I can see that has_many association returns [ModelClass]::ActiveRecord_Associations_CollectionProxy instance.


pygbag ci for wasm wheel

nb: remember to sync from pygbag main before merging unsure what could happen otherwise.
what differs :
raylib physac raygui are not pinned and use git latest
=> that way if something upstream breaks it may show up quick in CI
what is not done yet by order of increasing difficulty:

remove the multiple python builds in yaml since the module is abi3 ok ( i need to do change yml for  that upstream anyway so almost done )
whl is not automatically set into release. see https://github.com/pygame-web/python-wasm-sdk/blob/66fd3b811f24d385bf2cde6285fb7c36cb0c5722/.github/workflows/ci.yml#L53
python files are not yet into static filesystem for quick testing from project pages, so it would still actually access the published wheel.
wasi/osmesa testing.
vendor/readme and documentation. :D

it's fast <2min ! https://github.com/pmp-p/pygbag-vendor/actions/runs/8131568714

@pmp-p I have got the wheel     raylib-<IP_ADDRESS>-cp310-abi3-wasm32_bi_emscripten.whl from https://github.com/electronstudio/pygbag-raylib/actions/runs/8191675556 .  How do I test if it works?

use same way you did for the examples list https://electronstudio.github.io/raylib-python-cffi-pygbag-examples/,  just unzip the wheel next to the main.py  and remove the "raylib" from PEP block it will pack the wheel with the sample and  force a local load after relaunching pygbag main.py

pypi does not accept any wasm wheel yet.
There is a hack to use it to provide wasm wheels but it may has side effects :
eg on https://pypi.org/project/raylib/#files if there was a py3-none-any.whl like there https://pypi.org/project/raypyc/#files
pygbag, pyodide and pyscript would install it
and pygbag would be able to load it.
meanwhile the simplest would probably be "publish a github release" ( I'll try to add something to vendor script to can do that automatically) and drop a note on https://github.com/pygame-web/pkg-porting-wasm/issues/new
ref:
https://discuss.python.org/t/support-wasm-wheels-on-pypi/21924/8
https://github.com/python/cpython/issues/96426#issuecomment-1271144421


implement reader.Statistics

Let's also implement sources.v2.reader.Statistics

Spanner doesn't return the statistics. Also David mentioned that reporting the statistics may making the performance even worse. Cleaning the issue.


Unable to use IPv6 Address Hostname with custom Port

Hello,
I am having trouble using assh to connect to IPv6 Addresses that use a custom ssh Port.
Go is returning the error

failed to dial: dial tcp: address ::1:9922: too many colons in address

How to reproduce:

Set up an SSH host to listen on a non-standard port number such as 2222 or 9922
Connect to host by IPv6 Address, not FQDN/name

Observed Behavior:

assh connect reports the following output:

~$ assh connect -p9922 ::1
Error: failed to dial: dial tcp: address ::1:9922: too many colons in address
Usage:
  assh connect [flags]

Examples:
Argument is a host.

Flags:
      --dry-run      Only show how assh would connect but don't actually do it
  -h, --help         help for connect
      --no-rewrite   Do not automatically rewrite outdated configuration
  -p, --port int     SSH destination port

failed to dial: dial tcp: address ::1:9922: too many colons in address

Expected Behavior:

Execute SSH with -p<Port#> rather than appending a ":<Port#>" to the end of the connection request.

Troubleshooting:

I tried to wrap the IPv6 Address with '[' and ']' but this does not help.
I updated to the latest version (go get -u moul.io/assh/v2)
Verified SSH is able to connect without using assh /usr/bin/ssh -p9922 ::1

This does not appear to be a problem with custom ports only:
$> ssh 2601:280:c100:5d3::1
Error: failed to dial: dial tcp: address 2601:280:c100:5d3::1:22: too many colons in address
Usage:
  assh connect [flags]

Examples:
Argument is a host.

Flags:
      --dry-run      Only show how assh would connect but don't actually do it
  -h, --help         help for connect
      --no-rewrite   Do not automatically rewrite outdated configuration
  -p, --port int     SSH destination port

failed to dial: dial tcp: address 2601:280:c100:5d3::1:22: too many colons in address
kex_exchange_identification: Connection closed by remote host
Connection closed by UNKNOWN port 65535

Without assh this ssh alone works fine.

Ah yeah that makes sense. Also, I think the owner @moul may no longer be active; I haven't seen any updates from them for this project.
I use hostnames that resolve to the v6 address for now.


fixes as per PROD-85

This adds further improvement requests from integrations team extending original fixes from https://github.com/neonlabsorg/neon-evm.docs/pull/36

@YYYurchenko We ran out of time in last docs session to cover the FAQ and Neon Pass item. Then I accidentally merged the PR! This puts that PR back on the fixes branch plus some additional.

Reviewed with @YYYurchenko in meet and approved


Expose removeHeaders option in VirtualService

We currently allow appendHeaders in VirtualService but we do not allow the inverse removeHeaders.
removeHeaders requires implementing Envoy strip headers.
Use-Cases:

Sanitize input in-mesh as a privilege approach
Strip headers off before returning a response to a client at the Gateway level

API changes merged, working on implementation now

not stale, slated for 1.1


FrozenError: can't modify frozen object

bundle exec cap stage prod --trace
** Invoke stage (first_time)
** Execute stage
** Invoke load:defaults (first_time)
** Execute load:defaults
Pseudo-terminal will not be allocated because stdin is not a terminal.
** Invoke bundler:map_bins (first_time)
** Invoke passenger:bundler:hook (first_time)
** Execute passenger:bundler:hook
** Execute bundler:map_bins
** Invoke prod (first_time)
** Execute prod
Skipping task `load:defaults'.
Capistrano tasks may only be invoked once. Since task `load:defaults' was previously invoked, invoke("load:defaults") at /Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/capistrano-3.11.0/lib/capistrano/setup.rb:24 will be skipped.
If you really meant to run this task again, use invoke!("load:defaults")
THIS BEHAVIOR MAY CHANGE IN A FUTURE VERSION OF CAPISTRANO. Please join the conversation here if this affects you.
https://github.com/capistrano/capistrano/issues/1686
** Invoke load:defaults
cap aborted!
FrozenError: can't modify frozen object
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/capistrano-3.11.0/lib/capistrano/setup.rb:25:in `extend_object'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/capistrano-3.11.0/lib/capistrano/setup.rb:25:in `extend'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/capistrano-3.11.0/lib/capistrano/setup.rb:25:in `block (2 levels) in <top (required)>'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/task.rb:271:in `block in execute'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/task.rb:271:in `each'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/task.rb:271:in `execute'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/airbrussh-1.3.0/lib/airbrussh/rake/context.rb:62:in `execute'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/task.rb:213:in `block in invoke_with_call_chain'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/2.5.0/monitor.rb:226:in `mon_synchronize'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/task.rb:193:in `invoke_with_call_chain'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/task.rb:182:in `invoke'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/application.rb:160:in `invoke_task'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/application.rb:116:in `block (2 levels) in top_level'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/application.rb:116:in `each'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/application.rb:116:in `block in top_level'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/application.rb:125:in `run_with_threads'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/application.rb:110:in `top_level'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/application.rb:83:in `block in run'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/application.rb:186:in `standard_exception_handling'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/rake-12.3.1/lib/rake/application.rb:80:in `run'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/capistrano-3.11.0/lib/capistrano/application.rb:14:in `run'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/capistrano-3.11.0/bin/cap:3:in `<top (required)>'
/Users/jcoyne/.rbenv/versions/2.5.3/bin/cap:23:in `load'
/Users/jcoyne/.rbenv/versions/2.5.3/bin/cap:23:in `<top (required)>'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.1/lib/bundler/cli/exec.rb:74:in `load'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.1/lib/bundler/cli/exec.rb:74:in `kernel_load'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.1/lib/bundler/cli/exec.rb:28:in `run'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.1/lib/bundler/cli.rb:463:in `exec'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.1/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.1/lib/bundler/cli.rb:27:in `dispatch'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.1/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.1/lib/bundler/cli.rb:18:in `start'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.1/exe/bundle:30:in `block in <top (required)>'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.1/lib/bundler/friendly_errors.rb:124:in `with_friendly_errors'
/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.1/exe/bundle:22:in `<top (required)>'
/Users/jcoyne/.rbenv/versions/2.5.3/bin/bundle:23:in `load'
/Users/jcoyne/.rbenv/versions/2.5.3/bin/bundle:23:in `<main>'
Tasks: TOP => prod
Pseudo-terminal will not be allocated because stdin is not a terminal.

$ cap prod doctor
Pseudo-terminal will not be allocated because stdin is not a terminal.

Environment

    Ruby     ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-darwin18]
    Rubygems 2.7.6
    Bundler  1.17.1
    Command  /Users/jcoyne/.rbenv/versions/2.5.3/bin/cap prod doctor

Gems

    capistrano                3.11.0
    airbrussh                 1.3.0  (update available)
    rake                      12.3.1
    sshkit                    1.18.0
    net-ssh                   5.0.2
    capistrano-bundle_audit   0.2.1
    capistrano-bundler        1.4.0
    capistrano-one_time_key   0.0.1
    capistrano-passenger      0.2.0
    capistrano-shared_configs 0.2.2
    dlss-capistrano           3.4.1

Variables

    :application                     "modsulator-app"
    :branch                          <ask>
    :bundle_audit_ignore             [""]
    :bundle_bins                     ["gem", "rake", "rails", "honeybadger"]
    :bundle_binstubs                 nil
    :bundle_clean_options            ""
    :bundle_env_variables            {}
    :bundle_flags                    "--deployment --quiet"
    :bundle_gemfile                  nil
    :bundle_jobs                     nil
    :bundle_path                     #<Pathname:/opt/app/modsulator/modsulator-app-rails/shared/bundle>
    :bundle_roles                    :all
    :bundle_servers                  [#<Capistrano::Configuration::Server:0x00007fbecf57c048 @keys=[], @local=false, @user="modsulator", @hostname="modsulator-app-rails-prod.stanford.edu", @port=nil, @properties=#<Capistrano::Configuration::Server::Properties:0x00007fbecf3254e8 @properties={}, @roles=#<Set: {:web, :db, :app}>>>]
    :bundle_without                  "test development deploy"
    :chruby_map_bins                 ["honeybadger"]
    :default_env                     {}
    :deploy_to                       "/opt/app/modsulator/modsulator-app-rails"
    :format                          :airbrussh
    :git_environmental_variables     {:git_askpass=>"/bin/echo", :git_ssh=>"/tmp/git-ssh-modsulator-app-prod-jcoyne.sh"}
    :git_shallow_clone               false
    :git_wrapper_path                "/tmp/git-ssh-modsulator-app-prod-jcoyne.sh"
    :honeybadger_env                 :prod
    :keep_releases                   5
    :linked_dirs                     ["log", "tmp"]
    :linked_files                    ["config/secrets.yml", "config/honeybadger.yml"]
    :local_user                      "jcoyne"
    :log_level                       :debug
    :passenger_environment_variables {}
    :passenger_restart_command       "passenger-config restart-app"
    :passenger_restart_limit         2
    :passenger_restart_options       "/opt/app/modsulator/modsulator-app-rails --ignore-app-not-running"
    :passenger_restart_runner        :sequence
    :passenger_restart_wait          5
    :passenger_restart_with_sudo     false
    :passenger_roles                 :app
    :passenger_rvm_ruby_version      nil
    :pty                             false
    :rails_env                       "production"
    :rbenv_map_bins                  ["honeybadger"]
    :repo_url                        "https://github.com/sul-dlss/modsulator-app-rails"
    :rvm_map_bins                    ["honeybadger"]
    :skip_bundle_audit               false
    :ssh_options                     {:keys=>["/var/folders/9t/rygbnddx0b1ckw6tjs3m18qm0000gq/T/d20181106-52308-k2237t/capistrano_key"], :forward_agent=>false, :auth_methods=>["publickey", "password"]}
    :stage                           :prod
    :tmp_dir                         "/tmp"

    :honeybadger_env is not a recognized Capistrano setting (/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/2.5.0/delegate.rb:83)
    :linked_dirs is not a recognized Capistrano setting (/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/2.5.0/delegate.rb:83)
    :linked_files is not a recognized Capistrano setting (/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/2.5.0/delegate.rb:83)
    :rails_env is not a recognized Capistrano setting (/Users/jcoyne/.rbenv/versions/2.5.3/lib/ruby/2.5.0/delegate.rb:83)

Servers (1)

<EMAIL_ADDRESS>[:web, :db, :app]

Pseudo-terminal will not be allocated because stdin is not a terminal.

Oops, wrong command was issued.