proposal: x/crypto/ssh: add a specific error for algorithm negotiation issues/errors

A common requirement for applications using x/crypto/ssh is to report some errors differently than others.
We currently have ServerAuthError and ErrNoAuth which are useful for authentication related errors.
If the client and the server cannot negotiate a common algorithm for host key, KEX, cipher, MAC we have a generic error and can only search for the error string.
New algorithms are added over time and old algorithms are deprecated and disabled by default, so a well defined error allows applications using the library to better report errors to end users and allow them to fix the issue (e.g by enabling an old algorithm).
An algorithm negotiation error is typically returned in the findCommon method, but the same error should also be returned in other places, for example if pickHostKey fails or in enterKeyExchange so searching for an error string is quite fragile.
We can add something very simple like this
// ErrAlgorithmNegotiation is the error returned if the client and the server cannot agree
// on an algorithm for host key, KEX, cipher, MAC or if an unsupported algorithm
// is configured.
var ErrAlgorithmNegotiation = errors.New("ssh: algorithm negotiation error")

and wrap this error when needed, for example in findCommon we could use
return "", fmt.Errorf("%w: ssh: no common algorithm for %s; client offered: %v, server offered: %v", ErrAlgorithm, what, client, server)

instead of
return "", fmt.Errorf("ssh: no common algorithm for %s; client offered: %v, server offered: %v", what, client, server)

and the same in other places where there is an algorithm error.
If you see CL 508398, this error may also be returned if NewSignerWithAlgorithms fails for example.
We could also evaluate something more complex, such as an error structure with an exported error code for each error category.
This way we could, for example, have specific error codes for MAC, KEX or cipher negotiation errors, I'm not sure if it's worth the effort to implement and maintain, but if you prefer this approach I can try to propose an API for that as well.
cc @golang/security

This sounds good. Two notes: it should be possible to make this play well with #58523, at least to expose the remote’s supported algorithms, which might be useful to track in metrics for applications; and we can make the final error string the same as before so we don’t break current string matching applications.ErrAlgorithms feels a bit generic as a name. ErrAlgorithmNegotiation or ErrNoCommonAlgorithms?On Jul 23, 2023, at 11:54, Nicola Murino @.***> wrote:
A common requirement for applications using x/crypto/ssh is to report some errors differently than others.
We currently have ServerAuthError and ErrNoAuth which are useful for authentication related errors.
If the client and the server cannot negotiate a common algorithm for host key, KEX, cipher, MAC we have a generic error and can only search for the error string.
New algorithms are added over time and old algorithms are deprecated and disabled by default, so a well defined error allows applications using the library to better report errors to end users and allow them to fix the issue (e.g by enabling an old algorithm).
An algorithm negotiation error is typically returned in the findCommon method, but the same error should also be returned in other places, for example if pickHostKey fails or in enterKeyExchange so searching for an error string is quite fragile.
We can add something very simple like this
// ErrAlgorithm is the error returned if the client and the server cannot agree
// on an algorithm for host key, KEX, cipher, MAC or if an unsupported algorithm
// is configured.
var ErrAlgorithm = errors.New("ssh: algorithm error")
and wrap this error when needed, for example in findCommon we could use
return "", fmt.Errorf("%w: no common algorithm for %s; client offered: %v, server offered: %v", ErrAlgorithm, what, client, server)
instead of
return "", fmt.Errorf("ssh: no common algorithm for %s; client offered: %v, server offered: %v", what, client, server)
and the same in other places where there is an algorithm error.
If you see CL 508398, this error may also be returned if NewSignerWithAlgorithms fails for example.
We could also evaluate something more complex, such as an error structure with an exported error code for each error category.
This way we could, for example, have specific error codes for MAC, KEX or cipher negotiation errors, I'm not sure if it's worth the effort to implement and maintain, but if you prefer this approach I can try to propose an API for that as well.
cc @golang/security
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are on a team that was mentioned.Message ID: @.***>

@FiloSottile do you mean something like this?
// ErrAlgorithmNegotiation is the error returned if the client and the server cannot agree
// on an algorithm for host key, KEX, cipher, MAC or if an unsupported algorithm
// is configured.
var ErrAlgorithmNegotiation = &AlgorithmNegotiationError{}

type AlgorithmNegotiationError struct {
	err              error
	ClientAlgorithms []string
	ServerAlgorithms []string
}

func (e *AlgorithmNegotiationError) Error() string {
	return e.err.Error()
}

func (e *AlgorithmNegotiationError) Is(target error) bool {
	_, ok := target.(*AlgorithmNegotiationError)
	return ok
}

func (e *AlgorithmNegotiationError) Unwrap() error {
	return e.err
}

and in findCommon:
func findCommon(what string, client []string, server []string) (common string, err error) {
	for _, c := range client {
		for _, s := range server {
			if c == s {
				return c, nil
			}
		}
	}
	return "", &AlgorithmNegotiationError{
		err:              fmt.Errorf("ssh: no common algorithm for %s; client offered: %v, server offered: %v", what, client, server),
		ClientAlgorithms: client,
		ServerAlgorithms: server,
	}
}

I mean that if in #58523 we come up with an Algorithms type, we should maybe expose it as part of AlgorithmNegotiationError. (No need to have ErrAlgorithmNegotiation if we have AlgorithmNegotiationError, applications can just use errors.As.)

ok thanks.
So the struct approach should be fine
// AlgorithmNegotiationError defines the error returned if the client and the
// server cannot agree on an algorithm for host key, KEX, cipher, MAC or if an
// unsupported algorithm is configured.
type AlgorithmNegotiationError struct {
	err                 error
	SupportedAlgorithms []string
}

func (e *AlgorithmNegotiationError) Error() string {
	return e.err.Error()
}

func (e *AlgorithmNegotiationError) Is(target error) bool {
	_, ok := target.(*AlgorithmNegotiationError)
	return ok
}

func (e *AlgorithmNegotiationError) Unwrap() error {
	return e.err
}

for now the algorithms are strings. If this changes in the future, we can use of the Algorithm type instead of strings.
However, it's probably better to wait for an accepted proposal for #58523 before proceeding here

for now the algorithms are strings. If this changes in the future, we can use of the Algorithm type instead of strings.

we can't change the type for things like "aes128-ctr" from string to something else. That would break backward compatibility.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

it should be possible to make this play well with #58523, at least to expose the remote’s supported algorithms,

not sure: that bug is about exposing algorithms in a successful connection setup (single algorithm for hostkey, kex, mac & cipher), where this issue is about unsuccessful connection setup (list of algorithms for one of {kex,mac,cipher,hostkey}). For backward compat reasons, the algorithms have to be string, so I don't think you can do much better than a proposal of struct AlgorithmError { What string; Algorithms []string }

@hanwen if we want to add What string perhaps we should also consider exposing these constants.
Other than that, what do you think about this?
// AlgorithmNegotiationError defines the error returned if the client and the
// server cannot agree on an algorithm for host key, KEX, cipher, MAC or if an
// unsupported algorithm is configured.
type AlgorithmNegotiationError struct {
	err                 error
	What                string
	RequestedAlgorithms []string
	SupportedAlgorithms []string
}

I don't understand what the inner error is good for.
other than that, Requested+Supported is likely needed to make sure the error string doesn't change, so LGTM.

I don't understand what the inner error is good for.
other than that, Requested+Supported is likely needed to make sure the error string doesn't change, so LGTM.

the inner error is to encapsulate the current error and thus keep the same error string for people who, copying our test cases, do things like strings.Contains(err.Error(), "common algorithm").
An example of usage in findCommon would be
return "", &AlgorithmNegotiationError{
		err:                 fmt.Errorf("ssh: no common algorithm for %s; client offered: %v, server offered: %v", what, client, server),
		What:                what,
		SupportedAlgorithms: ..., // need to pass if we are the client or the server
		RequestedAlgorithms: ...,
	}

@drakkan I still don't see why you need err. The AlgorithmNegotiationError can implement a Error method returning that string directly, no?

@drakkan I still don't see why you need err. The AlgorithmNegotiationError can implement a Error method returning that string directly, no?

This error can also be used in other places than findCommon  and we may not always have a client and a server. For example this error is also appropriate for NewSignerWithAlgorithms, see this CL. We could use it also in pickHostKey and in enterKeyExchange and the error strings are all different. The (private) inner error is a way to allow to customize the error string and keep backward compatibility.

I agree with Russ that the inner error seems out of place. Can we change the details of how the error string is formatted, or is that subject to a compat promise too?
If we want to keep the string completely intact, it's a little annoying, because it says "server" and "client", so we'd have to add an IsServer or IsClient boolean.
re. other places: worst case, we can introduce different error types for the different types of negotiation failures.

I agree with Russ that the inner error seems out of place. Can we change the details of how the error string is formatted, or is that subject to a compat promise too?

I'm not sure about the compat promise for error strings, maybe there is no compat promise here.

If we want to keep the string completely intact, it's a little annoying, because it says "server" and "client", so we'd have to add an IsServer or IsClient boolean.

yes, this is the point, if we can change the error string it would be simpler. In our test case we do this. I also do something similar in SFTPGo because an algorithm negotiation error must be reported differently from other errors. Maybe we could just leave ssh: no common algorithm in the error string and remove the inner error.

re. other places: worst case, we can introduce different error types for the different types of negotiation failures.

we can but even there we have a list of supported algos and a list of requested algos so this error would fit perfectly

No new comments here since August. Have we converged on an API proposal?

Any updates here?

Sorry for the delay. I think we can simplify the proposal like this
// AlgorithmNegotiationError defines the error returned if the client and the
// server cannot agree on an algorithm for key exchange, host key, cipher, MAC.
type AlgorithmNegotiationError struct {
	What                string
	RequestedAlgorithms []string
	SupportedAlgorithms []string
}

we will discuss the structure's private fields and other implementation details in the CL. I think it's reasonable to use this error only for client/server negotiation errors and not other places too and we can keep the current error string to avoid any issues to our users

Have all remaining concerns about this proposal been addressed?
Proposal is to add:
// AlgorithmNegotiationError defines the error returned if the client and the
// server cannot agree on an algorithm for key exchange, host key, cipher, MAC.
type AlgorithmNegotiationError struct {
	What                string
	RequestedAlgorithms []string
	SupportedAlgorithms []string
}

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group
Proposal is to add:
// AlgorithmNegotiationError defines the error returned if the client and the
// server cannot agree on an algorithm for key exchange, host key, cipher, MAC.
type AlgorithmNegotiationError struct {
	What                string
	RequestedAlgorithms []string
	SupportedAlgorithms []string
}

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group
Proposal is to add:
// AlgorithmNegotiationError defines the error returned if the client and the
// server cannot agree on an algorithm for key exchange, host key, cipher, MAC.
type AlgorithmNegotiationError struct {
	What                string
	RequestedAlgorithms []string
	SupportedAlgorithms []string
}


Documented, Tested Examples of Idempotent Resource Creation

In light of #5006, I think the community would benefit greatly from having canonical examples of how to write scripts to do things like "ensure resources exist".
These types of scripts are used all over the place, and having a documented method for idempotent resource creation is table stakes, in my opinion.
Further, I've been personally broken by changes in the CLI, due to the fact that there was either no guidance around this, no testing around it, or both.
Additionally, someone on Twitter indicated that I might be better off using az resource show (rather than az [resource] show as it would then be more likely to be consistent about how it handles 404s. Which is a great point, and would be a great thing to see written down in some guidance and example bash scripts.
(Apologies if these such examples exist, I've not been able to find them yet!)

Most create commands are idempotent so that you can just always run the create command to ensure it exists. There are exceptions to this (unfortunately) due to services who raise an error if a you attempt to PUT on something that already exists (even if the payload is the same).
Otherwise, I'd defer to @johanste on this topic.

What @tjprescott said. For ARM control plane operations, the platform is generally using PUT as the only means for resource creates. Which is inherently idempotent. Which means that our create commands are expected to be idempotent. Which also has the benefit of ensuring that the resource not only exists, but that it is also in the state you expect (e.g. having a network resource in the wrong location probably won't help - you probably want your script to fail or correct the existing resource at that point). The main drawback is performance for some resources (in theory, it should be a no-op if the resource already exists in the state indicated by the request - in practice, less so).
The pattern we originally wanted to follow was to have a 'create if not exists' flag on the create command. However, unfortunately, it has never been a requirement for an Azure resource provider to provide support for etags/if-match/if-none-match headers, which means that this support is somewhat spotty (we are pushing to get it included in the next rev of the Azure Resource Provider contract - not sure if it will make it or not). We could (and still can) implement this with a GET to determine if the resource exists beforehand modulo the race condition introduced if the resource provider doesn't support etags/if-non-match.
Thoughts?

Closing for now due to #6740. Thanks.


Store new community members

When someone wants to join the community, first store them in the db (#15), then kick off a transactional email with a link to Slack.
Note: This is tightly coupled with #18.

For now I'm using a manual Netlify form (#21). If we begin getting so many registrations that it becomes unwieldy, then I'll adjust.


Object Pools

It would be extremely helpful to have pools built into Zenject. Any type of object that needs to be created often (bullets, enemies, particles, events) would benefit greatly. My current project would fall flat on its face if I used Zenject factories as-is.
Honestly, I'm not very familiar with IoC or Zenject, so if anything here doesn't make sense, I apologize.
Pool bindings would be written like this:
// Monobehaviour to gameobject pool
_container.BindPool<Asteroid>(SceneSettings.Asteroid.Prefab, size, inflationType, overflowType);
// Short for:
_continer.Bind<IPool<Asteroid>>().To(
    new GameObjectPool<Asteroid>(_container, Settings.Asteroid.Prefab, size, inflationType, overflowType));

// Concrete class to pool
_container.BindPool<Enemy>(size, inflationType, overflowType);
// Short for:
_container.Bind<IPool<Enemy>>().ToSingle<Pool<Enemy>>(size, inflationType, overflowType);

// Prefab to pool
_container.Bind<IPool<Player>>().ToSingleFromPrefab<Pool<Player>>(Settings.Player.Prefab, size, inflationType, overflowType);

.BindPool() would be defined in DiContainer as generic a method with one and two types along with overrides for standard and prefab pools. I'm not quite sure how you would handle the arguments for BindPool internally.
The classes Pool and GameObjectPool would be written custom factories similar to Factory and GameObjectFactory.
Example usage:
public class Enemy : IPoolable
{
    public Action<Enemy> OnDeath = delegate { };

    public Enemy() { }

    #region IPoolable Implementation

    // Reset instance to default values
    public void Restore()
    {
        OnDeath = delegate { };
    }

    #endregion

    private void Die()
    {
        OnDeath(this);
    }
}

public class EnemySpawner
{
    private IPool<Enemy> pool;

    public EnemySpawner(IPool<Enemy> pool)
    {
        this.pool = pool;
    }

    public Enemy Create(params object[] constructorArgs)
    {
        var enemy = pool.Create(constructorArgs);
        enemy.OnDeath += OnEnemyDeath;

        return enemy;
    }

    private void OnEnemyDeath(Enemy enemy)
    {
        pool.ReturnInstance(enemy);
    }
}

You could use this and bind the generic buffer to a non-generic type.
Binding to the container might be a little tricky since you have to provide a source function.
One thing left I am working on is runtime generation of gameobjects in the main thread.
public class FlyweightBuffer<T> {
		private readonly Queue<T> buffer = new Queue<T>();
		private readonly Func<T> itemSource;

		public FlyweightBuffer(Func<T> source) {
			this.itemSource = source;
		}

		public T getItem() {
			if (buffer.Count > 0)
				return buffer.Dequeue();
			else
				return itemSource();
		}

		public void returnItem(T item) {
			buffer.Enqueue(item);
		}
	}

Added on develop branch


Opening preview in a new window discards query parameters

When opening a preview that has query parameters in the URL in a new window, these query parameters are discarded.
This might not be a bug and just how Lookbook is intended to work, but I found it surprising. I have used the Lookbook demo to illustrate the bug.
I have tested this in:

Chrome Version 103.0.5060.134 (Official Build) (x86_64)
Safari Version 15.5 (176<IP_ADDRESS>.8)

Steps to reproduce

navigate to the Avatar - Rounded page
in the Params tab, change the size to Small
click the Open in new window button on the top right hand side of the preview

Expected result
The new window displays a small avatar
Actual result
The new window displays the default avatar

Hi @andapopovici! Thank you for the bug report and I'm really sorry it has taken so long to reply. I've been away on holiday and am just catching up on issues here.
I've tested this and it is indeed a bug - good spot :-) I'll get it fixed as soon as I can and into the next release.
Many thanks for taking the time to report it 👍

I can confirm this is now fixed in 0.9.4 which we are running in our Lookbook instance. Thanks a lot for the fix @allmarkedup !


Update ReadMe.md

Things I have edited:

Add acknowledgement to AB3
Update the link of the GitHub Actions build status badge to our team's repo.

Codecov Report
Base: 72.15% // Head: 72.15% // No change to project coverage :thumbsup:

Coverage data is based on head (1da95d6) compared to base (4df3d67).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##             master      #12   +/-   ##
=========================================
  Coverage     72.15%   72.15%
  Complexity      399      399
=========================================
  Files            70       70
  Lines          1232     1232
  Branches        125      125
=========================================
  Hits            889      889
  Misses          311      311
  Partials         32       32

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


copr: BitVec should implement PartialEq correctly

Development Task
Currently we use the default derive of BitVec. However, when BitVec get truncated, default PartialEq implementation may not work correctly.

Another reason to use a crate. 😢

Hi! As described, derived PartialEq does not work for truncated BitVec. Failing test case:
fn test_partial_eq() {
    let mut vec1 = BitVec::with_capacity(0);
    vec1.push(true);

    let mut vec2 = BitVec::with_capacity(0);
    vec2.push(true);
    vec2.push(true);

    vec2.truncate(1);

    assert_eq!(vec1, vec2);
}

The work done in https://github.com/tikv/tikv/pull/8809 that does cleanup on truncate should resolve this issue.
Are you using a custom BitVec implementation instead of a crate for perfomance reasons and/or to keep the dependency tree small? You could try to benchmark some of the existing bitvec crates. They may be well optimized already

At that time, I wanted to bit "or" vectors in a more controllable way, when calculating expressions on multiple columns. Now I thought existing crates like BitVec could be enough for this task. I have some motivation to migrate to that.

@skyzh could I help?

@skyzh could I help?

You may have a try if you want, thanks!


Git Bash not added automatically

Windows Terminal version
1.17.11461.0
Windows build number
10.0.19045.3086
Other Software
Git 2.41.0
Steps to reproduce

Install Terminal from Windows Store or via winget (winget repo)
Start Terminal
Look at list of profiles

Expected Behavior
Git Bash profile is picked up automatically.
It did so on my other computers (Win11).
Actual Behavior
No Git Bash on the list but it does have WSL distros.

Thanks for reporting this!
Git for Windows has an option in the installer to enable automatic Terminal integration.

We have stopped adding new automatically-detected profiles for the time being, and Git is using one of our supported interfaces for adding new profiles :smile:

I'm using winget so that's probably why I miss this.
Would it be safe for Git to always register even if terminal is not installed (i.e. have this on by default in git package)?

Absolutely, it would be safe for them to register all the time.
Tech Details:
All it does is put a JSON file in a specific location, either %ProgramData%\Microsoft\Windows Terminal or %LOCALAPPDATA%\Microsoft\Windows Terminal.


Fix problems with validation border color / validation classes

Because both FluentDatePicker and the contained FluentTextField derive from FluentInputBase the ClassValue is set twice and that in the end leads to inconsistent values for validation in the class attribute.
To solve, I'm adding a bool parameter Embedded to FluentInputBase (defaults to false). If set to true, ClassValue will not include the FieldCssClass for that component.
Because it is a parameter on FluentInputBase, we can apply this fix to all input components that have other embedded input components.

Add Embedded parameter to FluentInputBase
[DatePicker] Use Embedded
[DatePicker] Use CurrentValueAsString and FormatValueAsString from base class
[DatePicker] turn off AutoComplete

Fix #1311
✅ Checklist
General

[ ] I have added tests for my changes.
[X] I have tested my changes.
[ ] I have updated the project documentation to reflect my changes.
[ ] I have read the CONTRIBUTING documentation and followed the standards for this project.

Component-specific

[ ] I have added a new component
[ ] I have added Unit Tests for my new compontent
[ ] I have modified an existing component
[ ] I have validate Unit Tests for an existing component

⏭ Next Steps

Oops, Fix for #1350 should have gone to different branch. But it is too small of a fix to revert/recreate, etc. so we will just merge it through this one.


[cinder-csi-driver] delete statefulset pod then new pod remounted failed with  blkid returns invalid output

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
What happened:
i deploy a statefulset with replicas one used cinder pvc ,then running
second,i delete the pod and the new replicas pod remount pvc but failed:
web-0              1/1     Running             0          4d23h   <IP_ADDRESS>   <IP_ADDRESS>
web-0              1/1     Terminating         0          4d23h   <IP_ADDRESS>   <IP_ADDRESS>
web-0              0/1     Terminating         0          4d23h           <IP_ADDRESS>
web-0              0/1     Pending             0          4s              <IP_ADDRESS>
web-0              0/1     ContainerCreating   0          4s              <IP_ADDRESS>
the web-0 pod logs :
Events:
Type     Reason                  Age                From                     Message

Normal   Scheduled               2m8s               default-scheduler        Successfully assigned default/web-0 to <IP_ADDRESS>
Normal   SuccessfulAttachVolume  104s               attachdetach-controller  AttachVolume.Attach succeeded for volume "pvc-c9947920-991c-41cf-b08e-648ad67b6eb4"
Warning  FailedMount             24s (x8 over 95s)  kubelet, <IP_ADDRESS>      MountVolume.MountDevice failed for volume "pvc-c9947920-991c-41cf-b08e-648ad67b6eb4" : rpc error: code = Internal desc = failed to get disk format of disk /dev/disk/by-id/virtio-c14a81a4-3d68-4288-9: blkid returns invalid output: /dev/disk/by-id/virtio-c14a81a4-3d68-4288-9: UUID="27b52caf-ec56-489e-91e6-4f3d003b43c2" TYPE="ext4"
Warning  FailedMount             5s                 kubelet, <IP_ADDRESS>      Unable to attach or mount volumes: unmounted volumes=[www]
the ds node-plugin logs :
I0611 09:04:39.526996       1 mount_linux.go:405] Attempting to determine if disk "/dev/disk/by-id/virtio-c14a81a4-3d68-4288-9" is formatted using blkid with args: ([-p -s TYPE -s PTTYPE -o export /dev/disk/by-id/virtio-c14a81a4-3d68-4288-9])
I0611 09:04:39.544355       1 mount_linux.go:408] Output: "/dev/disk/by-id/virtio-c14a81a4-3d68-4288-9: UUID="27b52caf-ec56-489e-91e6-4f3d003b43c2" TYPE="ext4"\n", err:
E0611 09:04:39.546005       1 utils.go:83] GRPC error: rpc error: code = Internal desc = failed to get disk format of disk /dev/disk/by-id/virtio-c14a81a4-3d68-4288-9: blkid returns invalid output: /dev/disk/by-id/virtio-c14a81a4-3d68-4288-9: UUID="27b52caf-ec56-489e-91e6-4f3d003b43c2" TYPE="ext4"
What you expected to happen:
the new pod can running
How to reproduce it:
Anything else we need to know?:
Environment: k8s v1.17  csi-cinder-driver v1.18 release version

openstack-cloud-controller-manager(or other related binary) version:
OpenStack version:
Others:

@ramineni  can you see the problem ? thanks

@jianglingxia please follow the issue template to indicate this is a cinder CSI issue

hi, i found the logs print :
the blkid command output not same with the command result in k8s.io/utils go code
Output: "/dev/disk/by-id/virtio-c14a81a4-3d68-4288-9: UUID="27b52caf-ec56-489e-91e6-4f3d003b43c2" TYPE="ext4"\n", err:
but i exec the command in my minion
[root@paas-controller-1:/home/ubuntu]$ blkid -p -s TYPE -s PTTYPE -o export /dev/disk/by-id/virtio-c14a81a4-3d68-4288-9
DEVNAME=/dev/disk/by-id/virtio-c14a81a4-3d68-4288-9
TYPE=ext4

@ramineni  jichenjc  can see the issue? is maybe pod reschedule other node have some problem? thanks

/remove-lifecycle stale

@jianglingxia blkid is executed inside the nodeplugin daemonset container. can you show your daemonset manifest?
@ramineni I think this is a good example of why using exec in go is not a good idea. ref https://github.com/kubernetes/cloud-provider-openstack/pull/861#discussion_r359881506


Moving to Node.js v6 and v7 support

To make it short - I'd like to stop supporting Node.js v4 and v5 and focus on v6 and v7.
Any strong reasons why that would be an issue?
Longer story:

Multiple libraries simply don't support older than specific Node.js v6 versions (nodemailer and protractor to name a few)
Maintaining the travis matrix and test setup for v4 and v5 is a pain
Node.js v4 entered maintenance mode this April

Done on our sub stack.
Possible to maintain two versions, to let the time to follow, but 4 is too restrictive ... And can cause to spend too much time to the developers ... not the priority for us in my opinion

So I'll definitely upgrade our deps and project to Node v6.

I've been running MEANJS on Node v6.6 for over 6 months, and haven't encountered any issues. In fact, most (if not all) npm issues have disappeared relating to Node 4 and previous versions.
Additionally, I've been running a MEANJS project on Node 7 for a short time. I haven't touched the project in a few weeks, but I don't recall any issues.

It further strengthen my decision to move to 6.9 and above.

Done!


[Testing] QA validate embedded etcd

master currently has embedded etcd functionality (replacing dqlite). This needs QA testing before our v1.19.0 release, which is when we currently plan to pull in from master (thus have embedded etcd support).
It's important that we also test upgrades. Older k3s versions come with dqlite - we should start with a 3-node cluster running dqlite and upgrade to v1.19.0. This won't work -- but we need to understand and document why and how it does not work so this can be called out in v1.19.0 release notes.

PR: https://github.com/rancher/k3s/pull/1770

Validated using k3s version v1.19.1+k3s-a08e998b.(master build)
Create first node using
sudo curl -sfL https://get.k3s.io | INSTALL_K3S_COMMIT=a08e998bc5dd93ba3696cb6f08ffc363e6a753d8  INSTALL_K3S_EXEC="--cluster-init" sh -

Join subsequent nodes using
sudo curl -sfL https://get.k3s.io | INSTALL_K3S_COMMIT=a08e998bc5dd93ba3696cb6f08ffc363e6a753d8  sh -s - server --server https://MASTERIP:6443 --token TOKEN

Verified cluster-reset flag taking down two nodes in a 3 node cluster, leading to quorum loss
Steps:
1. Create 3 node cluster
2. Deploy some workloads
3. Shutdown two nodes
4. Update k3s unit file to include --cluster-reset flag
5. Reboot the node
6. Remove cluster-reset from the unit flag (See this msg in logs)
7. Restart k3s
8. Cluster becomes available.

To find the leader and etcd status

Install etcdctl using
``
apt install etcd-client
sudo ETCDCTL_API=3 etcdctl --cacert=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key --endpoints https://<IP_ADDRESS>:2379,https://<IP_ADDRESS>:2379,https://<IP_ADDRESS>:2379 endpoint status  -w table


merge from template-node-app

package.json

chore(deps): add ^8.0.1 remove ^8.0.0 (devDependencies.c8)

:tada: This PR is included in version 6.4.5 :tada:
The release is available on:

npm package (@latest dist-tag)
v6.4.5
GitHub release

Your semantic-release bot :package::rocket:


Terrain system gives different results depending the order you place the tiles.

Godot version
4.0 rc5
System information
Ubuntu 22.04, Vulkan renderer, gforce 1650ti
Issue description
Im making use of the terrain system for a side-scroller. I set the terrain and when i start painting, i find that the results are not always the same depending in the order i paint the tiles (and many of the results should not be valid).
Im ussing "match corners and sides". This video shows the issue:
https://user-images.githubusercontent.com/46932830/221331754-11542a33-375d-40ca-8e34-3def33020043.mp4
Steps to reproduce
1- Set up the terrain system.
2- Paint 2x2 squares in different order.
Minimal reproduction project
TilemapTest.zip

Just a tip, you can fix any mistakes with pencil after

I can confirm this on 4.0.rc adbabfbaa (Linux).

I think I kind of know what is happening.
When you draw a set of tiles like that, it's a bit like if you drew the tiles one by one. The problem arises when the first tile is added on the map, as there's no tile (in your tileset) set up to have the center bit set but nothing around it, it randomly selects a tile that fits the situation the most. Then, when drawing the remaining of the square, it tries to keep what is already in place, as much as possible (as other users complained the algorithm was doing that).
The only solution I can think of is executing the drawing at the end of the drag (like the rectangle tool does), instead of doing it at every frame. That means that you'll have to release the mouse to see the drawn area then, otherwise I fear it would destroy performances.

The problem arises when the first tile is added on the map, as there's no tile (in your tileset) set up to have the center bit set but nothing around it, it randomly selects a tile that fits the situation the most.

Im not sure thats the issue, because i indeded have a tile that has only the center bit. If you look at the video, it first selects a single tile platform, and when i paint the one below, it converts it to a column right away (without needing to release) correctly. The problem is when i paint the one on the side.
Also note that if i do the opperation in another order, it does update the tiles correctly, which also leds me to think the problem is other. This seems to be consistent btw.

I also have this issue, but I consider it minor/non-urgent since you can correct the odd mistake with pencil tool.
Remember the Terrain tool just functions as a brush like the pencil. It doesn't add persistent logic onto your tile grid.

I also have this issue, but I consider it minor/non-urgent since you can correct the odd mistake with pencil tool.
Remember the Terrain tool just functions as a brush like the pencil. It doesn't add persistent logic onto your tile grid.

I understand for your use case it may be not important. But if you are adding/changing tiles by code, you cannot really fix them with the pencil.
Also, if you are doing a lot of big levels, it can soon start to be annoying to need to fix invalid combinations every time.

That's true I hadn't thought of using the Terrain brush programatically/procedurally. In that case it would need to be 100%

Then, when drawing the remaining of the square, it tries to keep what is already in place..

Another observation that may help to find the solution: I don't think the problem is trying to keep what is already in place, because as you can see, it is actually changing the tile in the last step. Only it is changing it for one that should not be valid. The last tile has a bit in the top-side, and there is nothing in the top. It shouldn't pick that tile, but one that has no bit in the top (only center, bot, right, and bot-right corner)

I found something else, having in mind what @groud said.
As i didn't have a tile that has only center and bot bits, when doing a 2 tiles column, it picked one that had also top bit (best option). Then when updating the tiles, it tried to choose a tile that had that top bit also, even if it would be better in this case to chose another tile when completing the 4 tiles square.
If i set a tile to have only bot and center, when doing the 2 tiles it choose that one, and then updates correctly to one that does not have top bit.
I still think it should update it to something valid given there is something valid to choose, because you not always have complete tilesets. But i guess is less dramatic now, as it not as unpredictable as i thought.

I understand the point of changing a minimum number of tiles. But the autotile system should be systematic non-causal to support a consistent UI and programatic control.

I just tested this MRP to attempt to reproduce the issue, and found that the tile at atlas coords (6,1) had the top side bit set to "walls". By erasing that bit (setting it to empty), the tileset seems to paint as expected in 4.0.3. The overall point that the terrain system sometimes fails to find correct matches is valid (I've been able to reproduce #64300 and #70218, for example), but it seems to be choosing tiles correctly here.

Edited: I just re-read the prior comments and I'm unclear if this had already been caught. I apologize if this unnecessarily brought up an old post. I was just trying to prevent someone else from trying to troubleshoot it.

Yes, exactly, that's what i tried to explain in my last post. The tile at coords (6,1) should never be used in that 4 tiles arrangement. But if i dont have a tile that has only bot and center, it doesnt work properly, even if it has the 4 correct tiles to pick.
And i not always use a tilesets with all the possible combinations. It should imho always pick tiles that matches correctly.
You can test by removing completely the tile at (6,1) and see how it still fails.

You can test by removing completely the tile at (6,1) and see how it still fails.

Ah thank you for clarifying! Here's a gif with Godot 4.0.3 vs a plugin when that tile is removed.

Is the plugin's behavior the expected one here? (The last 3 results are identical as it doesn't update-as-you-go when drawing.) I am planning on turning the plugin into a feature proposal for updating the terrain algorithm if it is working well enough, so I've been testing it on various open issues.

Is the plugin's behavior the expected one here? (The last 3 results are identical as it doesn't update-as-you-go when drawing.) I am planning on turning the plugin into a feature proposal for updating the terrain algorithm if it is working well enough, so I've been testing it on various open issues.

Yes! The plugin is working as expected it seems.

It's interesting you mention that because the real-time updates are (one of) the causes of this problem. As you can see, it chooses all the right tiles if you paint with the rectangle.
Here is a video using Terrain Debugger of what's happening at the very beginning, that's the root of the problem. It starts out choosing a different tile but it calls many updates when dragging to the second cell (the screenshot below shows this -- every printed "tile is painted" meant that a full update occurred), and one of them causes the cell to change to an incorrect one. Then when the bottom tile is painted, the top tile is stuck in that configuration, since the bits that aren't immediately adjacent to the newly painted tile aren't allowed to be updated. (This is also the reason that painting single tiles in corners mode causes so many failures -- it can't fully update the neighbors).
The updates are happening too quickly, so I don't know what made it switch to the wrong tile in the first place, but it's more than just the frequent updates that are causing this. The reason the plugin succeeds in this case is partly due to having a more deterministic algorithm (though it's impossible to be fully deterministic with a system this complex), and it fully updates all the adjacent cells in Connect mode.
https://github.com/godotengine/godot/assets/68911895/ae4f8427-bcc6-494b-afb8-a39c792299a1

While understsand the complications, I dont think it couldn't be done. Other softwares like tiled, LDTk, which also have complex algorithms, work fine and update as you paint. I know is not of much use comparing to other tools, but anyways I think this should be taken into account, also because in 3.x the autotile worked flawlessly and updated in real time as you paint.
Also, even if this method is not deterministic, a deterministic method like the one provided in 3.x MUST be provided imho. It would be frustrating to generate levels procedurally in runtime if algorighm is not deterministic.
Having said that, in this specific case we have four tiles that match to form a square. It when you place the last tile, it should fix the others to matching ones. I understand it first chose a bad tile because it didnt have anyone matching, but it makes no sense to leave a not matching set of tiles imo.

Yeah, I didn't mean to imply that real-time updates can't be accurate. Just that if the editor hadn't been updating in real-time in draw mode, it would have chosen the correct tiles in this case. The combination of real-time updates and not fully updating surrounding tiles (as well as whatever caused it to switch to the wrong tile above) are what caused this. An algorithm that didn't have the other limitations should be able to handle real time updates. Real-time updates just expose the limitations here.
Also, I do want to argue the point that it's ok for it to have chosen a bad tile. In this entire example, the algorithm has always had options with fully matching peering bits, so there's no reason it should have ever chosen non-matching tiles, even temporarily.

In my experiments, I also had strange terrain placement results. Terrain, instead of a completely suitable tile, chooses a completely unsuitable tile, which changes the surrounding tiles.
https://github.com/godotengine/godot/assets/10379487/f23c7b1d-71c6-4d90-a3c8-989346700725
The incorrect tiles displayed in the 'Terrains Panel' are due to alternate tiles (bug  #70825). In my understanding, everything is set up correctly.

TileMapTerrains_Test.zip


Clicking developer doc is taking to iGrant.io dev docs

In this case, a default developer doc shall be created.
@georgepadayatti Could it be a GitHub page or a published version of the developer doc pdf, to begin with? (We of course, do not want to make it complicated with docusaurus for this for now; keep it simple)

Link to pdf makes sense.
On Sat, 4 Nov 2023 at 10:11 PM, Lal Chandran @.***>
wrote:

Assigned #188
https://github.com/decentralised-dataexchange/bb-consent-admin-dashboard/issues/188
to @georgepadayatti https://github.com/georgepadayatti.
—
Reply to this email directly, view it on GitHub
https://github.com/decentralised-dataexchange/bb-consent-admin-dashboard/issues/188#event-10863192980,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD5DNCG6LWQUVKNL2BVP2RLYCZV3BAVCNFSM6AAAAAA65V7EG2VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJQHA3DGMJZGI4TQMA
.
You are receiving this because you were assigned.Message ID:
<decentralised-dataexchange/bb-consent-admin-dashboard/issue/188/issue_event/10863192980
@github.com>

Or I can convert it to a .me file that can he linked.

Or I can convert it to a .me file that can he linked.

Yes. A link towards bb-consent-docs wiki.

https://github.com/decentralised-dataexchange/bb-consent-docs/wiki/developer-documentation


contributing and design links in README.md are broken

Exactly what it says. Links just give 404

they are fixed here: https://github.com/openstack-k8s-operators/dataplane-operator/pull/648


show function params in completion detail

This resolves #7842 by updating the detail for function completions from -> T to fn(T, U) -> V. I added an expicit unit test for this, ide_completion::render::fn_detail_includes_args_and_return_type, which passes.
Lots of other unit tests fail (~60 of them) due to this change, although I believe the failures are purely cosmetic (they were testing the exact format of this output). I'm happy to go update those tests, but before I do that I'd like to make sure this is in fact the format we want for the detail?
edit - I realized UPDATE_EXPECT=1 cargo test automatically updates expect! tests. Big :+1: to whoever worked on that! So I'll go ahead and update all these tests soon. But I still would like to confirm fn(T, U) -> V is the desired content in the detail field.

I think we can hide () return types, but I don't know what the detail is supposed to show. It seems reasonable for now.

I believe this will miss out generic parameters? Although I'm not sure what the best way to display them is, especially for functions with complex where clauses.

I've updated this to omit the unit return types, as suggested by @lnicola. It also handles methods more correctly (printing self rather than the type).
I also updated the test case to demonstrate generics in both the parameters and the return types. This currently does not list the generics.
// current
fn(T) -> T

// actual
fn<T>(T) -> T

I haven't looked too closely at how this might need to be done. But I think it would need to consider not just whether a given parameter was generic, but also whether the function itself was generic over that parameter or instead if the impl block was generic.
Its also starting to feel a bit odd to me that all this specialized code for printing a function signature exists in the completion module. Is there a chance any of this code already exists somewhere else?

We may want to consider fixing #7565 as a followup.

Its also starting to feel a bit odd to me that all this specialized code for printing a function signature exists in the completion module. Is there a chance any of this code already exists somewhere else?

So I spent some time trying to answer this question. In short I think the answer is yes, but it led me to some follow up questions. Not sure if zulip is the preferred place for questions like this, but for now I'll leave them here.
The ide::display module exists, which says it "contains utilities for turning SyntaxNodes and HIR types into types that may be used to render in a UI". This module re-exports a function called function_declaration(&ast::Fn) -> String from the syntax::display module, which does something similar to the code I wrote in the detail method in this PR.
The code in this PR is in the ide_completion crate, so it wouldn't be able to use the function as re-exported from ide::display, but it could directly call the underlying syntax::display::function_declaration. But the completion code has a hir::Function not an ast::Fn. I believe hir::HasSource would allow us to convert from the hir representation to the ast representation, but based on the HasSource trait, this transformation might not always be possible (it returns Option<ast::Fn>).

Under what circumstances would hir::HasSource return None when looking up an hir::Function? Is this when the function was generated by a macro?
Given the transformation from hir to ast can "fail" (or return none), it seems we would want some specific code to stringify the hir representation directly rather than trying to convert to ast first? I'm not sure if it is possible to avoid duplicating a bunch of logic here, but maybe that is ok-ish?
It seems the most appropriate place for this display code hir -> String would be ide::display, but that wouldn't allow use by the ide_completion crate. Maybe there should be an ide_display crate? The ide crate could then re-export things from ide_display, but also ide_completion could use ide_display.

Let me know if I've gone off track here. I know this doesn't address the most recent comments by @matklad, I just wanted to try to answer for myself the more fundamental question of am I even putting this code in the "right" place (and am I rewriting something which already exists).

On the meta-note, I wouldn't proactively worry about the duplication -- it's better to start with duplication and refactor it away, then to start with an abstraction (compression oriented programming).
Regarding hir vs ast, that's a tricky design question. ast is the literal text of the function. hir is the compiler's semantic model of the function. The best way to understand the difference between the two is imaginning working with library which is available only in an .rlib form. We'll have hir for this library, but no ast. We don't support rlibs right now, but that's a long-term goal. So, all functionality should be implemented on top of hir, with optional fallbacks to the AST.
At some point, we'd want to maybe move ide_display to ide_db crate, but I am 89% sure that the needs of completion are different, and it's better re-implementing the thing. For example, the hard constraint for completion is that you can use only a single line (so you can't draw a where clause). At the same time, completion can show ... and otherwise elide non-significant parts.

At some point, we'd want to maybe move ide_display to ide_db crate, but I am 89% sure that the needs of completion are different, and it's better re-implementing the thing.

I'm guessing for this reason we don't want to re-implement this PR on top of #8000. So perhaps this is good to go?

Feels like it!
bors r+

changelog feature show function parameters in completion detail


update() breaks when sequelize configured with raw:true

Affects master, v1.4.3, etc.
A call to update() results in a Model.findById call:
https://github.com/feathersjs/feathers-sequelize/blob/master/src/index.js#L168
If sequelize is configured with raw: false (the default), this returns a DAO, with a toJSON method, which is then called several lines later:
https://github.com/feathersjs/feathers-sequelize/blob/master/src/index.js#L174
However, if sequelize is configured with raw: true, the findById call returns a JSON object without this method.
There are two simple fixes:

Only call toJSON if it exists and is a function
pass {raw: false} as a second argument to the findById call to force the expected behaviour

Makes sense. This can probably easily be fixed by changing the line you pointed out to
Object.keys(typeof instance.toJSON === 'function' ? instance.toJSON() : instance).forEach(key => {

Thanks to @lowip this has been fixed in #100 and released as v1.4.4

Unfortunately my PR might have been too fast
In order to update, the DOA instance is used:
https://github.com/feathersjs/feathers-sequelize/blob/master/src/index.js#L182
return instance.update(copy, options);

The best solution I see would be replacing:
https://github.com/feathersjs/feathers-sequelize/blob/master/src/index.js#L168
return this.Model.findById(id).then(instance => {

with
return this.Model.findById(id, { raw: false }).then(instance => {

Ah, I see. Well at least we know it didn't break anything else ;)
I think we should do what patch does and use this.Model.update(omit(data, this.id), options) instead of calling save on the model instance.

I updated the PR #101, would love some feedback on the issue I'm raising here:
https://github.com/feathersjs/feathers-sequelize/pull/101/commits/b6a4128a2e9120aaa3cef755621a498cdc84833b
Thanks!

Now it's been fixed via #101 in v1.4.5


Uncaught Exception: Command failed:<PHONE_NUMBER>

An uncaught exception was reported.
Info:
OS: win32
Arch: ia32
GPMDP Version: 3.0.0
Time: Mon Feb 25 2019 11:13:26 GMT 0200 (South Africa Standard Time)
Error:
Command failed:<PHONE_NUMBER>
Error: Command failed:<PHONE_NUMBER>
System.AggregateException: One or more errors occurred. ---> System.Net.WebException: The remote server returned an error: (500) Internal Server Error.
   at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
   at System.Net.WebClient.GetWebResponse(WebRequest request, IAsyncResult result)
   at System.Net.WebClient.DownloadBitsResponseCallback(IAsyncResult result)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Squirrel.Utility.<LogIfThrows>d__4d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Squirrel.FileDownloader.<DownloadFile>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwait
...Some of the stack is missing

This issue was created automatically inside the uncaughtException handler

Closing this automatically reported issue as a duplicate of #2799


Wallpaper zoomed when applied using inbuilt apply

Hi there,
How do I make the update to the candybar-sample-master. I'm using it for my icons and don't have see the WallpaperActivity or the Wallpaper Helper java. I am very new to Android Development so any help would be great.

Read the Wiki Site, How to Update.


Wrong link opened in case of changing port

Describe the bug
In my situation port 8080 was bonded by another process and label-studio gracefully took port 8081 during the start command. And in the text description label-studio correctly shown http://localhost:8081, but opened page was http://localhost:8080.
To Reproduce
Steps to reproduce the behavior:

Run any other server on 8080 port
Start label-studio
Check opened page

Thank you for the report, we will fix it in release 0.7.3

I fixed this problem in this PR: https://github.com/heartexlabs/label-studio/pull/320
it will be great If you test :slightly_smiling_face:


Feat: The typography feels very heavy

Describe the feature
The typography feels very heavy when we open the website and also there's not enough gaps which makes it look conjusted.
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Please assign this to me under gssoc24


Option to set which BIG format to use for packing

Currently you can only change BIG format to use for packing only at compile time.
https://github.com/Phrohdoh/easage/blob/master/src/bin/easage_pack.rs#L35
A runtime easage pack option to pick the BIG kind to pack into would be more user friendly.

I agree entirely. Would you be interested in taking this on?

It sounds simple enough, I'll look into it after #10 is resolved.

https://github.com/Phrohdoh/easage/commit/16997aba06e2e004de3ded758e4542d670821b3f closes this

16997aba06e2e004de3ded758e4542d670821b3f added a kind flag to the easage pack command.
--kind <kind>        BIG archive kind (BIGF or BIG4, case-sensitive)

Example usage:
easage pack --source WindowSource/ --output window-easage-new.big --kind BIGF


Consider using semantic versioning

sharp breaks my (re)deploy sometimes, because it doesn't mark breaking changes as 'major'.
One could argue that I need to change my package.json and lock versions. On the other hand, the default for npm install package --save is semantic versioning where minor and patch releases are installed automatically, and the major version is locked by default, AKA ^x.y.z.
Today (applause for the app running over six months) it was https://github.com/lovell/sharp/issues/1392. This is a breaking change.
Please consider using the first digit in the version number, and increase it when a breaking change is made.
I know in my specific case that would mean you'd be at 3.x.x now, and I know some people do not feel comfortable using version numbers above or equal to 1.0.0 as it implies commercial-grade stability, but it's okay.
Just do it:
Changelog
1.0.0

New: Started using semantic versioning. (#1754)

Bam! :fireworks:

PS - I like this new version. :+1:

Hello, did you see https://github.com/lovell/sharp/issues/1448#issuecomment-436599693 ? The tl;dr is that sharp v0.y.z not only conforms to but exceeds semver.

Hi @lovell I did not see that comment, thank you for pointing it out.

sharp currently places bug fixes and API additions in patch increments and deprecations and breaking changes in minor increments. This means the caret range operator ^ can be used when including sharp as a dependency.

Unless I'm missing something, this is false.
The ^ operator, I believe, which is the npm default, causes breaking changes in minor version bumps. Manually going back in package.json and changing the caret to tilde ~ will work in the interim, but I don't think it's desirable to give one dependency special treatment and remember to switch back at some point.
I'm missing something. The documentation says:

Caret Ranges ^1.2.3 ^0.2.5 ^0.0.4
(...) this allows patch and minor updates for versions 1.0.0 and above, [and] patch updates for versions 0.X >=0.1.0

So theoretically you're correct. However, I am observing across three different node and npm versions that this is not working as intended. This issue is empirical rather than theoretical. At the same time, I don't believe npm would have this issue persist over a long period, so I trust that somehow this is my own fault.
I hope 1.0.0 will be released soon, because it would fix some issues for me.

If anyone comes across this issue, I've done an npm init locally as a test:
{
  "name": "tmp",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "sharp": "^0.21.0"
  }
}

npm install does indeed stay with<EMAIL_ADDRESS>My docker containers install 0.22.0. I think I broke something in the multi stage build process.

https://semver.npmjs.com/ is a useful tool to understanding semver as applied by npm.


I2C: hw/ip/i2c/data/i2c_testplan.hjson

Below are my understandings on test plan.
•	Test names are i2c_testname whereas they have to be i2c_host/target_testname
•	I2c_smoke for target version of test is marked V1 which is still due as DUT was never in target mode.
•	All tests should be renamed with host or target category of tests.
please add your comments as i need to continue to work with I2C DUT in Target mode
This will need changes to i2c_agent and i2c environment.
Kindly add any relevant stake holders.

The entries in the testplan (i2c_testplan.hjson) are called "testpoints". A "testpoint" is what you intend to test. An "implemented" test is what you actually end up writing and running with dvsim (i.e. the entries in i2c_sim_cfg.hjson). The point of the testplan is to capture discrete-enough aspects of the design separately to book-keep everything that is planned to be tested.
The testplan is written in the very early stage, so the implementation details are not clear during that stage. When you actually start implementing the test, you may adequately exercise constrained randomization to hit large portions of the design state space. So an implemented test can address multiple testpoints. The converse is also true - multiple implemented tests may be needed to satisfy a single testpoint. The entry in the testplan and the entry in the *_sim_cfg.hjson need not have a 1:1. Which implemented test(s) satisfies the testpoint is indicated with the tests key in the testpoint entry.
In case of I2C, the testpoint intentionally lists host_smoke and device_smoke separately, but the same implemented test i2c_smoke is mapped to both - which suggests that it caters to both modes. If not, then thank you for raising this issue - it would mean that the i2c_smoke test is incomplete and needs to be updated.
The onus is of course, on the DV engineer to identify and create / enhance ALL of the necessary DV components to achieve the end goal (tb, agents, components, tests, sequences, etc), which is V3 closure on the block.

@sriyerg thanks for the clarification and as you mentioned i shall move forward and still fix any legacy implementations if necessary.


Process Framework Control Plane

Process Framework Control Plane

Process Framework is great, but it would be nice to have a native control panel. In this panel one could have complete visibility and control over all the different steps added to the process. Specific functionalities might include the ability to start/stop/restart a certain step and the ability to trace a certain prompt to analyze all the steps involved in the response for said prompt (logs, token used, etc).

Since Dapr support has been added, having this type of control plane would help a lot in a distributed env. Maybe we could leverage .NET Aspire as a starting point and implement few components to also support a "build your own control plane" scenario?

@tommasodotNET - good idea, we will take a look after we go through the core Process Framework items.


chore(master): release 1.2.18

:robot: I have created a release beep boop
1.2.18 (2023-06-24)
Bug Fixes

deps: update dependency friendsofphp/php-cs-fixer to v3.19.0 (a1e7383)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/wayofdev/php-cs-fixer-config/releases/tag/v1.2.18 :sunflower:


Regexps for filtering messages

Let the player specify in the config file the regexp for
messages that do not interrupt running and another for messages
that appear only in the history window. Perhaps yet another
for messages that trigger a --more-- prompt.

This is now being implemented based not on regexps, but messages classes. The remaining task, an easy one, is to add all the overrides ot hardwired settings to the config file format, just as it's done for message colours.


Copying OP to add path to clipboard

Based on this old RFE of mine: https://forum.derivative.ca/t/rfe-copy-pasting-ops-produce-the-name-or-path-in-text-context/286534
It's actually fairly easily doable.
Can also be dynamic when pasting, so the path resolves to relative or shortcut... But that's some extra effort.

Could also be extra with it, in so that ui.lastChopChannelSelected path matches the copy path, it also pastes the channel


Autocrafting with Pam's Presser improper functionality

Issue description: Autocrafting w/ Pam's Presser improper functionality
https://prnt.sc/h1223v
What happens: Using a Crafter, and pattern made from the Pattern Encoder, to pump items into the Pam's Presser, along with an Importer to pull completed items from the Presser. The initial craft works fine (ie: soy bean placed, presser takes a few moments to create silken tofu and grain bait as output). However, while the presser is churning, any inputs (soy bean in this case) over that first one are immediately pulled out by the importer again instead of leaving them there to be processed by the presser. So, if I auto craft a full stack of Silken Tofu, the Crafter drops 64 soy bean into the presser, but while soy bean #1 is being pressed you can watch the stack of beans dropping in count, and when the presser finishes the first bean it starts on #2 but by this time the import has sucked around 20 or so back into the system... the end result is from a stack of soy beans, only 4 get processed into Silken Tofu (and grain bait)
What you expected to happen: It should drop the necessary number of beans into the presser and only pull out the processed Silken Tofu (and grain bait), not the soy beans.
Steps to reproduce:

Place a Crafter and Presser into an RS system (importer on the bottom of the Presser set to Items)
Create a Pattern for Silken Tofu from the Pattern Encoder and place into the Crafter
From a Crafting Grid, request more than one Silken Tofu (10, 20, a stack, etc.)
...

Version (make sure you are on the latest version before reporting):

Minecraft: 1.10.2
Forge: forge-<IP_ADDRESS>8
Refined Storage: 1.2.26

Does this issue occur on a server? No
If a (crash)log is relevant for this issue, link it here:
[pastebin/gist/etc link here]

1.10.2 is unsupported


Feature request: word navigation

Hi,
Thanks for this great plugin! I was thinking having a word navigation feature similar to vim would be very useful! For example:

w: Move cursor to the beginning of the next word
e: Move cursor to the end of the current word
b: Move cursor to the beginning of the previous word

Thanks!

Because Logseq do now have cursor for now, so It's impossible to do this from a plugin level. So we can just wait together about this feature from Logseq team.

Okay. Thanks for letting me know. Hopefully they will give the possibility soon :)

Hi, if you have to be less demanding, try this：
https://github.com/j-wyatt-a/vim-wyatt-logseq-plugin

Hi, if you have to be less demanding, try this： https://github.com/j-wyatt-a/vim-wyatt-logseq-plugin

Wow, it's amazing what can be done with some programming knowledge. Thanks for advancing how we can use Vim in Logseq


accept retracted XtStatus

Retracted tx status means that it had been included in a block which happens to be orphaned on a non-finalized fork.
We saw this happening more frequently recently and actually its not a problem in the usual flow because finality will still happen eventually as the nodes inject retracted into tx pool again automatically.
I'd suggest to accept retracted as a non-error
It may still be worth a warning in the logs

example commits (no PR because based on old release):
https://github.com/brenzi/substrate-api-client/commit/480823e6a82236c4d6eb3a488a56f4bce2c4be2c
https://github.com/brenzi/substrate-api-client/commit/d01bc07fe0c8a8db1451d0d5c8bf82493b274d80

@brenzi I will have a look at it.
Just to clarify: The two commits from your comment would basically implement this? Or am I missing somthing?

Yes they would. Happy to submit a PR, but I first wanted to raise the discussion to see if you agree and would merge rhis

That sounds better than my hack commits

Ok, I will try to come up with a PR. Still need to do some thinking on how to do this. This change could lead to some very subtle breaks of backward compatibility for clients.

When we change to is_final instead of the current expected one, we shouldn't forget about the future status. So it probably makes sense to do https://github.com/scs/substrate-api-client/issues/295 in the same swoop.


gapi.auth2.authorize auto refresh revoked access token.

As described, I am trying to use gapi.auth2.authorize instead of the recommended signIn flow. Everything is fine with gapi.auth2.authorize until a user revokes the token / disconnects the app and tries to login again. Then gapi.auth2.authorize will return a new code but the old, revoked, access token. It seems like for every gapi.auth2.authorize the access token stays same until access token expires.
It will be best if the api will auto refresh the access token or return a different access token for every single call.
Don't know if it is the expected behavior, if so I would love to get some suggestion to solve the issue I currently have.

@p0kjin57 does it happen within the same window or in another session? In other words, do you reproduce the issue doing so:

Go to app, grants the app access to the scopes requests for the user using gapi.auth2.authorize
In the same (or another) window, go to myaccount.google.com, disconnect the app.
In the same window than 1., go to the app, call gapi.auth2.authorize

Or in 3., you use a different window? The library performs some caching for better performance so it might be the reason.

@TMSCH 3. Same window. I think caching might be the reason. I can tell it since the expires_in, expires_at, and first_issued_at stays the same.

@p0kjin57 It's a limited edge case that we are aware of. In practice, the conditions to reach such state for a user in a normal usage of an app is very rare. To fix this issue, it would require a call to the backend to detect such state, which would render the cache useless. We think the benefits in performance for most users are higher than the drawbacks of such behavior for very limited scenarios.


WSL2 Register Command

Is your feature request related to a problem? Please describe.
#4591 I recently refreshed Windows install after a hardware upgrade so my WSL distros were deleted from the registry but I still had the .vhdx files. I also exported my distro with the plan of importing it when I re-installed windows. When I tried to import with WSL2 as the default type I get  https://github.com/microsoft/WSL/issues/4530

after quite a few minutes has elapsed. I had to import as WSL1 and then convert to WSL2 after the import. It took ~2.5 hours for a 50gb image on a fast workstation. Even if the import worked directly with WSL2 the process is still very long.
Describe the solution you'd like
It would be nice if you could just run something like WSL --register with the same options as --import (except it looks for a vhdx and not an archive) and have it properly register the distro image in the registry and do anything else that needs to be done. This would allow just backing up the vhdx directly without the need to use import and export.
Describe alternatives you've considered
Right now import/export is terribly slow and maybe broken on WSL2 so I don't think it's a good alternative.

I like this idea, let me play with it a bit.

It might also be cool if you could specify a UID to set the default user when doing this.

@synergies
Thanks for that... got my wsl back this way
Third time i lost my wsl due to a windows update (i guess)

In my case, the BasePath

Thanks @rwilliams for the registry file! For anyone that runs into this issue, below is the registry file I used to "import" the existing ext4.vhdx to show up properly as a WSL distro:
Windows Registry Editor Version 5.00

[HKEY_USERS\[SID]\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\{[UUID]}]
"State"=dword:00000001
"DistributionName"="[DISTRO_NAME]"
"Version"=dword:00000002
"BasePath"="\\\\?\\[VHDX_PATH]"
"Flags"=dword:0000000f
"DefaultUid"=dword:000003e8

Below are the items you need to update in the registry script above:

[SID]: Open command prompt and run whoami /user to get your SID
[UUID]: Go to this generator create a UUID
[DISTRO_NAME]: Name of distro you want, for example: Ubuntu
[VHDX_PATH]: Path of the distro with escaping slashes, for example: D:\\WSL\\Ubuntu

Hopefully this will help anyone stuck in a similar situation as myself. Good luck!

In my case, I just have to write the path without scaping... \\?\C:\WSL\ubuntu

I've just done the same, had to to reset my PC because of DCOM errors. WSL was wiped however I still have the ext4.vhdx file in Windows.old. How do I use wsl --import to get back to where I was?

@Robula You can re-register the ext4.vhdx using the following https://github.com/microsoft/WSL/issues/4762#issuecomment-578545574 though this method is not officially supported. I don't believe there is a way to use the wsl --import  if you don't have a exported backup.

I've found this solution https://www.reddit.com/r/bashonubuntuonwindows/comments/gdiubo/wsl2_import_existing_ext4_image/
It says "Solved this by installing a new Ubuntu instance, removing its EXT4 image, and replacing with the EXT4 image from my old install." and it really worked for me rather than the script mentioned above.

I struggle with this example. How exactly do you open the ext4.vdhx to then move the files over to the localstate. I am unable to find the new installations ext4.vdhx anywhere

@Jirubizu I can't speak to the steps on the reddit link. However, the process I commented above worked for me. Did that not work for you?

In my case, I just have to write the path without escaping... \\?\C:\WSL\ubuntu.
If I escape them I got an error of incorrect path or the one referenced here #4860
I check other distro installations in the same registry folder, and in the other, there was no escaping

The escaping part is confusing because in the .reg file the BasePath must be escaped, but when you check the results in regedit you'll see that value with no escaping.

In case anyone else finds this page and has the same question as @Jirubizu... the "hard drives" for WSL distros will be a .vdhx if WSL version 2, but will be a regular directory of files if WSL version 1. So I'd posit that whoever said "Solved this by installing a new Ubuntu instance, removing its EXT4 image, ..." probably has their WSL set to version 2 by default. But on a freshly-installed Windows 10 (as of May 2022), the default is still version 1.
So, do one of the following:

Run wsl --set-default-version 2 before creating the new WSL distro. Then any new distros will start in .vdhx format.
Run wsl --set-version Ubuntu 2 to convert an existing "Ubuntu" distro to .vdhx format.

For newer come to here like me reinstall window 10 but keep files and you still have ext4.vhdx then you can go to register and make smt like this

You can follow synergies answer above https://github.com/microsoft/WSL/issues/4762#issuecomment-578545574
But the Base Path is not that hard

Thanks @rwilliams for the registry file! For anyone that runs into this issue, below is the registry file I used to "import" the existing ext4.vhdx to show up properly as a WSL distro:
Windows Registry Editor Version 5.00

[HKEY_USERS\[SID]\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\{[UUID]}]
"State"=dword:00000001
"DistributionName"="[DISTRO_NAME]"
"Version"=dword:00000002
"BasePath"="\\\\?\\[VHDX_PATH]"
"Flags"=dword:0000000f
"DefaultUid"=dword:000003e8

Below are the items you need to update in the registry script above:
* **[SID]:** Open command prompt and run `whoami /user` to get your SID

* **[UUID]:** Go to [this generator](https://www.uuidgenerator.net/) create a UUID

* **[DISTRO_NAME]:** Name of distro you want, for example: `Ubuntu`

* **[VHDX_PATH]:** Path of the distro with escaping slashes, for example: `D:\\WSL\\Ubuntu`

Hopefully this will help anyone stuck in a similar situation as myself. Good luck!

Thanks for this, kind of solved my issue.
As this restoration method seems to have different variations, I'll add mine for future readers.

I had to use the escape back slashes. Did not work without.
The DefaultEnvironment "Multi-String" is missing. Mine looks like this:

HOSTTYPE=x86_64
LANG=en_US.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
TERM=xterm-256color

The \\?\ prefix in the BasePath might be needed or not. I have distributions that feature this and others that don't. If your distribution is not found, remove that prefix and check again.
At first, I did not realise that BasePath is actually the path to the directory, where the ext4.vhdx is supposed to be. If the path to the ext4.vhdx is provided, the installation won't be found, either.

After rebuild windows, I found the ext4.vhdx of the old system but could not mount it normally. The disk manager prompted me to format it. I used the 7zip program to check the dir and saw two img.

Thanks @rwilliams for the registry file! For anyone that runs into this issue, below is the registry file I used to "import" the existing ext4.vhdx to show up properly as a WSL distro:
Windows Registry Editor Version 5.00

[HKEY_USERS\[SID]\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\{[UUID]}]
"State"=dword:00000001
"DistributionName"="[DISTRO_NAME]"
"Version"=dword:00000002
"BasePath"="\\\\?\\[VHDX_PATH]"
"Flags"=dword:0000000f
"DefaultUid"=dword:000003e8

Below are the items you need to update in the registry script above:

[SID]: Open command prompt and run whoami /user to get your SID
[UUID]: Go to this generator create a UUID
[DISTRO_NAME]: Name of distro you want, for example: Ubuntu
[VHDX_PATH]: Path of the distro with escaping slashes, for example: D:\\WSL\\Ubuntu

Hopefully this will help anyone stuck in a similar situation as myself. Good luck!

I have error "Deny ACCESS", Any Solution for it?

working with ubuntu 20.04.6  on Win 11 host and I didn't have any issue with everything that has been described here. I just replaced .vhdx backup and everything worked seamlessly. I just used the same distro, same name and password I was using on the previews installation.

Command wsl --import-in-place <Distribution name> <path of vhdx>  can be used now to import the distribution in place

Indeed this is now possible via wsl --import-in-place.
Closing


Detecting and following links in plain-text files should be optional

Current Parser, when it thinks a page has plain-text content, finds things that look like URLs in them and adds them to the queue for retrieval.
There are many situations where this is not desirable - especially since some web servers send text/plain content type for any unknown file format. Also Javascript seems to be detected as plain text, and JS files often have many false matches to the URL pattern.
I'd suggest having a
setIncludePlainTextContentInCrawling(false); .
similar to h
setIncludeBinaryContentInCrawling(false); .

Can you give an example page/site where it's happening?


[serverless-apollo-contentful] Review the current kit and determine what remains to be completed

Background
Once the kit has been deployed we need to review the current contents of the kit and compare it against the new specifications to see what has been completed, and what remains to be completed. The specifications can be found here: https://docs.google.com/document/d/1iEXK6BFgu5HZ4dfU7pfv80zLOAd86T8AzstCMEYTUXA/edit. This review should include Maarten and/or Ihar as part of this review.

[ ] TypeScript needs to be updated
[ ] Readme mentions npm and yarn as tools. These both need to be verified
[ ] pnpm is not mentioned and also needs to be verified
[ ] Convert all non-yaml files to using tabs (instead of spaces)
[ ] Ensure all files have final newlines
[ ] .env file instructions are missing
[ ] CORS need to be verified

Thank you @mbicknese for these. Tickets have been created. Looking forward to your in-depth review and feedback.

Current test coverage (does not reach 100%)
-----------------------|---------|----------|---------|---------|------------------------------
File                   | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
-----------------------|---------|----------|---------|---------|------------------------------
All files              |    42.3 |        0 |   29.62 |   39.66 |
 handlers              |     100 |      100 |     100 |     100 |
  graphql.ts           |     100 |      100 |     100 |     100 |
  healthcheck.ts       |     100 |      100 |     100 |     100 |
 models                |   21.21 |      100 |       0 |   21.21 |
  CommentModel.ts      |   21.21 |      100 |       0 |   21.21 | 5-13,17-23,27-39,43-51,55-62
  PostModel.ts         |   21.21 |      100 |       0 |   21.21 | 5-13,17-23,27-39,43-51,55-62
 schema                |     100 |      100 |     100 |     100 |
  index.ts             |     100 |      100 |     100 |     100 |
 schema/comment        |   44.44 |        0 |   33.33 |      40 |
  comment.resolvers.ts |   16.66 |        0 |       0 |   18.18 | 7-38
  comment.typedefs.ts  |     100 |      100 |     100 |     100 |
  index.ts             |     100 |      100 |     100 |     100 |
 schema/hello          |     100 |      100 |     100 |     100 |
  hello.resolvers.ts   |     100 |      100 |     100 |     100 |
  hello.typedefs.ts    |     100 |      100 |     100 |     100 |
  index.ts             |     100 |      100 |     100 |     100 |
 schema/post           |   44.44 |        0 |   33.33 |      40 |
  index.ts             |     100 |      100 |     100 |     100 |
  post.resolvers.ts    |   16.66 |        0 |       0 |   18.18 | 7-38
  post.typedefs.ts     |     100 |      100 |     100 |     100 |
 utils                 |      50 |      100 |       0 |      50 |
  contentful.ts        |      50 |      100 |       0 |      50 | 8-13
-----------------------|---------|----------|---------|---------|------------------------------

Linting issues need to be fixed. There are currently 30 problems (19 errors, 11 warnings)


Add support for Node.js 0.12.0

Node.js 0.12.0 is released. Will Brackets upgrade to support this version?

I have created a task for this in the backlog. https://trello.com/c/DJwcfxyh
Please upvote it so it can be picked up on priority.

@ghostoy If you or someone else could comment on that card about the benefits of upgrading Node, I think it would be helpful.  Updating is a bunch of work and could be destabilizing, so we'd want to know that Brackets is getting something worthwhile out of it before undertaking that work.
See also #10001, which is about a much shorter-term upgrade to a newer version of 0.10.x...


⚠ Fortnite has degraded performance

In c113ffa, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1547 ms

Resolved: Fortnite performance has improved in 8ba2924.


Terminal: Context-menu does not work in the PS Terminal

Issue Type: Bug
The context-menu does not show when right-clicking in the PowerShell terminal window.
VS Code version: Code 1.52.1 (ea3859d4ba2f3e577a159bc91e3074c5d85c0523, 2020-12-16T16:34:46.910Z)
OS version: Windows_NT x64 10.0.19042

Change the setting terminal.integrated.rightClickBehavior : default

Change the setting terminal.integrated.rightClickBehavior : default


feat: settings profiles

This would be a way to address multiple feature regarding

Custom prompting
Copy/paste workflows
Quick toggle between switching languages

With the new GUI, it seems to work. I just need to choose 'English' as the output language, and it will translate to English even if I speak in Swedish. It would be helpful to have a convenient way to switch between translating the text to English or not. For now, I'm delighted with the update and its numerous quality of life improvements :) Thank you for providing this technology! You're amazing!

Originally posted by @Detet in https://github.com/braden-w/whispering/issues/55#issuecomment-2210698866

@braden-w : would be a fantastic approach!


Trimming

In addition to the work done in #303 we should consider trimming. Our assemblies are already very large, so trimming would be of great use.
See https://devblogs.microsoft.com/dotnet/customizing-trimming-in-net-core-5/

Trimming is more suited for the end consumer (application) instead of libraries, as you don't want to prematurely trim away IL for it to blow up on the downstream consumer.

In the article they mention that libraries can (and should if possible) annotate APIs.
This won't be needed anymore once reflection has been eliminated, but if that doesn't work out, annotating the api is a good idea.

I am not open to any trimming operations being done to Silk.NET itself. However, if we needed to annotate some APIs for the new (experimental) trimmer then this should be done no earlier than 3.0.

Could you explain why you don't want this to be (optionally) done in 2.0?

Primarily because as of 2.0 Silk.NET is still a .NET Standard library, and the new trimmer is .NET 5 only.

I see, so you're not happy to multi-target to net5 just for this?

Not for something like this, as it'll be large-scale and files will get messy with lots of preprocessor directives.

Apparently auto trimming is cool, see this tweet from Tanner https://twitter.com/tannergooding/status/1412124486539702272?s=20

@Perksey Trimming is becoming more of a thing now, not sure your comments aged well. One of those decisions that were perhaps made hastily or without considering trimming to be more mainstream. It's definitely up to the libraries to provide hints, as AOT is more and more a thing. Silk.NET is quite bloaty and trimming would help a lot.

I still stand by all of my comments, it would be a maintenance nightmare for 2.X to annotate everything given the multitargeting. You missed the part where I said we’ll do this in 3.0 and the fact that the issue is still open, so we will do this eventually. But thank you for your opinion.

One minor change for 2.x that we can do here for sure is annotating Silk.NET.Maths to be trimmable. I just keep forgetting to do this. PRs welcome as always. Would also impact binary size quite a bit already I think.

I still stand by all of my comments, it would be a maintenance nightmare for 2.X to annotate everything given the multitargeting. You missed the part where I said we’ll do this in 3.0 and the fact that the issue is still open, so we will do this eventually. But thank you for your opinion.

You're right, I don't see it mentioned previously for 3.0, but now you have affirmed it, that's cool.
Issues on many other projects stay open for years sometimes, and sometimes for no reason (sometimes forgetting), one cannot deduce something will be implemented by an issue remaining open :)
But either way that's good, you guys got this. I'll use this library for my project knowing this feature will come, thank you ahead of time.

So incidentally we had to turn on trimming for another optimization being made elsewhere in the library (we need to tell the trimmer to get rid of some full-AOT paths in non-full-AOT scenarios) and, at least for TriangleNET6, I didn't see any trimmer warnings? I'd assume that most of our warnings would come from Windowing and Input, which is covered by that project, so I guess we're good to go.
#1645 implements this


Error while running validation application on React.js

When running the validation application on React.js which i got from https://github.com/iTwin/Course-Property-Validation-API.
the URL : https://api.bentley.com/imodel/rpc//mode/1/context/b997c9fe-eb6d-4fdb-907b-3313e7591dde/imodel/5e8e0bca-ac64-47bb-b93a-3933e30339b6/changeset/0/IModelReadRpcInterface-3.1.0-getConnectionProps
response: {"error":"client spa-aV2KgrBuko9PIBZWS1u4m5frm is not allowed to use visualization version v3"}

This course and the guide (the repo) is using iTwin.js 3.x which has just recently reached end of life. The code needs to be updated to use the latest 4.x version, which shouldn't be a huge effort. You can see the migration guide https://github.com/iTwin/itwinjs-core/discussions/5606 if you want to try it locally. We will look to getting the repo updated in the meanwhile


-webkit-overflow-scrolling:touch with dropdowns produces flashes and hidings in other elements

I have been struggling for some days with dropdowns in ios (ipad) because whenever I clicked a dropdown many other elements (labels, buttons, dropdowns and even other elements) started to flash and many times they remain hidden after some flashing.
Because my code was big, I have been trying to simplify the code too few lines during days, and at least I have found what is causing the malfunction.
Basically, the problem only appears in ios using dropdowns inside a div with “-webkit-overflow-scrolling:touch” .
You can try the code in: http://www.haiku-media.com/Resources/Tests/Bug/Bug.html

Thanks for the report. This is well defined. I'll try to debug on my iphone.

I have been able to reproduce the problem in an ipad with ios 9.3 and in an iPhone 5 with ios 8.3.
Because the example has only one label and one dropdown, the label does not hide at all, but it flashes.
In my developement forms where I have dozens of fields (labels, dropdowns, inputs, buttons...) after some flashings many elements remain hidden after the flash and the only way to show them again, is to force a full screen repaint with another component, but not always working.
Please, ask for any other information that you may need to help you reproduce the problem.
Thank you.


drop core

 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.:x: Varorbc sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Chest movers results in tile entity being associated with incorrect location

This isn't something I necessarily want to support, but given the wide variety of ways in which tile entities can be moved, it's entirely possible for a situation where a new tile entity is instantiated from a moved one which, for some reason, does not have last position saved.
Potential solution:

Serialize last position when saving tile entities
Modify the incoming tile entities function to refresh and/or update the position & dimension of a tile id if the tile id already exists in the system (instead of just presuming the current entry is valid).

I believe this is fixed but it'll require further testing.

Okay, this is definitely resolved as per using Carry On.


Basic Auth Plugin leads to dispatch of multiple request.

We are using Moya in our App and our Quality-Engineer realized that each request which will be send through Moya using the BasicAuthCredential-Plugin actually results in two requests.
One without Credentials and one with Credentials.
I added Code of an Example that results in this behaviour.
If I add the the authorization header directly through the header property everything works as expected.
I tried to dive deeper into the code but I could not find the place where both requests will be sent.
We are using Moya 10.0.0  and Charles 3.1.2 for request analysis.
import UIKit
import Moya
import CryptoSwift

private typealias EndpointClosure = (Test) -> Endpoint<Test>

enum Test: TargetType {
	var basicAuthCredentials : URLCredential {
		switch self {
		case .test(let username, let password):
			return URLCredential(user: username, password: password.sha1(), persistence: .none)
		}
	}

	var baseURL: URL {
		return URL(string: "http://foo.com")!
	}

	var path: String {
		return "/pathThatNeedsAuth"
	}

	var method: Moya.Method {
		return .get
	}

	var sampleData: Data {
		return Data()
	}

	var task: Task {
		return .requestPlain
	}

	var headers: [String : String]? {
		return nil
	}

	var parameters: [String: Any]? {
		return nil
	}

	var parameterEncoding: ParameterEncoding {
		return URLEncoding.default
	}

	var sampleResponseClosure: () -> EndpointSampleResponse {
		return { return EndpointSampleResponse.networkResponse(200, Data()) }
	}

	case test(username: String, password: String)

}

class ViewController: UIViewController {
	@IBAction func request() {
		let basicAuthPlugin = ViewController.makeBasicAuthPlugin()
		let provider =  MoyaProvider<Test>(endpointClosure: ViewController.makeEndpointClosure(), plugins: [basicAuthPlugin])

		provider.request(.test(username<EMAIL_ADDRESS>password: "estateSmart#2017!")) { response in
			switch response {
			case .success(let value):
				print(value)
			case .failure(let error):
				print(error.localizedDescription)
			}
		}
	}

	private static func makeEndpointClosure() -> EndpointClosure {
		return { (target: Test) -> Endpoint<Test> in

			let target = target
			let method = target.method
			let httpHeader = target.headers
			let url = target.baseURL.appendingPathComponent(target.path).absoluteString

			var targetTask = target.task
			if let parameters = target.parameters {
				targetTask = .requestParameters(parameters: parameters, encoding: target.parameterEncoding)
			}

			let endpoint = Endpoint<Test>(url: url, sampleResponseClosure: target.sampleResponseClosure, method: method, task: targetTask, httpHeaderFields: httpHeader)
			return endpoint
		}
	}

	private static func makeBasicAuthPlugin() -> CredentialsPlugin {
		let basicAuthPlugin = CredentialsPlugin { target -> URLCredential? in
			guard let target = target as? Test else {
				return nil
			}

			return target.basicAuthCredentials
		}
		return basicAuthPlugin
	}
}

We really appreciate your QE's (and your) time to surface this bug, that you guys used Charles to make sure it was a legitimate issue, and then wrote a minimal reproducible example 😄
It sounds like a problem and we'd love to fix it. In my opinion, the easiest way to find the cause and fix the bug is through TDD - we can write a failing test that shows the 2 request behavior, and then mess with the code until the test passes.
We'd be more than happy to accept a PR from you, or if you wait a couple days/longer, a contributor will probably come around and try to fix it

@SebastianBoldt I just noticed this same bug using Moya 11.0.2 and found this auto-closed issue. Did you by chance find a solution or work-around that you'd be willing to share?

@robfeldmann I solved it by not using the basic-auth plugin and adding the auth header properties directly into the header fields inside the endpoint closure.

Could any of you guys create an example project that I could look at? @SebastianBoldt @robfeldmann or maybe someone else with the same problem? Would help a lot.

I am experiencing this issue in the latests version of master with commit bbe5d2c8096105a0906a676b521de48fb82d3704, when using the CredentialsPlugin with basic auth.

Actually it's due to Alamofire I would try to investigate why is it.
But if you execute the following it will have the same behaviour.
Alamofire.request(url, method: .get)
      .authenticate(user: "test", password: "test")

@hamdshah ah this is awesome, thanks for the finding!

@hamdshah 🙌


Expose the "require" function, use in place of assert!() in example.

This might not be exactly the right thing to do; but I noticed one of the examples uses assert!() and that pulls in all the formatting machinery and makes the contract wasm 5kb when it is only 1kb when we use something simpler like require from env-common.
I'm open to other options here, but .. I think we should provide some help for people to avoid the space overhead of assert!()

Closing as this was addressed in #246.


log additional information in exchanges

When we move money between Gittip and the outside world we call that an "exchange" and we record each such event in the exchanges table. Here's its schema:
=> \d exchanges
                                     Table "public.exchanges"
┌─────────────┬──────────────────────────┬────────────────────────────────────────────────────────┐
│   Column    │           Type           │                       Modifiers                        │
├─────────────┼──────────────────────────┼────────────────────────────────────────────────────────┤
│ id          │ integer                  │ not null default nextval('exchanges_id_seq'::regclass) │
│ timestamp   │ timestamp with time zone │ not null default now()                                 │
│ amount      │ numeric(35,2)            │ not null                                               │
│ fee         │ numeric(35,2)            │ not null                                               │
│ participant │ text                     │ not null                                               │
│ recorder    │ text                     │                                                        │
│ note        │ text                     │                                                        │
└─────────────┴──────────────────────────┴────────────────────────────────────────────────────────┘
Indexes:
    "exchanges_pkey" PRIMARY KEY, btree (id)
Foreign-key constraints:
    "exchanges_participant_fkey" FOREIGN KEY (participant) REFERENCES participants(username) ON UPDATE CASCADE ON DELETE RESTRICT
    "exchanges_recorder_fkey" FOREIGN KEY (recorder) REFERENCES participants(username) ON UPDATE CASCADE ON DELETE RESTRICT

The relationship between amount and fee is complicated and should be cleaned up. That's #2442.
The recorder and note fields are used when an admin manually enters an exchange.
What we need here is more information recorded during an exchange in order to aid debugging, e.g. on #2372. Exchanges involve API calls to Balanced (etc.). We should record detailed information about what API call was made and what the result was. We should also record what funding instrument was involved so that whether or not there is a failure we can make our reporting more accurate (#1681).

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/2387872-log-additional-information-in-exchanges?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github).

Added to the Balanced shutdown milestone.

if we're comfortable trusting Balanced as our datastore

:disappointed:

If we want to fix those we'll have to do lots of Balanced API queries to retrieve the information.

I downloaded all transactions in JSON format on https://github.com/gratipay/inside.gratipay.com/issues/308 and uploaded them to https://github.com/gratipay/logs/tree/master/misc/308/raw/balanced/transactions.

We should also record what funding instrument was involved so that whether or not there is a failure we can make our reporting more accurate (#1681).

That's the route column, which we have now and need to use properly in #3839, which is blocked on #2779, which is blocked on #3822.

What we need here is more information recorded during an exchange in order to aid debugging, e.g. on #2372. Exchanges involve API calls to Balanced (etc.). We should record detailed information about what API call was made and what the result was.

This is the new ref column that was added in #3810 and should be cleaned up alongside route.
Closing this as done with ref.