Option to disable strong password policy enforcement

Hello,
I would very much like to have this feature disabled. It does not provide anything in my local network, except discomfort.
I see this issue is closed, but the problem is still there. Will you do something about it?
Originally posted by @djbobyd in https://github.com/portainer/portainer/issues/6846#issuecomment-1121236231

I second this.  In a small home lab deployment this is an annoyance.  The ability to accept the "danger" and disable password complexity should be possible.

Second this as well. This "feature" resulted in me being loged out for good.

Same here... local access only... some ENV parameter or so maybe...

Good to see I'm not the only one that wants to be able to disable this. I'm all for strong passwords when they are relevant but if you REALLY want security, you don't use passwords at all. You use PKI and client certificates.

Why should I pick a password for Portainer that is even stronger than the server-password im using? Makes no sense. Let me choose whatever I need for my system. Im gonna roll back to previous version until fixed.

Hi all, thanks for the feedback on this. I'm discussing options internally with the team here and will let you know what the outcome of those conversations is.

I strongly second this!

Again, it resulted in me not being able to login to Portainer at all. There was definitely no typo in the password used. This is therefore more than an inconvenience.
I changed my password to strong and copy pasted it for changing it. I then used the same password to login and was denied!
I am super happy to have a backup!

Hi all, thanks for the feedback on this. I'm discussing options internally with the team here and will let you know what the outcome of those conversations is.

Again, it resulted in me not being able to login to Portainer at all. There was definitely no typo in the password used. This is therefore more than an inconvenience.
I changed my password to strong and copy pasted it for changing it. I then used the same password to login and was denied!
I am super happy to have had a backup in place, that saved me.

seconded, very much.
Even more so, since the password rules that are enforced only provide a marginally stronger password.
For a "random string generator"-type attack against passwords,<PHONE_NUMBER>1234 is exactly the same difficulty to guess as M1r0sl4v12!!,, so if you really want to increase security, add 2FA and/or ssl client certificates, or at least arbitrary length passphrases with blanks.

Seconded this, make it an option but not rudely enforced.

Fully agree, please make it an option instead of enforcing it, as it's an extreme measure, which is exasperating, at least for me (and probably others too).

I hope this gets removed as well. Very annoying.

Seconded, what a pointless restriction to force on local networks.

IMO it should be freely configurable - max and min length, number of required character classes, max age.

Oh dear... back to a previous version for me - this is unworkable. Sure it's OK by default (although a pain), but not to be able to turn off is unworkable. Thanks.

Reverted to previous version until this becomes optional - password strength is irrelevant when Portainer is simply making access to containers on a Raspberry Pi easier, behind a firewall in a home environment.

Thanks for all your comments and feedback everyone.
It seems we have overdone the password policy in this case!
The driver for this change is that we have observed our users using very weak passwords in some instances, which can be an expensive mistake to make.
In light of the feedback that we've received, we are removing the restriction that is enforcing the mix of lower case, upper case, numeric and special characters; which means that any passphrase that is at least 12 characters long will be accepted in the 2.13.1 patch release.

...not good enough. make it configurable the way it should: let the administrator define what the policy should be.

this is what a password policy on freeipa offers to be configurable:

...not good enough. make it configurable the way it should: let the administrator define what the policy should be.

fully agree, 12 characters for a home environment is still too much

Just plain curuosity, how did you even identify this as a topic, without actually reading our passwords?
But back to this topic, I would rather ask for the option of 2 factor, then to have 12 characters minimum. 'cause I agree if you are really using portainer outside of private use, it better be protected well. Even though I would never expose it directly to the Internet.

@huib-portainer I'd add some option to just disable password checking policy in general. Fancy fine granular policy definitions would be nice, but are optional IMHO...

Just plain curuosity, how did you even identify this as a topic, without actually reading our passwords?

Yep, that I wondered as well...

I'm sure my Raspberry Pi will sleep well at night knowing you're worrying about safety for it too - but insisting on a 12 character password will ensure that I simply save that detail in my browser (as I currently do not), making it shared and therefore weaker. Please provide the option to remove this new password policy, and/or provide us with a mechanism to set strength requirements for ourselves.

Please allow us to configure what security is required for password - sure by default allow 12 chars, but allow us to change it to lower if required... why must this be forced on us all - this sort of policy change hurts your brand and people then may look at  alternatives such as yacht. Although I hear where you are coming from, it is a bit "dictatorship" based... when customisable is the way forward. Thanks

For those asking how it works. It's actually just frontend form validation logic. If what you're submitting doesn't conform with some regex you'll get redirected based on that frontend logic after the backend has logged you in.

My issue was not with enforcing symbols, letters, numbers, etc. But the password having to be so long.
For the CE version of Portainer, there should be no such enforcement.  In fact, you'd do well to make that a part of the BE only as your paying customers are the ones who really care about this sort of thing.

The password policy should be configurable to suit individual needs.
If we really want to take care of security, we should add 2FA and/or auto-blocking after unsuccessful attempts.
Another issue is that such security is required when offering services on the Internet, many such mechanisms and limitations in the internal network are problematic and unnecessary.
Unfortunately, I rolled back the version, and I am waiting for the situation to develop, the worst part is that I was planning to switch to the paid version, but now I have to hold back and wait for the situation to develop.

As Huib mentioned earlier we are planning to release 2.13.1 which will dial back the restrictions to a 12 character minimum without the additional complexity requirements. We consider this a temporary fix.
In 2.14 we plan to introduce functionality that will let you customize your required password strength to meet your needs. As we're still determining exactly how this will work I don't have any detail to share with you as of yet, but we will be taking into account all of the incredibly valuable feedback you've given us in this thread.

Thanks for all your comments and feedback everyone.
It seems we have overdone the password policy in this case! The driver for this change is that we have observed our users using very weak passwords in some instances, which can be an expensive mistake to make.
In light of the feedback that we've received, we are removing the restriction that is enforcing the mix of lower case, upper case, numeric and special characters; which means that any passphrase that is at least 12 characters long will be accepted in the 2.13.1 patch release.

If people are using week passwords on Portainer, then the passwords on the server itself is probably week as well. So what's the point? Portainer is just a frontend.  I dont have my Portainer exposed to everyone on the internet, and I will still be forced to use 12 characters in 2.13.1?
My password is 9 characters with a mix of lower case, upper case, numeric and special characters, and that is on my own internal network(!) - Ill think that will do it juuuust fine.
Why do you guys feed the need to be responsible for what passwords people are using? Not even Ubuntu Server does that.
Let people use week passwords if they want to, and let them choose their own risks. Hopefully people know what they are doing.

Strong passwords don't make any sense!
It will only cause trouble

https://github.com/portainer/portainer/issues/6846
The person who asks this question is simply mentally disabled

Update, uninstall and update again, wasting working time. Forcing users to change their passwords is a powerful thing it does

As Huib mentioned earlier we are planning to release 2.13.1 which will dial back the restrictions to a 12 character minimum without the additional complexity requirements. We consider this a temporary fix.
In 2.14 we plan to introduce functionality that will let you customize your required password strength to meet your needs. As we're still determining exactly how this will work I don't have any detail to share with you as of yet, but we will be taking into account all of the incredibly valuable feedback you've given us in this thread.

I don't think there's any difference between 12 characters and 8 characters. Is it safer to add 4 characters? The user experience is terrible. Users know what they're doing. If users feel unsafe, they can add characters by themselves. You don't need to enforce it

this is what a password policy on freeipa offers to be configurable:
and for anyone who can't read german:

maximum age in days
minimum time between changes in hours
length of the password history (how many different passwords do you have to go through before reuse is ok)
number of different character classes you have to have in a password
minimum length
maximum number of errors before lockout
time until error count resets
time until lockout resets

and what you see there is what i will be using on my internal network once i switch everything to ipa, which basically means as long as the password is 8 characters long, anything goes, with 10 minute logout if you fail more than 6 times.

I just want to use portal to manage docker, but what do you want me to define these junk things for?  Compulsory password length is something that primary school students can do, but you are very active. Container backup has not made any progress since 2018.
https://github.com/portainer/portainer/issues/1850
https://github.com/portainer/portainer/issues/1608

Default to 12 characters is really safer. but must leave an option to allow disabling this policy would be better for many people.

Default to 12 characters is really safer. but must leave an option to allow disabling this policy would be better for many people.

Would 100 be characters? Do you consider user experience? Are you a front-end Engineer? In the back-end, what's the meaning of what you say?

In order to disable the policy, you need to modify the docker command. Will you be happy? Just for a password

If users feel insecure, they will add their own character length. It's a talent to set a policy that enforces password length and then disable it. Portainer has released versions 2.13.0, 2.13.1, 2.13 For a password

I don't think there's any difference between 12 characters and 8 characters. Is it safer to add 4 characters?

There are tools around the internet like this one that allow you to estimate time-to-crack on a password. An 8 character password of all lowercase text would take approximately 5 seconds to crack, and simply adding 4 more lowercase letters to it increases that to 3 weeks.
Regardless, this will be tunable in 2.14.

...and if you're actually serious about cracking a password hash you offload the work to a GPU (or more than one) and you're back in the area of seconds. Even with way longer passwords than measly 12 characters.
2FA, or forget it, if you're so serious about passwords.
That being said: I'm still in favor of having this password security stuff fully configurable - length, classes, age, and so on. That way someone like me, who runs portainer on one internal host, and NOT reachable from the outside, can just turn it off.
That being said, I'd love to see kerberos as an option.

When you make this tunable, please also consider that in many cases it would be fine to enforce a policy for new users, but not on existing accounts.
Otherwise if you upgrade, you suddenly can't use the existing user/passwd anymore and other automation fails that uses the API to upload new images, etc.

When you make this tunable, please also consider that in many cases it would be fine to enforce a policy for new users, but not on existing accounts. Otherwise if you upgrade, you suddenly can't use the existing user/passwd anymore and other automation fails that uses the API to upload new images, etc.

I fully agree with this. Shocked to login to quickly check some stuffs then can't do anything else unless password forcefully changed. Back to the console for me. Please "Make Portainer Great Again"! 🤣

YESSS i didnt even wanted to change my password at all

It is hoped that the next version to remove the limitation of the length of the mandatory password is meaningless to security.
Users who need this aspect can set a very long and complicated password by themselves.
For users who do not need this function, it is a bit disgusting ,,,

is it even an option yet to disable the option

I don't think there's any difference between 12 characters and 8 characters. Is it safer to add 4 characters?

There are tools around the internet like this one that allow you to estimate time-to-crack on a password. An 8 character password of all lowercase text would take approximately 5 seconds to crack, and simply adding 4 more lowercase letters to it increases that to 3 weeks.

In that case, create a Fail2Ban (Or Fail2Timeout) function.

Hi, is there a flag to disable the strong password policy?
https://docs.portainer.io/whats-new#enforcing-strong-passwords

@rogervila have you tried adding --no-strong-password?

Well, this was a bad move. But this would need one line bug fix, so chop chop guys and gals, let's get this fixed.

Don't like the 12 char password enforcement, really adds nothing to security, can we roll this back? If you're needing something more secure for the enterprise version, I'd suggest 2FA, and/or certs.

I didn’t even need a password, because I use 2fa in front of Porta I er already.
In earlier versions, password disable was possible, and now this. It’s a joke

exactly my point - I use KRB5 to log in on my desktop, I'd like to see portainer to be able to just grab that kerberos token and be done with authentication but then that would need a fix for #6928 as well.

Just logged into my server to check the status of my containers only to be greeted with this.
The fact that I can't configure anything until I make my password "secure" makes me irrationally angry. This is a home server; I don't need a super long password.
This needs to be optional.

so true i looked everywhere but it isn't still an option to disable it

well i guess we have to wait for the next update

@rogervila I uninstalled 2.13 and went back to 2.11.1 to avoid the strong password until they fix that.
From the responses above, 2.13.1 will still require strong password and 2.13.3 might be the version that gets rid of the need to use strong passwords.
Until then you can try --no-strong-password - which you won't find in the documentation - but that did not works for me.

Thanks for the version tip. I just updated from 2.9.3 and delighted to see a dark mode, then sad to see I needed a new password to use this... I'll use 2.11.1 until I can find a replacement.

portainer should not be deciding my password parameters for me

portainer should not be deciding my password parameters for me

so true when is it going to be fixed i hate y 12 password

--no-strong-password
Doesn't work for me (with latest portainer release)

I also would like to disable this having portainer-access on private LAN only. Password fine, but password-strength should be admin control not by portainer themselfe.

+1 to have option to disable strong password policy enforcement

we have observed our users using very weak passwords in some instances

@huib-portainer How is this being observed?
If this is observed by publicly internet available portainer instances, there is a bigger issue at hand. Overall, this seems like an arbitrary policy to protect end users that may or may not need protection. For reference, personally I just utilized Portainer for a quick way to manage containers but if I need to type a complex password I might as well use SSH.  I have removed Portainer as its usefulness vs utility has become unbalanced and am entertaining alternatives.

we have observed our users using very weak passwords in some instances, which can be an expensive mistake to make.

@huib-portainer As with others, I'm curious as to how you know this. Surely our passwords aren't being stored in plaintext and being sent to Portainer, are they?
This change bothers me because I have no control over it. This is my server, not Portainer's. I already accept whatever risk comes with a shorter password because my server is not accessible from outside my network. Let me set password parameters; don't set them for me. I used Portainer to manage my Docker containers and clear out unused images, nothing more.
On another note, so far Yacht does everything I needed Portainer for, and it doesn't have any arbitrary password requirements.
I might be moving away from Portainer entirely.

To clarify, no your passwords are not being sent to us.
And the backend is only storing hashes.
It's actually much more simple than that. We have received feedback via email from our users where inadvertently using a trivial password ended up compromising access to container deployment environments.
So as always, Portainer is providing a certain level of security out of the box here.
But please note that you can configure OAuth, to for instance use Google, Microsoft or Keycloak, as the authentication mechanism.
That way you can use any password you like, that those identity providers allow, to log into Portainer.

:(

To clarify, no your passwords are not being sent to us. And the backend is only storing hashes.

If only hashes are being stored than how were passwords decided if they were not meeting the new enforcement restrictions or not? To quote your own documention:

If you're upgrading Portainer and your existing passwords don't meet this requirement, you'll be prompted to change your password when you first log in after the upgrade.

It's actually much more simple than that. We have received feedback via email from our users where inadvertently using a trivial password ended up compromising access to container deployment environments. So as always, Portainer is providing a certain level of security out of the box here.
But please note that you can configure OAuth, to for instance use Google, Microsoft or Keycloak, as the authentication mechanism. That way you can use any password you like, that those identity providers allow, to log into Portainer.

Yes. But the main use-case for a weak password is:
I am a developer, and I use docker with portainer solely on my local machine to navigate my local docker instance with a few changing containers on it. Portainers Web-UI isn't even exposed to others and only available on localhost.
A local dev does not have an OIDC identity provider running locally just for portainer to use it. And no, I won't setup a keycloak container just to be able to login to portainer easily.
I tried using the --admin-password flag, but with that I couldn't even login. Even the password file is too much hassle to set up for a local machine.
So for most of us the solution is simply to downgrade to 2.11.1, because heck, we actually don't need new features. It works fine.
For the next versions: The password policy can be that way and it can be on by default, but please let users decide on the policy and explicitly opt out of the rules or configure the rules with some simple env vars so that we simply can start our portainer for local management easily with a 1-liner and can use our local default password.

To clarify, no your passwords are not being sent to us. And the backend is only storing hashes.

If only hashes are being stored than how were passwords decided if they were not meeting the new enforcement restrictions or not? To quote your own documention:

If you're upgrading Portainer and your existing passwords don't meet this requirement, you'll be prompted to change your password when you first log in after the upgrade.

This is easy and happens all the time in pretty much all systems the same way: You log in with your current password. To be able to log in, you type in your password as plain text (as you don't provide the hash of your password). So your portainer installation (or whatever software you want to sign in to) see's the plain text password. It hashes it (be aware: it still can have the un-hashed plain text password in memory at this point together with the hash) and compares the hash it just calculated with what is in the database. If they match you are signed in.
Now, when you are signed in, it can still look at the plain text password (still in memory) and check complexity rules. If they don't match, it can flag your account with a "too weak" info and then remove the plaintext password from memory.
At this point the system knows your password is too weak without knowing your actual password anymore.

In light of the feedback that we've received, we are removing the restriction that is enforcing the mix of lower case, upper case, numeric and special characters; which means that any passphrase that is at least 12 characters long will be accepted in the 2.13.1 patch release.

This is not good enough. You should make it optional, and allow admins to completely turn of ANY password policies, if they deem them not needed. Have them enabled by default if you like, but admins should be allowed to explicitly turn it off.

But please note that you can configure OAuth, to for instance use Google, Microsoft or Keycloak, as the authentication mechanism. That way you can use any password you like, that those identity providers allow, to log into Portainer.

Sure, setup an even more complex authentication system to escape a simple password policy. That makes sense... [/sarcasm]
Please make this right again. I was caught once (hence why I am commenting here), but I think I will hold back upgrading my other instances until this is corrected.

upgraded and rolling back again... please give me the option to disable it! there is no need to enforce it in a local network when there is no access to it

Using the new password wasn't even an option for me, the login broke when I tried to change it, and I could no longer log in. Had to revert and restore from backup.

It's actually much more simple than that. We have received feedback via email from our users where inadvertently using a trivial password ended up compromising access to container deployment environments.
So as always, Portainer is providing a certain level of security out of the box here.

So you are saying the new password rules were a response to a few "users where inadvertently using a trivial password ended up compromising access to container deployment environments".
Maybe those few users are inexperienced users, or they just made a mistake, but most users don't do that.
Please, don't enforce this upon all users.
Create options to control/remove password restrictions.

Using the new password wasn't even an option for me, the login broke when I tried to change it, and I could no longer log in. Had to revert and restore from backup.

I had very much the same behavior. But I got the impression nobody seemed to care. I did a rollback too.

Based on the devs responses, it doesn't seem like they'll bring back the whatever password you want functionality, so are there alternatives to portainer that do the similar stack functionality?

Based on the devs responses, it doesn't seem like they'll bring back the whatever password you want functionality, so are there alternatives to portainer that do the similar stack functionality?

Sorry, but I do not entirely agree with your conclusion.
Refer to this comment earlier in the thread:

As Huib mentioned earlier we are planning to release 2.13.1 which will dial back the restrictions to a 12 character minimum without the additional complexity requirements. We consider this a temporary fix.

In 2.14 we plan to introduce functionality that will let you customize your required password strength to meet your needs. As we're still determining exactly how this will work I don't have any detail to share with you as of yet, but we will be taking into account all of the incredibly valuable feedback you've given us in this thread.

So we'll have to wait and see... Hopefully they will take this backlash serious, and not enforce policies on users without giving the option to disable them.

as a fan of Portainer for easy UI access to containers, I really HATE when something like this is enforced on me. Even Microsoft SQL-server lets ME, as the ADMIN decide how I want to enforce password policies.
Suggestion:
Default setting should be high security, strong passwords...
because if you are a newbie or lazy and just put this into production without RTFM ... aka if you don't know what you are doing, you follow the rules until you know why you don't need them.
But if I on the other hand as a developer or "home admin" just need a great tool which I have to log into many times a day, let me choose how high level I need, or allow me to make a "less secure" admin account below the "root" admin... which I can then use as my developer/home-admin account.
In Microsoft SQL server you install it with a SA (server admin)... from there you can create as many admins as you like.
Another simple approach would be to check for a ENV PASSWORDPOLICY="low, medium, high" or a number or flags... and then if that ENV PASSWORDPOLICY is not set, go for strongest settings available.
Always when you enforce something, leave an option to disable.

Additionally to everything said, this feature does not even enforce anything. at this point it is just a nagging modal, which can be easily bypassed:

change http://myportainerinstance/#!/account to http://myportainerinstance/#!/home, press enter
ignore modal and just refresh (strg+r, f5, whatever) the page
use portainer as you always did

If you're striving for improving security for users, who don't know that having an insecure password (which can also be passwords being 12 characters long) on a public facing service which has shell and root access to all services running inside of it, I don't think enforcing a password policy is an effective option.

Additionally to everything said, this feature does not even enforce anything. at this point it is just a nagging modal, which can be easily bypassed:

change http://myportainerinstance/#!/account to http://myportainerinstance/#!/home, press enter
ignore modal and just refresh (strg+r, f5, whatever) the page
use portainer as you always did

Nice workaround! Most casual users, like myself, would see the main page forcing password policy then would go nuts. At least now we can still use it without downgrading, or until the devs come to realize how frustrating it is for most of us who understood the risk, unlike those who's paranoid with local-only network passwords.

This makes no sense if it's not configurable. My instance is only reachable from within my home.

So apparently we need 12-character passwords to log into a service that's completely over unencrypted HTTP, that could be mitm'd, spoofed, etc. without anyone the wiser.
Very smart move here, devs

to log into a service that's completely over unencrypted HTTP

This is inaccurate. Since CE 2.9 and BE 2.10, both released last year, Portainer has defaulted to HTTPS encryption on the web interface, and our installation instructions do not expose the HTTP port by default.

@jamescarppe  but i can expose http if i want, so where is the logic in not letting me choose my password policy and enforce it? It basically breaks people setup without any way if changing it

@dimagoltsman As mentioned earlier in this thread, we're aware that we were overzealous in our initial release of this, and we are working on customizable password complexity for the next release (2.14).

Any ETA on when 2.14 will be released?
Here's another user that finds it total overkill and wants to disable it ASAP.

I want to know the how the developers "learned" of weak passwords. This is frightening that the developers are "learning" of our password usages, more then their implementation of arbitrary password polices.   Every enterprise deployed product has an ADMIN adjustable password policy, from firewalls, to routers, to servers. How is Portainter not providing such a policy setting but yet arbitrarily defining policies.
A good solution to the issue, is to allow admins to define a policy and for the developers to make an initial decision of what they suggest as a good policy.  This way users who just install it, will get a good policy by default but admins who choose can modify it as necessary of a case-by-case basis.  E.g. in an enterprise, it may require STRONGER rules, or additional requirements such as remembering the last x passwords, etc. At the same time in some orgs or home labs a policy is useless other than for end user frustration.
Please don't take this as any thing negative, just offering a solution for both parties.   Portainer is a great product.

Any ETA on when 2.14 will be released?

We're targeting June for the 2.14 release.

jamescarppe:

As mentioned earlier in this thread, we're aware that we were overzealous in our initial release of this, and we are working on customizable password complexity for the next release (2.14).

The current implementation in code does not provide any option for disabling the new password complexity. Can you confirm that will be able to be disabled entirely in the upcoming 2.14?
https://github.com/portainer/portainer/blob/85ad4e334aaa7f7b65d500c7b22962e70d18b558/api/http/handler/auth/authenticate.go#L104
https://github.com/portainer/portainer/blob/85ad4e334aaa7f7b65d500c7b22962e70d18b558/api/internal/passwordutils/strengthCheck.go#L31

We appreciate that Portainer is running on laptops, local networks, Raspberry Pis and other environments that don’t require additional security, however, Portainer is also often run behind reverse proxies and deployed on cloud provider infrastructure which exposes it to the Internet and is where problems can occur.
Our mission to make container technology accessible to everyone, which means we have to create a system that meets everybody’s needs – and when it comes to security that forces us to go to the highest common denominator, not the lowest.
Many Portainer users start their container journey inside Portainer and don’t fully understand all of the concepts underpin the tech and get things wrong. Most of the time the risks are low, but not always. For example, when working in a dashboard provided by a cloud provider, things may appear secure but an insecure instance of Portainer could open them up to a range of risks (financial and data loss).
Portainer Community Edition is used in home and business contexts. We have a moral obligation to prevent behaviours that expose environments managed by Portainer to undue risk. For this reason we are enforcing a 12-character password, which an administrator will be able to reduce to 8 characters. Inevitably this will be inconvenient for home users where there is no risk, but we think it’s a small price to pay to keep all of our IT infrastructure safe in a time where cybercrime is on the rise.

"[...]moral obligation[...]"
I'm starting to look for alternatives now. Have a nice day.

"moral obligation" is a strange phrase for self righteousness... if moral obligation was the reasoning here, there would be default settings for password parameters enforcement with an option to disable them. that way the devs would be able to sleep soundly knowing that they did their knightly obligated honor, and users wouldnt be forced to accept someone elses morals

done so regarding downgrading, but thats not the point. You're talking about a fix..... thats the point. We're pressing for a fix for an issue which wasn't broken. The portainer devs need to rethink what their approach is. If it is developing against the user base, then it's a decision i have to accept. Wasn't it this NIST guy, which apologizes after he retired, that it was a bullshit move to propose long passwords...... anyway....and regarding babying, it's not the point to have password security, it's the point to press policies which i cannot configure/disable

when it comes to security that forces us to go to the highest common denominator, not the lowest

I think it's fair to say that most, if not all, security experts would agree that requiring a secure password by default is a good practice, but their should also be the option to reduce that requirement for those that wish to - whether that is a good idea or not!
My ISP, for example, ships their standard router with a default login of 'admin' and the password 'sky'. There is the option to open the web ui to be accessible over the internet without changing these credentials. Is this a good idea? Hell no, but do Sky 'have a moral obligation to prevent behaviours'? Of course not. Warnings are put in place on these options explaining the consequences of the enabling the feature.
The real danger here is that users of Portainer will instead move to alternatives where their default security is non-existent (I'm looking at you Yacht with<EMAIL_ADDRESS>and no requirement to change!), and now those users are left exposed and uneducated as to the dangers they face.

@jamescarppe
Just to emphasize my main concern again:
While I don't really need/want password requirements with >= 12 chars, this is more a a potential nuisance for cases where it's not needed.
What I really can't have is that existing users are required to update their password!
Because then suddenly things start breaking in production. I can accept that new users are subject to longer passwords, although not particularly happy about it for our use-case.
So please consider only applying this new policy for new users.

I don't say they the basic criticism isn't valid and I don't say they solved the issue they strived to solve the best way there is.
I say just because I don't have that issue, doesn't mean no one else has and doesn't make it an issue not worth solving.
Are there better ways than enforcing a password policy? Sure.
Are there better security measures than enforcing a password policy? Yes.
Is a password policy which is enforced only on the frontend a sufficient password policy? Absolutely not.
There's a lot of valid criticism against the current solution and its all already in this discussion. The devs are aware and are working on it, just taking further dumps on the devs isn't bringing anything productive to this discussion.

this post is irrelevant. there is a big difference between developing software for layman and developing software intended for admins ... know your audience

I don't know what point you're trying to make. Admins are no infallible entities who never make mistakes configuring software due to time- or money-constraints or just pure incompetence. All insecurely exposed databases, badly configured consumer products or database leaks with insecurely hashed passwords can be traced back to admins or devs not doing their jobs.
An insecure portainer instance does not only hurt the people who are at fault for possible security incidents but also the end-users using the underlying services. The devs being aware of these things shows a good sense of responsibility, imho.
Which brings me back to my main point:
It's totally fair to criticize how they implemented that feature (which has been sufficiently done at this point) , but criticizing the reasoning for implementing it isn't productive.

@maexrakete, noble of you, but the decision to just make the change and them force the user to use it without the ability to disable it or at the very least keep the current password for the time being was an extremely dumb move.
Let me log in and nag me about how my password is not long enough if you must.  That is a very good first step. That's the best thing they could have done without breaking things or pissing people off.  Next release they could have added whatever configurable password policy mechanism they felt was the best for their intended audience.
Now I imagine this was not a one rogue dev that decided to implement this and release it.  A number of people got together and decided it was a good idea to just force everyone to change their passwords and how the new password needs to meet some criteria because some people who use their product are, quite frankly, idiots.
There is just one word to describe this entire fiasco: dumb.

All this forced to install https://yacht.sh/ and Im liking it...

It is hoped that the next version to remove the limitation of the length of the mandatory password is meaningless to security. Users who need this aspect can set a very long and complicated password by themselves.  I don't know if you have ever developed back-end programs. Does MySQL force you to use a 12 character password? If users feel insecure, they can add it themselves. You don't need to force it. And is 12 characters safe? If someone wants to crack the password, 100 characters is useless. There is no doubt that forcing passwords is a foolish act. Look at how many people have responded to this question. Of course, the program you participate in can do whatever you like ~ no, I will choose the previous version, or find another substitute

Phhh as my portainer is not even avail from outside my homenet, this is really annoying :-(

Uhh just updated portainer to 2.13 and immediately have to downgrade ... never again use latest tag.

Whats the latest version without strong password enforcement?
need to downgrade immidiately.

Whats the latest version without strong password enforcement? need to downgrade immidiately.

Im with 2.11.1 and it doesnt ask for it

Thanks, done. Home is working again

All this forced to install https://yacht.sh/ and Im liking it...

I do hope you changed from the default credentials! 😜

Uhh just updated portainer to 2.13 and immediately have to downgrade ... never again use latest tag.

I figured id update to latest too, never again. I now have 2.11.1 specified, and Ill check back to see if they roll back the requirement.

Give us the ability to control how our passwords are -- especially us using this to toy around in a home lab!

Hi everybody,
I wanted to post an update to this thread to go into a bit more detail as to what we're doing with this functionality in 2.14. Your feedback here and elsewhere has been incredibly valuable in helping us come to a solution that we feel balances the desires for customizability with the need to provide a strong level of security to Portainer by default.
In version 2.14, we'll be adding the ability for admins to customize the minimum password length required by Portainer. This will be done via a slider in the Portainer UI, under Settings, Authentication. Portainer will default to 12 characters for new installs, but the slider will allow you to set this as high as 18 and as low as 1. The slider will also tell you the strength of your set length as you adjust. When you try to set a length of 8 or below, you'll be presented with a warning that this is insecure - you can accept this warning to apply the change.
Users that do not currently meet the password length requirement will be advised of this on login and given the opportunity to change their password. We've also added the option for a user to defer this change twice, after which a change will be required. When an administrator is asked to change their password they will also be provided a link to adjust the length if they prefer.
I appreciate it has taken us a bit to get to this point and I want to thank you for your patience while we worked on this. We clearly didn't get this quite right in our initial implementation, missing some legitimate use cases, and we're sorry about that. Hopefully this new implementation resolves your concerns about this feature.
In terms of when this will be out: version 2.14 is currently undergoing testing with a release planned by the end of this month.

This is great news. I think for a home lab / local only installation it is totally acceptable to change the default in the UI once when you have to go through the initial setup anyways. Thanks a lot!

great

Portainer will default to 12 characters for new installs, but the slider will allow you >to set this as high as 18 and as low as 1.

if you go that low ("1") can you go a step further to "0" and disable completely authentication, for guys like me which have other authentication mechanisms running in front of portainer like 2FA

Completely agree with @mamema - having to remember a password for a non-commercial system that is already heavily protected doesn't make much sense - I would prefer the option of being able to disable passwords if possible, completely understanding that this should not be the default behaviour.

Yes, please, please, please give us the option to disable the password completely.
My portainer instance is private, and not accessible from the internet, so the annoyance of entering one more password makes no sense.

I support this proposal - current implementation is horrible and unnecessary. I should be allowed to use a bad password in my own environment if I wish.

@jerry1333 , cool over function obviously.
I don't know about anyone else, but I have my lastpass setup to generate all my random passwords to 50 characters.  So the limit of 18 for me it quite honestly limiting if you ask me.  I use Portainer in an environment that does not need password auth to begin with, so whether it's 1, 18, or 1,000,000,000 characters long, has no other effect other than get on the way.

Uhh just updated portainer to 2.13 and immediately have to downgrade ... never again use latest tag.
I figured id update to latest too, never again. I now have 2.11.1 specified, and Ill check back to see if they roll back the requirement.
 For home users who only access it via lan this is just another remedial 'qol' type of addition and the clear backlash from the community hopefully expresses that enough.

Uhh just updated portainer to 2.13 and immediately have to downgrade ... never again use latest tag.
I figured id update to latest too, never again. I now have 2.11.1 specified, and Ill check back to see if they roll back the requirement.
 For home users who only access it via lan this is just another remedial 'qol' type of addition and the clear backlash from the community hopefully expresses that enough.

...and anyone running portainer as an enterprise level container management solution would most likely tie it into the corporate AD or IPA anyway.

My main concern would be whether the new version will also enforce the use of special characters. I was disappointed to see that my very long (and consequently strong) pass phrase did not meet the new requirements simply because it lacked special characters.

We removed the special character requirements in the 2.13.1 patch release, and it will stay removed in 2.14.

I don't know about anyone else, but I have my lastpass setup to generate all my random passwords to 50 characters. So the limit of 18 for me it quite honestly limiting if you ask me.

The slider sets the minimum password length required. You can of course use a password much longer than this.
I will pass the feedback on the interface method on to the UX team, however.

if you go that low ("1") can you go a step further to "0" and disable completely authentication, for guys like me which have other authentication mechanisms running in front of portainer like 2FA

We provide the ability to use external authentication providers already which bypasses the built-in authentication, and we are actively looking at adding other providers in the future (for example Authelia). I'd suggest starting a separate Github issue around this so we can gather that feedback separately from this rather long thread.

Oh well, I don't want to run all those damn docker things at home if it's going to be this much trouble.

One of them, already mentioned above, is Yatch https://yacht.sh/

Thank you, I'll go with this one.

Portainer CE-2.14.0 is here.

The only remaining open issue in this version is the one from this very thread #7055
Password is still required by policy
The minimum password length is still 1 (one) character

All this makes me feel very, very disappointed... :disappointed:
I really do like Portainer, however this stubborn refusal of allowing the users to disable authentication is too much for me.
It seems that it's time to move on :cry:: broken_heart:

Portainer CE-2.14.0 is here.

The only remaining open issue in this version is the one from this very thread Introduce the ability for an admin to configure the password length #7055
Password is still required by policy
The minimum password length is still 1 (one) character

All this makes me feel very, very disappointed... 😞 I really do like Portainer, however this stubborn refusal of allowing the users to disable authentication is too much for me. It seems that it's time to move on 😢 💔

wait someone say they going to do something about it at the end of the mouth hopefully

This thread has been about disabling the enforcement of the strong password policy, which 2.14 has done. It has not been about disabling password authentication entirely - this should be opened as a separate feature request if it is desired.
As the issue this thread is about has been alleviated in the 2.14 release, I am closing the thread.

How can I set the password length before portainer installation? With an environment variable?

Ehm, how do i actually use this now? It asks for 12 character password on install.

The simplest way is to use a 12 character initial password. After the initial setup is complete, just change the password length and set the correct password.

12 characters doesn't automatically make a strong passwords. The password @$$ is a lot stronger and harder to brute force than 123456789abc

so what about this? seems to be an issue for years. just installed portainer and have to use a useless long passwort. what is this shit?

@apfffr - I has been fixed. There is a setting for number of characters to use. Change that for fit your desires. Create a user and assign a password.

If you are setting up your user/password during a new installation, you will need a 12-character password. Then, you can enter the settings to set the character length and set a new password.

If you are setting up your user/password during a new installation, you will need a 12-character password. Then, you can enter the settings to set the character length and set a new password.

Set a password, change the preferences, done.
Unsubscribed.

I found it troublesome to come up with a 12-character password for temporary use. I initially repeated the password like passwordpassword, and then changed it to password.

Almost 2 years later and people still crying abou this...
Set a password, change the preferences, done.
Unsubscribed.

Yeah now that I know I can change it, setting a one-time 12 characters temporary password is not a big deal. Hell, you can even set it as<PHONE_NUMBER>2 or aaaaaaaaaaaa and then adjust the password rules before you change it to your favorite.

The thing is, 2 years later or not, this is still a weird design choice, with all due respect.
I'm currently in the process of setting up a staging environment for my homelab. This staging environment is ephemeral and inaccessible from the outside world. I don't need a strong password there. Heck, I don't even need a password at all. I just want to set a simple one like '1234' to be iso with prod while still typing it quickly.
When using the cloud hosted offers of Portainers this probably makes a lot of sense. But when you're hosting yourself you know what your use case is, and only you can decide which policy is relevant for which scenario. See my use case just above: I hate having Portainer think in my place here, that's not why I self host open source services. I expect this kind of "protecting you from yourself behaviour" from proprietary solutions, that's a given, but I'm really sad to see it in the open source world, especially still ongoing years after the issue was raised.
Why not just use an env var, a runtime parameter or whatever else to allow disabling this policy? Why would devs @ Portainer think allowing to just tweak the password length requirement after first login (making it useless in an automated deploy environment) is a better solution? Why forcing us to do anything we don't want to? I'm really confused.

Why not just use an env var, a runtime parameter or whatever else to allow disabling this policy? Why would devs @ Portainer think allowing to just tweak the password length requirement after first login (making it useless in an automated deploy environment) is a better solution? Why spending time to develop features that decrease the number of ways we can use Portainer? I'm really confused.

Because their project, their way.
It was annoying for sure, but 2 years later and it's still the same, they're not going to change it.
Options:

use is as it is
find an alternative product
it runs as a container itself, spin one up, configure it to your liking, then clone it again and again as needed.
clone the repo, make the change and enjoy, possibly even making it available to others who don't like it either

I didn't like it either, but it is what it is and I moved on.

Because: their project, their way.

This is a truism. Of course. I think we can still emit criticism though (and I did my best to make mine constructive, I don't think it's just me venting).

It was annoying for sure, but 2 years later and it's still the same. I'm pretty sure they're not going to change it back.

We don't know, man. Their project, their schedule. :D Could be a matter of number of people complaining, could be a matter of dev bandwidth, could be a matter of reasons to make the change... In any case, left this message in a bottle because I felt like it.

Options:

I consider many of those options, for now I'm doing 1., 2. is a little overkill for such an issue (I'll end up just registering the staging password in my browser, as stupid as it is), 4. is obviously too much maintenance for such a trivial problem (I don't think this deserves a fork, yes there is a space between "it's worth me criticizing it" and "it's worth forking and maintaining the fork" :smile: ).
Option 3 is actually interesting, I didn't consider it. But at first glance it seems a little flaky/too complicated to me: containers being ephemeral by nature, if the image doesn't give you a customisation option at startup, it means you gotta mount the customisation data each time, or modify the image directly with commands configuring the data; in both cases you meddle with the private implementation, and again, it means maintenance costs. But maybe I'm missing something in your suggestion.
Anyway, yes, this was just my 2 cents, I know very well they don't have to act on it. Thank you.

this entire thread is a monument to the arrogance of coders.  The community has asked they change something back, and the devs are plugging their ears screaming
Sounds like a community fork is in order.

this entire thread is a monument to the arrogance of coders. The community has asked they change something back, and the devs are plugging their ears screaming
Sounds like a community fork is in order.

Godspeed!

annnd done..
for those who want to run with any password length. I give you the portainer-genx fork
install instructions
docker volume create portainer_data
docker run -d -p 8000:8000 -p 9443:9443 --name portainer-genx --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_genx_data:/data phoenixalight/portainer-genx:latest
problem solved, community heard and respected.  how hard was that?


Rewrite search algorithm

This PR rewrites the search algorithm to use https://github.com/EthanRutherford/fast-fuzzy instead, the result improved a lot in a real and large Nextra site according to my test.
Also changed the option to search instead of flexsearch because we don't need to expose too much info about the underlying implementation.
Examples
Here are some examples on nextra.site. Old / new:
"meta": _meta should be the first result

"chat": two results link to the same place

I shouldn't have changed the frontmatter typing there... totally unintended 😬. The problem was that we had both search in frontmatter and flexsearch in nextra config, and I changed flexsearch to search and then they conflict...

probably a bit late for a pitch here, but fast-fuzzy ain't all that fast, and probably a bit too fuzzy :)
https://leeoniya.github.io/uFuzzy/demos/compare.html?libs=uFuzzy,fast-fuzzy&search=super ma
https://github.com/leeoniya/uFuzzy#a-biased-appraisal-of-similar-work

@leeoniya late is better than never :))

I want to find a good algorithm to give scores to each page.

it sounds like you want something closer to a document/fulltext search that can also take into account term frequency and which part of the document it occurs in. while uFuzzy is a great fuzzy search, it would take more legwork for it to rank documents with those metrics. existing document searches (FlexSearch, Lyra) use an index, which gets big in memory and expensive to start up if you want typo tolerance and partial matching.
it would be interesting to experiment with a uFuzzy wrapper than can do reasonably well without an index by just doing a pre-pass over all facets together (pageTitle, title, content) to quicky reduce the search space and then do each facet and needle word independently to count total matches and have that as part of final ranking/sorting.

@shuding are you planning to ship this? I guess it will solve my problem as well

Also curious if there are any updates on merging this PR? Fixing the "two results link to the same place" helps clean up the search results a ton.

Closed by https://github.com/shuding/nextra/pull/2569


Issue 7 !streaklongest length

GetContributionsByUsername

New behavior added to to accept an options object
Added pagination to go around GitHub API's 1 year limit.

GetYearsBetweenDates

A new function in date.go which returns a slice of int's representing years between two given dates.

Close #7
Close #15

Yo solid PR.. just one last addressable comment :)


Making the outcome look closer to native jupyter notebook format

This is an amazing project. I want to share my idea that the outcome could look closer to native jupyter notebook format.
The preamble settings (reference) are:
\newlength\inwd
\setlength\inwd{1.3cm}

\newcounter{ipythcntr}

\newtcblisting{ipythonnb}[1][\theipythcntr]{
  enlarge left by=\inwd,
  width=\linewidth-\inwd,
  enhanced,
  boxrule=0.4pt,
  colback=light-gray,
  listing only,
  top=0pt,
  bottom=0pt,
  overlay={
    \node[
      anchor=north east,
      text width=\inwd,
      font=\footnotesize\ttfamily\color{blue!50!black},
      inner ysep=2mm,
      inner xsep=0pt,
      outer sep=0pt
      ]
      at (frame.north west)
      {\stepcounter{ipythcntr}In [#1]:};
  },
  listing options={
    basicstyle=\footnotesize\ttfamily,
    language=python,
    escapechar=¢,
    showstringspaces=false,
    frame=none,
    backgroundcolor=\color{white!95!black},
    numbers=none,
    breaklines=true,
  },
}

And the code is:
\begin{ipythonnb}
import pynq
from pynq.lib import AxiGPIO
from pynq import Overlay
import time
import struct

overlay = Overlay("./bp_gpio.bit")
\end{ipythonnb}

The rendered pdf would look like this:

Anyway, hope if this could help someone.

Hello @Godfly666 , thanks for the report!
The problem I see with this "original look" is the width. In a realy Jupyter environment you have the whole browser and the whole screen (normally very wide) to your disposition. That way, if you have long lines, you can make everything larger with no issue.
But in a book the width is a very important factor. Books are narrow. And you cannot adjust their size. And having wrapped lines is so ugly!
In that spirit, losing a lot of available width because the "In [1]: " it's a misfeature.
Thanks!

FTR, I'm ok to include code in Jupynotex that, optionally, render the output like this (the default would be as it is now). Patches welcomed! :)


Extraneous symbols are incorrectly ignored

E.g.
dateparser.parse(')(*&^%$#@!7)(*&^%$#@!) )(*&^%$#@!4)(*&^%$#@! )(*&^%$#@!1776)(*&^%$#@!) ')
returns
1776-07-04 00:00:00 instead of None - I take this to be undesirable behavior.
Whereas with extraneous letters e.g.
dateparser.parse('q7 4q q1776')
None is returned - which I take to be desirable behavior.
OS: macOS 10.12.1

@jfrancos first string contains characters which the parser treats same as it does comma, period or dash or other popular date delimiters. Hence, you get the date.
there's a way to parse the second example:
dateparser.parse('q7 4q q1776', settings={'SKIP_TOKENS': ['q']})
Out[2]: datetime.datetime(1776, 7, 4, 0, 0)


Fix inactive service worker

Subscribe to onStartup event so that Chrome runs our service worker on startup

dist.zip


Google indexes ajax links

Reported by Predominant | September 9th, 2010 @ 07:21 AM
I recently noticed that google indexes ajax links like "Add new comment" and "Reply", showing the plain form, which gets loaded by the plugin. I added the the attribute rel="nofollow" to all links created by the plugin, since anonymous commenting is allowed on the site.

fixed


only tries to connect to saved AP if WIFI_MANAGER_DEBUG is set

just a very tiny change needed to move xEventGroupSetBits() call outside of #if/#endif.
patch.txt

Good catch, I've just fixed it! --marking as closed


OpenGL crash

Not sure if it's related with the library but after implementing it I started to get reports from users experiencing a crash with the following error message:
void org.jetbrains.skiko.OpenGLLibraryKt.loadOpenGLLibraryWindows()
Any help will be appreciated. Thanks in advance

@KevinnZou sorry for so many questions and feedback. I could solve the crash by upgrading compose plugin. But here is another issue I'm experiencing. Some Windows users are getting the restart required message every time they open the app and the KCEF download process is not starting.
After some debug sessions we found that it works perfect when running app as an administrator, so I guess the issues is related with write permissions. Did you experience this issue before or have any idea on how to fix it?
Thanks in advance

@DatL4g Could you have a look at this issue?

@KevinnZou @DatL4g I was able to prevent the crash by upgrading org.jetbrains.compose plugin from version 1.5.1 to 1.5.11


how can you show them when they are on a scroll position

Hi,
I want to show slide 2,3,4 when i scroll to them. Now they are animated all at once.
What do i need to change to have this behavior?
html:

 Block One

 Block Two

 Block Three

 Block Four

css:
.slide {
  position: relative;
  height:400px;
}

Kind regards,
Allaerd

Hi @allaerd ,
Remove the  container:  '.itemset' from the [ngsRevealSet] options, and you should be good!
See this working plunker.
Also, you can play with [ngsInterval] option to adjust the delay (in mlillis) between each item's animation.
Cheers,

No feedback in 10 days, closing issue.

Hi,
sorry yes. IT works great. Thanks for the feedback
regards,
Allaerd

On 23 Apr 2017, at 10:07, Tine Kondo<EMAIL_ADDRESS>wrote:
No feedback in 10 days, closing issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/tinesoft/ng-scrollreveal/issues/8#issuecomment-296426796, or mute the thread https://github.com/notifications/unsubscribe-auth/AArN6WohwVkUYKfH7d-46ybmN88lV1VBks5rywalgaJpZM4M8pH1.


chore(config): remove upgrade package mappings

The package is not listed in package.json and https://github.com/angular/angular.io/pull/2803 will contain instructions to add it manually.

I also removed '@angular/router/upgrade': <EMAIL_ADDRESS>for the same reason


contributor

This are the changes which I want to add in the js file if there any suggestions is there to let me know

This are the changes which I want to add in the js file if there any suggestions is there to let me know

Hi! Which task is this referencing to? I don't see any files changed in the tasks directory.

check in the commits just now added in commit tasks

check in the commits just now added in commit tasks

You committed three empty files within the new commit. Was the first commit about some kind of new issue suggestion?

yes, i suggested

yes, i suggested

Okay, so can you provide me name and description of the task you are suggesting, difficulty level (easy, medium, hard), installing instructions (if there are any) etc?

Pull request closed because there was no answer from the pull request creator.


Make getjigsaw.sh script compatible on the MacOSX - use perl instead of grep where needed

I recommend replacing the last grep to perl -nle 'print$& if m{jdk-9+\K\w+}' since OS X 10.12 (Sierra) doesn't support grep -oP or the \K option.
Related to #63

Fixed via #67


Minor bugfix and changelog updates

Fix bug where workspace configuration deprecation notice errantly shows on workspace view page on reload.
Update changelog for enhancements.

Checklist:

[x] Have you successfully tested with your changes locally?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Reviewed in office hours, Nov 15, 2023.


Test Fails after getCode Call to Moonbeam Precompiles against --fork-url Moonbeam Fork

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (b174c3a 2024-02-09T00:16:22.953958126Z)
What command(s) is the bug in?
forge test
Operating System
Linux
Describe the bug
We are executing a simple test against a Moonbeam precompile running it against a Moonbeam specific fork that supports their precompiles. We check precompile support by doing a simple eth_call to the precompile fetching the balanceOf a specific address. The JSON-RPC works, meaning that the fork supports Precompiles.
The test is fairly simple, it loads the precompile address through an ERC_20 token interface and calls the balanceOf method. We added a console log for Hello! just to understand where it failed, if in the loading the token interface, or executing the balanceOf.
pragma solidity ^0.8.0;

import<EMAIL_ADDRESS>import<EMAIL_ADDRESS>
import {IERC20} from<EMAIL_ADDRESS>
contract BalanceIntegrationTest is Test {
    function testBalance() public {
        IERC20 token = IERC20(0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080);
        console.log("Hello!");
        uint256 balance = token.balanceOf(0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3);
        console.log(balance);
    }
}

After running the test, it failed in the balanceOf operation. Test logs:
No files changed, compilation skipped

Running 1 test for test/BalanceIntegrationTest.t.sol:BalanceIntegrationTest
[FAIL. Reason: EvmError: Revert] testBalance() (gas: 6176)
Logs:
  Hello!

Traces:
  [6176] BalanceIntegrationTest::testBalance()
    ├─ [0] console::log("Hello!") [staticcall]
    │   └─ ← ()
    ├─ [6] 0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080::balanceOf(0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3) [staticcall]
    │   └─ ← EvmError: Revert
    └─ ← EvmError: Revert

In the Moonbeam Fork, we enabled the JSON-RPC trace, meaning we had visibility to all the JSON-RPC requests and responses from the fork itself.
The first weird thing we noticed is that there are a lot of weird eth_getTransactionCount, eth_getBalance and eth_getCode calls to smart contracts, some of them were not even in the tests! Another weird thing is that these calls referred to values in block 0x59. Moonbeam fork actually builds on top of the latest block of the chain, which is already past 5.4M blocks. For example, this is the JSON-RPC trace for the precompile address before the test fails and there are no more JSON-RPC calls:
2024-02-09 10:46:09.396 TRACE tokio-runtime-worker rpc_metrics: [http] on_call name=eth_getTransactionCount params=Params(Some("[\"0xffffffff1fcacbd218edc0eba20fc2308c778080\",\"0x59\"]")) kind=method call
result="{\"jsonrpc\":\"2.0\",\"result\":\"0x0\",\"id\":19}"

2024-02-09 10:46:09.401 TRACE tokio-runtime-worker rpc_metrics: [http] on_call name=eth_getBalance params=Params(Some("[\"0xffffffff1fcacbd218edc0eba20fc2308c778080\",\"0x59\"]")) kind=method call
result="{\"jsonrpc\":\"2.0\",\"result\":\"0x0\",\"id\":18}"

2024-02-09 10:46:09.405 TRACE tokio-runtime-worker rpc_metrics: [http] on_call name=eth_getCode params=Params(Some("[\"0xffffffff1fcacbd218edc0eba20fc2308c778080\",\"0x59\"]")) kind=method call
result="{\"jsonrpc\":\"2.0\",\"result\":\"0x60006000fd\",\"id\":20}"

Note that the bytecode for the precompile is just REVERT, but it is set as such so that when doing a address size check it returns something different to zero and the execution understands that the target address is a contract and not an EOA.
We never see the eth_call to fetch the balance of the address on the precompile. Our theory is that Foundry is doing some checks against the bytecode returned by eth_getCode.
Any ideas?
Thanks in advance

We ran the same test but against a regular ERC-20 and it seems that our precompile does not support eth_getStorageAt queries. Why is this not done via a simple eth_call?
Thanks in advance

thanks for flagging, this sounds weird indeed.
I'd appreciate if you could put this simple example into a minimal repro, so I don't have set it up manually
what are you're cli args?

We never see the eth_call to fetch the balance of the address on the precompile. Our theory is that Foundry is doing some checks against the bytecode returned by eth_getCode.

The way fork testing works is by fetching bytecode of the contract via eth_getCode and executing it instead of making eth_calls. This is needed because eth_calls does not let you mutate and track changes of the EVM state.
This limitation is explained in Moonbeam docs https://docs.moonbeam.network/builders/build/eth-api/dev-env/foundry/#forking-with-cast-anvil

Yeah, eth_getStorageAt queries don't work as precompiles do not store any data in the actual smart contract storage.
There is currently no way to run tests without eth_getStorage as we need those queries to be able to process storage reads happening during execution.
If we'd use eth_calls, it would only be able to response with data relevant for current mainnet state. That way, if your test mutates state of precompile token (via transfer), we wouldn't be able to know what the next result of balanceOf will be. Thus, you wouldn't be able to test any behavior dependent on precompiles state

Yeah, eth_getStorageAt queries don't work as precompiles do not store any data in the actual smart contract storage.
There is currently no way to run tests without eth_getStorage as we need those queries to be able to process storage reads happening during execution.
If we'd use eth_calls, it would only be able to response with data relevant for current mainnet state. That way, if your test mutates state of precompile token (via transfer), we wouldn't be able to know what the next result of balanceOf will be. Thus, you wouldn't be able to test any behavior dependent on precompiles state

Understood.
What happens is not that precompiles do not store any data in the actual smart contract data (which you are correct and they don't), is just that Moonbeam's Ethereum compatibility layer does not have a map for eth_getStorageAt  for precompiles so it looks in the Ethereum emulation layer we run etc.
So we'll have to support this so that devs can run tests against these type of Moonbeam forks.
Is there a way to have Foundry use a custom fork methodology for Moonbeam that is not Anvil? This will allow devs to fork and use precompiles (after we fix the issue of getStorageAt)
Thanks for all your replies!

custom precompile handlers would be possible once we've updated the evm dependency
could you point us to the moonbeam precompiles?

custom precompile handlers would be possible once we've updated the evm dependency
could you point us to the moonbeam precompiles?

Happy to help!
We have the following: https://docs.moonbeam.network/builders/pallets-precompiles/precompiles/
And also a lot of Substrate based assets like DOT is served to our EVM as a precompile as well. Here are the list of such precompiles (that are erc-20)
https://docs.moonbeam.network/builders/interoperability/xcm/xc20/overview/#current-xc20-assets


Child selectors

Version: 4.1.0
Environment: Both
Type: General

Description
I read the http://fela.js.org/docs/basics/Rules.html#5-child-selector section and it answers some of my needs, but I feel it leaves some parts out...
BTW, there is a broken link at this page: https://github.com/rofrischmann/fela-stylesheet should be https://github.com/rofrischmann/fela/tree/master/packages/fela-stylesheet (and I failed to understand that is the purpose of this tool).
Back on topic: the > notation allows to select an immediate child under a processed class, which is nice already. But it leaves out some cases that can be used to handle 3rd party styles.
For example, I need a descendant selector to attain a deeper child, at an unknown level, within perhaps divs without classes. I discovered at the above page that the >> selector can be used for this purpose, perhaps you can handle it?
Another case is adding an adjacent class that must keep its naming. Like class="foo bar" noted .foo.bar in CSS. foo name can be processed but .bar needs to remain as is. I don't think that combined rules can handle this. Other libs use the & notation for that: &.bar or &bar as selector name.
Last case, perhaps a bit controversial given the scope of Fela, is to style a child by its tag name. In CSS, that would be .foo p ie. any paragraph under a container class. >> p notation could work here.
Actually, the & operator can handle all these cases, if it means "stick to current class name, keep what follows (including space)". That's how JSS and Glamor handle these cases.
I don't know if these cases fit in the philosophy of Fela, but it started some support with child selectors, I hope it can go a bit further... 😄

Yes, I discovered >> when I wrote this issue... 😄
The .foo.bar case might be resolved in a more idiomatic way with Fela. I needed it in the https://github.com/hellofresh/css-in-js-perf-tests project, where we have one stylesheet declaration for all CSS-in-JS libraries, with minor adjustments for syntax. Note that's in the context of server-side rendering (no interaction).
In an example, I have a list of components, and I add a special class name on some of them (conditionally) to change its look (background color). This is supposed to reflect a state in the component's data.
So the case is to add a class name to alter the look. Which is not the Fela way to doing things, I suppose...
About your example: it doesn't reflect the usage of > because you used a property that is inherited. I changed it a bit to use non-inherited properties, like border or margin: https://jsfiddle.net/foj2toqv/1/
The innermost div doesn't get these properties, while it does if you remove the >.
About consistency: some libraries require & before :hover, while others consider that the : is enough to indicate it must stick to the parent class name. Kind of implicit &.

@PhiLhoSoft

About consistency: some libraries require & before :hover, while others consider that the : is enough to indicate it must stick to the parent class name. Kind of implicit &.

The problem is, that these solutions yield different effects.
&:hover !== & :hover The first one applies if the current className is hovered, the second one applies to all children if hovered. (see https://jsfiddle.net/jsjb3by0/)
I would want to have: :hover to apply to the current element while &:hover applies to its children, but then the & is not the best character here.

@PhiLhoSoft this gets released in 20mins :P


Fix: many bugs in assignment, initialization, ...

Introducing some C++ unit tests uncovered a few bugs:

miscalculating some buffer sizes;
miscalculating round-up-to-power-of-two logic;
some copying and assignment bugs.

This change lightly refactors to make more of the above testable, tests them, and fixes the problems that surfaced. Code inspection also shows some memory leaks and other issues, but Rome wasn't built in a day and the patch is getting big as-is.

Will look into failing pytest ...

Hi, @kmapb! Just saw that you wanted to look into the Python tests. They are already passing, I've just pushed the code. Now I'm in the processes of merging our changes. Will push them with a working GitHub CI.
Next up - checking which C++ interfaces are missing to start integrating into Chromium or other major C++ project, as planned 🤗

Looks like pytest has been broken for a while. After fixing the typing and pytest annotation issues, we're failing one of the asserts in sz_size_log2i in the guts of the sz_sort_introsort. We're about 8 frames deep in the hardware stack in an explicit recursion here. Let's see if I can figure out what went wrong; please hold the review for now in case it's something substantial.

Ah, yes, we call it with zero, which is undefined behavior. (0 has no logarithm in any base).

OK, now the majority of the test_fuzzy_substring cases fail. Repushed with fixes for sort, retrying.

It's trying to execute a function named choice introduced in c9aad691. No such function is present in that revision of the file, nor in HEAD. Assuming I need to reintroduce from random import choice

Yes, that's the random choice function. I am surprised the Python tests are failing for you. Maybe I need to shuffle better 🤔

Can I already sync our versions on main-dev or do you want to push something else in this PR, @kmapb ?

I think I'm done now! Just squashed enough changes to get pytest running again.

Phew! Let's see what the automated tests think. If they're green, I think we're ready for review here.


SegFormer model exported to CoreML is slow

I was trying to export Segformer models to CoreML but the exported model is slow compared to the same model exported on my own.
I tried to export the model using the following command:
python -m exporters.coreml --model=nvidia/mit-b2 --feature=semantic-segmentation exports/

This model median prediction time is 500ms on my MacBook Pro M1 using all the available accelerators (ANE, GPU, CPU), above the 300ms of the same model exported on my own using coremltools directly.
I did a little of profiling to identify the issue using Xcode Instruments. It look like the model is exported and executed in Float32. This greatly undermined the performance since Float16 data is required for the ANE to be used. Thus, the ANE is not used at all and the model is executed on GPU only on most devices. Also, Float32 computations are slower than Float16 computations on the GPU, thus Float32 should be avoided when possible. In the coremltools documentation Apple suggests to use Float16 as a default and as of version 7.0 Float16 is the default precision for CoreML exports.
With the option --quantize=float16 the inference time is on par with the model I exported (around 300ms). I suggest to use the coremltools default Float16 precision instead of Float32 in order to get the most of the specialized hardware or Apple platforms.
I also noted another issue but not related to the exporters framework. In Float16 and with the ANE, the Instruments trace suggests that half of the prediction time is spent in GPU kernels. That is weird since only 1 operator is executed on the GPU in this case: the argmax operation at the end of the model. This slowdown needs further investigation but this may be due to the large size of the input tensor (1000x512x512). I tried with only 16 output classes and the inference time drop down to 60ms.

Thanks a lot @laclouis5! Very interesting observations!
The philosophy we have been applying is to preserve the weights in their original precision when possible, but I tend to agree that it probably makes sense to default to 16-bit for exporters. If you'd like to propose a PR I'd be happy to review it; otherwise I'll get to it in a few days :)
Very interesting comment about argmax performance too. Do you think something like https://developer.apple.com/documentation/accelerate/bnns/reductionfunction/argmax could be faster in this particular case? Another option could be to write a custom Metal kernel, but that sounds similar to what appears to be happening under the hood.

I just opened a PR that just changes the default behavior (#58).
For the argmax thing, I did not try the BNNS or MPS custom kernel. Would be great to compare but I assume that Apple used its best implementation in CoreML anyway. I rapidly tested the performance of argmax in PyTorch using MPS just to get an idea and the operation seems slow there too.  I got 300 ms for an argmax on the channel dim for a tensor of shape 1x1000x512x512.
This may not be easily solvable. However, having 1000 classes for semantic segmentation is very rare I guess, so this may not be an issue in practice.

In the PR implementing this changes I mentioned that in my experience I never observed a drop in performance when using FP16 on vision models but that did not try LLM's:

I personally never observed a significant drop in performance when exporting vision models to CoreML in Float16 (Yolov8, UNets, etc.). I wasn't able to run the tests because of dependency issues but this would be great to know if a network suffers from poor performance in Float16, especially LLMs.

Recently, I needed to export to CoreML models integrating a LLM component such a Open-CLIP and UForm but I faced accuracy issues when using FP16 conversion. More precisely, this causes overflows in some layers resulting in an accuracy close to 0.
I was able to solve the issue by keeping the overflowing operators in FP32 precision and this mostly solved the issue (see the details in this issue).
Were you able to run the tests of the exporters library to know if this issue affects some models here?


IIFE on build with gulp or grunt

What do you think about wrapping your files content in a IIFE on the build process instead of the file themself???
Could be done with gulp-wrap adding something like this to your gulpfile
gulp.src("./src/*.js")
    .pipe(wrap('(function(){\n"use strict";\n<%= contents %>\n})();'))
    .pipe(gulp.dest("./dist"));

I assume the point is that you're guarding against the possibility that something leaks into the global namespace because one of the source files is not itself an IIFE and does not "use strict".
That's belt-and-suspenders thinking. It seems harmless, but might not be. Your imposing "use strict" over the entire concatenated contents. You'll break the code if someone (why? they might have reasons) needs a code block to execute in non-strict mode. Whether you like that or not, I've seen this cause bugs.
Personally, I think it is overkill + the non-strict risk and I wouldn't do it. I wonder what others think.

I prefer to use IIFE in my code explicitly. This allows me to choose when to use it and I can opt out on a file basis if I need to. Plus even when I do it for all files, I don;t need to process my files to run them. I like to do as little as possible to my files before running them in dev mode (unlike when I do a full optimize/build). Touching every file and updating them can be slow too (see ng-templates).
It's a good question, but I personally do not feel its worth it.


Make a small correction to sumstats files for GCST005362 and GCST012597

Background
These two summary statistics files were formatted by me (@eks-ebi) and submitted on behalf of the author. I have since noticed a small error in formatting that has introduced incorrect data in two rows of each file.
The original files contained non-standard indel notations for some alleles which could not be converted to normal nucleotide sequences. In order not to lose this information, I kept the raw alleles provided by the author as additional optional columns: orig_effect_allele and orig_other_allele, while the main effect_allele and other_allele columns have been formatted to extract only nucleotide-like strings using regex:[ACTG]+.
Current issue
2 rows in each file contained an "A" in the orig_effect_allele column that does not actually represent a nucleotide. So the extract operation has incorrectly left these in the effect_allele column:
GCST005362_buildGRCh37.tsv.gz (ADHD males):

GCST012597_buildGRCh37.tsv.gz (ADHD females):

Task

Delete the highlighted "A" from each row
Update the md5sum of the file
Check for any other downstream consequences (?)

@jdhayhurst This is not urgent, but could you help me with this when you have a free moment? It's presumably fairly straightforward, I just don't know exactly how to pinpoint a specific row and edit within a gzipped file.
Also wanted to check if this edit would have any flow-on effects other than changing the md5sum?

@jdhayhurst thanks! I think it would be quicker to do the sed option to edit the files in situ on the ftp if that sounds ok. I've just used zgrep to confirm that these rows are the only instances '55512437\tA' and '157521024\tA' in both files, so there shouldn't be any off-target changes.

Should sed work on a compressed file, or does it need to be unzipped first?
I did some reading on sed and tried this command on my own copy of one of the files (added -n and /p to print only the replaced lines), but it doesn't seem to change anything:
sed -n 's/55512437\tA/55512437\t/p' GCST005362_buildGRCh37.tsv.gz

yes, it needs to be uncompressed first. If you want to make an in situ edit use -i. Ensure you have a backup of the original before doing that.

@jdhayhurst I've finally made these edits and revalidated the edited files. I have them in my "homes". What is the best way to replace the old files without messing up the harmonisation etc.?

released. the harmonisation pipeline had already completed for these, so I deleted the harmonised data and requeued it with the new files you provided


esp32s3 in panic / reboot loop

I tried this lib with existing code that already has wifi enabled in the code.  I added the 1st 2 lines of my sketch:
#include <gpio_viewer.h>
GPIOViewer gpio_viewer;

and added as the last line of my setup():
  //init gpioviewer
  gpio_viewer.begin();

Here is the serial output with the errors:

Rebooting...
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4203be3a
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3808,len:0x44c
load:0x403c9700,len:0xbd8
load:0x403cc700,len:0x2a80
entry 0x403c98d0
Test V1.1

assert failed: tcpip_api_call IDF/components/lwip/lwip/src/api/tcpip.c:497 (Invalid mbox)

Backtrace: 0x40377e1a:0x3fceb9c0 0x4037b70d:0x3fceb9e0 0x403817f5:0x3fceba00 0x4201ae39:0x3fcebb30 0x4200a13d:0x3fcebb60 0x42009592:0x3fcebbb0 0x42002bdb:0x3fcebbd0 0x4200340e:0x3fcebc30 0x4200ef9a:0x3fcebc50

ELF file SHA256: fb9bc28191471c18

Are you using platformIO ?

No using Arduino 1.8.19
I notice that with your lib installed I do get an error at compile time: Error compiling for board ESP32S3 Dev Module
but it continues it upload.  Same exact compile and runtime errors when I use your sample code as the sketch

here is the board info:
BN: ESP32S3 Dev Module
VID: 303a
PID: 1001
SN: DC:DA:0C:45:0C:0C

Maybe it is related to this : https://github.com/thelastoutpostworkshop/gpio_viewer/pull/5

I am not using PlatformIO and I followed the Arduino instructions exactly

Try it on Arduino IDE version 2


Add standard library support

The standard library is special because the toolchain needs to be
rebuilt when checking out the tree.

Thanks


z index on custom node with drop down

Hi, Having an issue with a custom node with a drop down, it always appears behind other nodes, is there a way (and I've tried forcing it's z-index) to make a dropdown appear above another node?

Hello, do you mean the whole node appears behind other nodes? Or just the dropdown (weird)?

Just the drop down (screenshot showing issue attached)

)

I'm sorry but I don't understand the screenshot since I don't know your design.
Can you point out your nodes in the screenshot? Is the dropdown on the top a node of its own? If yes, do you have a node that only contains a dropdown? I can't see in the screenshot a dropdown being behind another node.
Although if your custom node is simply just a dropdown, and that node was created before another one, then it'll be behind it (the order of the rendering is the order of addition).

Ok, lets see if I can explain the picture, the "not started" and "in dev" are Custom node (type1, both are inline edit hence the pencil icon) the permission is a 2nd custom node type (in it's collapsed state it is fine as just the editor / text part shows) however in the expanded (as shown) to allow the user to select which permission(s) are required, the list is shown behind the "in dev" node. HTH (I'll look at the order they are added and see If I can use that to help)

I can solve this, as you said by ensuring I add the permission node after the 2nd "state" node (i.e. add the permission custom node after the "in dev" state node. I think I can work with this for the POC. Thanks.

Glad it helps.
I am still thinking of a better way to order items, so rest assured that this isn't a final "solution".


fix files.json parsing.

I think that one line fix works better and its very easy to update/maintain if upstream change the files.json again.

This is already handled by #29 which makes it order independent for future updates.


Automatic events discovery

As a part of #77 we should think about how events the user can subscribe to should be exposed. I suggest the following: put event names in either package.json or named export of the main plugin file and load them with utils/architect.

Please note that this issue is tightly coupled with both #43 (same discovery logic) and #39 (since event names will be used in the UI they need to be localisable).


no Higher Order Functions exercise

Describe your problem and - if possible - how to reproduce it
In following exercise I'm forced to write higher order arrow functions with map, filter and reduce without knowing anything about them. This is pretty weird.
Add a Link to the page with the problem
https://learn.freecodecamp.org/javascript-algorithms-and-data-structures/es6/write-higher-order-arrow-functions

duplicate of #14903

Thank you for reporting this issue.
This is a standard message notifying you that this issue appears to be very similar to issue #14903, so I am closing it as a duplicate.
If you think I’m wrong in closing this issue, please reopen it and add further clarification. Thank you, and happy coding.

From: Tom<EMAIL_ADDRESS>Sent: Friday, July 27, 2018 2:09:35 PM
To: freeCodeCamp/freeCodeCamp
Cc: Subscribed
Subject: Re: [freeCodeCamp/freeCodeCamp] no Higher Order Functions exercise (#17849)
Thank you for reporting this issue.
This is a standard message notifying you that this issue appears to be very similar to issue #14903https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FfreeCodeCamp%2FfreeCodeCamp%2Fissues%2F14903&data=02|01||0272cbf14abb40ad79df08d5f3e3baef|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636683081765820840&sdata=QglHdYY%2Fu3T9zIULD1dzNlIVm7fgGEIJr123nFUoEMU%3D&reserved=0, so I am closing it as a duplicate.
If you think I’m wrong in closing this issue, please reopen it and add further clarification. Thank you, and happy coding.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FfreeCodeCamp%2FfreeCodeCamp%2Fissues%2F17849%23issuecomment-408481236&data=02|01||0272cbf14abb40ad79df08d5f3e3baef|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636683081765820840&sdata=VNfNikLigJmQnroNzoC%2Bbo3B8strOETqSMyz%2B0EXDQs%3D&reserved=0, or mute the threadhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAF-4BVC8tkd6VFBobcfwY44V5WaTSnI9ks5uK0lPgaJpZM4VJaxF&data=02|01||0272cbf14abb40ad79df08d5f3e3baef|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636683081765820840&sdata=oFPO45MYb9ID2KfbHxs6nciQ%2BPFktFl6%2BE0S%2FVqMFHM%3D&reserved=0.


feat: import faucet into finschia-js

This PR import faucet into finschia-js.
The faucet version is from https://github.com/cosmos/cosmjs/commit/287278004b9e6a682a1a0b1664ba54646f65a1a0
Description

This PR imports a cosmjs/faucet into finschia-js
Motivation and context

We will need to add some original modules to the faucet in the future.
How has this been tested?

Please run the Finschia chain first, and then refer to the README in the packages/faucety.
Notice: This PR does not fix the Dockerfile, so please run the command locally.
Screenshots (if appropriate):
Checklist:

[ ] I have added a relevant changelog to CHANGELOG.md.
[ ] I have added tests to cover my changes.
[ ] I have updated the documentation accordingly.

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


Multiple plot windows requires FILO

In a script, say we run three plot commands each in a separate figure().
If the last call in the script is to show() the figures, the script blocks allowing examination of the figures, good. To end the script we close down the figure windows; if the order of shutdown is anything other than first in last out then the script crashes with a segfault.
Close 3, close 2, close 1 : script terminates quietly. Also close 2, close 3, close 1 is good.
Close 1 then 2,3 : segfault. Close 2, 1, 3 : segfault.
It may only be an inconvenience, but perhaps indicates other things not terminating properly.

What happens if you try the same thing in Python (with the same backend)?

Same thing, segmentation fault.
Example Python code for test:
import matplotlib.pyplot as plt
a = [1,2,3,4,5]
plt.figure(1)
plt.plot(a)
plt.figure(2)
plt.plot(a)
plt.figure(3)
plt.plot(a)
plt.show()

If it happens in Python, then it is a Matplotlib bug and you should report it there.


Can't run the evaluation script in the point 2 of the documentation for Reaching and Grasping Evaluation

I'm trying to run the evaluation script in the point 2 of the documentation for Reaching and Grasping Evaluation
When running the script
bash scripts/eval/reach_and_grasp/perobj.sh

I get the following error
Traceback (most recent call last):
  File "/home/ros/NGDF/OMG-Planner/omg_bullet/panda_scene.py", line 109, in main
    scenes = env.get_scenes(hydra_cfg)
  File "/home/ros/NGDF/OMG-Planner/omg/../omg_bullet/envs/acronym_env.py", line 493, in get_scenes
    with open(
FileNotFoundError: [Errno 2] No such file or directory: '/home/ros/NGDF/scripts/eval/reach_and_grasp/../../../data/../data/object_rotations.csv'

Where do I get the data/object_rotations.csv ?

Hi Pau, thank you for raising this issue -- I've updated the instructions in the README here to include a link to the missing file, here it is as well: object_rotations.csv

Thanks ! That fixed that error but Now after fixing a few hardcoded paths ( PR coming) I get the following error:
Traceback (most recent call last):
  File "/home/ros/NGDF/OMG-Planner/omg_bullet/panda_scene.py", line 125, in main
    info = planning_scene.step(category=category, pc_dict=pc_dict, viz_env=env)
  File "/home/ros/NGDF/OMG-Planner/omg/core.py", line 565, in step
    plan = self.planner.plan(
  File "/home/ros/NGDF/OMG-Planner/omg/planner.py", line 928, in plan
    info_t = self.optim.optimize(self.traj, force_update=True, tstep=t + 1)
  File "/home/ros/NGDF/OMG-Planner/omg/optimizer.py", line 137, in optimize
    cost, grad, info = self.cost.compute_total_loss(traj)
  File "/home/ros/NGDF/OMG-Planner/omg/cost.py", line 587, in compute_total_loss
    "grasp": traj.goal_cost,
AttributeError: 'Trajectory' object has no attribute 'goal_cost'

Hi Pau, you are right that self.info shouldn't be empty; however, I do not have an empty self.info when I execute the script.
The first line that you referenced is only executed for baseline methods that use Contact GraspNet (see this line above it).
The second line should be executed when running the NGDF evaluation. info_t is returned by the optimization and then appended to self.info. Is it possible that in your debugging, the code execution was still in the first loop, so self.info was empty before the first info_t was appended?
It does seem that you are on the correct commit for OMG-Planner, so that is unlikely to be the issue. If you want to share the modifications you made to get the code running for you, I can take a look, thank you.

Do you have in the standard error the following meesages?
Unknown tag "contact" in /robot[@name='panda']/link[@name='panda_leftfinger']
Unknown tag "contact" in /robot[@name='panda']/link[@name='panda_rightfinger']

I think the problem might come from there.


Add FAQs to main page

See mockup
For more context see the internal discussion

We decided for a different design


is 'Get Started' script still working?

Describe the bug
I'm just trying to run with most basic setup which is 10 lines of html. Camera opens but no object is shown on the marker. There is a 'markersAreaEnabled :false' text at the bottom. On the comment section of youtube video lots of people encountered same problem. What am I missing here?
To Reproduce
Just wrote the sample 10 line code and opened my browser.
Expected behavior
Same behavior as in youtube video
Screenshots
https://ibb.co/Qfb4gw3
Smartphone (please complete the following information):

Device: [iPhone6s+]
OS: [iOS11.3]
Browser [safari]

Adding console logs here:
Warning: THREEx.ArMarkerControls: 'markersAreaEnabled' is not a property of this material.
Error: Failed to load resource: jeromeetienne.github.io/AR.js/data/data/camera_para.dat:1 net::ERR_BLOCKED_BY_CLIENT

Hi, you are right, thanks for that!
I see that is not working for me too. I think it uses an old version of aframe and also ar.js. Also, it uses  entity that last time I saw it, it was not working (better use a static camera and a marker as a separate entity).
Tomorrow I will update this :)

It works for me, if I update the versions.
But it does not show the entire animation claimed. (Refer to the image)

Source code here:
https://codepen.io/commentatorboy/pen/BbXvPW

@commentatorboy I am using exactly the same code that you have shared and still cant see anything on the marker. Can it be related to IOS?
@nicolocarpignoli  Can you tell me when you guys update the code?

If you are using Chrome on iOS, it won't work, it is a known issue. Try with Safari instead. This afternoon I will probably update that code on Readme, anyway

For now, if you need a quick working version (again, in ios only on safari), try with this:
<script src="https://aframe.io/releases/0.9.0/aframe.min.js"></script>
<script src="https://cdn.rawgit.com/jeromeetienne/AR.js/1.6.2/aframe/build/aframe-ar.js"></script>
<body style='margin : 0px; overflow: hidden;'>
	<a-scene embedded arjs='sourceType: webcam;'>
                <a-marker preset='hiro'>
                    <a-box position='0 0.5 0' material='opacity: 0.5;'></a-box>
                 </a-marker>
                 <a-entity camera> </a-entity>
	</a-scene>
</body>

In here, I used a-entity static camera and a-marker instead of a-marker camera. Although I don't believe this is the problem in your case, try with this. Let us know if it works so we can understand better

Last example works like charm thank you!
Off topic: When I wrap a-scene with html elements in body it is not working properly. Is there a way to eliminate this because I'm trying to integrate it to my React project.

It is impossible to answer to this in general. If you have a specific issue, please provide an example. On a separate issue, this one only for the 'get started' bug :)


Proposed Element: Interagency Agreements

While financial systems record Interagency Agreements (IAAs), they are not provided in public information on government spend. It would be interesting to see IAA data, especially for shared services.

This is a really interesting idea @JeremyArensdorf. What kind of data would be most interesting to you and do you have a sense of what type of information is already recorded in agency financial systems? It seems like the trickiest part could be IAAs that don't conform to the same rules of the award id.

Thanks, Kaitlin. It would be good to have a Contracting Officer/Contract Specialist weigh in on what they enter into the system now, but since it is a financial obligation/transfer, I would assume a number of relevant data points are entered that would be similar to a contract. It would be interesting to see the dollar amount, the awarding agency, the agency recipient, the purpose of the IAA (product/services description), period of performance, etc. Ultimately, it would be very interesting to see how that money flows from the awarding agency to the shared services center, and then if it flows further down to a contractor or remains with the government.