Rails 5.1 deprecation warnings

With the latest Rails 5.1.0.beta1 I get the following deprecation warnings:

DEPRECATION WARNING: The behavior of changed_attributes inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after save returned (e.g. the opposite of what it returns now). To maintain the current behavior, use saved_changes.transform_values(&:first) instead.

DEPRECATION WARNING: The behavior of attribute_changed? inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after save returned (e.g. the opposite of what it returns now). To maintain the current behavior, use saved_change_to_attribute? instead.

I traced this back to having a counter culture on my model (unfortunately I don't have an exact backtrace, but when I remove the counter the deprecation warning is gone). According to the deprecation message it looks like the "fix" is easy (just swap out some method calls?).

Backtrace for changed_attributes:
DEPRECATION WARNING: The behavior of `changed_attributes` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method afte
r `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_changes.transform_values(&:first)` instead. (called from block in accept_event_applications at /U
sers/markus/svn/caseman-events/app/models/event.rb:257)
/Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/attribute_methods/dirty.rb:103:in `changed_attributes'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/counter_culture-1.3.1/lib/counter_culture/counter.rb:184:in `previous_model'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/counter_culture-1.3.1/lib/counter_culture/extensions.rb:111:in `block (2 levels) in _update_counts_after_update'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/counter_culture-1.3.1/lib/counter_culture/extensions.rb:108:in `each'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/counter_culture-1.3.1/lib/counter_culture/extensions.rb:108:in `block in _update_counts_after_update'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/counter_culture-1.3.1/lib/counter_culture/extensions.rb:80:in `_wrap_in_counter_culture_active'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/counter_culture-1.3.1/lib/counter_culture/extensions.rb:107:in `_update_counts_after_update'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:413:in `block in make_lambda'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:235:in `block in halting_and_conditional'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:511:in `block in invoke_after'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:511:in `each'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:511:in `invoke_after'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:132:in `run_callbacks'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:825:in `_run_update_callbacks'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/callbacks.rb:344:in `_update_record'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/timestamp.rb:107:in `_update_record'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/persistence.rb:555:in `create_or_update'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/callbacks.rb:336:in `block in create_or_update'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:131:in `run_callbacks'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:825:in `_run_save_callbacks'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/callbacks.rb:336:in `create_or_update'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/persistence.rb:125:in `save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/validations.rb:44:in `save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/attribute_methods/dirty.rb:35:in `save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:308:in `block (2 levels) in save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:384:in `block in with_transaction_returning_status'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/connection_adapters/abstract/database_statements.rb:225:in `block in transaction'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/connection_adapters/abstract/transaction.rb:186:in `within_new_transaction'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/connection_adapters/abstract/database_statements.rb:225:in `transaction'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:210:in `transaction'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:381:in `with_transaction_returning_status'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:308:in `block in save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:323:in `rollback_active_record_state!'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:307:in `save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/suppressor.rb:42:in `save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/persistence.rb:263:in `update_attribute'

Backtrace for attribute_changed?:
DEPRECATION WARNING: The behavior of `attribute_changed?` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the me[90/4918]
r `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_change_to_attribute?` instead. (called from block in accept_event_applications at /Users/markus/s
vn/caseman-events/app/models/event.rb:257)
/Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/attribute_methods/dirty.rb:225:in `attribute_changed?'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activemodel-5.1.0.beta1/lib/active_model/attribute_methods.rb:384:in `user_id_changed?'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/counter_culture-1.3.1/lib/counter_culture/extensions.rb:114:in `block (2 levels) in _update_counts_after_update'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/counter_culture-1.3.1/lib/counter_culture/extensions.rb:108:in `each'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/counter_culture-1.3.1/lib/counter_culture/extensions.rb:108:in `block in _update_counts_after_update'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/counter_culture-1.3.1/lib/counter_culture/extensions.rb:80:in `_wrap_in_counter_culture_active'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/counter_culture-1.3.1/lib/counter_culture/extensions.rb:107:in `_update_counts_after_update'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:413:in `block in make_lambda'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:235:in `block in halting_and_conditional'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:511:in `block in invoke_after'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:511:in `each'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:511:in `invoke_after'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:132:in `run_callbacks'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:825:in `_run_update_callbacks'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/callbacks.rb:344:in `_update_record'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/timestamp.rb:107:in `_update_record'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/persistence.rb:555:in `create_or_update'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/callbacks.rb:336:in `block in create_or_update'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:131:in `run_callbacks'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activesupport-5.1.0.beta1/lib/active_support/callbacks.rb:825:in `_run_save_callbacks'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/callbacks.rb:336:in `create_or_update'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/persistence.rb:125:in `save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/validations.rb:44:in `save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/attribute_methods/dirty.rb:35:in `save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:308:in `block (2 levels) in save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:384:in `block in with_transaction_returning_status'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/connection_adapters/abstract/database_statements.rb:225:in `block in transaction'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/connection_adapters/abstract/transaction.rb:186:in `within_new_transaction'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/connection_adapters/abstract/database_statements.rb:225:in `transaction'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:210:in `transaction'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:381:in `with_transaction_returning_status'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:308:in `block in save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:323:in `rollback_active_record_state!'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/transactions.rb:307:in `save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/suppressor.rb:42:in `save'
  /Users/markus/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.1.0.beta1/lib/active_record/persistence.rb:263:in `update_attribute'

Yeah I've been working on this. It's not super straightforward, unfortunately. But, hey, Rails 5.1 is only at its first beta, so I've got time, right? 😄

Sure, thanks for the update, just wanted to make sure all the info you need is here :-)

@doits this should be fixed in the 1.4.0 gem version.


data-test selectors are not stripped from colocated component templates

I noticed that not all data-test-* selectors are being stripped from my production build. It seems that the commonality among those that remain is that the selectors that remain are all from component templates that are using the new colocated component file structure (i.e. having the component.hbs file inside the app/component directory alongside the corresponding component.js file.

I honestly have no idea what to do about this.
@chancancode @rwjblue any clues?

I assume this is implanted as an AST transform? Sounds like that is not being run for some reason? What version of ember-cli-htmlbars?

we're still on v3 of htmlbars since we haven't dropped Node 6 support yet 🤔

I would think that it’s the app’s ember-cli-htmlbars version that matters in this case, but I’m not totally sure. @rwjblue?

I would assume that co-location wouldn't work at all then 🤔

@kpfefferle - What ember-cli-htmlbars version is your application using? There were a number of bugs in the implementation around AST plugins not running properly, but as far as I can tell all reported issues have been addressed and things are working properly with the latest release (v4.0.8 atm). If you are on the latest version, I'm happy to dig into a reproduction.

@rwjblue Our application is using<EMAIL_ADDRESS>I'll see if I can reproduce this with a new Octane app.

@kpfefferle any news on this?

@Turbo87 I can confirm I'm still seeing this issue when building our app for production. I haven't had the bandwidth to try and reproduce in a new sharable Octane app yet.

Please let us know, I'm very interested in figuring out what is going on here. There were absolutely bugs in the early 4.x series that caused AST plugins to not be ran properly, but as far as I can tell (from issues reported over there) they have all been addressed.

ran into this issue. anything I can to to get this moving along or is someone already digging into it?

a reproduction repository with instructions would be good :)

@Turbo87 will this work?
https://github.com/void-mAlex/test-selector-repro

I am experiencing this as well. All packages are on latest possible versions, except maybe some transitive dependencies.

This is still an issue with a brand new ember app today. I put some debuggers in @void-mAlex's reproduction (and a nearly identical one with a brand new app). All the options seem to be working, but https://github.com/simplabs/ember-test-selectors/blob/master/strip-test-selectors.js#L16 is never called.

I can confirm that StripTestSelectorsTransform.prototype.transform is not ever run for any of the colocated templates. I can reproduce it in https://github.com/rust-lang/crates.io too 😢
@rwjblue any ideas?

@Turbo87 Just wondering if there has been any progress on figuring this one out?

not from my side. I think it's a bug in the build pipeline somewhere, but not related to the implementation here.

ZOMG, I spent a while debugging this :sob:, and have a fix. Basically, what is happen (in order) is:

ember-cli-htmlbars's included hook runs, and does:
1a. gather all AST plugins registered as htmlbars-ast-plugin in the registry
1b. add babel-plugin-htmlbars-inline-precompile to the babel configuration
ember-test-selectors's included hook runs, and registers a new htmlbars-ast-plugin

Specifically, the babel config is already locked down before ember-test-selectors. I do not think this issue is related to colocation at all (I doubt this ever ran against inline compiled templates), but the fact that colocation happens to desugar into using inline templates (e.g. hbs) makes it much more common to care.
The simplest fix, is to ensure that ember-test-selectors runs before ember-cli-htmlbars, and I've confirmed that works when manually tweaked into void-mAlex/test-selector-repro. See https://github.com/simplabs/ember-test-selectors/pull/521.

FWIW, I'm working on adding some additional logging in ember-cli-htmlbars to make debugging things like this a bit easier: https://github.com/ember-cli/ember-cli-htmlbars/pull/547.


Not working for user accounts other than ID "0"

Package works great for the main Admin account. However, when trying to use this for other user accounts, I log in, and get presented with the "Specify your two-factor authentication option" screen, as expected.
However, when I then click on GoogleAuthenticator, I get a 500 error in console with the error below.
In my FortressUser2FASettings table, I only have an entry for User ID 0.
I'm going to try and work this out, but if you have any ideas?
Thanks!
{Message: "An error has occurred.",…}
ExceptionMessage
:
"This account has already setup GoogleAuthenticator"
ExceptionType
:
"System.UnauthorizedAccessException"
Message
:
"An error has occurred."
StackTrace
:
"   at Orc.Fortress.Controllers.TwoFactorSetupController.SetupGoogleAuth()
↵   at lambda_method(Closure , Object , Object[] )
↵   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass10.b__9(Object instance, Object[] methodParameters)
↵   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.Execute(Object instance, Object[] arguments)
↵   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken)
↵--- End of stack trace from previous location where exception was thrown ---
↵   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
↵   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
↵   at System.Web.Http.Controllers.ApiControllerActionInvoker.d__0.MoveNext()
↵--- End of stack trace from previous location where exception was thrown ---
↵   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
↵   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
↵   at System.Web.Http.Controllers.ActionFilterResult.d__2.MoveNext()
↵--- End of stack trace from previous location where exception was thrown ---
↵   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
↵   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
↵   at System.Web.Http.Dispatcher.HttpControllerDispatcher.d__1.MoveNext()"

The problem seems to be in Controllers.TwoFactorSetupController.SetupGoogleAuth() - this line
var user =  SignInManager.GetVerifiedUserId();
... always returns 0.

Thanks for reporting this one, wonder if its an issue with when we poke the userID into the table or when we pull it out via GetVerifiedUserId(). I suspect it will be at the point of saving to the table (probably using the admin id to create the entry rather than the one for the currently edited user from the front end at a guess. Will take a look.

Hi Pete
Thanks for coming back. I've tried to find a workaround, but wasn't able to come up with one. It seems that, when you show the selection form, and the subsequent POST to SetUpGoogleAuth(), when it tries to GetVerifiedUserId(), that always returns 0. I've tried to get the current User ID server side, without success. However, after the call to PostLogin, the correct UserID is returned (with the view name) so perhaps it could be passed in to the SetUpGoogleAuth action?
Cheers,
Tom.

Hello!
I was wondering whether you'd had chance to find a fix/update for this, or if I can do anything to help?
Thank you!
Tom.

Hi Tom,
Kyle has been take a look and I've got Ste assigned to it later this week. We are hoping to get it into a PR for Core so this package might not be needed anymore but that would require us awaiting a 7.7 release so we suspect we will get this package running too as a stop gap.
Watch this space.
Pete

I've experienced the same issue. If i hard code the id to replace GetVerifiedUserId  i still get tripped up on backoffice endpoint "PostVerify2FACode" which is returning "User is locked out". I suppose as it's not authenticated it can't reach this endpoint. Also, I can't locate this endpoint in the source.

Hi Pete, Kyle, Ste.
Any update on this issue? We've got a number of clients who are asking for 2FA, now that the EU GDPR legislation is close on the horizon. You've created such an elegant solution I'd rather not start from scratch...
If we can do anything to help, with either finding a work around of convincing UHQ to bake it in to 7.7, please let me know.
Thank you, Tom.

Hi @wr-dev and @Frosty2,
We are working on it this week/next. Hoping to have it sorted before Code Garden so you know (even if its just a PR into Core with the fix) but we will have something at least, ideally have it fixed but until we find the cause we can't promise it.
Also working on getting it into Core too :)
Cheers
Pete

Any updates @PeteDuncanson? Here to help if we can.

Any news on this one, @cssquirrel, @PeteDuncanson?
Thanks.

Hi guys,
We stopped work on this just before Code Garden as it was tweeted out that HQ had got this working in Core, why would we fix this if its in Core right? Turns out they haven't really, they have a chunk of code you can drop in and then set it up yourself which is not quite the same as a nice tidy package that does it all for you and supports you while you set it up. As a result we are warming this one back up so this package can have some legs until Core get it in there properly once and for all. Its been a busy few weeks since getting back from Code Garden but I've got some time scheduled in for fixing this one next week.
Cheers
Pete

Did you get the time to look into it last week, @PeteDuncanson?
Appreciate your work.

Yes we did, hit a snag and are awaiting confirmation on if its a "fixable" thing or not.

Did you make any progress as to whether it is fixable?
Thanks for your work!

Holidays and babies stopped play on this one. All back on board now and playing catch up so will warm this one back up. Thanks for the prod (keep them coming)

Any news one this one? In a similar situation of looking for 2FA, but only working for the admin user is a showstopper for us :(

Just a heads up for those following this one. We've rewritten the way the login works to get around the issue that was stopping us and this seems to have worked. Doing some final testing and then we hope to get this out to you. Sorry for the hold up but thanks for the interest. Working hard on trying to get it out the door so you can get it installed :)

Great news Pete, thanks for the update and the hard word. Still actively following, looking forward to testing and deploying!

@PeteDuncanson when we can expect this fix available? I am still facing the same issue.

@PeteDuncanson Any news?

Hi All,
Just to update you we have found the cause of the issue living somewhere in the integration with Umbraco and ASP.Net Owin identity where something is failing.
We have opened an support issue with umbraco to try to find the root cause of this http://issues.umbraco.org/issue/U4-10620
Thanks
Stephen

Thanks for the work on this very promising package.
I've just tested on 7.6.11 and I am getting the same issue.
Does SignInManager.GetVerifiedUserId() only work if the useris logged in? That would explain why it's possible to generate but not verify.
Thanks again.

Thanks for the test Harvey, will take another look asap.


🚀 Feature: SearchPage component supports custom initial state

🔖 Feature description
We would like to be able to render the SearchPage route with custom initial state. The SearchContextProvider can be initialized with a custom search config initial state. However, in the SearchPage component, the SearchContextProvider is used, but we're unable to pass an initial state.
🎤 Context
I would like to be able to customize the SearchPage to have a default page limit. I found a workaround, but I believe it would be this simple feature would be beneficial to others.
✌ Possible Implementation
plugins/search/src/components/SearchPage/SearchPage.tsx
export const SearchPage = (prop) => {
  const outlet = useOutlet();

  return (
    <SearchContextProvider initialState={prop.initialState}>
      <UrlUpdater />
      {outlet}
    </SearchContextProvider>
  );
};

👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

Letting @backstage/discoverability-maintainers decide whether it's worth exposing this, but I'd lean towards sticking to the existing way to customize the search page.

I would recommend setting the default limit via app-config.yaml, what do you think?

@camilaibs That definitely works. Is it possible to do it via app-cnfogi.yaml right now? I might have missed this in the docs.

@rikez currently it is possible on the backend side as per this pull request, but the configuration is not consumed on the frontend side. We would appreciate it if you could contribute with us by making this improvement 🙂

@camilaibs Sounds good to me. I'm willing to contribute.

@camilaibs Sounds good to me. I'm willing to contribute.

Thanks a lot and don't hesitate to ping us whenever you need support 🙌🏻

Hi @rikez, just checking to see if you've had the opportunity to start working on this? Feel free to ping us on this issue in case you need some support.

Hey @camilaibs, I haven't started, but it's on my radar to get this done this week.

Perfect, thanks again for helping us 🙌🏻

@camilaibs Can this be closed?

@camilaibs Can this be closed?

Yes! Thanks again for your help on this issue 🙌🏻


Glossary and Concepts Section

To be reviewed w/ @bobbilee19 for validity before slating for work.
Kirah to provide a list (with input from OSE) of Concepts/Terms to know
Once that is complete, DevRel and OSE work together to complete and validate the content.
Aim for approval on this page by EOW Friday March 10. List of concepts/terms by EOW Friday 17 March.

Here is the file for it, https://github.com/TBD54566975/docs-sitemap/blob/main/term-glossary.md, but soon I'll have a HackMD file to collaborate ideas listed here in the READMe

Here is the HackMD file @kirahsapong https://hackmd.io/Y-EgFK51RH2oon3dpEPbIA


No text or image is shown.

Hi.
I have included the main .js file and it works, except that
I can see the CSS animation and colors correctly, but no text or image are shown with neither of the templates included.

I was missing the /themes/language css file. thx


add tocaro for Mac(Latest version)

If there’s a checkbox you can’t complete for any reason, that's okay, just explain in detail why you weren’t able to do so.
After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if adding a new cask:

[x] Named the cask according to the token reference.
[x] brew cask install {{cask_file}} worked successfully.
[x] brew cask uninstall {{cask_file}} worked successfully.
[x] Checked there are no open pull requests for the same cask.
[x] Checked the cask was not already refused in closed issues.
[x] Checked the cask is submitted to the correct repo.

Travis CI detected a few errors that should have been caught by audit and style --fix commands. I’ve already fixed them.
Next time you make a submission, please double check those before ticking the boxes. We need to know it the error messages aren’t clear enough — which made you miss them — and we need to improve them. Alternatively, if no error messages were shown it means there’s something wrong we need to fix.
It’s important to ensure those commands work correctly as they save both CI time and maintainer time.
Thank you for the contribution!

Thank you for your contribution.


ansible-compat: fix build by patching tests

Ref: https://github.com/ansible/ansible-compat/pull/420
Hydra: https://hydra.nixos.org/build/283196918/log

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@ofborg eval

@ofborg build

@ofborg build python3Packages.ansible-compat

Is this PR still relevant after https://github.com/NixOS/nixpkgs/pull/369664?

ansible-compat builds for me on master, thank you for the ping. Let me close this PR.


Removed unnecessary pipe escape

It seems like https://github.com/squidfunk/mkdocs-material handles |s in code blocks automatically so there's no need to escape them for table columns.

Thank you!


Fix playback behavior in NativeAudioSource

The sequel to pull #1456, this request fixes two issues brought up in that thread. I would love to have amended that request, but I didn't feel like spending the time to figure out how.
Anyway, the big issue is that sound could potentially play despite playing being false. Besides that, one of the comments was incorrect.

I heard from the developer who complained about sound playback, said it’s working great for him again. Thanks!


Vim9: no error for wrong type in list of variables used to iterate over list of lists

Describe the bug
In Vim9 script, no error is given when we specify a wrong type in a list of variables used to iterate over a list of lists.
To Reproduce
Run this shell command:
vim -Nu NONE -S <(cat <<'EOF'
    vim9script
    def Func()
        var d: dict<number> = {a: 1, b: 2}
        for [k: job, v: job] in d->items()
        endfor
    enddef
    Func()
EOF
)

No error is given.
Expected behavior
A type mismatch error is given:
E1012: Type mismatch; expected job but got string

Possibly at compile time; at least at runtime.
Because neither k, nor v, are jobs; they are respectively strings and numbers.
vim9script
def Func()
    var d: dict<number> = {a: 1, b: 2}
    for [k: job, v: job] in d->items()
        echo [k->typename(), v->typename()]
    endfor
enddef
Func()

['string', 'number']
['string', 'number']

Environment

Vim version: 8.2 Included patches: 1-3107
OS: Ubuntu 20.04.2 LTS
Terminal: XTerm(353)

Additional context
If we iterate over a single variable, and we specify a wrong type, then an error is correctly given at compile time:
vim9script
def Func()
    var d: dict<number> = {a: 1, b: 2}
    for k: job in d->keys()
    endfor
enddef
defcompile

E1012: Type mismatch; expected job but got string

At the script level, the exact same code correctly gives errors:
vim9script
var d: dict<number> = {a: 1, b: 2}
for [k: job, v: job] in d->items()
endfor

E1012: Type mismatch; expected job but got string
E1012: Type mismatch; expected job but got number


Support importing existing schema-registry clusters (fixes #75)

Replicate change that was done on kafka clusters to support import of schema-registry clusters.
As a consequence, id for a schema-registry cluster should be in the form /

Looks good! thanks @jfgaretSymphony !


Clarity on relative savings interpretation

In the reporting of relative uncertainty, there is a common confusion over the meaning of the result. For example, when we report a savings like this:
Relative savings: 30%
Relative savings uncertainty: 10%
We are saying that the savings is 30% +- 3% (30%*10% = 3%). I.e. the relative savings uncertainty is uncertainty as a percentage of the savings.
However, this can be easily confused to mean the savings is 30% +- 10%. This is the misinterpretation that the relative uncertainty is a percentage point value.
We are interested in the uncertainty as a percentage of savings because this is used for our thresholds of acceptability for our savings calculations. This value should be included in the reports we write as part of our evidence that our savings calcs are valid.
However, the uncertainty in terms of percentage points is also useful and important. In reports, we should list the uncertainty of the savings in percentage points, because this is a lot more intuitive.
I suggest creating a method that calculates the uncertainty of the savings in terms of percentage points and calling it "relative_uncertainty_percent_points". This would be useful for report writing and would be more clarifying.

Again I think this is a methodology issue and should be discussed with @krysh1

@equalaction That being said... the current lib allows us to create new savings calcs for notebooks by subclassing and overriding the _savings hook method.
If its a matter for specific reporting then I think its best to do any extra work scaling numbers in a client application, spreadsheet or jupyter notebook and not rely on this library to directly output report schemas

To be clear you want us to add:
relative_uncertainty_percent_points = relative_savings*relative_psu
?

Yes @krysh1, that is my suggestion

Ok, I see... If we are just appending a new calc at the end of the pipeline this is not a big lift... i just have to assure things are backwards compatible as much as possible.

To be clear it's not as small a lift as we think -- we have people trying to use this library right now (max you included), so I think the better option would be to add this calc into the notebooks for now. In few a weeks when we have new code deployed we can come back to something like this that would necessitate schema chances.


204 status returns non-zero content-length

The full example in the quickstart of the docs show the response to a 204 status should be a zero content length, I'm unable to reproduce this with the latest version of flask & flask-restful.
The following minimal python file will reproduce the issue:
from flask import Flask
from flask_restful import Api, Resource

app = Flask(__name__)
api = Api(app)

class Test(Resource):
    def get(self):
        return '', 204

api.add_resource(Test, '/test')

if __name__ == '__main__':
    app.run(debug=True)

Running and querying with curl I get the following:
$ curl -v http://<IP_ADDRESS>:5000/test
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 5000 (#0)
> GET /test HTTP/1.1
> Host: <IP_ADDRESS>:5000
> User-Agent: curl/7.54.0
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 204 NO CONTENT
< Content-Type: application/json
< Content-Length: 3
< Server: Werkzeug/0.14.1 Python/2.7.14
< Date: Mon, 12 Feb 2018 12:20:57 GMT
<
* Closing connection 0

I've started with a fresh venv in Python 2.7.14 on macos, the following is my pip freeze:
aniso8601==2.0.0
click==6.7
Flask==0.12.2
Flask-RESTful==0.3.6
itsdangerous==0.24
Jinja2==2.10
MarkupSafe==1.0
pytz==2018.3
six==1.11.0
Werkzeug==0.14.1

I've also checked out this project and wrote the following test case for inclusion in tests/test_api.py which reproduces the bug when asserting the content-length line (again still on Python 2.7.14):
    def test_handle_api_204(self):
        app = Flask(__name__)
        api = flask_restful.Api(app)

        class Test(flask_restful.Resource):
            def get(self):
                return '', 204

        api.add_resource(Test(), '/api', endpoint='api')
        app = app.test_client()

        resp = app.get("/api")
        assert_equals(resp.status_code, 204)
        assert_equals(resp.data.decode(), '')
        assert_equals(resp.headers['Content-Length'], 0)

I'm digging deeper, the following issue and pull request on Werkzeug that were merged in 0.14 should have fixed the issue:
https://github.com/pallets/werkzeug/issues/1025
https://github.com/pallets/werkzeug/pull/1026
FWIW, I'm unable to reproduce the issue with Flask itself:
from flask import Flask
app = Flask(__name__)

@app.route('/test')
def test():
    return '', 204

curl -v http://<IP_ADDRESS>:5000/test
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 5000 (#0)
> GET /test HTTP/1.1
> Host: <IP_ADDRESS>:5000
> User-Agent: curl/7.54.0
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 204 NO CONTENT
< Content-Type: text/html; charset=utf-8
< Content-Length: 0
< Server: Werkzeug/0.14.1 Python/2.7.14
< Date: Mon, 12 Feb 2018 13:01:54 GMT
<
* Closing connection 0

The issue is not present if using Werkzeug 0.13 with flask-restful, only Werkzeug 0.14+.

I can confirm the problem is also present on the latest versions: Flask 0.12.2, flask-restful 0.3.6 and werkzeug 0.14.1.
The problem is that some browsers are waiting for the 3 bytes and requests are running into a timeout. For any reason they "ignore" the 204 status code.
class TestHandler(BaseResource):
    def get(self):
        return '', 204

curl -v http://<IP_ADDRESS>:5000/test
*   Trying <IP_ADDRESS>...
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 5000 (#0)
> GET /http_error HTTP/1.1
> Host: <IP_ADDRESS>:5000
> User-Agent: curl/7.47.0
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 204 NO CONTENT
< Content-Type: application/json
< Content-Length: 3
< Access-Control-Allow-Origin: *
< Server: Werkzeug/0.14.1 Python/3.5.2
< Date: Wed, 07 Mar 2018 12:38:54 GMT
<
* Closing connection 0

Opened a PR

I've asked werkzeug maintainers to release a minor version containing a fix for this issue.

Hi @ikonst! Do you have any update regarding the minor version?

werkzeug 0.15.1 is out!   https://pypi.org/project/Werkzeug/0.15.1/


refresh_signature crash when source collection is missing

It is probably acceptable to crash out loud in that situation, but at least the job should continue refreshing the remaining collections before exiting with an error

I wrote that without looking at the code 🤦 it's already the case


MAE different betweern jvm-package on spark and python package

I had trained two xgboost models with spark and python package (both 0.80) which run using same train dataset and test dataset and I provide them the same params.
param = {
'booster': 'gbtree',
'objective': 'reg:linear',
'eval_metric': 'mae',
'eta': 0.020209749520997883,
'num_round': 1200,
'min_child_weight' : 4.016289581092819,
'gamma' : 0.4275434126320313,
'lambda' : 2.9996223584471635,
'colsample_bytree': 0.7078453564565381,
'subsample': 0.7485739182368198,
'max_depth': 10,
'seed': 20190129,
'silent': 1,
'missing':np.NaN,
'nthread':4
}
But the mae of them are different.
python:0.20
jvm-package:0.22.
Could you tell me why?

Could you please try lastest XGBoost and don't set the silent parameter?

Could you please try lastest XGBoost and don't set the silent parameter?

Thanks for reply!
I have set tree_method 'approx' and updater 'grow_histmaker,prune' and get nearly same mae

@SongBiu The jvm package and Python package have slightly different ways of specifying parameters.  For example num_round is not a parameter in Python, nor is missing.

Using the latest XGBoost on Python will give you a warning when some parameters are not used provided you don't set the silent parameter.

@SongBiu The jvm package and Python package have slightly different ways of specifying parameters. For example num_round is not a parameter in Python, nor is missing.

Using the latest XGBoost on Python will give you a warning when some parameters are not used provided you don't set the silent parameter.

I will try, Thanks!

Using the latest XGBoost on Python will give you a warning when some parameters are not used provided you don't set the silent parameter.

[12:21:36] WARNING: /workspace/src/objective/regression_obj.cu:167: reg:linear is now deprecated in favor of reg:squarederror.
[12:21:36] WARNING: /workspace/src/gbm/gbtree.cc:72: DANGER AHEAD: You have manually specified updater parameter. The tree_method parameter will be ignored. Incorrect sequence of updaters will produce undefined behavior. For common uses, we recommend usingtree_method parameter instead.
[12:21:36] WARNING: /workspace/src/learner.cc:328:
Parameters: { missing, num_round } might not be used.

Using the latest XGBoost on Python will give you a warning when some parameters are not used provided you don't set the silent parameter.

I would like to know what updater can use when I train model with python package and cli on yarn?

Updaters are the same across bindings.

Just that we recommend using tree_method instead of updater.  tree_method is a preconfigured sequence of updaters.

The missing is a DMatrix parameter.

Updaters are the same across bindings.

Thanks!
Due to models produced by two bindings are different with updater 'grow_colmaker,prune', I'm wonder if there is other params which are default value different across bindings except updater
and tree_method?

You can call Booster.save_config on Python to get a JSON doc of internal parameters.  I'm not sure about the Scala.

You can call Booster.save_config on Python to get a JSON doc of internal parameters. I'm not sure about the Scala.

I train a model use
param = {
        'booster': 'gbtree',
        'objective': 'reg:linear',
        'eval_metric': 'mae',
        'updater': 'grow_histmaker,prune',
        'eta': 0.020209749520997883,
        'num_round': 1,
        'min_child_weight' : 4.016289581092819,
        'gamma' : 0.4275434126320313,
        'lambda' : 2.9996223584471635,
        'colsample_bytree': 0.7078453564565381,
        'subsample': 0.7485739182368198,
        'max_depth': 10,
        'seed': 20190129,
        'silent': 1,
        'missing':np.NaN,
        'nthread':4
}
bst = xgb.train(param, dtrain, param['num_round'], watchlist, verbose_eval=1,early_stopping_rounds=10)

But the result that print when I use save_config is
{
    "learner": {
        "generic_param": {
            "enable_experimental_json_serialization": "0",
            "gpu_id": "-1",
            "gpu_page_size": "0",
            "n_gpus": "0",
            "n_jobs": "0",
            "nthread": "0",
            "random_state": "0",
            "seed": "0",
            "seed_per_iteration": "0",
            "validate_features": "0",
            "validate_parameters": "0"
        },
        "gradient_booster": {
            "gbtree_train_param": {
                "num_parallel_tree": "1",
                "predictor": "auto",
                "process_type": "default",
                "tree_method": "auto",
                "updater": "grow_colmaker,prune",
                "updater_seq": "grow_colmaker,prune"
            },
            "name": "gbtree",
            "specified_updater": false,
            "updater": {
                "grow_colmaker": {
                    "colmaker_train_param": {
                        "opt_dense_col": "1"
                    },
                    "train_param": {
                        "alpha": "0",
                        "cache_opt": "1",
                        "colsample_bylevel": "1",
                        "colsample_bynode": "1",
                        "colsample_bytree": "1",
                        "default_direction": "learn",
                        "enable_feature_grouping": "0",
                        "eta": "0.300000012",
                        "gamma": "0",
                        "grow_policy": "depthwise",
                        "interaction_constraints": "",
                        "lambda": "1",
                        "learning_rate": "0.300000012",
                        "max_bin": "256",
                        "max_conflict_rate": "0",
                        "max_delta_step": "0",
                        "max_depth": "6",
                        "max_leaves": "0",
                        "max_search_group": "100",
                        "min_child_weight": "1",
                        "min_split_loss": "0",
                        "monotone_constraints": "()",
                        "refresh_leaf": "1",
                        "reg_alpha": "0",
                        "reg_lambda": "1",
                        "sketch_eps": "0.0299999993",
                        "sketch_ratio": "2",
                        "sparse_threshold": "0.20000000000000001",
                        "split_evaluator": "elastic_net,monotonic",
                        "subsample": "1"
                    }
                },
                "prune": {
                    "train_param": {
                        "alpha": "0",
                        "cache_opt": "1",
                        "colsample_bylevel": "1",
                        "colsample_bynode": "1",
                        "colsample_bytree": "1",
                        "default_direction": "learn",
                        "enable_feature_grouping": "0",
                        "eta": "0.300000012",
                        "gamma": "0",
                        "grow_policy": "depthwise",
                        "interaction_constraints": "",
                        "lambda": "1",
                        "learning_rate": "0.300000012",
                        "max_bin": "256",
                        "max_conflict_rate": "0",
                        "max_delta_step": "0",
                        "max_depth": "6",
                        "max_leaves": "0",
                        "max_search_group": "100",
                        "min_child_weight": "1",
                        "min_split_loss": "0",
                        "monotone_constraints": "()",
                        "refresh_leaf": "1",
                        "reg_alpha": "0",
                        "reg_lambda": "1",
                        "sketch_eps": "0.0299999993",
                        "sketch_ratio": "2",
                        "sparse_threshold": "0.20000000000000001",
                        "split_evaluator": "elastic_net,monotonic",
                        "subsample": "1"
                    }
                }
            }
        },
        "learner_model_param": {
            "base_score": "0.500000",
            "num_class": "0",
            "num_feature": "164"
        },
        "learner_train_param": {
            "booster": "gbtree",
            "disable_default_eval_metric": "0",
            "dsplit": "auto",
            "objective": "reg:linear"
        },
        "metrics": [
            "mae"
        ],
        "objective": {
            "name": "reg:squarederror",
            "reg_loss_param": {
                "scale_pos_weight": "1"
            }
        }
    },
    "version": [
        1,
        0,
        2
    ]
}

Why params are different?

Could you provide a sample that I can run.  I just tried the 1.0.2 branch and it works correct:
import xgboost as xgb
import numpy as np

kRows = 1000
kCols = 100

X = np.random.randn(kRows, kCols)
y = np.random.randn(kRows)

param = {
    'booster': 'gbtree',
    'objective': 'reg:linear',
    'eval_metric': 'mae',
    'updater': 'grow_histmaker,prune',
    'eta': 0.020209749520997883,
    'num_round': 1,
    'min_child_weight': 4.016289581092819,
    'gamma': 0.4275434126320313,
    'lambda': 2.9996223584471635,
    'colsample_bytree': 0.7078453564565381,
    'subsample': 0.7485739182368198,
    'max_depth': 10,
    'seed': 20190129,
    'silent': 1,
    'missing': np.NaN,
    'nthread': 4
}

dtrain = xgb.DMatrix(X, y)
watchlist = [(dtrain, 'train')]

bst = xgb.train(param,
                dtrain,
                param['num_round'],
                watchlist,
                verbose_eval=1,
                early_stopping_rounds=10)

print(bst.save_config())

[0]	train-mae:0.87545
Will train until train-mae hasn't improved in 10 rounds.
{"learner":{"generic_param":{"enable_experimental_json_serialization":"0","gpu_id":"-1","gpu_page_size":"0","n_gpus":"0","n_jobs":"4","nthread":"4","random_state":"20190129","seed":"20190129","seed_per_iteration":"0","validate_features":"0","validate_parameters":"1"},"gradient_booster":{"gbtree_train_param":{"num_parallel_tree":"1","predictor":"auto","process_type":"default","tree_method":"auto","updater":"grow_histmaker,prune","updater_seq":"grow_histmaker,prune"},"name":"gbtree","specified_updater":true,"updater":{"grow_histmaker":{"train_param":{"alpha":"0","cache_opt":"1","colsample_bylevel":"1","colsample_bynode":"1","colsample_bytree":"0.70784533","default_direction":"learn","enable_feature_grouping":"0","eta":"0.0202097502","gamma":"0.427543402","grow_policy":"depthwise","interaction_constraints":"","lambda":"2.99962234","learning_rate":"0.0202097502","max_bin":"256","max_conflict_rate":"0","max_delta_step":"0","max_depth":"10","max_leaves":"0","max_search_group":"100","min_child_weight":"4.01628971","min_split_loss":"0.427543402","monotone_constraints":"()","refresh_leaf":"1","reg_alpha":"0","reg_lambda":"2.99962234","sketch_eps":"0.0299999993","sketch_ratio":"2","sparse_threshold":"0.20000000000000001","split_evaluator":"elastic_net,monotonic","subsample":"0.748573899"}},"prune":{"train_param":{"alpha":"0","cache_opt":"1","colsample_bylevel":"1","colsample_bynode":"1","colsample_bytree":"0.70784533","default_direction":"learn","enable_feature_grouping":"0","eta":"0.0202097502","gamma":"0.427543402","grow_policy":"depthwise","interaction_constraints":"","lambda":"2.99962234","learning_rate":"0.0202097502","max_bin":"256","max_conflict_rate":"0","max_delta_step":"0","max_depth":"10","max_leaves":"0","max_search_group":"100","min_child_weight":"4.01628971","min_split_loss":"0.427543402","monotone_constraints":"()","refresh_leaf":"1","reg_alpha":"0","reg_lambda":"2.99962234","sketch_eps":"0.0299999993","sketch_ratio":"2","sparse_threshold":"0.20000000000000001","split_evaluator":"elastic_net,monotonic","subsample":"0.748573899"}}}},"learner_model_param":{"base_score":"0.500000","num_class":"0","num_feature":"100"},"learner_train_param":{"booster":"gbtree","disable_default_eval_metric":"0","dsplit":"auto","objective":"reg:linear"},"metrics":["mae"],"objective":{"name":"reg:squarederror","reg_loss_param":{"scale_pos_weight":"1"}}},"version":[1,0,2]}

Could you provide a sample that I can run. I just tried the 1.0.2 branch and it works correct:
import xgboost as xgb
import numpy as np

kRows = 1000
kCols = 100

X = np.random.randn(kRows, kCols)
y = np.random.randn(kRows)

param = {
    'booster': 'gbtree',
    'objective': 'reg:linear',
    'eval_metric': 'mae',
    'updater': 'grow_histmaker,prune',
    'eta': 0.020209749520997883,
    'num_round': 1,
    'min_child_weight': 4.016289581092819,
    'gamma': 0.4275434126320313,
    'lambda': 2.9996223584471635,
    'colsample_bytree': 0.7078453564565381,
    'subsample': 0.7485739182368198,
    'max_depth': 10,
    'seed': 20190129,
    'silent': 1,
    'missing': np.NaN,
    'nthread': 4
}

dtrain = xgb.DMatrix(X, y)
watchlist = [(dtrain, 'train')]

bst = xgb.train(param,
                dtrain,
                param['num_round'],
                watchlist,
                verbose_eval=1,
                early_stopping_rounds=10)

print(bst.save_config())

[0]	train-mae:0.87545
Will train until train-mae hasn't improved in 10 rounds.
{"learner":{"generic_param":{"enable_experimental_json_serialization":"0","gpu_id":"-1","gpu_page_size":"0","n_gpus":"0","n_jobs":"4","nthread":"4","random_state":"20190129","seed":"20190129","seed_per_iteration":"0","validate_features":"0","validate_parameters":"1"},"gradient_booster":{"gbtree_train_param":{"num_parallel_tree":"1","predictor":"auto","process_type":"default","tree_method":"auto","updater":"grow_histmaker,prune","updater_seq":"grow_histmaker,prune"},"name":"gbtree","specified_updater":true,"updater":{"grow_histmaker":{"train_param":{"alpha":"0","cache_opt":"1","colsample_bylevel":"1","colsample_bynode":"1","colsample_bytree":"0.70784533","default_direction":"learn","enable_feature_grouping":"0","eta":"0.0202097502","gamma":"0.427543402","grow_policy":"depthwise","interaction_constraints":"","lambda":"2.99962234","learning_rate":"0.0202097502","max_bin":"256","max_conflict_rate":"0","max_delta_step":"0","max_depth":"10","max_leaves":"0","max_search_group":"100","min_child_weight":"4.01628971","min_split_loss":"0.427543402","monotone_constraints":"()","refresh_leaf":"1","reg_alpha":"0","reg_lambda":"2.99962234","sketch_eps":"0.0299999993","sketch_ratio":"2","sparse_threshold":"0.20000000000000001","split_evaluator":"elastic_net,monotonic","subsample":"0.748573899"}},"prune":{"train_param":{"alpha":"0","cache_opt":"1","colsample_bylevel":"1","colsample_bynode":"1","colsample_bytree":"0.70784533","default_direction":"learn","enable_feature_grouping":"0","eta":"0.0202097502","gamma":"0.427543402","grow_policy":"depthwise","interaction_constraints":"","lambda":"2.99962234","learning_rate":"0.0202097502","max_bin":"256","max_conflict_rate":"0","max_delta_step":"0","max_depth":"10","max_leaves":"0","max_search_group":"100","min_child_weight":"4.01628971","min_split_loss":"0.427543402","monotone_constraints":"()","refresh_leaf":"1","reg_alpha":"0","reg_lambda":"2.99962234","sketch_eps":"0.0299999993","sketch_ratio":"2","sparse_threshold":"0.20000000000000001","split_evaluator":"elastic_net,monotonic","subsample":"0.748573899"}}}},"learner_model_param":{"base_score":"0.500000","num_class":"0","num_feature":"100"},"learner_train_param":{"booster":"gbtree","disable_default_eval_metric":"0","dsplit":"auto","objective":"reg:linear"},"metrics":["mae"],"objective":{"name":"reg:squarederror","reg_loss_param":{"scale_pos_weight":"1"}}},"version":[1,0,2]}

My result is incorrect because I load model after training.

@SongBiu Those parameters are gone once the model is saved into disk.  See https://xgboost.readthedocs.io/en/latest/tutorials/saving_model.html for details about model persistence implementation.

@SongBiu Those parameters are gone once the model is saved into disk. See https://xgboost.readthedocs.io/en/latest/tutorials/saving_model.html for details about model persistence implementation.

Thanks, I will try dump config of scala binding.

You can call Booster.save_config on Python to get a JSON doc of internal parameters. I'm not sure about the Scala.

Finally I want to know if it's OK that two models produced by python package and jvm package are different？

@SongBiu I believe the output should be the same when parameters are matched, and Python uses only the default parameters defined in C++.   But I don't have a lots of experience with jvm packages.  So pinging @CodingCat .

@SongBiu I believe the output should be the same when parameters are matched, and Python uses only the default parameters defined in C++. But I don't have a lots of experience with jvm packages. So pinging @CodingCat .

I produce a model with xgboost cli running on yarn, and get same output with jvm package, and both of them are different from python package.

I produce a model with xgboost cli running on yarn

Great!  CLI is something I can work on. Will look into this tomorrow or so.

 CLI is something I can work on. Will look into this tomorrow or so.

And do you know How can I decide the method that CLI fill missing value?

I produce a model with xgboost cli running on yarn

Great! CLI is something I can work on. Will look into this tomorrow or so.

My datasets are libsvm fils with missing value.
Python loads files use
dtrain = xgb.DMatrix("train.libsvm", missing=np.nan)

and CLI doesn't config missing fill.

I produce a model with xgboost cli running on yarn

Great! CLI is something I can work on. Will look into this tomorrow or so.

I have read code of python bindings and found it would update learning_rate after each iteration.
But I don't find this method in CLI code, do you know if CLI update learning_rate(eta)?

@SongBiu I don't think Python binding does something like that unless you explicitly instruct it to do so via a call back function.  I just added a test to show CLI having same model output with Python: #5535 .  So I'm suspecting it's due to missing value handling.
When the data is loaded from a svm or csr file, DMatrix doesn't handle missing value as these two formats are sparse format leaving missing value as empty.  But it's a feature we can add to maintain the consistency.

@trivialfis The input files of both bindings are libsvm files with missing value.
Both Python package and CLI call DMatrix:Load to load file. Are they different?

@trivialfis
I use follow dataset and mae after 1200 epoch of training set is
python:0.394748
CLI:1.653196
https://www.csie.ntu.edu.tw/~cjlin/libsvmtools/datasets/regression/cpusmall

@trivialfis
When I train with cpusmall dataset, both bindings set updater=grow_histmaker,prune, them produce same model. But if I set updater=grow_colmaker,prune, the model produced by CLI is different from python produced.
So I am wonder if distributed CLI only support grow_histmake,prune?

I don't think grow_colmaker updater supports distributed training. So when you set updater=grow_colmaker,prune, the distributed CLI will silently change the updater to grow_histmaker,prune.


Add additional maintainer for the Gradle plugin

Description
As a follow up for https://github.com/jenkins-infra/helpdesk/issues/3469.
Give deploy rights to the new maintainer for https://github.com/jenkinsci/gradle-plugin.
New maintainer:
@alextu

Submitter checklist for adding or changing permissions
Always

[x] Add link to plugin/component Git repository in description above

When adding new uploaders (this includes newly created permissions files)

[x] Make sure to @mention an existing maintainer to confirm the permissions request, if applicable
[x] Use the Jenkins community (LDAP) account name in the YAML file, not the GitHub account name
[x] Make sure to @mention the users being added so their GitHub account names are known if they require GitHub merge access (see below).
[x] All newly added users have logged in to Artifactory and Jira at least once

Reviewer checklist (not for requesters!)

[ ] Check this if newly added person also needs to be given merge permission to the GitHub repo (please @ the people/person with their GitHub username in this issue as well). If needed, it can be done using an IRC Bot command
[ ] Check that the $pluginId Developers team has Admin permissions while granting the access.
[ ] In the case of plugin adoption, ensure that the Jenkins Jira default assignee is either removed or changed to the new maintainer.
[ ] If security contacts are changed (this includes add/remove), ping the security officer (currently @Wadeck) in this pull request. If an email contact is changed, wait for approval from the security officer.

There are IRC Bot commands for it

@alextu needs to log into Jira to get a passing build.

Thanks, I logged in yesterday, could you please rerun the checks ?

There we go :)

Thanks 👍 !


docs(readme): include npm stats

Coverage remained the same when pulling b3a2854f6617e2013b7e58907770097ce1524f59 on gdi2290:patch-1 into cc03d8f307aaa881b641c2311016050aaae7ac7d on blakeembrey:master.


Pharo will use PCG as numpy

But it can be interesting to package it alone here too.
// *Really* minimal PCG32 code / (c) 2014 M.E. O'Neill / pcg-random.org
// Licensed under Apache License 2.0 (NO WARRANTY, etc. see website)

typedef struct { uint64_t state;  uint64_t inc; } pcg32_random_t;

uint32_t pcg32_random_r(pcg32_random_t* rng)
{
    uint64_t oldstate = rng->state;
    // Advance internal state
    rng->state = oldstate *<PHONE_NUMBER>846793005ULL + (rng->inc|1);
    // Calculate output function (XSH RR), uses old state for max ILP
    uint32_t xorshifted = ((oldstate >> 18u) ^ oldstate) >> 27u;
    uint32_t rot = oldstate >> 59u;
    return (xorshifted >> rot) | (xorshifted << ((-rot) & 31));
}

https://lemire.me/blog/2017/08/22/testing-non-cryptographic-random-number-generators-my-results/


[ESP32] Fix ota-provider-app build failure

Problem

ota-provider-app/esp32 build is broken due to some common changes introduced in #13329

Change overview

Added the required changes introduced in #13329
Fixed the build by moving BdxOtaSender.h to examples/ota-provider-app/esp32/main/include/ota-provider-common so that OTAProviderExample.h will include this header file based on include path.

This is the workaround to fix the build, we will need some interface which can be used by platforms for implementing OTA provider.
Testing

Linux-ota-provider and Linux-ota-requestor
ESP32-ota-provider and ESP32-ota-requestor
Linux-ota-provider and ESP32-ota-requestor

Why wasn't this caught by CI?

Why wasn't this caught by CI?

This example is not added to CI, #13212 adds this to CI.

Why wasn't this caught by CI?

This example is not added to CI, #13212 adds this to CI.

Sorry I broke this when fixing it on Linux OTA Provider


Fix required for kubestr and k0s

A fix is required for kubestr and k0s which have made breaking changes to their download URLs meaning the e2e tests are now failing.
Expected Behaviour

make e2e should pass
Current Behaviour

Possible Solution

First confirm the issue with arkade get k0s etc
Then:

Check the releases pages of each too
Copy the URL for a binary
Edit the template with the new URL format
Run the unit tests

Finally, run go build && ./arkade get k0s and it should be fixed.
Do the same for kubestr and then send a PR.

I can pick this up?

Sorry the e2e tests need fixing immediately, I'll take it.


"assets/waymo/test.pkl" does not exist.

This break tests/test_functionality/test_read_waymo_data.py

It is a deprecated one. I fixed it in latest main now


Hard mode?

Could it be? Eek!

To save time I started from the Modern Greek branch, which I did before modes were introduced. Realistically, I may find time to do it over Easter to the summer holidays.

It would make things very hard, def. not a priority!


error: use of undeclared identifier 'isnan' on macOS Big Sur (11.4 and 11.5)

When cargo build in a clean checkout, I get:
% cargo build
   Compiling implot-sys v0.4.0 (/Users/maoe/src/github.com/4bb4/implot-rs/implot-sys)
The following warnings were emitted during compilation:

warning: In file included from third-party/cimplot/implot/implot.cpp:69:
warning: In file included from third-party/cimplot/implot/implot_internal.h:39:
warning: In file included from /Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui-sys-0.6.0
/third-party/imgui/imgui_internal.h:48:
warning: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Develo
per/SDKs/MacOSX.sdk/usr/include/c++/v1/math.h:309:
warning: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Develo
per/SDKs/MacOSX.sdk/usr/include/c++/v1/type_traits:417:
warning: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Develo
per/SDKs/MacOSX.sdk/usr/include/c++/v1/cstddef:37:
warning: /Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui-sys-0.6.0/third-party/version:1
:1: error: unknown type name 'Generated'
warning: Generated by cimgui version 98e6ff7051df19b76854bc3eb3cea2798f8d3bc5
warning: ^
warning: /Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui-sys-0.6.0/third-party/version:1
:13: error: expected ';' after top level declarator
warning: Generated by cimgui version 98e6ff7051df19b76854bc3eb3cea2798f8d3bc5
warning:             ^
warning: In file included from third-party/cimplot/implot/implot.cpp:69:
warning: third-party/cimplot/implot/implot_internal.h:101:84: error: use of undeclared identifier 'isnan'
warning: inline bool ImNanOrInf(double val) { return val == HUGE_VAL || val == -HUGE_VAL || isnan(val); }
warning:                                                                                ^
warning: third-party/cimplot/implot/implot_internal.h:103:51: error: use of undeclared identifier 'isnan'
warning: inline double ImConstrainNan(double val) { return isnan(val) ? 0 : val; }
warning:                                                   ^
warning: 4 errors generated.

error: failed to run custom build command for `implot-sys v0.4.0 (/Users/maoe/src/github.com/4bb4/implot-r
s/implot-sys)`

Caused by:
  process didn't exit successfully: `/Users/maoe/src/github.com/4bb4/implot-rs/target/debug/build/implot-s
ys-3e514974c2ebd667/build-script-build` (exit status: 1)
  --- stdout
  TARGET = Some("x86_64-apple-darwin")
  OPT_LEVEL = Some("0")
  HOST = Some("x86_64-apple-darwin")
  CXX_x86_64-apple-darwin = None
  CXX_x86_64_apple_darwin = None
  HOST_CXX = None
  CXX = None
  CXXFLAGS_x86_64-apple-darwin = None
  CXXFLAGS_x86_64_apple_darwin = None
  HOST_CXXFLAGS = None
  CXXFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("true")
  CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2,sse3,ssse3")
  CXX_x86_64-apple-darwin = None
  CXX_x86_64_apple_darwin = None
  HOST_CXX = None
  CXX = None
  CXXFLAGS_x86_64-apple-darwin = None
  CXXFLAGS_x86_64_apple_darwin = None
  HOST_CXXFLAGS = None
  CXXFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2,sse3,ssse3")
  CXX_x86_64-apple-darwin = None
  CXX_x86_64_apple_darwin = None
  HOST_CXX = None
  CXX = None
  CXXFLAGS_x86_64-apple-darwin = None
  CXXFLAGS_x86_64_apple_darwin = None
  HOST_CXXFLAGS = None
  CXXFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2,sse3,ssse3")
  CXX_x86_64-apple-darwin = None
  CXX_x86_64_apple_darwin = None
  HOST_CXX = None
  CXX = None
  CXXFLAGS_x86_64-apple-darwin = None
  CXXFLAGS_x86_64_apple_darwin = None
  HOST_CXXFLAGS = None
  CXXFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2,sse3,ssse3")
  running: "c++" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m6
4" "-arch" "x86_64" "-I" "/Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui-sys-0.6.0/thir
d-party" "-I" "/Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui-sys-0.6.0/third-party/img
ui" "-I" "third-party/cimplot/implot/" "-Wall" "-Wextra" "-Wno-return-type-c-linkage" "-Wno-unused-paramet
er" "-std=c++11" "-DCIMGUI_NO_EXPORT" "-DIMGUI_DISABLE_OSX_FUNCTIONS" "-DIMGUI_DISABLE_WIN32_FUNCTIONS" "-
o" "/Users/maoe/src/github.com/4bb4/implot-rs/target/debug/build/implot-sys-3c5e13d3fc633769/out/third-par
ty/cimplot/cimplot.o" "-c" "third-party/cimplot/cimplot.cpp"
  exit status: 0
  running: "c++" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m6
4" "-arch" "x86_64" "-I" "/Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui-sys-0.6.0/thir
d-party" "-I" "/Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui-sys-0.6.0/third-party/img
ui" "-I" "third-party/cimplot/implot/" "-Wall" "-Wextra" "-Wno-return-type-c-linkage" "-Wno-unused-paramet
er" "-std=c++11" "-DCIMGUI_NO_EXPORT" "-DIMGUI_DISABLE_OSX_FUNCTIONS" "-DIMGUI_DISABLE_WIN32_FUNCTIONS" "-
o" "/Users/maoe/src/github.com/4bb4/implot-rs/target/debug/build/implot-sys-3c5e13d3fc633769/out/third-par
ty/cimplot/implot/implot.o" "-c" "third-party/cimplot/implot/implot.cpp"
  cargo:warning=In file included from third-party/cimplot/implot/implot.cpp:69:
  cargo:warning=In file included from third-party/cimplot/implot/implot_internal.h:39:
  cargo:warning=In file included from /Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui-sy
s-0.6.0/third-party/imgui/imgui_internal.h:48:
  cargo:warning=In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform
/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/math.h:309:
  cargo:warning=In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform
/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/type_traits:417:
  cargo:warning=In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform
/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/cstddef:37:
  cargo:warning=/Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui-sys-0.6.0/third-party/ve
rsion:1:1: error: unknown type name 'Generated'
  cargo:warning=Generated by cimgui version 98e6ff7051df19b76854bc3eb3cea2798f8d3bc5
  cargo:warning=^
  cargo:warning=/Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui-sys-0.6.0/third-party/ve
rsion:1:13: error: expected ';' after top level declarator
  cargo:warning=Generated by cimgui version 98e6ff7051df19b76854bc3eb3cea2798f8d3bc5
  cargo:warning=            ^
  cargo:warning=In file included from third-party/cimplot/implot/implot.cpp:69:
  cargo:warning=third-party/cimplot/implot/implot_internal.h:101:84: error: use of undeclared identifier '
isnan'
  cargo:warning=inline bool ImNanOrInf(double val) { return val == HUGE_VAL || val == -HUGE_VAL || isnan(v
al); }
  cargo:warning=                                                                                ^
  cargo:warning=third-party/cimplot/implot/implot_internal.h:103:51: error: use of undeclared identifier '
isnan'
  cargo:warning=inline double ImConstrainNan(double val) { return isnan(val) ? 0 : val; }
  cargo:warning=                                                  ^
  cargo:warning=4 errors generated.
  exit status: 1

  --- stderr

  error occurred: Command "c++" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-fram
e-pointer" "-m64" "-arch" "x86_64" "-I" "/Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui
-sys-0.6.0/third-party" "-I" "/Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui-sys-0.6.0/
third-party/imgui" "-I" "third-party/cimplot/implot/" "-Wall" "-Wextra" "-Wno-return-type-c-linkage" "-Wno
-unused-parameter" "-std=c++11" "-DCIMGUI_NO_EXPORT" "-DIMGUI_DISABLE_OSX_FUNCTIONS" "-DIMGUI_DISABLE_WIN3
2_FUNCTIONS" "-o" "/Users/maoe/src/github.com/4bb4/implot-rs/target/debug/build/implot-sys-3c5e13d3fc63376
9/out/third-party/cimplot/implot/implot.o" "-c" "third-party/cimplot/implot/implot.cpp" with args "c++" di
d not execute successfully (status code exit status: 1).

where
% c++ --version
Apple clang version 12.0.5 (clang-1<IP_ADDRESS>)
Target: x86_64-apple-darwin20.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I'm on MacBook Pro 16'' 2019 (Intel). I'm sure it used to work but it stopped working at some point. Maybe when I upgraded the OS to Big Sur? I'm not sure.

Apparently it builds fine on Catalina: https://github.com/maoe/implot-rs/runs/2858954514

Interesting... I have access to a Mac, but I think it's still on Catalina as well. Looking at https://en.cppreference.com/w/cpp/numeric/math/isnan, it appears isnan should be defined in cmath / math.h, which in the linked version of implot_internal.h is included through imgui_internal.h here. So in principle the right headers should be included.
Looking around the internet for people with similar problems, I found https://stackoverflow.com/questions/68168291/macos-big-sur-m1-silicon-cmath-error-during-r-devtool-monocle3-install which is quite recent and where someone also had their math operations going missing on Big Sur. They solved their issue by including the math.h on their system by an absolute path - which of course is not a permanent solution and will not be portable, but it's something we could try out.
You could also try experimenting with building simple code that includes math.h and then uses something like isnan on your system:
#include <math.h>

int main(void) {
    double x = 0.0;
    bool is_it_nan = isnan(x);
}

If that already doesn't build with the clang on your system, maybe something with the system include paths is wrong. If it does, we need to look for why it works there but does not for the implot build.

Thanks for your input.  search starts here:
#include <...> search starts here:
 /usr/local/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.5/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -no_deduplicate -dynamic -arch x86_64 -platform_version macos 11.0.0 11.3 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o a.out -L/usr/local/lib /var/folders/3t/ycv0ctpn4qb5k7djxy72k4dm0000gn/T/isnan-7ac428.o -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.5/lib/darwin/libclang_rt.osx.a
% echo $?
0

Good, that means nothing is wrong with the system's include path in general. I'm upgrading to Big Sur now and will try out whether I can reproduce the problem then. I think I'm getting 11.5 in the upgrade, but it'll be a data point anyway.

FWIW I just updated macOS to 11.5 and confirmed that the issue remained.

Bad news first: The build worked fine on my machine also on Catalina, so I can't reproduce the problem. That doesn't mean it's not a problem of course, it just makes it trickier for me to help.
The good news is that I think I found what the problem is: I looked a bit more closely at your error output. The early part makes it seem as if it's trying to interpret the VERSION file as code. What's more, this seems to be the case at line 37 of /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform /Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/cstddef.
I went and looked at that line on my system, and it is:
#include <version>

.... I guess that shows where the issue comes from (to spell it out: It seems the build is attempting to include this spurious VERSION file I linked to instead of the C++ version header) . The reason I don't have that problem on my system is likely that I've configured my file system to have case-sensitive file names, but if I remember correctly, the default is to be case insensitive, which I suspect you have.
I have to think about how to best fix this - likely the build will start working for you if you locally delete /Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui-sys-0.6.0/third-party/version and then do cargo build again (cargo does not notice if you delete files from its cache, since one would not typically do this... but for this experiment it would be worth a shot). I'll try to think of a more permanent solution and get back to you.

likely the build will start working for you if you locally delete /Users/maoe/.cargo/registry/src/github.com-1ecc6299db9ec823/imgui-sys-0.6.0/third-party/version and then do cargo build again

This indeed fixed the build issue, and yes, I'm using the case-insensitive filesystem. I'm meaning to migrate to case-sensitive file system though I haven't gotten around to it yet..

This has been found and fixed upstream in https://github.com/imgui-rs/imgui-rs/commit/794ece895673a94fe480e1d81587108f34c8f586 already a while back, but we have not yet been able to profit from that fix so far because of https://github.com/4bb4/implot-rs/issues/13. However, #13 is now un-blocked, so I expect to be able to soon merge https://github.com/4bb4/implot-rs/pull/24 and with that fix the issue here as well.

Nice! Thanks for the heads up.

Unfortunately this will take a little while longer, since I noticed that the latest release of imgui-rs we now point to (https://github.com/imgui-rs/imgui-rs/tree/v0.7.0) does not include the fix yet after all, sorry. I can point the imgui-rs dependency version to imgui-rs's master (which has the fix), but I can't make a release of that because crates.io does not take releases of packages that point to git dependencies. I'll ping you once I do that on master or a branch - it will take a bit of work because there are API changes on imgui-rs master as well.

Thanks for the heads up. It's okay. I've been using the workaround that you suggested earlier for now so it's not a showstopper.

@maoe the master branch now points to imgui 0.8, which should have the fix for the issue here. If you get around to trying this, let me know if it works for you so I can decide whether to close the issue here or more work is needed.

The master branch builds fine on macOS. Thanks!


Add ~NK~ Into the light (High pitch) by Nightkilla

Song Name
~NK~ Into the light (High pitch)
Artist Name
Nightkilla
Source
Youtube
Youtube Link
ZQ_-iW0a-Lk
Direct File Link
No response
Song ID
404595
Start Offset [ms]
0
Extra
Created from Auto Nong.
Created for level: 56632396

Yes, I accept.
On Fri, Jul 26, 2024, 10:41 PM auto-nong[bot] @.***>
wrote:

Thanks for contributing!
Someone will soon review your request.
Here is the JSON result for the reviewer:
{
"name": "~NK~ Into the light (High pitch)",
"artist": "Nightkilla",
"source": "youtube",
"startOffset": 0,
"yt-id": "ZQ_-iW0a-Lk",
"songs": [
404595
]
}
To accept the request, a reviewer needs to write "accept".
—
Reply to this email directly, view it on GitHub
https://github.com/FlafyDev/auto-nong-indexes/issues/1881#issuecomment-2253718469,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BJSK7HGKATAURMTVZZYT4TDZOMCFJAVCNFSM6AAAAABLRO6IWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJTG4YTQNBWHE
.
You are receiving this because you authored the thread.Message ID:
@.***>

reopen
On Sun, Aug 11, 2024, 10:26 PM github-actions[bot] @.***>
wrote:

This submission is stale because it has been open for 14 days with no
activity. If it is still relevant, please leave a comment and we will
reopen it.
—
Reply to this email directly, view it on GitHub
https://github.com/FlafyDev/auto-nong-indexes/issues/1881#issuecomment-2283016319,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BJSK7HD4TZKNNRWASOHD6HTZRAMNHAVCNFSM6AAAAABLRO6IWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBTGAYTMMZRHE
.
You are receiving this because you authored the thread.Message ID:
@.***>


Detail TLS version support and update link

Expanded warning about TLS support compatibility, and include reference document for finding the necessary update to add TLS 1.2 support to older SQL Server versions.

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

Thank you @keseph   @BYHAM please review

#sign-off


fix: lift the notification banner above the modal overlay

🎯 Goal
Fixes https://github.com/GetStream/stream-chat-react/issues/2160

@MartinCupela can you please make this change React-only, Angular has a different solution. Sorry for the late answer, I missed this PR.

@MartinCupela can you please make this change React-only, Angular has a different solution. Sorry for the late answer, I missed this PR.

@szuperaz I have namespaced the class to target only React notifications. Could you pls review? Thank you

Thank you!


Cache url with parameters

Right now if I try to cachehttps://fonts.googleapis.com/css?family=Montserrat:400,700 i get the following error:

WARNING in OfflinePlugin: Cache pattern [https://fonts.googleapis.com/css?family=Montserrat:400,700] did not matched any assets

If I invalidate the URL removing the ? the plugin gives no errors.
How can I overcome this issue?
My config:
const offlinePluginOptions = {
    caches:{
        main:[
            'index.js',
            'index.html',
            'https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.5.7/angular.min.js',
            'https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.5.7/angular-animate.min.js',
            'https://cdnjs.cloudflare.com/ajax/libs/ngStorage/0.3.6/ngStorage.min.js',
            'https://cdnjs.cloudflare.com/ajax/libs/color-thief/2.0.1/color-thief.min.js',
            'https://fonts.googleapis.com/css?family=Montserrat:400,700'
        ]
    },
    externals: [
        'https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.5.7/angular.min.js',
        'https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.5.7/angular-animate.min.js',
        'https://cdnjs.cloudflare.com/ajax/libs/ngStorage/0.3.6/ngStorage.min.js',
        'https://cdnjs.cloudflare.com/ajax/libs/color-thief/2.0.1/color-thief.min.js',
        'https://fonts.googleapis.com/css?family=Montserrat:400,700'
    ],
    ServiceWorker: {
        events: true
    },
    version: '[hash]'
}

Thanks

This a bug, thanks for reporting this.

This will be fixed in v4, probably in September.

@Naramsim
Well, this is September and I think I fixed this issue. Please try it with v4, you may install it with: npm install offline-plugin@next.
Also with v4 your config now can be minimized to this:
const offlinePluginOptions = {
    caches:{
        main:[
            'index.js',
            'index.html',
            ':externals:'
        ]
    },
    externals: [
        'https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.5.7/angular.min.js',
        'https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.5.7/angular-animate.min.js',
        'https://cdnjs.cloudflare.com/ajax/libs/ngStorage/0.3.6/ngStorage.min.js',
        'https://cdnjs.cloudflare.com/ajax/libs/color-thief/2.0.1/color-thief.min.js',
        'https://fonts.googleapis.com/css?family=Montserrat:400,700'
    ],
    ServiceWorker: {
        events: true
    },
    version: '[hash]'
}

and if index.html and index.js are generated by webpack, then even to this:
const offlinePluginOptions = {
    externals: [
        'https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.5.7/angular.min.js',
        'https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.5.7/angular-animate.min.js',
        'https://cdnjs.cloudflare.com/ajax/libs/ngStorage/0.3.6/ngStorage.min.js',
        'https://cdnjs.cloudflare.com/ajax/libs/color-thief/2.0.1/color-thief.min.js',
        'https://fonts.googleapis.com/css?family=Montserrat:400,700'
    ],
    ServiceWorker: {
        events: true
    },
    version: '[hash]'
}

Also, even though this is fixed you still may have issue due to this issue: https://github.com/NekR/offline-plugin/issues/98

Thanks, however, I can't try it now, I wrote my custom SW.
Thanks for the effort :+1:
Feel free to close

@Naramsim I see, no problem. Just btw, if some feature is missing in offline-plugin you don't need to re-write whole SW, you can still just use offline-plugin but additionally implement your own logic:
new OfflinePlugin({
  ServiceWorker: {
    entry: 'my-sw.js'
  }
})

Here my-sw.js is a file where you can handle SW as you want (e.g. fetch event) and still use offline-plugin.

Exactly what Ive done :smile:

@Naramsim nice!


[bug]: When config set-reduce-vol-when-voice is set to True, set max volume is not respected

What's happening?
When /config set-reduce-vol-when-voice is used and set to True, if someone were to speak, the bot functions correctly by temporarily lowering the volume to an amount specified, however, the volume returns to 100% instead of the currently set volume, for example, 20%, when everyone in the voice channel is no longer speaking.
Runtime
I'm running Muse:

[ ] Directly from the cloned repository
[X] Inside a Docker container
[ ] Something else (please elaborate)

Versions

Muse: 2.10.0
Docker (if applicable): 27.3.1
OS: Debian GNU/Linux 12 (bookworm)

Mind trying with ghcr.io/museofficial/muse:pr-1146?


Py gen test fix

Closes #1560
Basically, since grpc version 1.48, there has been a major change in how the stub files are generated, relying more heavily on the DESCRIPTOR tag for all the serialized infomation.
We now use this variable for all our generation, hopefully avoiding this issue going forward.

Checked for backwards compatibility, works fine!

@jayofdoom should I bump the versions up in this commit or make another PR?


Absorb 404-server from kubernetes/contrib?

We've taken echoheaders and the controllers out, why not absorb the default backend since we depend on it.
I've come to kubernetes/ingress at least n times now in search of the 404 server so I'm sure others must have as well?
ref https://github.com/kubernetes/contrib/tree/master/404-server
Curious what you think @aledbf

@JonPulsifer sure but I think we need to see if that's ok at least with one of the owners of that directory

I'm fine with moving it.
@bprashanth WDYT?

bprashanth doesn't work on Kubernetes anymore.  Perhaps @mikedanese or @lavalamp can comment.

This is fine by me.


[Wallet] Add redux migration v0

Description
In prep for the wallet release today, we need a migration to make sure our existing users don't have to redo the onboarding flow
Tested
Created a new test to confirm migration.
Currently testing by running dev app with old version and then upgrading to latest.
Backwards compatibility
Compatible

Looks good! great to see the tests you added 👍
Just a clarification, are app.inviteCodeEntered and app.numberVerified still used?
i.e. I'm wondering if those 2 should be migrated to undefined

We could do that yep. Does that get us any benefit?

I don't know yet, I'm mostly confused because I still see them in the app reducer. And your changes and comment suggests these are obsolete.
https://github.com/celo-org/celo-monorepo/blob/0319b93d72b15c7486951f6e75bc62532ba4cfe4/packages/mobile/src/app/reducers.ts#L5
What's the reality?

@jeanregisser They are obsolete but they will not be removed until we clean up the old onboarding flow, which we should do in the next week or two


Fail to install extension from Marketplace

I have found that attempting to install any extension from the marketplace via the GUI fails the Readiness check at the Checking Component Dependency stage.
This is caused by PHP memory_limit being set in the .htaccess to 756M which is too low 2G is recommended.
I have had to sed my .htaccess to fix this issue.

@Ratnarashi Which .htaccess did you change specifically and did you have to do anything else? I still get an error at ' Checking Component Dependency stage' after changing the few main ones.

@Ratnarashi Which .htaccess did you change specifically and did you have to do anything else? I still get an error at ' Checking Component Dependency stage' after changing the few main ones.

@Tenoke
After
docker-compose build
docker-compose up -d

And working through the Magento setup I then run,
	docker-compose exec web sed -i -e "s/php_value memory_limit 756M/php_value memory_limit 2G/g" /var/www/html/.htaccess
This edits the .htaccess in the running container.
`docker-compose exec web apachectl -k graceful`

Restart apache.
`docker-compose exec -u www-data web php /var/www/html/bin/magento config:set system/backup/functionality_enabled 1`

Enable Magento's backup system.
`docker-compose exec -u www-data web rm -rf /generated/metadata/* /generated/code/*`

Clear out the generated files.
`docker-compose exec -u www-data web bin/magento deploy:mode:set developer`

Set developer mode to get error reporting
`docker-compose exec -u www-data web bin/magento cache:enable`

Enable the cache so that it runs at a decent speed.
I could then install the demo data using composer and install extensions from the market place.
Hope this helps.

Thank you, that worked flawlessly!


Auto-calc Grid when Geographic coords are entered

User enters easting (lat), northing (long), and ellipsoidal height

Click Next

Grid coordinates are calculated and displayed:

(editable) State plane zone: calculated based on spatial boundaries of the zones (north, central, south)
(editable) Horizontal units: default to meters
(editable) NGS Adjustment: default to NGS 2011
(editable) Northing: calculated
(editable) Easting: calculated
(not editable) Elevation: default to NAVD88

Click Next

Goes to image upload (#93)

Is the ellipsoidal height 3 different units?

meters only

This is done at submission time in the database or do we show it to the submitter?

It is shown to the submitter.

Grid coordinates are calculated and displayed

The submitter has the option to

accept the calc'd coords and move on ('Next')
edit/enter their own coords, or even delete the calc'd coords, and move on (see "(editable)" fields in initial comment)

except "(not editable) Elevation"

Original comment edited, based on conversation on 9/29/2022

blocked by #105

https://drive.google.com/drive/folders/1mLmjz_Z962ChnQRdADpdMrjP-qNJhzot?usp=sharing
This folder contains a spreadsheet with the counties listed by state plane zone and contains a file with coordinates of a point in each state plane zone.
https://www.ngs.noaa.gov/web_services/ncat/index.shtml
This link is to the NGS coordinate conversion tool API and can possibly be used to perform our conversions.

@seanfernandez Great info here, thank you. I'm going to move it over to #105

https://drive.google.com/drive/folders/1mLmjz_Z962ChnQRdADpdMrjP-qNJhzot?usp=sharing This folder contains a spreadsheet with the counties listed by state plane zone and contains a file with coordinates of a point in each state plane zone. https://www.ngs.noaa.gov/web_services/ncat/index.shtml This link is to the NGS coordinate conversion tool API and can possibly be used to perform our conversions.

Ref: #105

closed, and info merged with #105


Fix creation functions with builtin like kwarg

This PR fixes #22 by making _maybe_inject_dtype_device fall back to the type of the provided like input if the attribute like.dtype does not exist.
Tests are added accordingly.

Hello @dwierichs! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file tests/test_autoray.py:

Line 872:1: E302 expected 2 blank lines, found 1
Line 872:80: E501 line too long (161 > 79 characters)
Line 873:80: E501 line too long (109 > 79 characters)
Line 878:1: W391 blank line at end of file

Hi @dwierichs, thanks for the issue and quick PR!
The test failure is genuine - and comes from the fact that the numpy default integer type on windows is int32 not int64... ( I think this is about to change with numpy v2.0).
You could change the type check to something softer, with e.g.:
assert "int" in ar.get_dtype_name(y)

for the integer case.

Thanks for the context @jcmgray , that would have taken me way too much time to find out :sweat_smile:
I went for
assert y.dtype in expected

and a list of  expected=[np.int32, np.int64] for that test case. Hope that works :)

Perfect thanks very much!


format_into() requires io::Write; what about fmt::Write in Debug/Display impls?

Simple (and the most common, I believe) use case - you're implementing Display or Debug for your type containing some time objects, and you are provided with std::fmt::Formatter which implements std::fmt::Write trait. (maybe I'm missing something trivial, so apologies in advance if that's the case)
Current format_into implementations though require &mut impl std::io::Write which is a different beast, more complex and aimed at different stuff, with vectored writes, flushing and all the rest. If one were to choose between the two, wouldn't it make sense to support fmt::Write and not io::Write? Is there a clean alternative way?
(There's crates like fmt2io that provide hacky bridges but that's just ugly and wrong)

It would be nice to make format (which only requires alloc) and any future formatting methods using core::fmt::Write available in no-std. However, the implementation and feature gate for format is coupled with format_into which depends on std::io::Write.
To summarize, the three use cases can all be made available behind different feature gates:

Method
Features

format
alloc

format_into
std

format_into_fmt_writer

The primary problem that formatting into fmt::Write is that arbitrary bytes can be present in the format description. It's not immediately clear how this interacts with an output that requires UTF-8.
That said, the existing format method can not change as it would be breaking to do so.

That said, the existing format method can not change as it would be breaking to do so.

No, but it could be made available under a formatting-alloc feature gate that would only imply alloc, and would be auto-enabled by full formatting.

It has to be under a different method name. Feature gates can't change a method signature.

Feature gates can't change a method signature.

Sorry about the possible confusion, but I'm not asking to modify the signature of format. Just enable it under a feature gate that does not pull in std.
I think this proposal needs to be discussed as its own issue; formatting into fmt::Write is somewhat relevant because it's another case where std is not required, but also alloc isn't.

The primary problem that formatting into fmt::Write is that arbitrary bytes can be present in the format description. It's not immediately clear how this interacts with an output that requires UTF-8.

That's got to be already solved for format which must end up with a String, hasn't it?

I'm not asking to modify the signature of format. Just enable it under a feature gate that does not pull in std.

This inherently requires a new method, as the existing signature requires std.

That's got to be already solved for format which must end up with a String, hasn't it?

Right now String::from_utf8_lossy is used — which requires std.

I'm not asking to modify the signature of format. Just enable it under a feature gate that does not pull in std.

This inherently requires a new method, as the existing signature requires std.

Ah, but changing the return type to alloc::string::String would not break the signature, as it's the same type.

Right now String::from_utf8_lossy is used — which requires std.

Understood, it will be more difficult with incremental output and no allocations.

Hmm...you may be right after ~30 seconds of looking at code. It may be possible to have format only require alloc. However, this would require behavior identical to current, which will not be easy to accomplish. Some things could be gated internally that aren't right now.

As I just mentioned in #407, my current intent is to wait for min_specialization. This will permit either io::Write or fmt::Write to be passed as a parameter, preferring io::Write if the value implements both. Marking this issue as blocked for on min_specialization.


Use official ratatui Tabs

https://ratatui.rs/examples/widgets/tabs/

Would you want the tabs to just be empty for now? just a skeleton render?

#18 #15 #8  <- for reference on tabs to add.

Would you want the tabs to just be empty for now? just a skeleton render?

I was imagining that the current Main, Registers, Stacks, and Instructions should be tabs.
Also, :upside_down_face: stacks should be stack

all "tabs" should be actual tabs ya?
so main, registers, stacks, instructions, output, and hexdump?


Refactor Compile, Parse, gen.js

add vl.data.stats

remove compile.js’s dependency on Encoding and make compile() take encoding as input

add encoding.compile and vl.parse = vl.Encoding.compile = vl.Encoding.fromSpec(...).compile(...)

move testutil to bin

make bin/gen.js

support encoding.data() without name param

Please merge #461 first

@domoritz  I'm putting this on hold as [WIP]  -- need further revision.


Minor fixes to Focalboard docs

Summary
This PR accompanies #1050. It fixes a Markdown link, adds two more relevant links, and makes the language more consistent. This should wrap up the Focalboard doc migration!

@BenLloydPearson @justinegeffen Apologies for the double PR, I caught a Markdown formatting issue after it was merged. Thanks! 🙂

Let me know if additional changes are needed to get this one merged in @justinegeffen @cwarnermm :) Thanks!