Lab homework for tmarsha1

@TroyLMarshall Let me know that you've seem my comments and I'll merge.

Yes, I would normally put the custom exceptions into a separate module. I
was more interested in using the exceptions and focusing on getting some of
the other functionality working.
My guess with the double indent is that it's probably related to me writing
the code in Notepad++ instead of PyCharm. Fortunately, I received my
license on Monday and have applied it to my copy already.
I'm not a big fan of chaining calls. In this particular case, it's probably
ok, but chaining calls like that can introduced hidden dependencies that
are difficult to maintain long term.
Troy
On Wed, Nov 11, 2015 at 9:03 AM, Michael Dunn<EMAIL_ADDRESS>wrote:

@TroyLMarshall https://github.com/TroyLMarshall Let me know that you've
seem my comments and I'll merge.
—
Reply to this email directly or view it on GitHub
https://github.com/bigfatpanda-training/pandas-practical-python-primer/pull/59#issuecomment-155791378
.

Cool.
On Wed, Nov 11, 2015 at 9:32 AM TroyLMarshall<EMAIL_ADDRESS>wrote:

Yes, I would normally put the custom exceptions into a separate module. I
was more interested in using the exceptions and focusing on getting some of
the other functionality working.
My guess with the double indent is that it's probably related to me writing
the code in Notepad++ instead of PyCharm. Fortunately, I received my
license on Monday and have applied it to my copy already.
I'm not a big fan of chaining calls. In this particular case, it's probably
ok, but chaining calls like that can introduced hidden dependencies that
are difficult to maintain long term.
Troy
On Wed, Nov 11, 2015 at 9:03 AM, Michael Dunn<EMAIL_ADDRESS>wrote:

@TroyLMarshall https://github.com/TroyLMarshall Let me know that
you've
seem my comments and I'll merge.
—
Reply to this email directly or view it on GitHub
<
https://github.com/bigfatpanda-training/pandas-practical-python-primer/pull/59#issuecomment-155791378
.

—
Reply to this email directly or view it on GitHub
https://github.com/bigfatpanda-training/pandas-practical-python-primer/pull/59#issuecomment-155798000
.

--
Mike Dunn
https://about.me/eikonomega
Returning hate for hate multiplies hate, adding deeper darkness to a night
already devoid of stars. Darkness cannot drive out darkness; only light can
do that. Hate cannot drive out hate; only love can do that. - MLK


Support for custom Ticket Version

Hello,
I need to do this, however, our ASP.Net 4.5 is using both a custom ticket Version. However, your serializer.deserializer (FormsAuthenticationCryptor's ConvertToBytes hardcodes it to 1 and ConvertToAuthenticationTicket ignores it) does not support this.
Is it something you would consider adding? I don't think it would be a major change. I would be ready to provide a PR.

A PR is welcome

Your PR is not forgotten, just haven't got around to it yet. Will finish it somewhere this week.


Revert "chore: add func-deploy task patch"

Reverts openshift-knative/kn-plugin-func#364

/cc @matejvasek

/approve
/lgtm


Remove well-level code to another library

Keep striplog to striplogs and make a new library: welly

Do you have any kind of ideas about what should belong where and a structure or scope for striplog and/or welly?
I'm keen to fork and start working on a library for handling data at the well scale. I have an urgent need for it (need to quickly combine LAS file geophysics with strat logs in custom JSON format and produce a smartly-auto-scaled plot - probably matplotlib initially as that's what I have experience with). I suspect that you have a bunch of good stuff in striplog that I could start from...

@kinverarity1 Great question. Short answer: I don't know.
I threw the well stuff into striplog to get a particular job done. But I have come to the conclusion that striplog should only do what it says on the tin — deal with striplogs.
The well-level stuff, which I see as using or wrapping your awesome lasio project (probably not las.py as I have now), would help deal with I/O, headers, well paths (eg deviation), coordinates, etc. I'm not 100% sure welly is going to turn into that at this point, it was more of a way to get that stuff out of striplog for now. 100% happy for input on that, or taking it in another direction. My main need just now is to be able to read and write LAS 2.0 and, ideally, LAS 3.0 with my striplog stuff, ideally without substituting into templates as I was doing before.
I think there's another package to be built around logs and petrophysics — log interpolation, unit conversion, smoothing (despiking, Backus averaging, etc), transforms (Gardner, Wyllie, etc), analysis, etc. That would potentially make a lot of use of bruges.
The best way to see what striplog does is to look at the Jupyter Notebooks in /tutorial. Maybe you can use some of that... I am just about to start another few months of work on it, so if you have requests, this is a great time for it... contributions also welcome of course :)
Thanks Kent!

OK thanks - I did see those striplog tutorials and really like them.
I'm trying to think through how a workflow might go...
w = welly.Well()
w.add_las("geophysics.las")             # uses lasio internally
w.add_striplog("stratigraphy.csv")      # uses striplog internally
w.add_striplog("intervals.las")         # uses striplog which will use las.py or lasio
w.basic_log_manipulation()              # e.g. top_and_tail - should this be in welly or bruges? I thought welly.
w.more_complex_data_manipulation()      # e.g. petrophysics calculations - bruges
w.plot()                                # implemented in welly itself ??
w.write_las("export.las", version=3)    # use lasio once that has LAS 3 support

How do you envisage this kind of workflow?
I might try to come up with something like this in my welly fork - maybe borrow some of the plotting code from striplog. I might also make welly.Well an object of its own rather than a subclass of las.LASReader (or lasio.LASFile), as I think that might complicate things.

This is done, from striplog's point of view. Closing.


Table styling no longer has table row highlighting

I noticed that the new bootstrap removed some of my favorite table styling features like the coloured headings and table row highlighting, will this be implemented again? I've added it in my own project:
tbody .table-striped tr:hover td, tbody .table-striped tr:hover th {background-color:#f0f0f0;}

The :hover effect was added back to 2.0.1-wip here: 546332d85de5837147b645bf6bab5fa06e2a1039


re: Skynet & MySky Security Fixes - 05/08/2021

Yesterday, David made an announcement on Discord:

As we were doing final checks before fully launching MySky and the leaderboard, we realized that there were a handful of security issues which may break compatibility with existing skapps. We tried our best to patch things together, but ultimately decided that the best course of action is to delay the launch until Wednesday. We believe that MySky is the future of the Internet, and we really want to make sure that things are done correctly. This security change impacts user seeds, and all existing MySky seeds will break / need to be changed once the fix is deployed.
If you are a dev building with MySky, we will have a follow-up announcement in #app-dev later today, explaining how you can test your app against the changes and make sure that everything still works. For most devs, the update will not break your code.

This document will cover how to test your app against the Skynet and MySky changes we'll be releasing Wednesday, May 12th.
If any of these steps break, you should reach out on Discord, either in the #app-dev channel or by DMing dghelm#8125.
What am I testing for?
We're seeing two major changes on May 12th.

Portals will disable access to Skynet API endpoints from subdomained Skynet URLs. This means you cannot access skapp.hns.siasky.net/skynet/*, skapp.hns.siasky.net/[skylink] or [base32Skylink].siasky.net/[notFileInUploadedDir].
These changes protect against a vulnerability that could let a malicious app extract a user's MySky or SkyID seed.
MySky will change how it internally handles seeds and userIDs. You should not need to make changes in your code, but data attached to old seeds will become 'read-only' after the switch.
These changes will secure and protect user MySky seeds moving forward.

Test for MySky Change
The MySky app available on siasky.dev is the version we plan to release into production on Wednesday. It should work without code changes, but you'll want to test your app.

Access your app through siasky.dev (using a URL like https://snew.hns.siasky.dev)
Launch MySky and check URL in the address bar -- if it says siasky.net instead of .dev, you have hardcoded the portal in your app. This needs to be fixed.
Login with MySky, and test things out.

Fixing a hardcoded portal URL
Your app should not make any requests to siasky.net when accessed through siasky.dev -- it breaks the decentralization of Skynet for your users.
Commonly, this happens because you've hardcoded a portal URL in your code. The most common reason this happens is not changing
const client = new SkynetClient('https://siasky.net');

to
const client = new SkynetClient();

before deploying your app to Skynet.
You can also use the Browser Console technique described below to confirm that no requests are being sent to siasky.net
Test for API Endpoint Change
This test may be trickier, as you'll want to look at the requests your browser is making to Skynet.

Access your app through siasky.dev (like https://snew.hns.siasky.dev)
Press F12 to open your Browser's Developer Console. Then click the "Network" tab.
Do something that interacts with Skynet beyond the initial page load. Examine the request URL.

First, no requests should point to siasky.net. If any request does, see "Fixing a hardcoded portal URL" section above.
No requests should go to yourapp.siasky.dev/[skylink] or .../skynet/registry -- these requests will fail when made on siasky.dev. See this image for an example.

Fixing subdomained access
Three scenarios might cause requests to be pointed to API endpoints at a subdomained URL:

You're loading a Skynet library by using <script> tags with a relative URL. For example, SkyID's recommended loading method will no longer be compatible with Skynet:

<script src="/hns/sky-id/skyid.js"></script>

Instead, you should do one of the following:

link to an immutable Skylink
detect your current portal then build and load the appropriate HNS url
build the JS library into your project
temporarily use a hard-coded portal URL for the JS file in the script tag as a short-term fix.

You're using an older (even if production) version of skynet-js. Update to the latest beta using npm install skynet-js@beta and take a look at the Upgrade Guide and CHANGELOG-BETA for details on recent breaking changes. Yes, you're being forced to use a beta -- we're sorry and will have a stable release soon.

You're using SkyID, which currently is not compatible with the upcoming changes to Skynet.

In addition to these changes, full skyfile metadata is no longer being returned in the header information for each skyfile request. We've exposed a new API endpoint and the fix has been incorporated into skynet-js 4.0.6-beta.

Changes are now live in both MySky and on siasky.net.

@dghelm Can this be closed now?


Implemented tab drag and drop functionality

Implemented tab drag and drop functionality across app instances, dragging tab outside creates a new instance of the app.

Also fixed opening new window by providing custom path.

@yaichenbaum  @duke7553 As requested #1417 is implemented here.

:shipit:


Eliminate incorrect capitalisation

Removed inappropriate capitalisation in "The".

@paulkel : Thanks for your contribution to the Azure documentation! The author, @ggailey777, has been notified to review your proposed change.

Thanks @paulkel #sign-off


Add documentation for team switch kit

Add documentation for team switch kit

See PGMDev/PGM#799 for details. Let me know if there are any suggested changes and I'll adjust asap 👍
Signed-off-by: applenick<EMAIL_ADDRESS>

Thanks for contributing :+1:


Nuxt: Broken since 0.0.35

What happens?
The requested module '/_nuxt/@fs/workspaces/nimbus/node_modules/boolbase/index.js?v=c13543d7' does not provide an export named 'default'
This did not break in 0.0.34.
What did you expect to happen?
It should not break
How can we reproduce the issue?

Have a nuxt app (tested in 3.11.2).
Install module as documented (and pin using bun add<EMAIL_ADDRESS>Start devserver and render random openapi schema
Observe app failure

Swagger/OpenAPI Example
No response

Hello @max06 thanks for reporting the issue! We are on the case 🔍 . In the meanwhile, I think version 0.0.33 should work.

Hey @amritk - thanks for the headsup!
0.0.34 is also working fine, just in case. Based on the commit history 0.0.35 looked like it could cause issues so I started testing at 0.0.34 - lucky hit 🍀

hmm strange, because I found another issue in 0.0.34. Could be that the issue is only in dev

Good to know, I'll keep my eyes open! 🙇🏼

On it! :)
0.34 gives me the following error:
500 The requested module '/_nuxt/node_modules/.pnpm/debug@4.3.4/node_modules/debug/src/browser.js?v=bd279dc8' does not provide an export named 'default'


change search test to look for fedora and not fedora-minimal

Signed-off-by: baude<EMAIL_ADDRESS>

LGTM

LGTM

@rh-atomic-bot r+

Alright, I'm going to manually merge this because it seems to be last in Homu's (long) line, and all the tests are magically green for once


Add an option to keep the nutrition table expanded

What

Add an option in the App settings to keep the nutrition table knowledge panel expanded, regardless of the instruction sent by the Knowledge Panel API
We can probably add the same option for ingredients

Two options with default value = true have been added in the App Setting, Please tell me if it is not OK for you:

https://user-images.githubusercontent.com/87010739/175891544-d1850133-1d95-4e7a-a002-f623e653abfa.mp4


aurora cluster different size

I want to make RDS Aurora Cluster with 1 read replica,
is it possible to set the replica with different size using this module?

There is no "read replicas" in Aurora. There is only cluster instances and they can be either readers or writers. And they must all be the same instance type.
So, no 🙂

There is no "read replicas" in Aurora. There is only cluster instances and they can be either readers or writers. And they must all be the same instance type.
So, no 🙂

Sorry, I mean reader.
from the console we could change the reader’s or the writer's instance type.
I thought we could specify each instance type.

I thought we could specify each instance type.

Sorry, yes you can, but currently not possible with this module.

closed with #146


bug(MatSlider): Value changes events fired twice on firefox

Is this a regression?

[ ] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
No response
Description
Described in reproduction & actual behaviour. I also found https://github.com/angular/components/issues/14363 but it was closed.
Reproduction
Steps to reproduce: https://stackblitz.com/edit/components-issue-u1fdsd?file=src%2Fapp%2Fexample-component.html,src%2Fapp%2Fexample-component.ts

Expected Behavior
valueChange is called only once on firefox. Should work same as on chrome.
Actual Behavior
valueChange is called twice, firstly with "weird" values on firefox (on chrome it works correctly)
Environment

Angular: 15
CDK/Material: 15
Browser(s): firefox
Operating System (e.g. Windows, macOS, Ubuntu): stackblitz, linux, windows

I tried this out on the latest version (15.0.3) but was unable to reproduce it. It may have been fixed in one of the latest patches. Are you able to reproduce it with @angular/material on version 15.0.3? Here's a link to my forked stackblitz
https://stackblitz.com/edit/components-issue-hvxcnh?file=package.json,src%2Fapp%2Fexample-component.ts

Indeed it works, on my project I've got 15.0.1 but it looks like on newest version everything works correctly. Thanks!


Get the stats in "Share your experience" from a different category

The stats are alright, but I missed that quite a lot relevant Discourse content is outside the Tell your Story category.
So instead, the same stats should be derived from the Internet of Humans category, including all public sub-categories. By using API access without login, omitting the non-public categories will automatically work.

(Resolution: implemented as proposed.)


Removed redundant code and modified embedding_modules file

I removed redundant code in embedding_modules file and added them to a new set_embed_para function.

 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.

@w4nderlust Could you please clarify your first and last points? The function is still in embedding_modules.py. And for the regularizer part, what are you exactly suggesting?

@w4nderlust Could you please clarify your first and last points? The function is still in embedding_modules.py. And for the regularizer part, what are you exactly suggesting?

You are right, i thought it was placed in another module, my bad.
The 2 lines if not regularize: regularizer = None should be placed before the call to embed_matrix_on_device not inside. The reason is that I try to avoid if i can functions with side effects like this, so that you then have to return the input.

Aah okay, that is indeed a good precautionary step. Thanks for the insight.

@w4nderlust I am afraid I am not so sure about what you are trying to convey. But, in the code, the function embedding_matrix_on_device already has the regularizer parameter which is passed only after modifying it with a value depending on the regularize parameter in the if statement before the function call.

Ah you moved it around from the bottom, that's fine then


Split EntitiesDescriptor class up based on its two purposes

Addresses a couple of issues with the existing db structure:

EntitiesDescriptor was a dual-concern class, which modelled parts of the input to saml-service from other sources and parts of the output created during metadata generation.
The upcoming addition of RawEntityDescriptor, which stores a blob of XML in the database for direct rendering into the output metadata, needed some changes to the hierarchy to prevent duplicated loops everywhere for the extra data type.

The new model classes are:

MetadataInstance — Models an output of saml-service. Currently there's no way in the schema to select which EntityDescriptor records will be included in a metadata instance. This can be implemented after #25 is merged.

EntitySource — Models an input to saml-service. The input may be an external metadata source, or it may be synced from another service (i.e. FR) or held entirely locally.
EntitySource#rank describes the precedence of the EntityDescriptor records from this source. If a MetadataInstance is being rendered but selects the same entityID from two or more EntitySource parents, the one with the highest rank will be used during metadata generation. (Not implemented yet)

KnownEntity — Simply "an entity known to saml-service". The entity may be described by a full EntityDescriptor hierarchy, or it may have some other structure to be defined in a future change. (Immediately, RawEntityDescriptor).

This change removes the ability to have nested EntitiesDescriptor nodes in the output, because there is now no way to model it in the database. We could easily add this back in the future if the database schema supported it somehow, but for now it would just be dead code.

Coverage decreased (-17.51%) to 82.26% when pulling 3802a95e0db4757c01886e56e13e3b433526bfe2 on feature/split-entities-descriptor into 9ec3469ac4be5fd1f656a95a0eb49a9491005e31 on develop.

Coverage decreased (-25.38%) to 74.38% when pulling 92123bb7a4c6ec8a467d4683f8fd0f42b435eb73 on feature/split-entities-descriptor into 9ec3469ac4be5fd1f656a95a0eb49a9491005e31 on develop.

Coverage decreased (-0.0%) to 99.76% when pulling c87365fa8f311594429105adbd4fca09bf44efbf on feature/split-entities-descriptor into 9ec3469ac4be5fd1f656a95a0eb49a9491005e31 on develop.

One potential issue here is that EntitySource no longer records the extensions from an EntitiesDescriptor imported into saml-service. We may need to look at where / how this needs to be recorded so that we can still generate the output we wanted to generate. Pending discussion.

Coverage decreased (-0.0%) to 99.76% when pulling 0baa02e3103f5020f47de79728a1b0b65f1bc66b on feature/split-entities-descriptor into 9ec3469ac4be5fd1f656a95a0eb49a9491005e31 on develop.

Coverage decreased (-0.0%) to 99.77% when pulling 71078658cb784ab8554e87c59e1dd1622b12d37e on feature/split-entities-descriptor into 64d73244762e5cb30f52308f2deee5445173c8c4 on develop.

I won't add any more to this - will save extra functionality for when it's actually needed by another feature.
MetadataInstance tagging is probably best left for another day.
Awaiting review feedback.

Coverage decreased (-0.0%) to 99.77% when pulling e26953a804a465053602069116f236bea9d58f36 on feature/split-entities-descriptor into 64d73244762e5cb30f52308f2deee5445173c8c4 on develop.

re: EntitiesDescriptor extensions, I believe we've modelled all the major ones (rpi/ui etc) in DB but something could still come up. Could MetadataInstance hold this a value (text field) like the previous impl of EntitiesDescriptor allowed for?
I am good apart from this discussion btw.

If that happens I would prefer to add a new model + table to support this hypothetical future extension. We're at a point where we don't have to be scared of code changes / redeployment, so let's use that to our advantage.
Happy to be swayed.

This was more a "how we could solve it like other models do" hypothetical so I am also happy to move on.

Looks like a successful split of EntitiesDescriptor to me


Create treasury account

Description
This is a step towards #50.
The subscription module defines a default account called treasury. This account performs the following roles:

It owns the new/unused subscription NFT tokes to be purchased by the other users.
It holds the income of the platform from the subscription sales.
It pays the fee of the stream transactions to the nodes.
It pays the profit share of the users via the reclaim transaction.

A few notes about the treasury account:

This account does not represent a seed/secret-recovery.
Subscriptions are generated by the development account and assigned to the treasury.
The only way to withdraw tokens from the treasury account via the Reclaim command for artists and the development account.

With the changes applied to the subscription module architecture explained in this article, we can consider this ticket obsolete/invalid and close it.


changed 252 to 252.0 so calendar returns are correct

Is the issue here that this is doing truncating integer division?  If so the right fix is to put from __future__ import division at the top of the file.
https://www.python.org/dev/peps/pep-0238/

I closed this issue which was original #65 with this commit last night:  https://github.com/quantopian/pyfolio/commit/7f585f9cca08ade116c851804c6da592af8da064

@justinlent now that this is a public repo, we should really try to get out of the habit of pushing behavior changes directly to master.
Also, it looks like there's already a __future__ division import in this file, which means the division here should have the exact same result regardless of the denominator here.  Can you guys show an example input where this is producing different results?

all good. feel free to revert my commit and i'll work on a branch in the future

It's not worth changing at this point, but I'm still curious about why we think this changed any behavior.  As far as I can tell the change here is a no-op.

Consider, for example:
In [1]: from __future__ import division

In [2]: 5 / 3
Out[2]: 1.6666666666666667

In [3]: 5 / 3.0
Out[3]: 1.6666666666666667

Agree with @ssanderson. https://github.com/quantopian/pyfolio/commit/38198f934ddfe9b74bae8506fb0a33d982707e89 implemented the right way to address this issue.


[Feature Request] Provide sorting and filtering to act as general agenda

I really like what you've done here. Would love to see it further enhanced to provide a general capability for sorting and filtering due date times in order to provide a more general agenda capability.
eg. filter in place "Overdue"
Or filter in place Due in 1d to 7d
etc
Anyway, cool plugin. Playing with it now.

Sorry. This plugin has only purpose - to display due dates. I see it as a part of the agenda setup, not the whole system, so you can have a plugin that adds some filtering capatibility, a plugin for displaying 'calendars', a todo-management plugin, etc.
Maybe I'll make some 'middleman' plugin for it, so different plugins could share one API.. but not in the near future :(
If you need an agenda functionality out of the box, I recommend you to try out org-mode in Emacs. Unfortunately, I haven't seen any good (neo)vim plugin as powerful as it is.
Anyway, thanks for the kind words 👽

(and, of course, thanks for all your hard work on this plugin... )

@wakatara try neorg


BINDINGS.md wrong license for GForth binding.

Issue description
BINDINGS.md has an error. The GForth binding indicates that its license is MIT, but the project https://github.com/ArnautDaniel/gforth-raylib doesn't have a license agreement. This means this person owns all the rights over the binding code and logo. It's not public domain.

and GForth is GPL v3.  Users of this indirect use of GForth will need to be attentive to that no matter what the status of gforth-raylib is.

Agree. One solution could be to send a message to the author's binding to consider adding the MIT license. Maybe he/she/them forgot that part.
Regardless, someone with credentials should correct the table. I don't see it necessary to create a PR for this IMO.

Updated BINDINGS.md to reflect the unknown license.


nucleotide-count: Decrease benchmark test runtime

Improve the running time for 'go test -bench .'
by removing StartTimer/StopTimer references.
StopTimer and StartTimer are for excluding startup costs
from a benchmark, but for this benchmark there is no
startup overhead logic to exclude, and the running time
is severely increased by the timer operations.
The observed improvement for the example
is roughly 9x from about 14 seconds to about 1.5 seconds.

Thanks @petertseng

Very good, thank you!


Cardboard HMD: Provide skewed FOVs to simulate a "focal distance"

Via https://github.com/mrdoob/three.js/pull/7036#issuecomment-135509274
I understand the FOVs for each eye should be slightly skewed inwards to simulate a focal distance.
See for example here: http://paulbourke.net/stereographics/stereorender/
The values I'm using are the ones provided by the experimental Chrome WebVR builds.
They result in a focal distance of ~1.90.
I've also changed the interpupillary distance to the average according to Wikipedia.
wdyt?
cc @tschw

I just tried this in Cardboard on a Nexus 5, and it looks super weird to me.

Point is, the device should use a viewport that is focused, ideally on a depth that looks non-weird :-). The calculation to skew the "all 40s angles" for the two images to converge at a certain distance is:
var TOTAL_FOV = 80;
var FOCAL_DISTANCE = 1.5; // perceived distance in meters

var TAN_HALF_FOV = Math.tan(TOTAL_FOV * Math.PI / 360);
var SKEW_SLOPE = INTERPUPILLARY_DISTANCE / (FOCAL_DISTANCE * 2);

var DEFAULT_MAX_FOV_TOP = TOTAL_FOV / 2;
var DEFAULT_MAX_FOV_BOTTOM = TOTAL_FOV / 2;
var DEFAULT_MAX_FOV_OUTER = Math.atan(TAN_HALF_FOV - SKEW_SLOPE);
var DEFAULT_MAX_FOV_INNER = Math.atan(TAN_HALF_FOV + SKEW_SLOPE);

Just pick a reasonable default for FOCAL_DISTANCE based on what you see.

How do you avoid toe-in described as undesirable in http://paulbourke.net/stereographics/stereorender ?

There's nothing we can do about it here - it depends on how the application (or underlying 3D library) constructs the matrices:
A rotation by the average of the left/right angles gives toe-in, instead we want to shear x along the z axis by what I called SKEW_SLOPE above.
This means the left and right parameters of glFrustum-style projection matrices must not have the same absolute value, but be asymmetric in respect to the origin; they express the bounds of the near plane. Adding the same distance to both left and right yields a skewed frustum. That is, it extends as if we were looking sideways through a window (note that there is no rotation, z remains orthogonal to the projection plane).
At a certain distance, the translation of the cameras (not part of a bare projection matrix) must be nullified by the skew, and rendering an x/y-plane at that distance yields exactly the same image for both eyes. This is the focal distance. For 3D monitors, it's what's perceived on the screen - as opposed to before or behind it.
Now, the first element of the glFrustum matrix, the x scale, is actually a quotient of the near distance and values specified at that distance. The scale doesn't care at which distance we determine its value, as long as the scheme remains consistent. Setting zNear = 1 actually makes left and right the same as the tangents of the WebVR angles. This approach works for many of the values in the matrix, so we can pluck the tangents directly into it. That's what the Three.js code does:
https://github.com/mrdoob/three.js/blob/master/examples/js/effects/VREffect.js#L173-L181
https://github.com/mrdoob/three.js/blob/master/examples/js/effects/VREffect.js#L196-L222
Note that your scene should use meters as world unit or .scale must be set accordingly.
We still want to improve it, such as steer the focus, know the exact position of the focal plane for sharp 2D rendering, allow input from authoring formats, and have one controller for stereoscopic rendering that works for all possible output methods, respecting the constraints from the min/max values in case it's WebVR.

This should now be resolved in https://github.com/borismus/webvr-boilerplate/commit/363840e07e05375159c998f580db162c3c0cd4d2.


Implement Product Review Sentiment Dataset

Previous datasets were rejected due to dataset size, I found a larger dataset in huggingface.
turkish_product_reviews
This is not benchmarked but benchmarked datasets are hybrid which means they contain movie reviews, twitter posts and hotel reviews, which can be addressed as seperate datasets.

Thanks for your recommendation. Here are two options for you

If there is already an academic work which we can bencmark ourselves please do refer to that one so that we can apply their method
Otherwise let's assume that this is a uniform dataset to see how well we perform over such a mixed copus ;)

In any way waiting for your baseline model
Regards,

PR #226 is merged.


update modular example, fix nested merges, closes #425

This is far too slow during model construction. I noticed this on Tony's examples too, that vector-based construction is faster than object-oriented. This should be fixed! But for the meantime, this works.

@whoburg, ready for review. Note that if you click on 'view' for the notebook file, it'll display it properly.

Reviewed.

see inlines
check 5ee7db0613c66996aed43ea8148aa78fe20ff67b (feel free to squash commits if you like)
I'd rename Flight to FlightCondition.

Seeing the modularity is super cool!!!

I feel like Flight is a good name; it takes off, takes on fuel, etc. for each case.

@whoburg, responded to code review

Maybe FlightSegment then? AirplaneFlight1 seems like an odd name to me.
Changes look good! I'm ready for you to merge once we decided on that name -- and Flight is fine if you insist.

I don't care very much (and don't know the naming conditions in this field); which do you prefer?

Oops! I misunderstood what Flight was doing (though I still think the name could be better). Perhaps Performance, or FlightPerformance?
Here are some relevant names with my interpretation of what they are usually used to mean:
FlightCondition: a condition at a single instant in time, like a 4g pullup, or crosswind takeoff, or steady level flight
FlightSegment: a portion of a mission over which some quantities change, and others are integrated -- like a cruise segment, or a climb segment, etc
Mission: a group of FlightSegments, and sometimes FlightConditions as well
Performance: overall name given to the "discipline" associated with analyzing range/payload/weights/fuel burn over a mission

@cjk12 your input welcome on my previous comment

@cjk12 proposes Airplane => Mission, Flight => Segment (or to FlightSegment)

Talking @cjk12 is proposing we adopt an explicit aircraft design taxonomy, a la

also, Spar => WingWeight. Or WeightWing, taking into account that there are various weight models; Fuel => WeightFuel, as well. Really these should be integrated into a Weight module (convenient naming scheme, eh)

@whoburg, given the above, what'd you propose as a renaming?

@whoburg, added a couple commits to this to close v0.3.4; once they're reviewed and Modular naming is finalized, we'll be good to go with that version.

Added a couple commits and one comment -- ready for review and merging. In case the diff is hard to view, the renamings (for now) in 9a3c1d9c030c9286646db7963edff296c579ede9 are:
Fuel --> FuelBurn
Flight --> FlightSegment
Spar --> WingBox

Looks good! Merging.


Update README page

UI Mockup

Add a UI mockup of your intended final product. Note that the image of the UI should be docs/images/Ui.png so that it can be downloaded by our scripts.
Limit the file to contain one screenshot/mockup only and ensure the new image is roughly the same height x width proportions as the original one. Reason: when we compile these images from all teams into one page (example), yours should not look out of place.
The UI mockup can be a hand-drawn sketch or created using a tool such as PowerPoint, PlantUML, Figma, etc.
Can the AB3 screenshot be used for this? Only in the unlikely case that your v1.2 UI looks exactly the same as AB3.

Project Content Updates

Update all contents to match your own project.

Build Status Badge

Update the link of the GitHub Actions build status badge (Build Status) so that it reflects the build status of your team repo.

Acknowledgements

Acknowledge the original source of the code e.g.,

This project is based on the AddressBook-Level3 project created by the SE-EDU initiative.

Also update site-wide settings, as necessary:
You need to update the AB-3 in the top navigation bar of your project website (it's in docs\_markbind\layouts\default.md if using MarkBind).

Do download this and save as Ui.png


Dynamic tariff: always charge when price is negative and optimize for grid inbalance

When using dynamic energy prices, the electricity price can become negative. This is done to help prevent unbalance on the grid, by "promoting" energy use during these periods of overproduction from green energy sources (wind, solar).
It would be nice to have the following functions, to optimize for this situation:

While the electricity price is negative, always start charging from the net (at a configurable or full speed). Even when in PV mode or min + PV mode.
This can probably be achieved with the existing "Enables temporary fast-charging in solar mode", however from my understanding this setting is temporary?

An override for the max charge capacity of the EV battery, which is applied while the energy price is negative.

e.g. normally charge the battery to what is needed for range (for example 70%), or optimal healthy state of charge (usually 80%). However while the energy prices are negative, allow the battery to charge to different value (for example 85%).
This way we can create a user definable buffer, to store excess grid energy. It also lets us send our solar energy to the grid, during times of normal grid demand, instead of using it to charge the car battery to a higher than required range/state.

While the electricity price is negative, always start charging from the net (at a configurable or full speed). Even when in PV mode or min + PV mode.

You cannot "start" in MinPV mode as you're already charging. You can in PV mode by setting smart price limit to -0.01.

An override for the max charge capacity of the EV battery, which is applied while the energy price is negative.

What is a max charge capacity?


error validating data: the server could not find the requested resource

Output of helm version:2.7.0
Output of kubectl version:v1.14.1
Cloud Provider/Platform (AKS, GKE, Minikube etc.): GCE

helm --debug install stable/mariadb --set master.pesistence.enabled=false --set slave.persistence.enabled=false generates the following Output:
[debug] Created tunnel using local port: '46833'
[debug] SERVER: "localhost:46833"
[debug] Original chart version: ""
[debug] Fetched stable/mariadb to /home/student/.helm/cache/archive/mariadb-5.11.2.tgz
[debug] CHART PATH: /home/student/.helm/cache/archive/mariadb-5.11.2.tgz
Error: error validating "": error validating data: the server could not find the requested resource
I also get the following errors fom the tiller log.
2019/05/08 19:57:51 info: manifest "mariadb/templates/initialization-configmap.yaml" is empty. Skipping.
2019/05/08 19:57:51 info: manifest "mariadb/templates/slave-pdb.yaml" is empty. Skipping.
2019/05/08 19:57:51 info: manifest "mariadb/templates/serviceaccount.yaml" is empty. Skipping.
2019/05/08 19:57:51 info: manifest "mariadb/templates/rolebinding.yaml" is empty. Skipping.
2019/05/08 19:57:51 info: manifest "mariadb/templates/master-pdb.yaml" is empty. Skipping.
2019/05/08 19:57:51 info: manifest "mariadb/templates/role.yaml" is empty. Skipping.
[tiller] 2019/05/08 19:57:51 failed install prepare step: error validating "": error validating data: the server could not find the requested resource

Upgraded helm to a later version.Version 2.13. Resolved issue


Modify toolbar and query-bar layout

Fixes #109, #88
Changes:

Double height for elements in query-bar
Toolbar on the left on all screen sizes, merged with old title-bar
Settings-panel moved into modal
Type-modal uses the standard modal footer now, which ensures the buttons are sticky

LGTM


Change Accerleromter to Accelerometer

Fix typo "Accerleromter"  in Pedometer Component Description to "Accelerometer"

@AppInventorWorkerBee ok to test


Can you please add reminders on crosser telling me to shade squares, add circles, add answers, make clues, save, etc.
great,
P

We dont have bootstraps like we use to


mod_wsgi (Apache) Troubleshooting tips needs one more

In http://flask.pocoo.org/docs/0.10/deploying/mod_wsgi/
I ran into an issue when following the guide to configure a current working Flask app for Apache.  It would have been much easier to discover the cause if the following tip was given:
Problem: application runs but can not access other files:
For WSGI applications, all paths used should always be absolute path names.  Even though the app will work fine using relative paths with the simpler python serving method, they will not work with WSGI.

I'm not sure what paths you're referring to, but as far as I know everything is relative to the app root in Flask, so this isn't actually true.


ERROR cncli::nodeclient::sync > find_intersect error!: ChannelError(NotConnected(None))

Describe the bug
I get this error when running: cncli sync --no-service --host <IP_ADDRESS> --port 6000
(initial sync works OK, just follow-up sync doesn't work):
ERROR cncli::nodeclient::sync > find_intersect error!: ChannelError(NotConnected(None))
To Reproduce
Steps to reproduce the behavior:
Run cncli sync --no-service --host <IP_ADDRESS> --port 6000 after initial sync finishes with cardano-node 8.1.2 - linux-x86_64 - ghc-8.10
This used to work just fine with older versions of cardano-node
Expected behavior
Not crash with error
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS] Debian GNU/Linux 11 (bullseye)
Browser [e.g. chrome, safari]
Version [e.g. 22] cncli 5.3.2 (compiled from current master)

This is a duplicate of an issue that we still await an answer for: https://github.com/cardano-community/cncli/issues/25#issuecomment-1500484078

Greetings,
In testing cardano-node 8.7.2, I have encountered the above error. I did not have any issues like this prior to 8.7.2 as the above posters did. I am using Ubuntu 22.04. I am running two relays, one on Mainnet and the other on Preview. Likewise, I am running two block producers, one on Mainnet and the other on Preview. The error only shows up for the block producers regardless of the network. I discovered that if I set enableP2P to TRUE in the configuration json for the block producers then I no longer have the error. I usually run the relay nodes with P2P on, so I never encountered the problem before. However, I always run the block producers in the non-P2P format since I understand that these should not contact or be contacted outside of your private network space.
So, the question in my mind is the following: Is this error evidence of a regression in cardano-node communication? Maybe, but why did it show up in earlier versions for the above posters, but not for me? Should I be configuring my block producer differently now? In other words, should I enable P2P on the block producer and then just limit the incoming nodes via firewall rules? Has IOG deprecated the non-P2P format? It seems that if there is a switch in the configuration to set P2P to disabled then the assumption is that it should be possible to configure the node to run this way.
In summary, I experience the ChannelError(NotConnected(None)) problem every couple minutes with cncli-sync. This causes a large use of virtual memory and heavy CPU usage. The node essentially cannot function properly if I continue to use CNCLI. The only workaround I know of is to use P2P mode on my block producer, which I currently am doing on the Preview network. For Mainnet, I currently have stopped CNCLI, but since that program is so valuable to my workflow, I likely will downgrade my cardano-node so I can continue using it.
Can anyone offer any insights on this issue? Is this a cardano-node problem, a cncli problem, or a node configuration issue? Does anyone have a solution?

I have found, since my https://github.com/cardano-community/cncli/issues/25#issuecomment-1650237680 which I said would be my final posting on this issue, that if cncli stops and restarts, it will not communicate with node 8.7.2 (with the find_intersect error) unless the node is also restarted.
For our workflow, that means every restart of cardano-node must be done by rebooting the machine.  We could restart the 2 daemons in sequence but it makes more sense for us to spend 20 seconds rebooting.  It also means that, as previously reported, cncli effectively can't run in --no-service mode, as we previously reported in that other thread.
My decision not to post anymore about this issue was based on the original maintainer @AndrewWestberg's not engaging with either of these issues.  I am happy to have had this tool and to have used it for years in my own workflow, and certainly appreciate its development, but from my own perspective of working on open source projects for many years I would consider cncli to be ummaintained.

It seems to me that Andrew did engage with the issue but could not reproduce the problem. Unless there is a wider engagement from the user base providing more information, it is very difficult to continue troubleshooting. It concerns me that since few others are acknowledging this problem that perhaps it's only a problem for a very few. I'm also not necessarily convinced that the problem is with cncli. It could be something else (?) This was the only forum where I found this problem discussed.

I don't think ultimately declaring "it's not a problem because it doesn't happen to me" (i.e. the developer) is really an engagement with the issue.

I have this issue on 8.7.2

Does v6.0.0-alpha1 solve this issue?

Please re-test on the 6.0.0-alpha2 release.

Please re-test on the 6.0.0-alpha2 release.

I am getting this error now.
2023-12-22T09:55:00.271211Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
2023-12-22T09:55:15.270Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentEnqueue(8, [130, 0, 25, 155, 217])))
2023-12-22T09:55:15.270Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
2023-12-22T09:55:25.313561Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
2023-12-22T09:55:40.297Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentEnqueue(8, [130, 0, 25, 149, 44])))
2023-12-22T09:55:40.297Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...

ok, I deleted cncli.db again, I'll try to sync with new version to 100% and then try to restart.

after sync to 100% and then restarting cncli I get this error.
2023-12-22T15:46:47.200954Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
 2023-12-22T15:47:02.201Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentEnqueue(8, [130, 0, 25, 113, 207])))
 2023-12-22T15:47:02.201Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
2023-12-22T15:47:12.224184Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
 2023-12-22T15:47:27.223Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentEnqueue(8, [130, 0, 25, 139, 215])))
 2023-12-22T15:47:27.223Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
2023-12-22T15:47:37.280276Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
 2023-12-22T15:47:52.244Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentEnqueue(8, [130, 0, 25, 228, 145])))
 2023-12-22T15:47:52.244Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
2023-12-22T15:48:02.263947Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
 2023-12-22T15:48:17.263Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentEnqueue(8, [130, 0, 25, 57, 93])))
 2023-12-22T15:48:17.263Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
2023-12-22T15:48:27.297833Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
 2023-12-22T15:48:42.284Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentEnqueue(8, [130, 0, 25, 247, 197])))
 2023-12-22T15:48:42.284Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
2023-12-22T15:48:52.312104Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
 2023-12-22T15:49:07.303Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentEnqueue(8, [130, 0, 25, 31, 93])))
 2023-12-22T15:49:07.303Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
2023-12-22T15:49:17.352466Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
 2023-12-22T15:49:32.323Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentEnqueue(8, [130, 0, 25, 245, 118])))
 2023-12-22T15:49:32.323Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
2023-12-22T15:49:42.342064Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
 2023-12-22T15:49:57.341Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentEnqueue(8, [130, 0, 25, 154, 8])))
 2023-12-22T15:49:57.342Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
2023-12-22T15:50:07.368956Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
 2023-12-22T15:50:22.362Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentEnqueue(8, [130, 0, 25, 145, 150])))
 2023-12-22T15:50:22.362Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
2023-12-22T15:50:32.403249Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
 2023-12-22T15:50:47.381Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentEnqueue(8, [130, 0, 25, 64, 159])))
 2023-12-22T15:50:47.381Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
2023-12-22T15:50:57.400385Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
 2023-12-22T15:51:12.401Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentEnqueue(8, [130, 0, 25, 153, 195])))
 2023-12-22T15:51:12.401Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
2023-12-22T15:51:22.421810Z ERROR pallas_network::multiplexer: beaerer IO error err=Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }

I use P2P and its Ubuntu on ARM64

@petroars Please try alpha3 now.

@petroars Please try alpha3 now.

nope, sorry. Different error. Maybe I am compiling wrong? Thats starting from 100% sync. I ll do a full resync later.
2023-12-23T19:20:10.536Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentDequeue))
 2023-12-23T19:20:10.540Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
 2023-12-23T19:20:35.548Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentDequeue))
 2023-12-23T19:20:35.548Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
 2023-12-23T19:21:00.555Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentDequeue))
 2023-12-23T19:21:00.555Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
 2023-12-23T19:21:25.561Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentDequeue))
 2023-12-23T19:21:25.561Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...

@petroars What exact version of cncli alpha3 are you running? Is the node you're connecting to local on the box, or remote? Are you still on cardano-node 8.7.2 or are you on 8.7.3 now?

The same behavior as for @petroars, cardano-node 8.1.2:
 2023-12-26T15:07:14.026Z INFO  cncli::nodeclient::sync   > block 9716112 of 9723531: 99.92% sync'd
 2023-12-26T15:07:21.653Z INFO  cncli::nodeclient::sync   > block 9722201 of 9723531: 99.99% sync'd
 2023-12-26T15:07:23.346Z INFO  cncli::nodeclient::sync   > block 9723531 of 9723531: 100.00% sync'd
 2023-12-26T15:07:55.397Z INFO  cncli::nodeclient::sync   > block 9723532 of 9723532: 100.00% sync'd
 2023-12-26T15:08:03.451Z INFO  cncli::nodeclient::sync   > block 9723533 of 9723533: 100.00% sync'd
^C

$ /var/tmp/cncli sync --host <IP_ADDRESS> --port 5001 --db /home/cardano/cardano-node/cncli-db/cncli.db
 2023-12-26T15:09:17.699Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentDequeue))
 2023-12-26T15:09:17.700Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
 2023-12-26T15:09:42.713Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentDequeue))
 2023-12-26T15:09:42.713Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
^C

$ RUST_BACKTRACE=1 /var/tmp/cncli sync --host <IP_ADDRESS> --port 5001 --db /home/cardano/cardano-node/cncli-db/cncli.db
 2023-12-26T15:10:05.464Z ERROR cncli::nodeclient::sync > miniprotocol error: ChainSyncError(Plexer(AgentDequeue))
 2023-12-26T15:10:05.464Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
 2023-12-26T15:10:22.028Z ERROR cncli::nodeclient::sync > miniprotocol error: ChainSyncError(Plexer(AgentDequeue))
 2023-12-26T15:10:22.028Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
^C

$ RUST_BACKTRACE=full /var/tmp/cncli sync --host <IP_ADDRESS> --port 5001 --db /home/cardano/cardano-node/cncli-db/cncli.db
 2023-12-26T15:10:43.173Z ERROR cncli::nodeclient::sync > miniprotocol error: ChainSyncError(Plexer(AgentDequeue))
 2023-12-26T15:10:43.173Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
 2023-12-26T15:10:59.571Z ERROR cncli::nodeclient::sync > miniprotocol error: ChainSyncError(Plexer(AgentDequeue))
 2023-12-26T15:10:59.571Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
^C

$ /var/tmp/cncli --version
cncli v6.0.0-alpha3 <e5b811e> (x86_64-unknown-linux-gnu)

$ cardano-node --version
cardano-node 8.7.2 - linux-x86_64 - ghc-8.10
git rev 30b6e447c7e4586f43e30a68fe47c8481b0ba205

@petroars What exact version of cncli alpha3 are you running? Is the node you're connecting to local on the box, or remote? Are you still on cardano-node 8.7.2 or are you on 8.7.3 now?

cardano-node 8.7.2 - linux-aarch64 - ghc-9.6
git rev 30b6e447c7e4586f43e30a68fe47c8481b0ba205
cncli --version
cncli v6.0.0-alpha3  (aarch64-unknown-linux-musl)
I usually run ./cncli sync --host <IP_ADDRESS> --port 6060 , but I also tried remote server, same effect. It connects from 0%, even at 47%+ you can restart, but somewhere further in sync it wont work. Maybe I ll try to find at what exact % it fails...

@cardano-apexpool What operating system?

@petroars I've never tested with cardano-node compiled with anything other than 8.10.7. Also never tested any of this on aarch. Can you try compiling cncli yourself?
cargo install --path . --force --target aarch64-unknown-linux-musl

@petroars I've never tested with cardano-node compiled with anything other than 8.10.7. Also never tested any of this on aarch. Can you try compiling cncli yourself?
cargo install --path . --force --target aarch64-unknown-linux-musl

thats how I compile it every time.

@petroars Try running with RUST_LOG=trace cncli... and see if we can't get more information about what is going wrong.

@AndrewWestberg Debian 11.8.
$ RUST_LOG=trace /var/tmp/cncli sync --host <IP_ADDRESS> --port 5001 --db /home/cardano/cardano-node/cncli-db/cncli.db
 2023-12-29T18:36:36.168Z DEBUG cncli::nodeclient::sqlite > Opening database
 2023-12-29T18:36:36.175Z DEBUG cncli::nodeclient::sqlite > Intialize database.
2023-12-29T18:36:36.179576Z TRACE pallas_network::multiplexer: waiting for segment header
2023-12-29T18:36:36.183826Z DEBUG pallas_network::miniprotocols::handshake::client: version proposed
2023-12-29T18:36:36.183186Z TRACE pallas_network::multiplexer: mux happening protocol=0
2023-12-29T18:36:36.184065Z TRACE pallas_network::multiplexer: write to bearer protocol=0 data="8200a707821a2d964a09f408821a2d964a09f409821a2d964a09f40a821a2d964a09f40b841a2d964a09f400f40c841a2d964a09f400f40d841a2d964a09f400f4"
2023-12-29T18:36:36.184226Z TRACE pallas_network::multiplexer: waiting for full segment
2023-12-29T18:36:36.184270Z TRACE pallas_network::multiplexer: demux happening protocol=32768
2023-12-29T18:36:36.184300Z TRACE pallas_network::multiplexer: waiting for segment header
2023-12-29T18:36:36.184498Z TRACE pallas_network::multiplexer: waiting for full message len=0
2023-12-29T18:36:36.185861Z DEBUG pallas_network::multiplexer: decoding done
2023-12-29T18:36:36.185890Z DEBUG pallas_network::miniprotocols::handshake::client: handshake accepted
 2023-12-29T18:36:36.186Z DEBUG cncli::nodeclient::sync   > keepalive process started!
 2023-12-29T18:36:56.190Z DEBUG cncli::nodeclient::sync   > sending keepalive...
2023-12-29T18:36:56.192899Z DEBUG pallas_network::miniprotocols::keepalive::client: sent keepalive message with cookie 36283
2023-12-29T18:36:56.192951Z TRACE pallas_network::multiplexer: waiting for full message len=0
 2023-12-29T18:36:56.193Z ERROR cncli::nodeclient::sync   > miniprotocol error: KeepAliveError(Plexer(AgentDequeue))
 2023-12-29T18:36:56.193Z WARN  cncli::nodeclient::sync   > Disconnected... retry in 5 secs...
2023-12-29T18:36:56.193051Z TRACE pallas_network::multiplexer: mux happening protocol=8
 2023-12-29T18:37:01.194Z DEBUG cncli::nodeclient::sqlite > Opening database
 2023-12-29T18:37:01.195Z DEBUG cncli::nodeclient::sqlite > Intialize database.
2023-12-29T18:37:01.197635Z TRACE pallas_network::multiplexer: waiting for segment header
2023-12-29T18:37:01.197661Z DEBUG pallas_network::miniprotocols::handshake::client: version proposed
2023-12-29T18:37:01.197705Z TRACE pallas_network::multiplexer: waiting for full message len=0
2023-12-29T18:37:01.197686Z TRACE pallas_network::multiplexer: mux happening protocol=0
2023-12-29T18:37:01.197881Z TRACE pallas_network::multiplexer: write to bearer protocol=0 data="8200a707821a2d964a09f408821a2d964a09f409821a2d964a09f40a821a2d964a09f40b841a2d964a09f400f40c841a2d964a09f400f40d841a2d964a09f400f4"
2023-12-29T18:37:01.198396Z TRACE pallas_network::multiplexer: waiting for full segment
2023-12-29T18:37:01.198430Z TRACE pallas_network::multiplexer: demux happening protocol=32768
2023-12-29T18:37:01.198466Z TRACE pallas_network::multiplexer: waiting for segment header
2023-12-29T18:37:01.198516Z DEBUG pallas_network::multiplexer: decoding done
2023-12-29T18:37:01.198545Z DEBUG pallas_network::miniprotocols::handshake::client: handshake accepted
 2023-12-29T18:37:01.198Z DEBUG cncli::nodeclient::sync   > keepalive process started!
 2023-12-29T18:37:21.200Z DEBUG cncli::nodeclient::sync   > sending keepalive...
2023-12-29T18:37:21.200712Z DEBUG pallas_network::miniprotocols::keepalive::client: sent keepalive message with cookie 27616
2023-12-29T18:37:21.200758Z TRACE pallas_network::multiplexer: waiting for full message len=0
2023-12-29T18:37:21.200880Z TRACE pallas_network::multiplexer: mux happening protocol=8
 2023-12-29T18:37:21.200Z ERROR cncli::nodeclient::sync   > miniprotocol error: KeepAliveError(Plexer(AgentDequeue))
 2023-12-29T18:37:21.200Z WARN  cncli::nodeclient::sync   > Disconnected... retry in 5 secs...
 2023-12-29T18:37:26.202Z DEBUG cncli::nodeclient::sqlite > Opening database
 2023-12-29T18:37:26.203Z DEBUG cncli::nodeclient::sqlite > Intialize database.
2023-12-29T18:37:26.205010Z TRACE pallas_network::multiplexer: waiting for segment header
2023-12-29T18:37:26.205010Z DEBUG pallas_network::miniprotocols::handshake::client: version proposed
2023-12-29T18:37:26.205092Z TRACE pallas_network::multiplexer: waiting for full message len=0
2023-12-29T18:37:26.205110Z TRACE pallas_network::multiplexer: mux happening protocol=0
2023-12-29T18:37:26.205263Z TRACE pallas_network::multiplexer: write to bearer protocol=0 data="8200a707821a2d964a09f408821a2d964a09f409821a2d964a09f40a821a2d964a09f40b841a2d964a09f400f40c841a2d964a09f400f40d841a2d964a09f400f4"
2023-12-29T18:37:26.205406Z TRACE pallas_network::multiplexer: waiting for full segment
2023-12-29T18:37:26.205437Z TRACE pallas_network::multiplexer: demux happening protocol=32768
2023-12-29T18:37:26.205474Z TRACE pallas_network::multiplexer: waiting for segment header
2023-12-29T18:37:26.207318Z DEBUG pallas_network::multiplexer: decoding done
2023-12-29T18:37:26.207353Z DEBUG pallas_network::miniprotocols::handshake::client: handshake accepted
 2023-12-29T18:37:26.207Z DEBUG cncli::nodeclient::sync   > keepalive process started!
2023-12-29T18:37:39.341572Z DEBUG pallas_network::miniprotocols::chainsync::client: send find intersect
2023-12-29T18:37:39.341913Z DEBUG pallas_network::miniprotocols::chainsync::client: waiting for intersect response
2023-12-29T18:37:39.341941Z TRACE pallas_network::multiplexer: waiting for full message len=0
2023-12-29T18:37:39.342937Z TRACE pallas_network::multiplexer: mux happening protocol=2
 2023-12-29T18:37:39.342Z ERROR cncli::nodeclient::sync   > miniprotocol error: ChainSyncError(Plexer(AgentDequeue))
 2023-12-29T18:37:39.343Z WARN  cncli::nodeclient::sync   > Disconnected... retry in 5 secs...
^C

cardano@oracle:/mypool$ sudo RUST_LOG=trace ./cncli sync --host <IP_ADDRESS> --port 6060
2023-12-29T18:42:51.295Z DEBUG cncli::nodeclient::sqlite > Opening database
2023-12-29T18:42:51.307Z DEBUG cncli::nodeclient::sqlite > Intialize database.
2023-12-29T18:42:51.315318Z TRACE pallas_network::multiplexer: waiting for segment header
2023-12-29T18:42:51.315333Z DEBUG pallas_network::miniprotocols::handshake::client: version proposed
2023-12-29T18:42:51.315343Z TRACE pallas_network::multiplexer: mux happening protocol=0
2023-12-29T18:42:51.316641Z TRACE pallas_network::multiplexer: write to bearer protocol=0 data="8200a707821a2d964a09f408821a2d964a09f409821a2d964a09f40a821a2d964a09f40b841a2d964a09f400f40c841a2d964a09f400f40d841a2d964a09f400f4"
2023-12-29T18:42:51.316284Z TRACE pallas_network::multiplexer: waiting for full message len=0
2023-12-29T18:42:51.316999Z TRACE pallas_network::multiplexer: waiting for full segment
2023-12-29T18:42:51.317029Z TRACE pallas_network::multiplexer: demux happening protocol=32768
2023-12-29T18:42:51.317041Z TRACE pallas_network::multiplexer: waiting for segment header
2023-12-29T18:42:51.317231Z DEBUG pallas_network::multiplexer: decoding done
2023-12-29T18:42:51.317244Z DEBUG pallas_network::miniprotocols::handshake::client: handshake accepted
2023-12-29T18:42:51.317Z DEBUG cncli::nodeclient::sync   > keepalive process started!
2023-12-29T18:43:11.318Z DEBUG cncli::nodeclient::sync   > sending keepalive...
2023-12-29T18:43:11.318386Z DEBUG pallas_network::miniprotocols::keepalive::client: sent keepalive message with cookie 4331
2023-12-29T18:43:11.318402Z TRACE pallas_network::multiplexer: waiting for full message len=0
2023-12-29T18:43:11.318491Z TRACE pallas_network::multiplexer: mux happening protocol=8
2023-12-29T18:43:11.318Z ERROR cncli::nodeclient::sync   > miniprotocol error: KeepAliveError(Plexer(AgentDequeue))
2023-12-29T18:43:11.318Z WARN  cncli::nodeclient::sync   > Disconnected... retry in 5 secs...
2023-12-29T18:43:16.320Z DEBUG cncli::nodeclient::sqlite > Opening database
2023-12-29T18:43:16.322Z DEBUG cncli::nodeclient::sqlite > Intialize database.
2023-12-29T18:43:16.325033Z DEBUG pallas_network::miniprotocols::handshake::client: version proposed
2023-12-29T18:43:16.325049Z TRACE pallas_network::multiplexer: waiting for full message len=0
2023-12-29T18:43:16.325065Z TRACE pallas_network::multiplexer: waiting for segment header
2023-12-29T18:43:16.325071Z TRACE pallas_network::multiplexer: mux happening protocol=0
2023-12-29T18:43:16.325115Z TRACE pallas_network::multiplexer: write to bearer protocol=0 data="8200a707821a2d964a09f408821a2d964a09f409821a2d964a09f40a821a2d964a09f40b841a2d964a09f400f40c841a2d964a09f400f40d841a2d964a09f400f4"
2023-12-29T18:43:16.325840Z TRACE pallas_network::multiplexer: waiting for full segment
2023-12-29T18:43:16.325876Z TRACE pallas_network::multiplexer: demux happening protocol=32768
2023-12-29T18:43:16.325893Z TRACE pallas_network::multiplexer: waiting for segment header
2023-12-29T18:43:16.325933Z DEBUG pallas_network::multiplexer: decoding done
2023-12-29T18:43:16.325950Z DEBUG pallas_network::miniprotocols::handshake::client: handshake accepted
2023-12-29T18:43:16.328Z DEBUG cncli::nodeclient::sync   > keepalive process started!
2023-12-29T18:43:36.328Z DEBUG cncli::nodeclient::sync   > sending keepalive...
2023-12-29T18:43:36.328813Z DEBUG pallas_network::miniprotocols::keepalive::client: sent keepalive message with cookie 14872
2023-12-29T18:43:36.328830Z TRACE pallas_network::multiplexer: waiting for full message len=0
2023-12-29T18:43:36.328851Z TRACE pallas_network::multiplexer: mux happening protocol=8
2023-12-29T18:43:36.328Z ERROR cncli::nodeclient::sync   > miniprotocol error: KeepAliveError(Plexer(AgentDequeue))
2023-12-29T18:43:36.328Z WARN  cncli::nodeclient::sync   > Disconnected... retry in 5 secs...
2023-12-29T18:43:41.330Z DEBUG cncli::nodeclient::sqlite > Opening database
2023-12-29T18:43:41.331Z DEBUG cncli::nodeclient::sqlite > Intialize database.
2023-12-29T18:43:41.333729Z DEBUG pallas_network::miniprotocols::handshake::client: version proposed
2023-12-29T18:43:41.334096Z TRACE pallas_network::multiplexer: waiting for full message len=0
2023-12-29T18:43:41.333777Z TRACE pallas_network::multiplexer: mux happening protocol=0
2023-12-29T18:43:41.334202Z TRACE pallas_network::multiplexer: write to bearer protocol=0 data="8200a707821a2d964a09f408821a2d964a09f409821a2d964a09f40a821a2d964a09f40b841a2d964a09f400f40c841a2d964a09f400f40d841a2d964a09f400f4"
2023-12-29T18:43:41.333751Z TRACE pallas_network::multiplexer: waiting for segment header
2023-12-29T18:43:41.334800Z TRACE pallas_network::multiplexer: waiting for full segment
2023-12-29T18:43:41.334808Z TRACE pallas_network::multiplexer: demux happening protocol=32768
2023-12-29T18:43:41.334819Z TRACE pallas_network::multiplexer: waiting for segment header
2023-12-29T18:43:41.334833Z DEBUG pallas_network::multiplexer: decoding done
2023-12-29T18:43:41.335192Z DEBUG pallas_network::miniprotocols::handshake::client: handshake accepted
2023-12-29T18:43:41.336Z DEBUG cncli::nodeclient::sync   > keepalive process started!

From what I can see, the node is actually rejecting the keep-alive miniprotocol messages. Can you both look in the cardano-node logs and see what messages you get when you have TraceMux and TraceHandshake set to true.

From what I can see, the node is actually rejecting the keep-alive miniprotocol messages. Can you both look in the cardano-node logs and see what messages you get when you have TraceMux and TraceHandshake set to true.

Is that the part?
Dec 29 22:22:55 oracle cardano-node[160263]: [oracle:cardano.node.ConnectionManager:Info:997] [2023-12-29 21:22:55.39 UTC] TrConnectionManagerCounters (ConnectionManagerCounters {fullDuplexConns = 0, duplexConns = 23, unidirectionalConns = 12, inboundConns = 6, outboundConns = 30}) Dec 29 22:22:55 oracle cardano-node[160263]: [oracle:cardano.node.Handshake:Info:998] [2023-12-29 21:22:55.39 UTC] WithMuxBearer (ConnectionId {localAddress = <IP_ADDRESS>:6060, remoteAddress = <IP_ADDRESS>:49224}) Recv (ClientAgency TokPropose,MsgProposeVersions (fromList [(NodeToNodeV_7,TList [TInt 764824073,TBool False]),(NodeToNodeV_8,TList [TInt 764824073,TBool False]),(NodeToNodeV_9,TList [TInt 764824073,TBool False]),(NodeToNodeV_10,TList [TInt 764824073,TBool False]),(NodeToNodeV_11,TList [TInt 764824073,TBool False,TInt 0,TBool False]),(NodeToNodeV_12,TList [TInt 764824073,TBool False,TInt 0,TBool False]),(NodeToNodeV_13,TList [TInt 764824073,TBool False,TInt 0,TBool False])])) Dec 29 22:22:55 oracle cardano-node[160263]: [oracle:cardano.node.Handshake:Info:998] [2023-12-29 21:22:55.39 UTC] WithMuxBearer (ConnectionId {localAddress = <IP_ADDRESS>:6060, remoteAddress = <IP_ADDRESS>:49224}) Send (ServerAgency TokConfirm,MsgAcceptVersion NodeToNodeV_11 (TList [TInt 764824073,TBool False,TInt 0,TBool False])) Dec 29 22:22:55 oracle cardano-node[160263]: [oracle:cardano.node.ConnectionManager:Info:998] [2023-12-29 21:22:55.39 UTC] TrConnectionHandler (ConnectionId {localAddress = <IP_ADDRESS>:6060, remoteAddress = <IP_ADDRESS>:49224}) (TrHandshakeSuccess NodeToNodeV_11 (NodeToNodeVersionData {networkMagic = NetworkMagic {unNetworkMagic = 764824073}, diffusionMode = InitiatorAndResponderDiffusionMode, peerSharing = PeerSharingDisabled, query = False})) Dec 29 22:22:55 oracle cardano-node[160263]: [oracle:cardano.node.ConnectionManager:Info:997] [2023-12-29 21:22:55.39 UTC] TrConnectionManagerCounters (ConnectionManagerCounters {fullDuplexConns = 0, duplexConns = 24, unidirectionalConns = 12, inboundConns = 6, outboundConns = 30}) Dec 29 22:22:55 oracle cardano-node[160263]: [oracle:cardano.node.Mux:Info:998] [2023-12-29 21:22:55.39 UTC] Bearer on ConnectionId {localAddress = <IP_ADDRESS>:6060, remoteAddress = <IP_ADDRESS>:49224} event: State: Mature Dec 29 22:22:55 oracle cardano-node[160263]: [oracle:cardano.node.Mux:Info:998] [2023-12-29 21:22:55.39 UTC] Bearer on ConnectionId {localAddress = <IP_ADDRESS>:6060, remoteAddress = <IP_ADDRESS>:49224} event: Started on demand (MiniProtocolNum 2) in ResponderDir Dec 29 22:22:55 oracle cardano-node[160263]: [oracle:cardano.node.Mux:Info:998] [2023-12-29 21:22:55.39 UTC] Bearer on ConnectionId {localAddress = <IP_ADDRESS>:6060, remoteAddress = <IP_ADDRESS>:49224} event: Started on demand (MiniProtocolNum 3) in ResponderDir Dec 29 22:22:55 oracle cardano-node[160263]: [oracle:cardano.node.Mux:Info:998] [2023-12-29 21:22:55.39 UTC] Bearer on ConnectionId {localAddress = <IP_ADDRESS>:6060, remoteAddress = <IP_ADDRESS>:49224} event: Started on demand (MiniProtocolNum 4) in ResponderDir Dec 29 22:22:55 oracle cardano-node[160263]: [oracle:cardano.node.Mux:Info:998] [2023-12-29 21:22:55.39 UTC] Bearer on ConnectionId {localAddress = <IP_ADDRESS>:6060, remoteAddress = <IP_ADDRESS>:49224} event: Started on demand (MiniProtocolNum 8) in ResponderDir

I actually don't see any errors in cardano-node logs during the time error in CNCLI happens.
Dec 29 22:39:05 oracle cncli[156859]:  2023-12-29T21:39:05.732Z ERROR cncli::nodeclient::sync > miniprotocol error: KeepAliveError(Plexer(AgentDequeue)) Dec 29 22:39:05 oracle cncli[156859]:  2023-12-29T21:39:05.732Z WARN  cncli::nodeclient::sync > Disconnected... retry in 5 secs...
Dec 29 22:39:04 oracle cardano-node[160263]: [oracle:cardano.node.LeadershipCheck:Info:280] [2023-12-29 21:39:04.00 UTC] {"chainDensity":4.9780954e-2,"credentials":"Cardano","delegMapSize":1328133,"kind":"TraceStartLeadershipCheck","slot":112319653,"utxoSize":10696871} Dec 29 22:39:04 oracle cardano-node[160263]: [oracle:cardano.node.Forge:Info:280] [2023-12-29 21:39:04.04 UTC] fromList [("credentials",String "Cardano"),("val",Object (fromList [("kind",String "TraceNodeNotLeader"),("slot",Number 1.12319653e8)]))] Dec 29 22:39:05 oracle cardano-node[160263]: [oracle:cardano.node.LeadershipCheck:Info:280] [2023-12-29 21:39:05.00 UTC] {"chainDensity":4.9780954e-2,"credentials":"Cardano","delegMapSize":1328133,"kind":"TraceStartLeadershipCheck","slot":112319654,"utxoSize":10696871} Dec 29 22:39:05 oracle cardano-node[160263]: [oracle:cardano.node.Forge:Info:280] [2023-12-29 21:39:05.04 UTC] fromList [("credentials",String "Cardano"),("val",Object (fromList [("kind",String "TraceNodeNotLeader"),("slot",Number 1.12319654e8)]))] Dec 29 22:39:06 oracle cardano-node[160263]: [oracle:cardano.node.LeadershipCheck:Info:280] [2023-12-29 21:39:06.00 UTC] {"chainDensity":4.9780954e-2,"credentials":"Cardano","delegMapSize":1328133,"kind":"TraceStartLeadershipCheck","slot":112319655,"utxoSize":10696871} Dec 29 22:39:06 oracle cardano-node[160263]: [oracle:cardano.node.Forge:Info:280] [2023-12-29 21:39:06.04 UTC] fromList [("credentials",String "Cardano"),("val",Object (fromList [("kind",String "TraceNodeNotLeader"),("slot",Number 1.12319655e8)]))] Dec 29 22:39:07 oracle cardano-node[160263]: [oracle:cardano.node.LeadershipCheck:Info:280] [2023-12-29 21:39:07.00 UTC] {"chainDensity":4.9780954e-2,"credentials":"Cardano","delegMapSize":1328133,"kind":"TraceStartLeadershipCheck","slot":112319656,"utxoSize":10696871} Dec 29 22:39:07 oracle cardano-node[160263]: [oracle:cardano.node.Forge:Info:280] [2023-12-29 21:39:07.05 UTC] fromList [("credentials",String "Cardano"),("val",Object (fromList [("kind",String "TraceNodeNotLeader"),("slot",Number 1.12319656e8)]))]

@petroars Try connecting to <IP_ADDRESS> for the host. You can't connect to <IP_ADDRESS>. That's only on the server side for listening.

@cardano-apexpool Did you build cncli yourself or are you using a binary?

@AndrewWestberg  I built it myself, on the same machine where I'm usually building it and where I'm also building cardano-node and mithril.
I usually used cargo install --path . --force, this time I also used cargo build (like for mithril), but the errors are the same.
The cardano-node logs messages are:
[relay2:cardano.node.ConnectionManager:Info:1027290] [2023-12-30 08:27:51.46 UTC] TrConnectionHandler (ConnectionId {localAddress = <IP_ADDRESS>:5001, remoteAddress = <IP_ADDRESS>:40858}) (TrHandshakeSuccess NodeToNodeV_11 (NodeToNodeVersionData {networkMagic = NetworkMagic {unNetworkMagic = 764824073}, diffusionMode = InitiatorAndResponderDiffusionMode, peerSharing = PeerSharingDisabled, query = False}))
[relay2:cardano.node.InboundGovernor:Info:590] [2023-12-30 08:27:56.46 UTC] TrDemotedToColdRemote (ConnectionId {localAddress = <IP_ADDRESS>:5001, remoteAddress = <IP_ADDRESS>:40858}) (OperationSuccess CommitTr)
[relay2:cardano.node.ConnectionManager:Info:1027311] [2023-12-30 08:28:03.91 UTC] TrConnectionHandler (ConnectionId {localAddress = <IP_ADDRESS>:5001, remoteAddress = <IP_ADDRESS>:44836}) (TrHandshakeSuccess NodeToNodeV_11 (NodeToNodeVersionData {networkMagic = NetworkMagic {unNetworkMagic = 764824073}, diffusionMode = InitiatorAndResponderDiffusionMode, peerSharing = PeerSharingDisabled, query = False}))
[relay2:cardano.node.InboundGovernor:Info:590] [2023-12-30 08:28:08.91 UTC] TrDemotedToColdRemote (ConnectionId {localAddress = <IP_ADDRESS>:5001, remoteAddress = <IP_ADDRESS>:44836}) (OperationSuccess CommitTr)
[relay2:cardano.node.ConnectionManager:Info:1027331] [2023-12-30 08:28:16.26 UTC] TrConnectionHandler (ConnectionId {localAddress = <IP_ADDRESS>:5001, remoteAddress = <IP_ADDRESS>:60164}) (TrHandshakeSuccess NodeToNodeV_11 (NodeToNodeVersionData {networkMagic = NetworkMagic {unNetworkMagic = 764824073}, diffusionMode = InitiatorAndResponderDiffusionMode, peerSharing = PeerSharingDisabled, query = False}))
[relay2:cardano.node.InboundGovernor:Info:590] [2023-12-30 08:28:21.27 UTC] TrDemotedToColdRemote (ConnectionId {localAddress = <IP_ADDRESS>:5001, remoteAddress = <IP_ADDRESS>:60164}) (OperationSuccess CommitTr)

@petroars Try connecting to <IP_ADDRESS> for the host. You can't connect to <IP_ADDRESS>. That's only on the server side for listening.

it had no trouble connecting with <IP_ADDRESS> when sync is 0%. It is the same with <IP_ADDRESS> . And I don't see any errors in Cardano-node logs, maybe I need to enable some other log settings in config.json?
Dec 30 11:12:30 oracle cardano-node[160263]: [oracle:cardano.node.ConnectionManager:Info:22196] [2023-12-30 10:12:30.57 UTC] TrConnectionManagerCounters (ConnectionManagerCounters {fullDuplexConns = 0, duplexConns = 44, unidirectionalConns = 16, inboundConns = 31, outboundConns = 30}) Dec 30 11:12:30 oracle cardano-node[160263]: [oracle:cardano.node.Handshake:Info:22197] [2023-12-30 10:12:30.57 UTC] WithMuxBearer (ConnectionId {localAddress = <IP_ADDRESS>:6060, remoteAddress = <IP_ADDRESS>:57280}) Recv (ClientAgency TokPropose,MsgProposeVersions (fromList [(NodeToNodeV_7,TList [TInt 764824073,TBool False]),(NodeToNodeV_8,TList [TInt 764824073,TBool False]),(NodeToNodeV_9,TList [TInt 764824073,TBool False]),(NodeToNodeV_10,TList [TInt 764824073,TBool False]),(NodeToNodeV_11,TList [TInt 764824073,TBool False,TInt 0,TBool False]),(NodeToNodeV_12,TList [TInt 764824073,TBool False,TInt 0,TBool False]),(NodeToNodeV_13,TList [TInt 764824073,TBool False,TInt 0,TBool False])])) Dec 30 11:12:30 oracle cardano-node[160263]: [oracle:cardano.node.Handshake:Info:22197] [2023-12-30 10:12:30.57 UTC] WithMuxBearer (ConnectionId {localAddress = <IP_ADDRESS>:6060, remoteAddress = <IP_ADDRESS>:57280}) Send (ServerAgency TokConfirm,MsgAcceptVersion NodeToNodeV_11 (TList [TInt 764824073,TBool False,TInt 0,TBool False])) Dec 30 11:12:30 oracle cardano-node[160263]: [oracle:cardano.node.ConnectionManager:Info:22197] [2023-12-30 10:12:30.57 UTC] TrConnectionHandler (ConnectionId {localAddress = <IP_ADDRESS>:6060, remoteAddress = <IP_ADDRESS>:57280}) (TrHandshakeSuccess NodeToNodeV_11 (NodeToNodeVersionData {networkMagic = NetworkMagic {unNetworkMagic = 764824073}, diffusionMode = InitiatorAndResponderDiffusionMode, peerSharing = PeerSharingDisabled, query = False})) Dec 30 11:12:30 oracle cardano-node[160263]: [oracle:cardano.node.ConnectionManager:Info:22196] [2023-12-30 10:12:30.57 UTC] TrConnectionManagerCounters (ConnectionManagerCounters {fullDuplexConns = 0, duplexConns = 45, unidirectionalConns = 16, inboundConns = 31, outboundConns = 30}) Dec 30 11:12:30 oracle cardano-node[160263]: [oracle:cardano.node.Mux:Info:22197] [2023-12-30 10:12:30.57 UTC] Bearer on ConnectionId {localAddress = <IP_ADDRESS>:6060, remoteAddress = <IP_ADDRESS>:57280} event: State: Mature

@cardano-apexpool Something in your topology.json or config.json for p2p settings is preventing cncli from communicating by demoting the peer connection to cold.

I have very standard configs, only P2P enabled.
topology.json
{   "localRoots": [     {       "accessPoints": [],       "advertise": false,       "valency": 1     }   ],   "publicRoots": [     {       "accessPoints": [         {           "address": "backbone.cardano.iog.io",           "port": 3001         }       ],       "advertise": false     },     {       "accessPoints": [         {           "address": "backbone.cardano-mainnet.iohk.io",           "port": 3001         }       ],       "advertise": false     },     {       "accessPoints": [         {           "address": "backbone.mainnet.emurgornd.com",           "port": 3001         }       ],       "advertise": false     }   ],   "useLedgerAfterSlot": 99532743 }
config.json
{   "AlonzoGenesisFile": "alonzo-genesis.json",   "AlonzoGenesisHash": "7e94a15f55d1e82d10f09203fa1d40f8eede58fd8066542cf6566008068ed874",   "ByronGenesisFile": "byron-genesis.json",   "ByronGenesisHash": "5f20df933584822601f9e3f8c024eb5eb252fe8cefb24d1317dc3d432e940ebb",   "ConwayGenesisFile": "conway-genesis.json",   "ConwayGenesisHash": "f7d46bdd3b3c8caf38351c4eef3346a89241707270be0d6106e8a407db294cc6",   "EnableP2P": true,   "LastKnownBlockVersion-Alt": 0,   "LastKnownBlockVersion-Major": 3,   "LastKnownBlockVersion-Minor": 0,   "MaxKnownMajorProtocolVersion": 2,   "Protocol": "Cardano",   "RequiresNetworkMagic": "RequiresNoMagic",   "ShelleyGenesisFile": "shelley-genesis.json",   "ShelleyGenesisHash": "1a3be38bcbb7911969283716ad7aa550250226b76a61fc51cc9a9a35d9276d81",   "TargetNumberOfActivePeers": 10,   "TargetNumberOfEstablishedPeers": 20,   "TargetNumberOfKnownPeers": 50,   "TargetNumberOfRootPeers": 50,   "TraceAcceptPolicy": true,   "TraceBlockFetchClient": false,   "TraceBlockFetchDecisions": false,   "TraceBlockFetchProtocol": false,   "TraceBlockFetchProtocolSerialised": false,   "TraceBlockFetchServer": false,   "TraceChainDb": true,   "TraceChainSyncBlockServer": false,   "TraceChainSyncClient": false,   "TraceChainSyncHeaderServer": false,   "TraceChainSyncProtocol": false,   "TraceConnectionManager": true,   "TraceDNSResolver": false,   "TraceDNSSubscription": false,   "TraceDiffusionInitialization": false,   "TraceErrorPolicy": false,   "TraceForge": true,   "TraceHandshake": true,   "TraceInboundGovernor": false,   "TraceIpSubscription": false,   "TraceLedgerPeers": false,   "TraceLocalChainSyncProtocol": false,   "TraceLocalConnectionManager": false,   "TraceLocalErrorPolicy": false,   "TraceLocalHandshake": false,   "TraceLocalRootPeers": false,   "TraceLocalTxSubmissionProtocol": false,   "TraceLocalTxSubmissionServer": false,   "TraceMempool": false,   "TraceMux": true,   "TracePeerSelection": false,   "TracePeerSelectionActions": false,   "TracePublicRootPeers": false,   "TraceServer": true,   "TraceTxInbound": false,   "TraceTxOutbound": false,   "TraceTxSubmissionProtocol": false,   "TracingVerbosity": "NormalVerbosity",   "TurnOnLogMetrics": true,   "TurnOnLogging": true,   "defaultBackends": [     "KatipBK"   ],   "defaultScribes": [     [       "StdoutSK",       "stdout"     ]   ],   "hasEKG": 12788,   "hasPrometheus": [     "<IP_ADDRESS>",     12798   ],   "minSeverity": "Info",   "options": {     "mapBackends": {       "cardano.node.metrics": [         "EKGViewBK"       ],       "cardano.node.resources": [         "EKGViewBK"       ]     },     "mapSubtrace": {       "cardano.node.metrics": {         "subtrace": "Neutral"       }     }   },   "rotation": {     "rpKeepFilesNum": 10,     "rpLogLimitBytes": 5000000,     "rpMaxAgeHours": 24   },   "setupBackends": [     "KatipBK"   ],   "setupScribes": [     {       "scFormat": "ScText",       "scKind": "StdoutSK",       "scName": "stdout",       "scRotation": null     }   ] }

@cardano-apexpool jump over to discord DM please.

Can you guys do a capture of the network traffic? Port is of course the port your cardano-node is listening on.
tcpdump -ni lo port 5001 -w /tmp/cncli.pcap

That was captured during cncli error
cardano@oracle:/mypool$ sudo tcpdump -r /tmp/cncli.pcap reading from file /tmp/cncli.pcap, link-type EN10MB (Ethernet), snapshot length 262144 15:40:40.133509 IP localhost.53116 > localhost.6060: Flags [P.], seq<PHONE_NUMBER>:3228600582, ack<PHONE_NUMBER>, win 10229, options [nop,nop,TS val 923840683 ecr 923822392], length 8 15:40:40.133541 IP localhost.53116 > localhost.6060: Flags [P.], seq 8:13, ack 1, win 10229, options [nop,nop,TS val 923840683 ecr 923822392], length 5 15:40:40.133717 IP localhost.6060 > localhost.53116: Flags [.], ack 13, win 512, options [nop,nop,TS val 923840683 ecr 923840683], length 0 15:40:40.133871 IP localhost.6060 > localhost.53116: Flags [P.], seq 1:14, ack 13, win 512, options [nop,nop,TS val 923840683 ecr 923840683], length 13 15:40:40.133884 IP localhost.53116 > localhost.6060: Flags [.], ack 14, win 10229, options [nop,nop,TS val 923840684 ecr 923840683], length 0 15:40:44.765587 IP localhost.6060 > localhost.53116: Flags [P.], seq 14:936, ack 13, win 512, options [nop,nop,TS val 923845315 ecr 923840684], length 922 15:40:44.765688 IP localhost.53116 > localhost.6060: Flags [.], ack 936, win 10229, options [nop,nop,TS val 923845315 ecr 923845315], length 0 15:40:45.383303 IP localhost.53116 > localhost.6060: Flags [P.], seq 13:21, ack 936, win 10229, options [nop,nop,TS val 923845933 ecr 923845315], length 8 15:40:45.383329 IP localhost.53116 > localhost.6060: Flags [P.], seq 21:23, ack 936, win 10229, options [nop,nop,TS val 923845933 ecr 923845315], length 2 15:40:45.383739 IP localhost.6060 > localhost.53116: Flags [.], ack 23, win 512, options [nop,nop,TS val 923845933 ecr 923845933], length 0 15:40:45.384052 IP localhost.6060 > localhost.53116: Flags [P.], seq 936:946, ack 23, win 512, options [nop,nop,TS val 923845934 ecr 923845933], length 10 15:40:45.384066 IP localhost.53116 > localhost.6060: Flags [.], ack 946, win 10229, options [nop,nop,TS val 923845934 ecr 923845934], length 0 15:40:47.030724 IP localhost.33968 > localhost.6060: Flags [S], seq<PHONE_NUMBER>, win 65495, options [mss 65495,sackOK,TS val 923847580 ecr 0,nop,wscale 7], length 0 15:40:47.030744 IP localhost.6060 > localhost.33968: Flags [S.], seq<PHONE_NUMBER>, ack<PHONE_NUMBER>, win 65483, options [mss 65495,sackOK,TS val 923847580 ecr 923847580,nop,wscale 7], length 0 15:40:47.030757 IP localhost.33968 > localhost.6060: Flags [.], ack 1, win 512, options [nop,nop,TS val 923847580 ecr 923847580], length 0 15:40:47.030900 IP localhost.33968 > localhost.6060: Flags [P.], seq 1:9, ack 1, win 512, options [nop,nop,TS val 923847581 ecr 923847580], length 8 15:40:47.030905 IP localhost.6060 > localhost.33968: Flags [.], ack 9, win 512, options [nop,nop,TS val 923847581 ecr 923847581], length 0 15:40:47.030912 IP localhost.33968 > localhost.6060: Flags [P.], seq 9:74, ack 1, win 512, options [nop,nop,TS val 923847581 ecr 923847581], length 65 15:40:47.030916 IP localhost.6060 > localhost.33968: Flags [.], ack 74, win 512, options [nop,nop,TS val 923847581 ecr 923847581], length 0 15:40:47.077926 IP localhost.6060 > localhost.33968: Flags [P.], seq 1:21, ack 74, win 512, options [nop,nop,TS val 923847628 ecr 923847581], length 20 15:40:47.077947 IP localhost.33968 > localhost.6060: Flags [.], ack 21, win 512, options [nop,nop,TS val 923847628 ecr 923847628], length 0 15:40:52.214491 IP localhost.6060 > localhost.33968: Flags [R.], seq 21, ack 74, win 512, options [nop,nop,TS val 923852764 ecr 923847628], length 0 15:41:00.135185 IP localhost.53116 > localhost.6060: Flags [P.], seq 23:31, ack 946, win 10229, options [nop,nop,TS val 923860685 ecr 923845934], length 8 15:41:00.135212 IP localhost.53116 > localhost.6060: Flags [P.], seq 31:36, ack 946, win 10229, options [nop,nop,TS val 923860685 ecr 923845934], length 5 15:41:00.135304 IP localhost.6060 > localhost.53116: Flags [.], ack 36, win 512, options [nop,nop,TS val 923860685 ecr 923860685], length 0 15:41:00.135518 IP localhost.6060 > localhost.53116: Flags [P.], seq 946:959, ack 36, win 512, options [nop,nop,TS val 923860685 ecr 923860685], length 13 15:41:00.135727 IP localhost.53116 > localhost.6060: Flags [.], ack 959, win 10229, options [nop,nop,TS val 923860685 ecr 923860685], length 0 15:41:08.272231 IP localhost.6060 > localhost.53116: Flags [P.], seq 959:1883, ack 36, win 512, options [nop,nop,TS val 923868822 ecr 923860685], length 924 15:41:08.272259 IP localhost.53116 > localhost.6060: Flags [.], ack 1883, win 10229, options [nop,nop,TS val 923868822 ecr 923868822], length 0 15:41:08.888076 IP localhost.53116 > localhost.6060: Flags [P.], seq 36:44, ack 1883, win 10229, options [nop,nop,TS val 923869438 ecr 923868822], length 8 15:41:08.888102 IP localhost.53116 > localhost.6060: Flags [P.], seq 44:46, ack 1883, win 10229, options [nop,nop,TS val 923869438 ecr 923868822], length 2 15:41:08.888709 IP localhost.6060 > localhost.53116: Flags [.], ack 46, win 512, options [nop,nop,TS val 923869438 ecr 923869438], length 0 15:41:08.889001 IP localhost.6060 > localhost.53116: Flags [P.], seq 1883:1893, ack 46, win 512, options [nop,nop,TS val 923869439 ecr 923869438], length 10 15:41:08.889018 IP localhost.53116 > localhost.6060: Flags [.], ack 1893, win 10229, options [nop,nop,TS val 923869439 ecr 923869439], length 0 15:41:12.110451 IP localhost.60980 > localhost.6060: Flags [S], seq<PHONE_NUMBER>, win 65495, options [mss 65495,sackOK,TS val 923872660 ecr 0,nop,wscale 7], length 0 15:41:12.110471 IP localhost.6060 > localhost.60980: Flags [S.], seq<PHONE_NUMBER>, ack<PHONE_NUMBER>, win 65483, options [mss 65495,sackOK,TS val 923872660 ecr 923872660,nop,wscale 7], length 0 15:41:12.110485 IP localhost.60980 > localhost.6060: Flags [.], ack 1, win 512, options [nop,nop,TS val 923872660 ecr 923872660], length 0 15:41:12.110601 IP localhost.60980 > localhost.6060: Flags [P.], seq 1:9, ack 1, win 512, options [nop,nop,TS val 923872660 ecr 923872660], length 8 15:41:12.110606 IP localhost.6060 > localhost.60980: Flags [.], ack 9, win 512, options [nop,nop,TS val 923872660 ecr 923872660], length 0 15:41:12.110613 IP localhost.60980 > localhost.6060: Flags [P.], seq 9:74, ack 1, win 512, options [nop,nop,TS val 923872660 ecr 923872660], length 65 15:41:12.110617 IP localhost.6060 > localhost.60980: Flags [.], ack 74, win 512, options [nop,nop,TS val 923872660 ecr 923872660], length 0 15:41:12.123283 IP localhost.6060 > localhost.60980: Flags [P.], seq 1:21, ack 74, win 512, options [nop,nop,TS val 923872673 ecr 923872660], length 20 15:41:12.123304 IP localhost.60980 > localhost.6060: Flags [.], ack 21, win 512, options [nop,nop,TS val 923872673 ecr 923872673], length 0 15:41:12.865509 IP localhost.60980 > localhost.6060: Flags [F.], seq 74, ack 21, win 512, options [nop,nop,TS val 923873415 ecr 923872673], length 0 15:41:12.905980 IP localhost.6060 > localhost.60980: Flags [.], ack 75, win 512, options [nop,nop,TS val 923873456 ecr 923873415], length 0 15:41:13.959439 IP localhost.6060 > localhost.60980: Flags [R.], seq 21, ack 75, win 512, options [nop,nop,TS val 923874509 ecr 923873415], length 0

somehow it uses different timezones, so it shows 1 hour difference. But it was done at the same time

@petroars I believe what is happening is that your cncli is taking too long to query the database and gather the points to send to the node to start the find-intersect call for the chainsync miniprotocol. I'm going to adjust the code so it queries this before making the connection instead of after.
The node has a default timeout of 5 seconds after the handshake completes. If the client doesn't send anything in that time, it gets dropped.
In the meantime, if you want to test this theory, you can temporarily set
"ProtocolIdleTimeout": 60,

in your config.json. This will see if my theory holds.

@petroars I believe what is happening is that your cncli is taking too long to query the database and gather the points to send to the node to start the find-intersect call for the chainsync miniprotocol. I'm going to adjust the code so it queries this before making the connection instead of after.
The node has a default timeout of 5 seconds after the handshake completes. If the client doesn't send anything in that time, it gets dropped.
In the meantime, if you want to test this theory, you can temporarily set
"ProtocolIdleTimeout": 60,

in your config.json. This will see if my theory holds.

Yes! It works now! Thank you! Is it safe to run nodes and BP with that setting? "ProtocolIdleTimeout": 60 ?

@petroars Please test alpha4.

@petroars You can remove the ProtocolIdleTimeout setting. In alpha4, the db query has been improved to running fast so the node won't kick you off for timing out.

@petroars You can remove the ProtocolIdleTimeout setting. In alpha4, the db query has been improved to running fast so the node won't kick you off for timing out.

Yes, Alpha5 works, thank you! I guess we can finally close this issue.

Thank you so much @AndrewWestberg for your excellent work in getting this great tool back into our workflow without any reservations.  I've tested the latest non-alpha release operationally among most of the scenarios above & that we reported up through https://github.com/cardano-community/cncli/issues/25#issuecomment-1650237680, and it stays working all around whatever happens to the node or the host networking environment. 🤩

Thanks @rphair . It was difficult to figure out all and resolve all the issues. It felt good to finally close out all the cncli issues.


Init date

How can I set the initial date and scroll to it?
If I have
minDate: DateTime(2010, 10, 1),
maxDate: DateTime(2030, 3, 1),

how can I scroll to DateTime.now() ?
Maybe it could work with scrollController. But jumpTo is not working because the months have an individual height.
Do you have a minimal example how this can be done?

Hi @desmeit we have another issue about this feature. #22
We will try to make it work as soon as possible.
Thanks for your feedback.
I'm closing this issue since it is duplicate.


Running pytest from base directory gives errors

I'm not sure if that's the desired behavior, but running pytest from the base directory gives many test failures as the sample data from tests/samples is not found.

Ah, I guess I could make that more generic. The "intended" way of running the tests is from the tests/ directory.

This is fixed -- I get the absolute path of the test file, and the sample file relative to it.


Add feature test for minimal information

What
This feature test will check that a user can complete the form journey
providing the bare minimum information required.
I have also removed the abilty for nhs_number to be null as it is
now always required.
Why
We had an incident in which it was discovered that a lot of the errors were being caused by users not completing some fields. In all cases, these were fields that is user is allowed to leave blank, for example, building_and_street_line_2 in the support address controller.
These values aren't just used in the controller where they're first stored, but across the app. So we need to check that these values can be nil at various places in the journey.
Trello card

Codecov Report

Merging #439 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #439   +/-   ##
=======================================
  Coverage   99.28%   99.29%
=======================================
  Files          71       71
  Lines        1955     1972   +17
=======================================
+ Hits         1941     1958   +17
  Misses         14       14

Impacted Files
Coverage Δ

...tures/filling_in_the_form/fill_in_the_form_spec.rb
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


[muser]is it OK to use userspace pointer in kernel direcly

I used the Debian 4.19 kernel to test the kmod, all seems OK except the function in muser.c
void dump_buffer(unsigned char const *const buf, uint32_t count)
I can see call trace of kernel like : BUG: unable to handle kernel paging request at ...
the "buf" is a userspace pointer, should it be used after call copy_from_user?

Yes I think you're right, it needs to be movde after copy_from_user, not sure why this didn't trigger for us in the first place. Feel free to raise a PR if you have a patch that fixes it.
Bear in mind that the kernel module is no longer maintained. Doesn't the purely user space version work for your use case?

Hi tmakatos,
I'm still estimating these frameworks, actually I want to emulate a simple pcie switch and static link/hotplug some endpoints behind it.
any suggestions?

I'm still estimating these frameworks, actually I want to emulate a simple pcie switch and static link/hotplug some endpoints behind it.

Isn't the purely user space solution implemented in the master branch suitable for this?

Just a heads-up, so far our focus has been on endpoints, further work in the framework would probably be necessary to emulate a switch.

closing as per above


Connect Unity with the Android app

This issue needs to be developed a bit more

Unity is not on the agenda so I'm closing this issue for now


Issues with fish shell

Looks really excellent tool! Unfortunatley, when I installed it, and activate it in my fish shell I  get:
from sourcing file -
	called on line 21 of file -
in function '__rtx_env_eval'
in event handler: handler for generic event 'fish_prompt'
source: Error while reading file '<stdin>'

The activation part of my shell is like so:
zoxide init fish | source
# source /opt/homebrew/opt/asdf/libexec/asdf.fish
mcfly init fish | source
starship init fish | source
rtx activate fish | source

Some versions:
fish --version
fish, version 3.6.0

rtx --version
1.20.1 macos-arm64 (built 2023-03-02)

Not sure how to start debugging this, help you fix it. Anything I can run/provide, I will!

can you show me the output of rtx doctor and rtx env? Also does rtx env | source work?

closing due to inactivity


keep-alive never used

While debugging with a proxy, i see that "connection: keep-alive" or "connection: close" is never written. It seems, the problem is in this line:
https://github.com/Bobris/Nowin/blob/master/Nowin/Transport2HttpHandler.cs#L621
            if (_isHttp10 && _isKeepAlive)
            {
                HeaderAppend("Connection: keep-alive\r\n");
            }

_isHttp10 is false, because it's http 1.1, so it will never run the if-block.
removing the "_isHttp10" seems to work (Header is written), but i'm not sure if all other works correct with this change.

By spec it does not need to be there because it is default:
https://stackoverflow.com/questions/7927566/is-an-http-1-1-request-implicitly-keep-alive-by-default?rq=1