AnnotationText database seed error

Doing db:seed fails, this came from the master branch by adding the peer review. I don't recall it doing this until recently, so possibly something in the master changed?
A db:reset fixes it.
rake aborted!
ActiveRecord::InvalidForeignKey: PG::ForeignKeyViolation: ERROR:  insert or update on table "annotation_texts" violates foreign key constraint "fk_annotation_labels_annotation_categories"
DETAIL:  Key (annotation_category_id)=(17) is not present in table "annotation_categories".
: INSERT INTO "annotation_texts" ("annotation_category_id", "content", "created_at", "updated_at") VALUES ($1, $2, $3, $4) RETURNING "id"
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:606:in `exec_prepared'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:606:in `block in exec_cache'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_adapter.rb:473:in `block in log'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_adapter.rb:467:in `log'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:605:in `exec_cache'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:589:in `execute_and_clear'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:160:in `exec_query'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:192:in `exec_insert'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:108:in `insert'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/query_cache.rb:14:in `insert'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/relation.rb:64:in `insert'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:524:in `_create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/counter_cache.rb:139:in `_create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/locking/optimistic.rb:75:in `_create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/attribute_methods/dirty.rb:132:in `_create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:306:in `block in _create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:555:in `block (2 levels) in compile'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:92:in `__run_callbacks__'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:778:in `_run_create_callbacks'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:306:in `_create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/timestamp.rb:57:in `_create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:504:in `create_or_update'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:302:in `block in create_or_update'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:555:in `block (2 levels) in compile'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:92:in `__run_callbacks__'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:778:in `_run_save_callbacks'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:302:in `create_or_update'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:120:in `save'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/bullet-5.0.0/lib/bullet/active_record42.rb:27:in `save_with_bullet'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/validations.rb:37:in `save'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/attribute_methods/dirty.rb:21:in `save'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:286:in `block (2 levels) in save'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:351:in `block in with_transaction_returning_status'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `block in transaction'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/transaction.rb:184:in `within_new_transaction'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `transaction'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:220:in `transaction'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:348:in `with_transaction_returning_status'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:286:in `block in save'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:301:in `rollback_active_record_state!'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:285:in `save'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:34:in `create'
/home/vagrant/Markus/lib/tasks/rubric.rake:61:in `block (5 levels) in <top (required)>'
/home/vagrant/Markus/lib/tasks/rubric.rake:60:in `times'
/home/vagrant/Markus/lib/tasks/rubric.rake:60:in `block (4 levels) in <top (required)>'
/home/vagrant/Markus/lib/tasks/rubric.rake:54:in `times'
/home/vagrant/Markus/lib/tasks/rubric.rake:54:in `block (3 levels) in <top (required)>'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/relation/delegation.rb:46:in `each'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/relation/delegation.rb:46:in `each'
/home/vagrant/Markus/lib/tasks/rubric.rake:22:in `block (2 levels) in <top (required)>'
/home/vagrant/Markus/db/seeds.rb:7:in `<top (required)>'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:268:in `load'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:268:in `block in load'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:240:in `load_dependency'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:268:in `load'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/railties-4.2.4/lib/rails/engine.rb:547:in `load_seed'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/tasks/database_tasks.rb:250:in `load_seed'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/railties/databases.rake:183:in `block (2 levels) in <top (required)>'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/railties/databases.rake:142:in `block (2 levels) in <top (required)>'
/home/vagrant/.rvm/gems/ruby-2.1.3/bin/ruby_executable_hooks:15:in `eval'
/home/vagrant/.rvm/gems/ruby-2.1.3/bin/ruby_executable_hooks:15:in `<main>'
PG::ForeignKeyViolation: ERROR:  insert or update on table "annotation_texts" violates foreign key constraint "fk_annotation_labels_annotation_categories"
DETAIL:  Key (annotation_category_id)=(17) is not present in table "annotation_categories".
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:606:in `exec_prepared'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:606:in `block in exec_cache'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_adapter.rb:473:in `block in log'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_adapter.rb:467:in `log'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:605:in `exec_cache'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:589:in `execute_and_clear'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:160:in `exec_query'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:192:in `exec_insert'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:108:in `insert'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/query_cache.rb:14:in `insert'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/relation.rb:64:in `insert'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:524:in `_create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/counter_cache.rb:139:in `_create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/locking/optimistic.rb:75:in `_create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/attribute_methods/dirty.rb:132:in `_create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:306:in `block in _create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:555:in `block (2 levels) in compile'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:92:in `__run_callbacks__'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:778:in `_run_create_callbacks'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:306:in `_create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/timestamp.rb:57:in `_create_record'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:504:in `create_or_update'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:302:in `block in create_or_update'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:555:in `block (2 levels) in compile'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in `call'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:92:in `__run_callbacks__'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:778:in `_run_save_callbacks'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:302:in `create_or_update'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:120:in `save'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/bullet-5.0.0/lib/bullet/active_record42.rb:27:in `save_with_bullet'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/validations.rb:37:in `save'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/attribute_methods/dirty.rb:21:in `save'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:286:in `block (2 levels) in save'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:351:in `block in with_transaction_returning_status'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `block in transaction'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/transaction.rb:184:in `within_new_transaction'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `transaction'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:220:in `transaction'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:348:in `with_transaction_returning_status'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:286:in `block in save'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:301:in `rollback_active_record_state!'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:285:in `save'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:34:in `create'
/home/vagrant/Markus/lib/tasks/rubric.rake:61:in `block (5 levels) in <top (required)>'
/home/vagrant/Markus/lib/tasks/rubric.rake:60:in `times'
/home/vagrant/Markus/lib/tasks/rubric.rake:60:in `block (4 levels) in <top (required)>'
/home/vagrant/Markus/lib/tasks/rubric.rake:54:in `times'
/home/vagrant/Markus/lib/tasks/rubric.rake:54:in `block (3 levels) in <top (required)>'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/relation/delegation.rb:46:in `each'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/relation/delegation.rb:46:in `each'
/home/vagrant/Markus/lib/tasks/rubric.rake:22:in `block (2 levels) in <top (required)>'
/home/vagrant/Markus/db/seeds.rb:7:in `<top (required)>'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:268:in `load'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:268:in `block in load'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:240:in `load_dependency'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:268:in `load'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/railties-4.2.4/lib/rails/engine.rb:547:in `load_seed'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/tasks/database_tasks.rb:250:in `load_seed'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/railties/databases.rake:183:in `block (2 levels) in <top (required)>'
/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/railties/databases.rake:142:in `block (2 levels) in <top (required)>'
/home/vagrant/.rvm/gems/ruby-2.1.3/bin/ruby_executable_hooks:15:in `eval'
/home/vagrant/.rvm/gems/ruby-2.1.3/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => db:rubric
(See full trace by running task with --trace)

@WChrisK I think we talked about how to fix this error in the rubric
seed task. If you could do that, it would be much
appreciated.
On Thu, June 9, 2016 5:40 pm, Chris K wrote:

Doing db:seed fails, this came from the master branch by adding the
peer

review. I don't recall it doing this until recently, so possibly
something

in the master changed?

A db:reset fixes it.

rake aborted!

ActiveRecord::InvalidForeignKey: PG::ForeignKeyViolation: ERROR:
insert

or update on table "annotation_texts" violates foreign key
constraint

"fk_annotation_labels_annotation_categories"

DETAIL: Key (annotation_category_id)=(17) is not present in table

"annotation_categories".

: INSERT INTO "annotation_texts"
("annotation_category_id", "content",

"created_at", "updated_at") VALUES ($1, $2, $3,
$4) RETURNING "id"

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:606:in

`exec_prepared'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:606:in

`block in exec_cache'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_adapter.rb:473:in

`block in log'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/notifications/instrumenter.rb:20:in

`instrument'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_adapter.rb:467:in

`log'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:605:in

`exec_cache'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:589:in

`execute_and_clear'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:160:in

`exec_query'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:192:in

`exec_insert'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:108:in

`insert'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/query_cache.rb:14:in

`insert'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/relation.rb:64:in

`insert'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:524:in

`_create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/counter_cache.rb:139:in

`_create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/locking/optimistic.rb:75:in

`_create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/attribute_methods/dirty.rb:132:in

`_create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:306:in

`block in _create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:555:in

`block (2 levels) in compile'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:92:in

`run_callbacks'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:778:in

`_run_create_callbacks'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:306:in

`_create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/timestamp.rb:57:in

`_create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:504:in

`create_or_update'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:302:in

`block in create_or_update'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:555:in

`block (2 levels) in compile'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:92:in

`run_callbacks'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:778:in

`_run_save_callbacks'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:302:in

`create_or_update'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:120:in

`save'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/bullet-5.0.0/lib/bullet/active_record42.rb:27:in

`save_with_bullet'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/validations.rb:37:in

`save'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/attribute_methods/dirty.rb:21:in

`save'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:286:in

`block (2 levels) in save'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:351:in

`block in with_transaction_returning_status'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in

`block in transaction'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/transaction.rb:184:in

`within_new_transaction'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in

`transaction'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:220:in

`transaction'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:348:in

`with_transaction_returning_status'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:286:in

`block in save'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:301:in

`rollback_active_record_state!'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:285:in

`save'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:34:in

`create'

/home/vagrant/Markus/lib/tasks/rubric.rake:61:in `block (5 levels) in
<top

(required)>'

/home/vagrant/Markus/lib/tasks/rubric.rake:60:in `times'

/home/vagrant/Markus/lib/tasks/rubric.rake:60:in `block (4 levels) in
<top

(required)>'

/home/vagrant/Markus/lib/tasks/rubric.rake:54:in `times'

/home/vagrant/Markus/lib/tasks/rubric.rake:54:in `block (3 levels) in
<top

(required)>'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/relation/delegation.rb:46:in

`each'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/relation/delegation.rb:46:in

`each'

/home/vagrant/Markus/lib/tasks/rubric.rake:22:in `block (2 levels) in
<top

(required)>'

/home/vagrant/Markus/db/seeds.rb:7:in `<top (required)>'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:268:in

`load'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:268:in

`block in load'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:240:in

`load_dependency'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:268:in

`load'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/railties-4.2.4/lib/rails/engine.rb:547:in

`load_seed'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/tasks/database_tasks.rb:250:in

`load_seed'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/railties/databases.rake:183:in

`block (2 levels) in <top (required)>'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/railties/databases.rake:142:in

`block (2 levels) in <top (required)>'

/home/vagrant/.rvm/gems/ruby-2.1.3/bin/ruby_executable_hooks:15:in
`eval'

/home/vagrant/.rvm/gems/ruby-2.1.3/bin/ruby_executable_hooks:15:in

`'

PG::ForeignKeyViolation: ERROR: insert or update on table

"annotation_texts" violates foreign key constraint

"fk_annotation_labels_annotation_categories"

DETAIL: Key (annotation_category_id)=(17) is not present in table

"annotation_categories".

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:606:in

`exec_prepared'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:606:in

`block in exec_cache'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_adapter.rb:473:in

`block in log'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/notifications/instrumenter.rb:20:in

`instrument'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_adapter.rb:467:in

`log'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:605:in

`exec_cache'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:589:in

`execute_and_clear'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:160:in

`exec_query'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:192:in

`exec_insert'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:108:in

`insert'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/query_cache.rb:14:in

`insert'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/relation.rb:64:in

`insert'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:524:in

`_create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/counter_cache.rb:139:in

`_create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/locking/optimistic.rb:75:in

`_create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/attribute_methods/dirty.rb:132:in

`_create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:306:in

`block in _create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:555:in

`block (2 levels) in compile'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:92:in

`run_callbacks'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:778:in

`_run_create_callbacks'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:306:in

`_create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/timestamp.rb:57:in

`_create_record'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:504:in

`create_or_update'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:302:in

`block in create_or_update'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:117:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:555:in

`block (2 levels) in compile'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:505:in

`call'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:92:in

`run_callbacks'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/callbacks.rb:778:in

`_run_save_callbacks'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/callbacks.rb:302:in

`create_or_update'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:120:in

`save'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/bullet-5.0.0/lib/bullet/active_record42.rb:27:in

`save_with_bullet'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/validations.rb:37:in

`save'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/attribute_methods/dirty.rb:21:in

`save'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:286:in

`block (2 levels) in save'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:351:in

`block in with_transaction_returning_status'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in

`block in transaction'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/transaction.rb:184:in

`within_new_transaction'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in

`transaction'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:220:in

`transaction'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:348:in

`with_transaction_returning_status'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:286:in

`block in save'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:301:in

`rollback_active_record_state!'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/transactions.rb:285:in

`save'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:34:in

`create'

/home/vagrant/Markus/lib/tasks/rubric.rake:61:in `block (5 levels) in
<top

(required)>'

/home/vagrant/Markus/lib/tasks/rubric.rake:60:in `times'

/home/vagrant/Markus/lib/tasks/rubric.rake:60:in `block (4 levels) in
<top

(required)>'

/home/vagrant/Markus/lib/tasks/rubric.rake:54:in `times'

/home/vagrant/Markus/lib/tasks/rubric.rake:54:in `block (3 levels) in
<top

(required)>'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/relation/delegation.rb:46:in

`each'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/relation/delegation.rb:46:in

`each'

/home/vagrant/Markus/lib/tasks/rubric.rake:22:in `block (2 levels) in
<top

(required)>'

/home/vagrant/Markus/db/seeds.rb:7:in `<top (required)>'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:268:in

`load'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:268:in

`block in load'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:240:in

`load_dependency'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activesupport-4.2.4/lib/active_support/dependencies.rb:268:in

`load'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/railties-4.2.4/lib/rails/engine.rb:547:in

`load_seed'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/tasks/database_tasks.rb:250:in

`load_seed'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/railties/databases.rake:183:in

`block (2 levels) in <top (required)>'

/home/vagrant/.rvm/gems/ruby-2.1.3/gems/activerecord-4.2.4/lib/active_record/railties/databases.rake:142:in

`block (2 levels) in <top (required)>'

/home/vagrant/.rvm/gems/ruby-2.1.3/bin/ruby_executable_hooks:15:in
`eval'

/home/vagrant/.rvm/gems/ruby-2.1.3/bin/ruby_executable_hooks:15:in

`'

Tasks: TOP => db:rubric

(See full trace by running task with --trace)

You are receiving this because you are subscribed to this thread.

Reply to this email directly or view it on GitHub:

https://github.com/MarkUsProject/Markus/issues/2611

--
David Liu
Assistant Professor, Teaching Stream
Department of Computer Science
University of Toronto
Bahen 4260

I wanted to assign this to myself actually, I just made an issue to keep it on my radar and put the logfile somewhere so in case it doesn't error out I can see what happened.

#2620

Fixed!


Eliminate CDN use

Prism in index.html
xterm.js in setupXTerm.js

Project Description
Hey, Contributor!
Please help us select the best next communication platform for the project!
Vote here: https://github.com/tisztamo/Junior/issues/78
Interpret issues freely. Need help or have ideas? Comment right here.
Note: We eat our own dog food. We use Junior to work on Junior. Please, do not turn off the audit feature!
Keep it friendly, that's our vibe.
Happy contributing!

xterm.js worked during local development (npm start), but not from external repos (npx junior-web)
https://github.com/xtermjs/xterm.js/issues/2878


Asking some questions about training parameters using softmax script

Hi, I have some questions about the training parameters in train_softmax.py script and I hope someone could answer and help me.
For batch size we have default = 90 and number of batches per epoch is 1000 which is a I believe is 90*1000 = 90,000. While I'm using CASIA Webface dataset, it contains +450K images and after using --validation_set_split_ratio to split the data, I have like 425K images in training set now. As I know, in each epoch we should pass all the images for training, while having batch_size=90 and epoch_size=1000 we just pass 90K images in a single epoch. Is this normal or does it pass other images in other epochs ? Should I change those parameters to pass all images ?
And for the three parameters for data augmentation : --random_crop, --random_rotate, --random_flip, while using those parameters do we increase the batch size, like using random flip would give us horizontal flipping of training images so we double the size of images here, am i right ? Same for rotating and cropping.
A final question is about the center loss factor, if we use this loss function, how is it performed while using softmax loss too ?
Could somebody explain me more please and thanks !

@neklom The parameter epoch_size should rather be named evaluate_every_n_steps or similar since it has nothing to do with the number of examples in the dataset. You can refer to davidsandberg's answers #374, #158

@vkasojhaa Hi and thanks for your replay it helped me understand more. Can you explain me more how are all of the images in the training set are passed.
And having center loss combined with the softmax loss, is this implementation similar to the center loss paper "A Discriminative Feature Learning Approach for Deep Face Recognition" ?
And thanks


Using usethis

bcgovr 0.1.5

Utilized as many usethis functions as was reasonable for bcgov format
removed devtools dependency
add nicer messages for what is added to the repo

Here is an example of the output:

This looks great! I haven't tested it locally, but I love it. There is also usethis::use_rstudio - did you look at that?


Add Transformers  as detailed in DETR

Describe the feature
A recent paper by facebook propose the use of transformers as a predictor. They used resnet as the backbone to extract the feature maps and obtained decent results on COCO.
Motivation
This approach is quite novel and the new component could be useful for rresearch/experimenting.
The approach may also be lighter as stated in the readme.
Related resources
Official repo: https://github.com/facebookresearch/detr
They also propose a simplement implementation as a demo.

Hi @roya0045 ,
Thanks for your suggestion. We do have plans to support DETR but the progress will be slow, e.g., in the following several months. PRs are welcomed.

Hi @roya0045 ,
Thanks for your suggestion. We do have plans to support DETR but the progress will be slow, e.g., in the following several months. PRs are welcomed.

快一年啦，出来没


"window.onload = function() {setTimeout(function() {window.startSession();}, 3000); };" - giving black screen

For  -- samples/js/browser/avatar or samples/js/browser/avatar/js/basic.js
Bug is :
if you call 'startSession' on onload it giving blank screen, however manually using a button if you call 'startSession' on click its working fine.
	window.onload = function() {
	          setTimeout(function() {window.startSession();}, 9000);
	      };

Describe the bug
Calling startSession within window.onload results in a blank screen. However, if I press "Stop Session" and then "Start Session" after it is enabled, it shows no error. The issue occurs only when startSession is invoked via window.onload; it works fine when triggered manually using a button click.
To Reproduce
Steps to reproduce the behavior:

Use the following code snippet:
window.onload = function() {
setTimeout(function() { window.startSession(); }, 9000);
};

Load the webpage and observe the blank screen.

Press "Stop Session" and then "Start Session" manually; it works without errors.

Expected behavior
startSession should function correctly when invoked during the window.onload event, just as it does when triggered manually via a button.
Platform, Operating System, and Programming Language

OS: macos 14

Additional context
No error messages or stack trace are visible. This behavior is only specific to using window.onload.
@pankopon  kindly help. thank you.
below is the code.

CodeOfError.html.txt

CodeOfError.html.txt
remove txt. name file as 'CodeOfError.html' and run.


Remove target checks from Cargo.toml.

This PR removes the conditional compilation flags in Cargo.toml that mention the target platform.
The reason why this was needed is that it is that, though wasm-bindgen and js-sys issue code that panics when compiled to x64, we want to be able to run cargo check without having to specify the target triple (and both those crates check fine even on x64).
Note that this since these are breaking changes, it would require at least a minor version bump.

Personally, I don't think there is enough justification for this change. You can always run cargo check with specified target. In fact, you have to select corresponding feature anyway. On the other hand, these cfgs help the end users to properly select feature and prevent wrong backend selected.
Anyhow, thanks for the PR.


feat(chart): download CSV chart contents from S3 for Athena charts

SUMMARY
Add a right click context menu option if the chart is an Athena table to download full chart contents directly from S3 bucket instead of through Superset
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS
Set required env vars
SUPERSET_REGION=<my_aws_region>
SUPERSET_WORKGROUP=<my_superset-workgroup>
SUPERSET_ATHENA_DB=<my_superset_db>
Enable feature flags
'DOWNLOAD_CSV_FROM_S3'
'SHOW_DEFAULT_CSV_OPTIONS'
Ensure Athena is set to automatically persist query results to S3 bucket in CSV format
Test download of chart through right click option.
ADDITIONAL INFORMATION

[x] Has associated issue:
[x] Required feature flags:
[x] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[x] Introduces new feature or API
[ ] Removes existing feature or API

No DB changes
resolves #31482

@william-fundrecs I assume this PR was mistakenly opened against upstream Superset, not your fork?

Can we do it without adding two feature flags, perhaps leaning on config? And do we need to single out S3? Could there be numerous other options for where people get/store their CSV?

Potentially yes, it made sense to me to add the feature flag to enable the S3 feature but perhaps not as sensible to use a feature flag to hide the default CSV/XLSX right click options, if there is a better way to hide these I can change to it.
This is coloured by our own needs, we wanted to hide the default options in favour of using the S3 download as it's a lot faster, our users will only be using full export and retrieving the file handle from S3 is multitudes faster than creating the dataframe and processing the file.
S3 was specified as this is existing Athena functionality, it can be configured to automatically persist query results to a CSV inside a configured bucket. Potentially there are other use cases for other DB engines but we only use Athena Presto and PostGreSQL in-house.
If someone wants to use this PR as a foundation for expanding file output locations that is fine with me.


get rid of use of Seq

we are passing the Seq type around in a bunch of places. This type is an abomination we should avoid, since Seq doesn't tell us if the set is bounded, and doens't tell us if the set is immutable. There are, in fact, places in our code where we end up with a mutable Buffer. Even worse though is that there are places that we are calling .length on a List. We should probably just converge on Vector all these places.

Would using the immutable Seq type (per http://hseeberger.github.io/blog/2013/10/25/attention-seq-is-not-immutable/) be a reasonable replacement?


Populate Remaining Empty Links

There are several links on the home page that have no corresponding page on the website. @doomspork should we create new pages for each of them?
Here are the ones I've noticed - I may be missing a few:
Header:

[x] Get Involved
[ ] Support

Footer:

[x] Blog > Announcements
[x] Blog > Today I Learned
[x] Blog > Reviews
[x] Project > Contributors
[x] Project > Get Involved
[ ] Project > Support

Get Involved

Yes we need a new page here. I don't 💯  know what I wanted to capture here but essentially a few CTAs for different opportunities to contribute:

Translations. This could include steps to how to translate or link out to another new page depending on how much content we have for that.
New content. This could direct people to the Issues on the content repo maybe with a new-lesson label filter?
Blog posts.
??

Support

This is going to be on me and may not be doable by launch. I am exploring some legal things here.

Blog > Announcements
Blog > Today I Learned
Blog > Reviews

For these we need to implement the functionality to filter blog posts by tags and then link to those 3 pre-filtered.

Project > Contributors

@doomspork should we remove the support button for now then?

@kinson that works for me 🙌

Thanks for sorting this out! I created #74 & #75 & #76 to address the remaining pieces of work.


HC Dashboard - Acute Illness - Malaria [3h]

Issue

Comparison to CHW

Diagnosed Cases - Number of malaria diagnoses made at the HC only
Hospital Referrals - Number of referrals to Hospital for malaria from HC only

Tasks

Create the page
wire the data

https://chw-ihangane.pantheonsite.io/app
QA Review
Found issues and questions:
Checked and approved

Only malaria cases created at the HC level are displayed.


Incorrect /health and /ready paths in contracts/ref/oss.yml

/health and /ready paths should not be prepended with /api/v2 in contracts/ref/oss.yml.
Shouldn't /health and /ready be treated the same as /ping here?
https://github.com/influxdata/openapi/blob/d42650242f99e448721160e435ff7db64d021eab/scripts/reference.sh#L24
The correct, resolved URLs should be [baseurl]/health and [baseurl]/ready.

related to #149

@danxmoran @glinton Can we set servers.url in ping, health, and ready src paths to override the root servers.url?


add pip package required files

Pull Request Description
What issue does this change request address? (Use "#" before the issue to link it, i.e., #42.)
close #83
What are the significant changes in functionality due to this change request?

For Change Control Board: Change Request Review
The following review must be completed by an authorized member of the Change Control Board.

[ ] 1. Review all computer code.
[ ] 2. If any changes occur to the input syntax, there must be an accompanying change to the user manual.
[ ] 3. Make sure the Python code and commenting standards are respected (camelBack, etc.) - See on the wiki for details.
[ ] 4. Regression tests have to complete successfully.
[ ] 5. If significant functionality is added, there must be tests added to check this. Tests should cover all possible options.  Multiple short tests are preferred over one large test.
[ ] 6. The merge request must reference an issue.  If the issue is closed, the issue close checklist shall be done.

Test installation using: pip install -i https://test.pypi.org/simple/ sr2ml-ravenframework


Add helpers for working with sqlboiler

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 28 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.2%) to 12.611%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

sqlboiler/sqlboiler.go
0
28
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
227

Relevant Lines:
1800

💛  - Coveralls


OpenAIRE4 oai_openaire metadata format support

As decided in our Entities meeting (https://wiki.lyrasis.org/display/DSPACE/2019-11-19+DSpace+7+Entities+WG+Meeting), the XOAI Default Context should only display Publications or non Entity Items. An xoai.xml change was required to address this.
IMPORTANT NOTE: This PR depends on https://github.com/DSpace/xoai/pull/68 to fix a transformation exception that is occurring with the current release of XOAI lib. I've already referenced the future release version on this PR (for testing purposes you will need to firstly install that version on your system).
We are proposing to split the XOAI method retrieveMetadata in parts to ease comprehension of it and to enable reusing of some parts, but the PR does not demand those changes to be made.
It also proposes an alternate virtual-metadata.xml.openaire file to replace the default one when installers want to use more fields from entities on OAI interface.
This additional virtual metadata will enable to represent something like this in this XML in the oai_openaire metadata format:
<datacite:creators>
  <datacite:creator>
    <datacite:creatorName>Evans, R.J.</datacite:creatorName>
    <datacite:affiliation>Institute of Science and Technology</datacite:affiliation>
    <datacite:nameIdentifier nameIdentifierScheme="ORCID"
                    schemeURI="http://orcid.org">
      1234-1234-1234-1234
    </datacite:nameIdentifier>
  </datacite:creator>
</datacite:creators>

in order to test it, you must first ensure you have the oai.cfg setting uncommented:
oai.enabled = true
(NOTE: you may have to restart the service)
If you want need additional metadata at the oai_openaire metadata format, you need to rename [/dspace/]config/spring/api/virtual-metadata.xml.openaire file and replace it with the existing one [/dspace/]config/spring/api/virtual-metadata.xml and restart your tomcat service container.
Then you may need to run the OAI import from the command line with the cleaning cache parameter to load all data into your default xoai database/Solr:
/dspace/bin/dspace oai import -c
And access the URL:
http://host/server/oai/request?verb=ListRecords&metadataPrefix=oai_openaire

Just wanted to add the test results of /dspace/bin/dspace oai import -c for the current status of this PR:
Without this feature (434 items):
OAI 2.0 manager action ended. It took 36 seconds.
With this feature (434 items):
OAI 2.0 manager action ended. It took 283 seconds.
With this feature 2nd time (434 items):
OAI 2.0 manager action ended. It took 277 seconds.
the result is almost 8 times slower... a different approach (perhaps based on enhancing virtual metadata) will be tried. Every suggestion to pull this is welcome.

Commit https://github.com/DSpace/DSpace/pull/2592/commits/019a6c42a33b60b2f0ec54a3f35dc9497d590c4c removed loading relationships for each item in XOAI interface.
I kept the other code changes in this class because tests resulted in less oai processing time in comparison with the same class in master branch.

After the most recent changes, using virtual metadata the processing time decreases to 20sec to process a total of 438 items using:
dspace/bin/dspace oai import -c
But an error occurred related with XSL transformation. That error is easily fixed with this PR: https://github.com/DSpace/xoai/pull/68

Hi @paulo-graca , I started reviewing this PR today, but I noticed:

Travis is currently failing
I can build this locally, but I don't have a good database with the OpenAIRE relationships to test the functionality
I really appreciate the cleanup of the ItemUtils to avoid a single method without JavaDocs containing over 200 lines of code. Thanks for splitting this into multiple smaller methods and adding JavaDocs. One question about this: did you also change the functionality in this refactor (anything in particular to verify during the reviewing)
The changes to the defaultFilter imply e.g. authors are not returned anymore. I'm not sure what the desired default behavior should be. Either way, I would recommend to create a separate filter for OpenAire to ensure the guidelines are still applied when a repository admin wants different behavior for the default filter.

With the database I currently used (which had 1055 items and 1147 relationships) and without the virtual-metadata.xml.openaire4 file (since I didn't have any such relationships), the indexing time increased from 0m51.988s to 1m14.820s when comparing master with this branch. This implies performance is now barely impacted

Weird, that shouldn't occur because no significant changes were done to the indexing process. This solution just uses virtual metadata and proposes an alternative metadata to be used if someone wants more data on the OAI. Did it also occur on second time? Thank you @benbosman for this earlier feedback!

Travis is currently failing
Yes, this is because I've referenced a POM dependency of a specific XOAI release version (3.2.11) that isn't currently available. Perhaps, if you the have time, you can also help with bringing this up - https://github.com/DSpace/xoai/pull/73
Until the release, Travis will continue to fail and you will need to test it manually (as you did). Thank you @benbosman !

I really appreciate the cleanup of the ItemUtils to avoid a single method without JavaDocs containing over 200 lines of code. Thanks for splitting this into multiple smaller methods and adding JavaDocs. One question about this: did you also change the functionality in this refactor (anything in particular to verify during the reviewing)

No, the previous method was simply slipped in parts no additions were made. We initially intend to add a method for adding relationship elements but it was removed in the commit - https://github.com/DSpace/DSpace/commit/019a6c42a33b60b2f0ec54a3f35dc9497d590c4c
Code changes that we made in this PR:

Debugging message on XOAI.java
Splitting ItemUtils in readable parts (not really required for this PR to work, can be reverted)
Adding dspace url field element (to have it available on the XOAI)

Other changes are related with "configurations" like the XSLT on the OAI interface and alternative settings of virtual metadata.
As a enhancement for virtual metadata we can discuss to have for a future version a different configuration based on the "media" type. I can have a specific configuration if content is used on angular, or a different one if it's used on OAI. As an analogy HTML can have use different CSS depending on the context:
<link media="screen" href="main.css" />
<link media="print" href="print.css" />

The changes to the defaultFilter imply e.g. authors are not returned anymore. I'm not sure what the desired default behavior should be. Either way, I would recommend to create a separate filter for OpenAire to ensure the guidelines are still applied when a repository admin wants different behavior for the default filter.

The solution presented is based on a decision in this meeting - https://wiki.lyrasis.org/display/DSPACE/2019-11-19+DSpace+7+Entities+WG+Meeting
Repositories that are currently used to expose Publications, if entities are introduced and the default filter if is not changed, the repository will expose mingled Publications, OrgUnits, Persons and external harvesters and aggregators won't know how to deal with this mingled data. So the default behavior should be to only expose Publications on the default context.
An I agree with having a detached filter, specific for OpenAIRE4.
For exposing entities, an alternative and specific context can be addressed. But for that I think it can be addressed in a subsequent PR (I will be glad to propose one) unrelated with OpenAIRE4.

@paulo-graca : XOAI version 3.2.11 has now been released with this fix https://github.com/DSpace/xoai/pull/68  Please feel free to update the POM to use that release, as it is required by this PR.  (Be aware the 3.2.11 release may take an hour or two to show up in Maven Central, but it'll appear here: http://repo2.maven.org/maven2/org/dspace/xoai/)

Thanks @paulo-graca for your updates:

I will retest the performance on a test server (I tested it locally, which implies another process may have impacted the performance). I was primarily noticing the performance is still good
Thanks for specifying the changes to ItemUtils, that's great
I will be able to test the xsl's and virtual metadata better if you have a database, otherwise it would be hard to perform local tests. This would allow me to finalize my review
The last commits you made also look good

Thank you @benbosman !
I'will be glad to send you my database, but for testing I think it's also useful if you tried without my database, because bugs might occur that way.
You only need to have something like this in your XOAI metadata format to start viewing something useful ([hostname]/server/oai/request?verb=GetRecord&metadataPrefix=xoai&identifier=oai:localhost:123456789/403).

    <element name="contributor">
         <element name="author">
            <element name="none">
               <field name="value">Terra, Silvia R.</field>
               <field name="value">Canario, Adelino</field>
               <field name="authority">virtual::226</field>
               <field name="confidence">-1</field>
               <field name="value">Cardoso, João</field>
               <field name="value">Félix, Rute</field>
            </element>
         </element>

This PR still doesn't yet cover 100% (I will add this to the description) of the guidelines. I'm still missing:

Publisher - https://openaire-guidelines-for-literature-repository-managers.readthedocs.io/en/v4.0.0/field_publisher.html
Source - https://openaire-guidelines-for-literature-repository-managers.readthedocs.io/en/v4.0.0/field_source.html
Subject - https://openaire-guidelines-for-literature-repository-managers.readthedocs.io/en/v4.0.0/field_subject.html
License Condition - https://openaire-guidelines-for-literature-repository-managers.readthedocs.io/en/v4.0.0/field_licensecondition.html
Coverage - https://openaire-guidelines-for-literature-repository-managers.readthedocs.io/en/v4.0.0/field_coverage.html
Geo location - https://openaire-guidelines-for-literature-repository-managers.readthedocs.io/en/v4.0.0/field_geolocation.html
Resource version - https://openaire-guidelines-for-literature-repository-managers.readthedocs.io/en/v4.0.0/field_resourceversion.html
Audience - https://openaire-guidelines-for-literature-repository-managers.readthedocs.io/en/v4.0.0/field_audience.html

Despite of "only have configurations", this PR is becoming large. So I will include in this PR all "configurations" that are Mandatory and "Mandatory when Available" and leave the other transformations for subsequent PRs.


adding videos to component docs

Adds @justinbmeyer 's component docs to the top of the component API page.

Added for route:

Added ATM example to the can.Map page and made it fit full column width:

@daffl @moschel Those videos are not part of the "@description" of the video.  And, they shouldn't be above the API signatures.
Our docs are very "precise" and focused at the top.  A sort description and quick summary of the APIs / signatures.  These videos should be at the bottom.


Cmd + R on macOS has conflict: Run Scene and Toggle Ruler

Hello everyone.
I think there is a bug related to run scene shortcut on MacOs Mojave
Godot Version:
3.2 Alpha 1
OS Version:
Mojave (10.14.6)
Issue Description:
On MacOs CMR + R combination hides / shows ruler. Run Scene shortcut was working perfectly on Godot 3.1 and 3.1.1. Even it still runs scene also effects to editor too.
To reproduce issue:
Create a scene and press CMD + R to run scene.
Minimal Project to Reproduce:
Empty project will be enough.
Thank for everyone's support in advance.

CC @KoBeWi

It's about rulers, not the ruler tool.

Any opinion about how to solve it ?
I think the shortcut is good on PC (ctrl + R) for ruler with F5/F6 for launch game/scene, I think we should keep them.
Should we replace the run shortcut or the ruler one ? Any suggestion ?

tbh, I don't remember the last time when I wanted to toggle the rulers (probably never). They would be fine without shortcut or with Ctrl + Shift + R.

It's not really that frequent, and just two mouseclicks away.
CTRL + SHIFT + R conflicts with Soft Reload Script.
I find that shortcuts are most useful when your hands are already on the keyboard, anyways.


Assert on Compaction of simple writes.

We are integrating leveldb into an application and it is quite simple. Our current test is based on basic examples.
We set options create_if_missing, then open the database and start writing data.
Out initial test is just to write a u64 key and a u64 value. A for loop increments the key and value.
After around 40K writes, we get this:
: db/version_set.cc:1293: leveldb::Compaction* leveldb::VersionSet::PickCompaction(): Assertion `!c->inputs_[0].empty()' failed.
Aborted

Looking at the code, it appears that the first level file is not set? This seems odd?
Can someone please explain this behavior? Do we need to use a specific option?

I should note. If we set the write buffer bigger than the data we are attempted to write, this error doesnt occur.
I believe this indicates that compaction never occurs.

Ok. I think we have found our issue. We are using the c interface and were using a comparator.
It looks like if you dont return 1, 0 and -1 in the comparison function weird things can happen. This resolved our problem (we think).


EdDSASigner- The privatekeyBytes is 64?

Hello,
I generated a private key by ED25519, and the private key is 32 bytes.
I want to use EdDSASigner to sign it, but it seems like the EdDSASigner will check the private key bytes.
From my understanding, the ED25519 private key should be 32 bytes, right? I'm not sure if it is a bug or my misunderstanding.
Expecting your reply!
Thanks.

how did you generate the private key?
This library [currently] uses @stablelib/ed25519, which uses the same conventions as libsodium and NaCl to represent key material.
In this convention, Ed25519 secret keys are represented on 64 bytes which I believe is actually the full keypair, not just the secret part, adding up to a total of 64 bytes.
I think after we manage to modularize this library (see #170) the EdDSASigner will likely lose that 64 byte check logic, or be replaced entirely by something new, depending on the underlying crypto package being used.

In this convention, Ed25519 secret keys are represented on 64 bytes which I believe is actually the full keypair, not just the secret part, adding up to a total of 64 bytes.

about the full keypair, does that means "privatekey+publickey" or "publickey + privatekey"?

Hello,
Any question is that:
when I call verifyEd25519, I got the error "Error: invalid_signature: Signature invalid for JWT", it seems like this error from the function verify(publicKey, message, signature).
Do you have any idea about it?
Thanks.

about the full keypair, does that means "privatekey+publickey" or "publickey + privatekey"?

It seems to be private+public. See the code

when I call verifyEd25519, I got the error "Error: invalid_signature: Signature invalid for JWT", it seems like this error from the function verify(publicKey, message, signature).

I have no idea without more details. What parameters are you sending to the function?

Hi, I think I have found the issue, it is all caused by my misuse of the full keypair. Really thanks a lot.

I'm happy to hear that you solved it. I'm closing this then.


Is it possible to use 2 proxies or to change the proxy after chrome has launched?

I'm looking for a way to use a different proxy depending on which request is intercepted. Is that supported by DevTools Protocol? I know you can launch with a proxy and use it throughout but I can't find any information about changing it once launched.

See #678.


List all accounts in the service

As a user
I need to list all accounts in the service
So that I can view a summary of all available accounts
Details and Assumptions
* The service provides an API endpoint for listing all account information.
* Users have access credentials to authenticate and access the service.

Acceptance Criteria
gherkin
Given that I have access to the service API
When I send a GET request to the endpoint for listing accounts
Then I should receive a response with a list of all accounts
And the response status code should indicate success (200 OK)


Problem with automatic transitions

So I'm trying to use automatic transitions in combination with guards, but something isn't working as expected.
Here's a demo project with a few changes to the ninja_frog project:
test.zip

Set an expression property: $StateChart.set_expression_property("velocity_length_squared", velocity.length_squared())
Node: On Idle -> remove event, add expression guard with velocity_length_squared <= 0.005
Node: On Moving -> remove event, add expression guard with velocity_length_squared > 0.005

If you look at the state chart debugger, the frog seems to always stay in the Move state.

It would seem I misinterpreted the spec  :

Automatic transitions are transitions that are triggered as soon as a state is entered, sometimes causing the state that was just entered to exit.

and later

Such a guarded automatic transition is checked immediately after the state is entered.

So in the plugin these transitions will only ever be evaluated when a state is entered. However further down the text we have

... with this automatic transition in play for as long as the state is active.  Every time the statechart handles an event, the guard condition for these automatic transitions are checked.  If the guard condition ever succeeds, then the transition happens.

And this part is currently not implemented which explains why our example isn't working as expected. So there would need to be an implementation that checks all transitions in play:

If a machine is in a state with a guarded automatic transition, then that guard is checked as often as possible.  Being event driven, the guards are effectively only checked whenever an event has been processed.

In our case it would probably make sense to check for these transitions:

when a new event is sent (no matter which event)
when an expression property is updated

This could incur a slight overhead and I would probably need to build up some internal caching to make such calls efficient (e.g. not having to traverse the whole state chart for transitions in play on every event/expression property update), but I think it would be a very useful thing to have.  Sorry, that you had to write two tickets to get it through and thanks for taking the time! I'll cook something up.

Excellent! :+1:
And yes, checking only for expression property updates totally makes sense.

This was a lot harder to get right than I thought. There are a million edge cases. I'm cautiously optimistic that I got all of them handled properly while not killing existing projects and not tanking the performance, but we'll see.

Great work! :+1:


Not working on NixOS

I have no idea why, as I have everything set up correctly. I can post any extra info as needed, but I have no idea where to even begin.

#115

My timeoutlen is set to 1000 and it still doesn't work. Should I set it higher?

On NixOS, you install Neovim plugins via their builtin package manager, Nix. It installs the plugin in the Start or Opt folder depending on if the plugin is lazyloaded or not. However, it installs the plugin as comment.nvim instead of Comment.nvim. Could this change something?

That, I have no idea. You should ask other people that have similar config as yours.

A fix has been found! I have to run :runtime after/plugin/Comment.lua because :packadd doesn't automatically source the after directory in the opt directory. Someone in the thread called the use of the after directory an abuse, so I'm wondering why that is. What is the after directory used for?
PS: Since I found a working solution, I'll mark this as closed.

A fix has been found! I have to run :runtime after/plugin/Comment.lua because :packadd doesn't automatically source the after directory in the opt directory. Someone in the thread called the use of the after directory an abuse

Hmmm very interesting. I never thought that this might well be an anti-pattern or something. You said you lazyload the plugin, could you try an sync load the plugin? And tell me whether this issue still there or not. As I use packer.nvim and do lazyload. I never faced this issue myself.

so I'm wondering why that is. What is the after directory used for?

I am using it for setting up <Plug> mappings.

Hi @ObsidianChickenz, you might not need that workaround after 4818a4c2ecf64ace6358b81073ad5d76f657953d :)


[BUG] wrong port number in diagram

Diagram in Chapter 1 shows TCP port 5986, should show port 5985 to be consistent with the rest of the documentation and the system behaviour.
https://github.com/ukncsc/lme/blob/master/docs/eventforwarding_overview.jpg

Hi @m0gjr - I will change this, I agree that it should be consistent, Those which choose to use HTTPS connections would require 5986 so this will also be clarified in the documentation


HTML

HTLM
User Story
As a BootCamp student
I want the prework notes to be structure on a webpage
so that I can easily find and read information
Acceptacne Cirteria
GIVEN a Prework Study Guide website
WHEN I visit the website in my browser
THEN I see four boxes titled HTML, CSS, Git, and JavaScript with associated notes listed

added the index.html file to main.


Fixed several incorrect printf format in nbdebug(...) calls

Adding  __attribute__((format(printf, 1, 2))) to nbdbg(char *, ...)
and compiling with -DNBDEBUG revealed several incorrect printf
formats, fixed in this PR.

Codecov Report

Merging #3992 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3992      +/-   ##
==========================================
+ Coverage   79.13%   79.14%   +<.01%
==========================================
  Files         105      105
  Lines      141110   141110
==========================================
+ Hits       111670   111676       +6
+ Misses      29440    29434       -6

Impacted Files
Coverage Δ

src/netbeans.c
27.06% <ø> (ø)
:arrow_up:

src/gui_beval.c
61.57% <0%> (-0.44%)
:arrow_down:

src/if_xcmdsrv.c
83.84% <0%> (-0.18%)
:arrow_down:

src/screen.c
80.3% <0%> (-0.03%)
:arrow_down:

src/message.c
76.6% <0%> (ø)
:arrow_up:

src/window.c
83.56% <0%> (ø)
:arrow_up:

src/terminal.c
78.25% <0%> (ø)
:arrow_up:

src/gui.c
58.1% <0%> (+0.05%)
:arrow_up:

src/ui.c
50.22% <0%> (+0.07%)
:arrow_up:

src/channel.c
83.16% <0%> (+0.07%)
:arrow_up:

... and 2 more

Continue to review full report at Codecov.

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


Deploying to Celo/Celo Alfajores panics and crashes

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

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (427c1b5 2022-12-07T00:09:22.004732Z)
What command(s) is the bug in?
forge script
Operating System
macOS (Apple Silicon)
Describe the bug
I'm deploying to celo alfajores using forge script --broadcast --rpc-url <> --private-key <> <path to script>.
Specifically deploying the permit2 contracts. An example of the scripts I've been running to reproduce the issue:
forge script --broadcast --rpc-url <> --private-key <> script/DeployPermit2.s.sol:DeployPermit2

gets a panic application crashed error

and
forge script --broadcast --rpc-url <> --private-key <> --with-gas-price 2797229 script/DeployPermit2.s.sol:DeployPermit2

gets a Failed to estimate EIP1559 fees.

Thanks!
What's the right RPC URL for us to use? Do you have a faucet link?

i've been using infura but think this also works? https://alfajores-forno.celo-testnet.org/
here is the faucet https://celo.org/developers/faucet

Yeah it was the case.
@snreynolds while the PR goes through,  you can add --legacy to your command for it to work meanwhile.

Do we not want to auto-detect that for legacy chains and default to legacy transactions instead of requiring the user to do that?

Merged both!

@gakonst @joshieDo can we close it as resolved?

Hi all, I know we've closed this. The deploy to alfajores did work (even without the legacy flag) but the verification does not. Would it be helpful for me to open a new issue for this?

Yep pls open new issue, verification should be working as well, but maybe it's flaky?


python312Packages.simsimd: 6.2.1 -> 6.2.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python312Packages.simsimd is: Portable mixed-precision BLAS-like vector math library for x86 and ARM
meta.homepage for python312Packages.simsimd is: https://github.com/ashvardanian/simsimd
meta.changelog for python312Packages.simsimd is: https://github.com/ashvardanian/SimSIMD/releases/tag/v6.2.2
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.2.2 with grep in /nix/store/2hplcqpbkcyqv2w40sw0chwxzgnphyj6-python3.12-simsimd-6.2.2
found 6.2.2 in filename of file in /nix/store/2hplcqpbkcyqv2w40sw0chwxzgnphyj6-python3.12-simsimd-6.2.2

Rebuild report (if merged into master) (click to expand)

10 total rebuild path(s)

10 package rebuild(s)

First fifty rebuilds by attrpath

immich-machine-learning
python311Packages.albucore
python311Packages.albumentations
python311Packages.insightface
python311Packages.simsimd
python312Packages.albucore
python312Packages.albumentations
python312Packages.insightface
python312Packages.simsimd

Instructions to test this update (click to expand)

Either download from the cache:
nix-store -r /nix/store/2hplcqpbkcyqv2w40sw0chwxzgnphyj6-python3.12-simsimd-6.2.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nixpkgs-update-cache.nix-community.org/' \
  --option trusted-public-keys '
  nixpkgs-update-cache.nix-community.org-1:U8d6wiQecHUPJFSqHN9GSSmNkmdiFW7GW7WNAnHW0SM=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The nixpkgs-update cache is only trusted for this store-path realization.)
For the cached download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python312Packages.simsimd https://github.com/r-ryantm/nixpkgs/archive/8308e4fa982e9744df3c61528969f1400937b5bb.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/8308e4fa982e9744df3c61528969f1400937b5bb#python312Packages.simsimd

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/2hplcqpbkcyqv2w40sw0chwxzgnphyj6-python3.12-simsimd-6.2.2
ls -la /nix/store/2hplcqpbkcyqv2w40sw0chwxzgnphyj6-python3.12-simsimd-6.2.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 18 packages built:

immich-machine-learning
immich-machine-learning.dist
python311Packages.albucore
python311Packages.albucore.dist
python311Packages.albumentations
python311Packages.albumentations.dist
python311Packages.insightface
python311Packages.insightface.dist
python311Packages.simsimd
python311Packages.simsimd.dist
python312Packages.albucore
python312Packages.albucore.dist
python312Packages.albumentations
python312Packages.albumentations.dist
python312Packages.insightface
python312Packages.insightface.dist
python312Packages.simsimd
python312Packages.simsimd.dist

Maintainer pings
cc @dotlambda for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

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

@dotlambda @NickCao this fails bad on aarch64-linux
https://gist.github.com/PerchunPak/b4a329712d9e29b016a5e375aedb966d
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 366921

aarch64-linux

:x: 18 packages failed to build:

immich-machine-learning
immich-machine-learning.dist
python311Packages.albucore
python311Packages.albucore.dist
python311Packages.albumentations
python311Packages.albumentations.dist
python311Packages.insightface
python311Packages.insightface.dist
python311Packages.simsimd
python311Packages.simsimd.dist
python312Packages.albucore
python312Packages.albucore.dist
python312Packages.albumentations
python312Packages.albumentations.dist
python312Packages.insightface
python312Packages.insightface.dist
python312Packages.simsimd
python312Packages.simsimd.dist

x86_64-darwin

:white_check_mark: 16 packages built:

python311Packages.albucore
python311Packages.albucore.dist
python311Packages.albumentations
python311Packages.albumentations.dist
python311Packages.insightface
python311Packages.insightface.dist
python311Packages.simsimd
python311Packages.simsimd.dist
python312Packages.albucore
python312Packages.albucore.dist
python312Packages.albumentations
python312Packages.albumentations.dist
python312Packages.insightface
python312Packages.insightface.dist
python312Packages.simsimd
python312Packages.simsimd.dist

aarch64-darwin

:white_check_mark: 16 packages built:

python311Packages.albucore
python311Packages.albucore.dist
python311Packages.albumentations
python311Packages.albumentations.dist
python311Packages.insightface
python311Packages.insightface.dist
python311Packages.simsimd
python311Packages.simsimd.dist
python312Packages.albucore
python312Packages.albucore.dist
python312Packages.albumentations
python312Packages.albumentations.dist
python312Packages.insightface
python312Packages.insightface.dist
python312Packages.simsimd
python312Packages.simsimd.dist

But it builds on ofborg?

Oh, sorry, it was broken before this change with --rebuild. Actually, this version only updates docs. Probably emulation issues, I should apply to an aarch box...


When updating stack add option to auto pull new images

Is your feature request related to a problem? Please describe.
When you update a stack it does not pull down the newest image, and if you try and update a container
so it pulls the newest image it gives a error

(after that you can then re-update the stack and it will start correctly with the new image)
Describe the solution you'd like
a check box before the "Update the stack" button that says
"Always pull the image for all containers" knida like

for containers

Ticket update by Bala Natarajan<EMAIL_ADDRESS>Hi
pl share more details on this context, docker version. is it on swarm or
standalone docker. also share the compose file

portainer version
2.1.1
Docker details

Version
20.10.1 (API: 1.41)

Root directory
/var/lib/docker

Storage Driver
overlay2

Config
Standalone (No swarm)
Stack
version: '3'
services:
    app:
        container_name: SA7Website
        restart: always
        image: madpeter/streamadmin_r7:azurecastdev
        networks:
        - streamadmin
        ports:
        - 8082:80
        expose:
        - '8882/tcp'
        depends_on:
        - db
        - redis
        environment:
        - SITE_HOST=!!PUTDOMAINHERE!!
        - SITE_TITLE=!!PUTTITLEHERE!!
        - DB_HOST=db
        - DB_DATABASE=!!PUTDBNAMEHERE!!
        - DB_USERNAME=!!PUTDBUSERHERE!!
        - DB_PASSWORD=!!PUTPWHERE!!
        - REDIS_HOST=redis
        - SESSION_DRIVER=redis
        - CACHE_DRIVER=redis
        - INSTALL_OK=1
        volumes:
          - type: bind
            source: /srv/logs
            target: /srv/logs

    db:
        container_name: SA7Db
        image: mariadb
        restart: always
        networks:
        - streamadmin
        environment:
        - MYSQL_RANDOM_ROOT_PASSWORD=yes
        - MYSQL_ALLOW_EMPTY_PASSWORD=no
        - MYSQL_USER=!!PUTDBUSERHERE!!
        - MYSQL_PASSWORD=!!PUTPWHERE!!
        - MYSQL_DATABASE=!!PUTDBNAMEHERE!!
        volumes:
        - streamadmin-db:/var/lib/mysql

    phpmyadmin:
        container_name: SA7PHPmyAdmin
        environment:
        - PMA_HOST=db
        networks:
        - streamadmin
        image: 'phpmyadmin/phpmyadmin:latest'
        ports:
        - 8081:80
        expose:
        - '8881/tcp'
        depends_on:
        - db

    redis:
        container_name: SA7Redis
        image: redis:4.0-alpine
        networks:
        - streamadmin

networks:
  streamadmin:

volumes:
  streamadmin-db:

ENV values starting and ending with !! should be replaced with something :P

It would be very desirable if there was a way to pull images associated with a stack deployed by hand in Portainer UI. My use case is gitlab-ce container running on certain server and when I need to update it, I have to go to "Images" or Docker CLI and pull newest gitlab-ce because stack editor doesn't have "pull" functionality.

I support this issue because without it, having GitHub Actions trigger the webhook of a stack does nothing if the container uses the latest tag (or similiar, e.g. main for the main branch). The stack is indeed re-deployed because there were changes in the Git repository, but Portainer uses the same old image as before instead of pulling the updated latest version of the image. Please allow forcing to pull the latest images.
If there is already a way to achieve this behavior, please let us know.

How am I supposed to auto update a stack when portainer isnt actually pulling the latest image that my compose file is referring to 😂

My workaround is to just pull the image in the Images tab in portainer and then restarting the stack.

+1

Any update? This is a must have when using CI/CD

+1
I am also using this feature in CI/CD and sometimes automatic webhook update fails, because the newest image isn't pulled

Seems like this is available now, but is a Business Edition only feature:
https://www.portainer.io/update-stacks?from=stack-pull-image

Issue stays open as I am not a business :( and I wonder when they came up with that "idea" <_<

Issue stays open as I am not a business :( and I wonder when they came up with that "idea" <_<

I was also surprised - most of the other business edition features I could accept were business focused (easy setup of Single Sign on and the like) but I can't understand how this could be considered a business centric feature..

So this is just staying a Business feature and leaves the rest of us to figure out unintuitive and inconvenient workarounds? Cool

It looks like in the 2.15 release of Portainer this feature is no longer business edition only - when i click update stack I get a button to enable pulling the latest image.

Worth upgrading to 2.15 if you haven't already.

In 2.15.1 we made this feature available to both Business Edition and Community Edition. As such, I'm closing this ticket.


Fix an error for the Lockfile parser when it contains incompatible BUNDLED WITH versions

I recently found myself running rubocop against a folder with a lockfile generated with bundler v1. Bundler automatically loads the bundler version that is contained in the gemfile, even if locally you may have something more modern.
Bundler changed something between v1 and v2. In v1 parser.dependencies it used to return an array. Simply don't use the parser then, v2 is already 5 years old.
Stacktrace

undefined method 'values' for an instance of Array
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/lockfile.rb:32:in 'RuboCop::Lockfile#dependencies'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/cli/command/suggest_extensions.rb:74:in 'RuboCop::CLI::Command::SuggestExtensions#all_extensions'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/cli/command/suggest_extensions.rb:96:in 'RuboCop::CLI::Command::SuggestExtensions#not_installed_extensions'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/cli/command/suggest_extensions.rb:88:in 'RuboCop::CLI::Command::SuggestExtensions#extensions'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/cli/command/suggest_extensions.rb:18:in 'RuboCop::CLI::Command::SuggestExtensions#run'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/cli/command.rb:11:in 'RuboCop::CLI::Command.run'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/cli/environment.rb:18:in 'RuboCop::CLI::Environment#run'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/cli.rb:122:in 'RuboCop::CLI#run_command'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/cli.rb:134:in 'RuboCop::CLI#suggest_extensions'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/cli.rb:129:in 'block in RuboCop::CLI#execute_runners'
<internal:kernel>:91:in 'Kernel#tap'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/cli.rb:129:in 'RuboCop::CLI#execute_runners'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/cli.rb:51:in 'block in RuboCop::CLI#run'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/cli.rb:81:in 'RuboCop::CLI#profile_if_needed'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/lib/rubocop/cli.rb:43:in 'RuboCop::CLI#run'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/exe/rubocop:19:in 'block in <top (required)>'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/3.4.0+0/benchmark.rb:313:in 'Benchmark.realtime'
/home/earlopain/.rbenv/versions/3.4-dev/lib/ruby/gems/3.4.0+0/gems/rubocop-1.64.1/exe/rubocop:19:in '<top (required)>'
/home/earlopain/.rbenv/versions/3.4-dev/bin/rubocop:25:in 'Kernel#load'
/home/earlopain/.rbenv/versions/3.4-dev/bin/rubocop:25:in '<main>'

I'm not sure how to add worthfile tests for this. I think its fine without.

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[ ] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Thanks!


Compilation with Eigen 3.0.x now fails

This is caused by those lines:
const Vector meanReading =
		(mPts.reading.features.topRows(dimCount-1).array().rowwise() * w.array().transpose()).rowwise().sum() * w_sum_inv;
const Vector meanReference =
		(mPts.reference.features.topRows(dimCount-1).array().rowwise() * w.array().transpose()).rowwise().sum() * w_sum_inv;

The rowwise() multiplication was not yet defined in Eigen 3.0.x, but it is in more recent versions of Eigen. This is clear on Ubuntu 12.04.
@bkueng if you have a quick fix that doesn't used a rowwise multiplication that would be great. Otherwise, I'll have a deeper look later.

oh I didn't see that. Yes, this one should work:
OutlierWeights& w = mPts.weights;
const Vector meanReading = mPts.reading.features.topRows(dimCount-1).cwiseProduct(w.replicate(dimCount-1, 1)).rowwise().sum() / w.sum();
const Vector meanReference = mPts.reference.features.topRows(dimCount-1).cwiseProduct(w.replicate(dimCount-1, 1)).rowwise().sum() / w.sum();

(if you use const Vector& w = mPts.weights, then you need to use w.transpose() afterwards)
However it uses replicate, which I assume does memory allocations. Thus the current solution would be preferable once Eigen is updated on all distros.

Great I'll surround the other lines with #if EIGEN_MAJOR_VERSION > 0.
Any reasons why using .../ w.sum() instead of ... * w_sum_inv which is already precomputed?

the precomputed value is fine, I just took my initial version of the code.


Split a column into two sections?

I have an email template that I'm having problems with. What I'm trying to do is essentially split a column into 2 sections, if this is even possible. I've attached the full MJML code and a diagram of what I'm actually wanting, fingers crossed someone knows a better way around it as I'm stuck for ideas.

Here is the code: https://pastebin.com/Akx9xViD (it bugged out when I just added the code quotes so I just pasted it into PasteBin! BTW I'm just using the try-it-live site, so I'm not sure on the version, I believe it's v4.
Thanks in advanced!

Hi!
I'm really sorry but i'm not really sure what you want to achieve here 🤔
column cannot be split into sections because a section of an email is basically a "row" of your email.
You should be really careful when creating an email as a website because it doesn't behave like you would expect in email clients.

I'm really sorry but I'm not really sure what you want to achieve here 🤔
So the black boxes are 2/3 columns that are in a section, I'd like to essentially have the 2 columns that are there and half them, so they act independently from the top half. I can't add another section (which would be nice and easy) as it would be placed below Got a gift card?. Ideally, I would love to make a new section, trim it down to say 70% and slot it in the gap under the existing options, if that way of putting it makes sense for what I'm trying to achieve?

Mh, so what won't you just use regular table with 2 td instead of a section ?

I'm closing it, because I think the solution is to have a table width 2 td here if you need to split it.
Feel free to reopen if needed