Discussion about unique indexes

Hi @swanandp this PR is not meant to be merged but only to start a discussion on uniqueness constraints.
In current codebase unique indexes cannot be added to position columns otherwise lot of tests will fail. This is because there are some queries which swap values between rows and other issues with update order.
For instance a simple UPDATE table SET position = position + 1 will lead to duplicate values unless updates are executed in order (with a non standard SQL ORDER BY in UPDATE queries).
I think is worth to mention this in the readme because for list behavior I'd expect to be able to do one of the following
add_index :table, :position, unique: true # for unscoped lists
add_index :table, [:parent_id, :position], unique: true # for scoped lists

In any case it will be possible to make unique index working by using this approach in MySQL and using DEFERRABLE constraints in Postgres. I don't know if this is possible in SQLite.
Also a lot of queries can be rewritten using a standard CASE statement (example) to halve the number of executed queries and to avoid unique issue in Postgres.
If you're interested in this I can try to identify problematic method and they can be rewritten by wrapping them in a new method, something like
# Obviously this need to be customized according to adapter, this version is for MySQL
def without_unique_checks(&block)
  connection.execute('SET UNIQUE_CHECKS = 0;')
  block.call
  connection.execute('SET UNIQUE_CHECKS = 1;')
end

# For instance
def move_to_top
  without_unique_checks do
    increment_positions_on_higher_items
    assume_top_position
  end
end

What do you think?

Is this still alive?

I think this is worthy of pursuing. It would reduce bugs around multiple processes working on the list at the same time (with locking) etc...

Definitely worth pursuing. @fabn the current implementation might not work for MySQL. Have you tested if it does?

@swanandp I did not tested it, it was just a proof of concept. I'm afraid it won't work in MySQL and there's no trace of DEFERRED CONSTRAINT support in both MySQL and Sqlite.

That's unfortunate. Do you want to close this for now?

That's unfortunate. Do you want to close this for now?

I don't know. I still think that we need to support uniqueness constraint, imho it's very important that this gem supports it. We have 2 choices here:

Use the single query approach and make it working with unique constraint under PostgreSQL and leave the situation as is for other DBs.
Rewrite some methods to work with unique constraint.

Latter approach can be implemented by clearing current element position before updating other list elements, in this way even with immediate constraints there won't be any issue in database.
I did a quick test in a local branch with this change applied on top of unique index commit in this PR
diff --git a/lib/acts_as_list/active_record/acts/list.rb b/lib/acts_as_list/active_record/acts/list.rb
index f7adb0a..004c188 100644
--- a/lib/acts_as_list/active_record/acts/list.rb
+++ b/lib/acts_as_list/active_record/acts/list.rb
@@ -146,6 +146,7 @@ module ActiveRecord
           return unless lower_item

           acts_as_list_class.transaction do
+            set_list_position(nil) # Avoid duplicate positions
             lower_item.decrement_position
             increment_position
           end
@@ -156,6 +157,7 @@ module ActiveRecord
           return unless higher_item

           acts_as_list_class.transaction do
+            set_list_position(nil) # Avoid duplicate positions
             higher_item.increment_position
             decrement_position
           end
@@ -166,6 +168,7 @@ module ActiveRecord
         def move_to_bottom
           return unless in_list?
           acts_as_list_class.transaction do
+            set_list_position(nil) # Avoid duplicate positions
             decrement_positions_on_lower_items
             assume_bottom_position
           end
@@ -176,6 +179,7 @@ module ActiveRecord
         def move_to_top
           return unless in_list?
           acts_as_list_class.transaction do
+            set_list_position(nil) # Avoid duplicate positions
             increment_positions_on_higher_items
             assume_top_position
           end
@@ -184,8 +188,9 @@ module ActiveRecord
         # Removes the item from the list.
         def remove_from_list
           if in_list?
-            decrement_positions_on_lower_items
-            set_list_position(nil)
+            current_position = send(position_column).to_i
+            set_list_position(nil) # Avoid duplicate positions
+            decrement_positions_on_lower_items(current_position)
           end
         end

I still have a lot of failing tests but they decreased from 62 in master with unique index to 45 after this change. There is still a lot of work to do because all methods used to adjust list positions (decrement_positions_on_lower_items, increment_positions_on_lower_items, shuffle_positions_on_intermediate_items) rely on self.position being present to do their job.
There is a lot of work to do to make this working but it might be worth to try.

Ok, yes you have a good point. I did think about nulling the value and there's certainly nothing wrong with that, especially within a transaction. Definitely keep going if you're happy to :)

@fabn, how about using a temporary table to generate the updates then merge this all at once? I've seen mention of that out there. Not sure if it's workable across all database types. At least we have a test suite that tests all the databases now though.

I wonder why it was not posted/discussed here.. maybe this solution could be incorporated into codebase?

https://github.com/swanandp/acts_as_list/issues/245

I did think about nulling the value and there's certainly nothing wrong with that, especially within a transaction

This will fail not null constraint. Say, I want to enforce not null constraints to have list of items without missing pieces. It's important case. null can be replaced with -1, for example. It wont allow strict constraint like (position > 0), still way better than nullable column.

Closed by https://github.com/swanandp/acts_as_list/pull/246

Can anyone clarify why this wasn't accepted? The CASE expression way would work in any database.

Hi @faucct, I think this PR wasn't meant to be merged (See the opening comment). If you'd like to pursue this though, check through all the referenced tickets in this thread to get a sense of the history of the problem and what is currently in place (#246), then maybe put up a PR for us to see? :)


Include BenchmarkDotNet

As discussed in #702
It is a very nice idea to have a separate project which checks the performance of commonly used functions like RenderComponent, Find, etc.
For that we can introduce BenchmarkDotNet and define some scenarios to get a better understanding where we could potentially optimize our code.

Is this not closed @linkdotnet?

Indeed!


Users don't usually want -Werror

Remove -Werror from lib/Makefile
Wasn't sure, didn't change test/special/c90_bool/Makefile
compiler-test-% (for project maintainers) already includes -Werror

Closes #23


fuuzy: correctly expand option names

Pass the value of fuzzy from ExpandFromContext down to ExpandSettings.
In particular, in ExpandSettings fuzzy might be set to zero (because the
expansion type is not supported by fuzzy matching), but later on in
ExpandSettings Vim would still try to expand using the fuzzy matching.
closes #10318

Is the failure in Test_set_completion_2() relevant?

yes, let me check it. Not sure why it did not expand to the full option name

Ah, I think the failure was because the test did not check for the 'termguicolors' feature

okay, test succeeds now


hema's pull request

Related issue

What changes does this PR do?
Screenshots (If any)
Questions

this is a practice pull request


pre-release docs updates

Proposed changes:

review a few more pages on https://github.com/RasaHQ/rasa/issues/6775
remove references to the release candidate
update sidebar for http api
auto-expand the main things in the sidebar (https://rasa-hq.slack.com/archives/C016FLYV4QN/p1601458540058800?thread_ts=1601455391.052100&cid=C016FLYV4QN)
hide "miragte from" until these pages are checked again (https://github.com/RasaHQ/rasa/issues/6474)

Status (please check what you already did):

[ ] added some tests for the functionality
[ ] updated the documentation
[ ] updated the changelog (please check changelog for instructions)
[ ] reformat files using black (please check Readme for instructions)

@erohmensing can you take a look at the merge conflict?

fixed, do we force merge? :D

sure, there is going to be enough builds to catch if something wen't wrong 😂


Added the project for the issue #198

Description
Number Guessing Game
Fixes  #198
Type of change

New feature

Checklist:
Please tick all the boxes that are fulfilled by your Pull request

[x] I have named my files and folder according to this project's guidelines

[x] My code follows the style guidelines of this project

[x] I have commented my code, particularly in hard-to-understand areas

[x] I have created a helpful and easy to understand README.md

[x] I have included a requirements.txt file(if external libraries are required)

[x] My changes dont produce any warnings.

[x] I have added a working sample/screenshot of the script

@leader2one  LGTM, Awesome Job.

@leader2one LGTM, Awesome Job. You can also add the number of guesses it took the user to win and increase the range of numbers to make it more challenging, eg:1 to 100.

thanks. Also I placed an example working screenshot in readme file. Is image being showed ?

@leader2one LGTM, Awesome Job. You can also add the number of guesses it took the user to win and increase the range of numbers to make it more challenging, eg:1 to 100.

thanks. Also I placed an example working screenshot in readme file. Is image being showed ?

No, it wasn't showing But I fixed it.

validate your code with PEP8 standards
Check PEP8 Validation
flake8 main.py
Suggestions:
main.py:1:14: W291 trailing whitespace
main.py:2:1: W293 blank line contains whitespace
main.py:3:30: W291 trailing whitespace
main.py:4:1: W293 blank line contains whitespace
main.py:5:35: W291 trailing whitespace
main.py:6:27: W291 trailing whitespace
main.py:7:30: W291 trailing whitespace
main.py:8:1: W293 blank line contains whitespace
main.py:9:32: W291 trailing whitespace
main.py:10:34: W291 trailing whitespace
main.py:11:36: W291 trailing whitespace
main.py:12:32: W291 trailing whitespace
main.py:13:16: W291 trailing whitespace
main.py:15:1: W293 blank line contains whitespace
main.py:16:43: W291 trailing whitespace
main.py:17:1: W293 blank line contains whitespace
main.py:18:33: W291 trailing whitespace
main.py:19:13: W291 trailing whitespace
main.py:21:1: W293 blank line contains whitespace
main.py:22:36: W291 trailing whitespace
main.py:23:25: W291 trailing whitespace
main.py:24:1: W293 blank line contains whitespace
main.py:25:38: W291 trailing whitespace
main.py:26:36: W291 trailing whitespace
main.py:27:24: W291 trailing whitespace
main.py:28:1: W293 blank line contains whitespace
main.py:29:36: W291 trailing whitespace
main.py:30:35: W291 trailing whitespace
main.py:31:42: W291 trailing whitespace
main.py:32:37: W291 trailing whitespace
main.py:33:36: W291 trailing whitespace
main.py:34:80: E501 line too long (94 > 79 characters)
main.py:35:9: E265 block comment should start with '# '
main.py:37:1: W293 blank line contains whitespace
main.py:38:32: W291 trailing whitespace
main.py:39:29: W291 trailing whitespace
main.py:40:27: W291 trailing whitespace
main.py:41:25: W291 trailing whitespace
main.py:42:75: W291 trailing whitespace
main.py:43:1: W293 blank line contains whitespace
main.py:44:33: W291 trailing whitespace
main.py:45:33: W291 trailing whitespace
main.py:46:13: W291 trailing whitespace
main.py:47:10: W291 trailing whitespace
main.py:48:75: W291 trailing whitespace
main.py:49:1: W293 blank line contains whitespace
main.py:50:40: W291 trailing whitespace
main.py:52:1: W391 blank line at end of file

sorry i do not understand. can you clearify more? or give hint?

validate your code with PEP8 standards
Check PEP8 Validation
flake8 main.py
Suggestions:
main.py:1:14: W291 trailing whitespace
main.py:2:1: W293 blank line contains whitespace
main.py:3:30: W291 trailing whitespace
main.py:4:1: W293 blank line contains whitespace
main.py:5:35: W291 trailing whitespace
main.py:6:27: W291 trailing whitespace
main.py:7:30: W291 trailing whitespace
main.py:8:1: W293 blank line contains whitespace
main.py:9:32: W291 trailing whitespace
main.py:10:34: W291 trailing whitespace
main.py:11:36: W291 trailing whitespace
main.py:12:32: W291 trailing whitespace
main.py:13:16: W291 trailing whitespace
main.py:15:1: W293 blank line contains whitespace
main.py:16:43: W291 trailing whitespace
main.py:17:1: W293 blank line contains whitespace
main.py:18:33: W291 trailing whitespace
main.py:19:13: W291 trailing whitespace
main.py:21:1: W293 blank line contains whitespace
main.py:22:36: W291 trailing whitespace
main.py:23:25: W291 trailing whitespace
main.py:24:1: W293 blank line contains whitespace
main.py:25:38: W291 trailing whitespace
main.py:26:36: W291 trailing whitespace
main.py:27:24: W291 trailing whitespace
main.py:28:1: W293 blank line contains whitespace
main.py:29:36: W291 trailing whitespace
main.py:30:35: W291 trailing whitespace
main.py:31:42: W291 trailing whitespace
main.py:32:37: W291 trailing whitespace
main.py:33:36: W291 trailing whitespace
main.py:34:80: E501 line too long (94 > 79 characters)
main.py:35:9: E265 block comment should start with '# '
main.py:37:1: W293 blank line contains whitespace
main.py:38:32: W291 trailing whitespace
main.py:39:29: W291 trailing whitespace
main.py:40:27: W291 trailing whitespace
main.py:41:25: W291 trailing whitespace
main.py:42:75: W291 trailing whitespace
main.py:43:1: W293 blank line contains whitespace
main.py:44:33: W291 trailing whitespace
main.py:45:33: W291 trailing whitespace
main.py:46:13: W291 trailing whitespace
main.py:47:10: W291 trailing whitespace
main.py:48:75: W291 trailing whitespace
main.py:49:1: W293 blank line contains whitespace
main.py:50:40: W291 trailing whitespace
main.py:52:1: W391 blank line at end of file

sorry i do not understand. can you clearify more? or give hint?

ok @leader2one PEP8(Python Enhancement Proposals)  set some guideline while writing your code.
these guideline are the set of rules to follow while coding
style guide lines to write python code read more here..
flake8 is an external module helps to identify and validate these set of rules
Install flake8
pip install flake8

Run flake8
flake8 main.py

validate your code with PEP8 standards
Check PEP8 Validation
flake8 main.py
Suggestions:
main.py:1:14: W291 trailing whitespace
main.py:2:1: W293 blank line contains whitespace
main.py:3:30: W291 trailing whitespace
main.py:4:1: W293 blank line contains whitespace
main.py:5:35: W291 trailing whitespace
main.py:6:27: W291 trailing whitespace
main.py:7:30: W291 trailing whitespace
main.py:8:1: W293 blank line contains whitespace
main.py:9:32: W291 trailing whitespace
main.py:10:34: W291 trailing whitespace
main.py:11:36: W291 trailing whitespace
main.py:12:32: W291 trailing whitespace
main.py:13:16: W291 trailing whitespace
main.py:15:1: W293 blank line contains whitespace
main.py:16:43: W291 trailing whitespace
main.py:17:1: W293 blank line contains whitespace
main.py:18:33: W291 trailing whitespace
main.py:19:13: W291 trailing whitespace
main.py:21:1: W293 blank line contains whitespace
main.py:22:36: W291 trailing whitespace
main.py:23:25: W291 trailing whitespace
main.py:24:1: W293 blank line contains whitespace
main.py:25:38: W291 trailing whitespace
main.py:26:36: W291 trailing whitespace
main.py:27:24: W291 trailing whitespace
main.py:28:1: W293 blank line contains whitespace
main.py:29:36: W291 trailing whitespace
main.py:30:35: W291 trailing whitespace
main.py:31:42: W291 trailing whitespace
main.py:32:37: W291 trailing whitespace
main.py:33:36: W291 trailing whitespace
main.py:34:80: E501 line too long (94 > 79 characters)
main.py:35:9: E265 block comment should start with '# '
main.py:37:1: W293 blank line contains whitespace
main.py:38:32: W291 trailing whitespace
main.py:39:29: W291 trailing whitespace
main.py:40:27: W291 trailing whitespace
main.py:41:25: W291 trailing whitespace
main.py:42:75: W291 trailing whitespace
main.py:43:1: W293 blank line contains whitespace
main.py:44:33: W291 trailing whitespace
main.py:45:33: W291 trailing whitespace
main.py:46:13: W291 trailing whitespace
main.py:47:10: W291 trailing whitespace
main.py:48:75: W291 trailing whitespace
main.py:49:1: W293 blank line contains whitespace
main.py:50:40: W291 trailing whitespace
main.py:52:1: W391 blank line at end of file

sorry i do not understand. can you clearify more? or give hint?

ok @leader2one PEP8(Python Enhancement Proposals) set some guideline while writing your code.
these guideline are the set of rules to follow while coding
style guide lines to write python code read more here..
flake8 is an external module helps to identify and validate these set of rules
Install flake8
pip install flake8

Run flake8
flake8 main.py

ok i know what pep8 is. but i am thinking about what to do with flake8 main.py. If i run this locally, there will be no change in the code in  this repo. What exacty i should do right now? thanks for supporting

validate your code with PEP8 standards
Check PEP8 Validation
flake8 main.py
Suggestions:
main.py:1:14: W291 trailing whitespace
main.py:2:1: W293 blank line contains whitespace
main.py:3:30: W291 trailing whitespace
main.py:4:1: W293 blank line contains whitespace
main.py:5:35: W291 trailing whitespace
main.py:6:27: W291 trailing whitespace
main.py:7:30: W291 trailing whitespace
main.py:8:1: W293 blank line contains whitespace
main.py:9:32: W291 trailing whitespace
main.py:10:34: W291 trailing whitespace
main.py:11:36: W291 trailing whitespace
main.py:12:32: W291 trailing whitespace
main.py:13:16: W291 trailing whitespace
main.py:15:1: W293 blank line contains whitespace
main.py:16:43: W291 trailing whitespace
main.py:17:1: W293 blank line contains whitespace
main.py:18:33: W291 trailing whitespace
main.py:19:13: W291 trailing whitespace
main.py:21:1: W293 blank line contains whitespace
main.py:22:36: W291 trailing whitespace
main.py:23:25: W291 trailing whitespace
main.py:24:1: W293 blank line contains whitespace
main.py:25:38: W291 trailing whitespace
main.py:26:36: W291 trailing whitespace
main.py:27:24: W291 trailing whitespace
main.py:28:1: W293 blank line contains whitespace
main.py:29:36: W291 trailing whitespace
main.py:30:35: W291 trailing whitespace
main.py:31:42: W291 trailing whitespace
main.py:32:37: W291 trailing whitespace
main.py:33:36: W291 trailing whitespace
main.py:34:80: E501 line too long (94 > 79 characters)
main.py:35:9: E265 block comment should start with '# '
main.py:37:1: W293 blank line contains whitespace
main.py:38:32: W291 trailing whitespace
main.py:39:29: W291 trailing whitespace
main.py:40:27: W291 trailing whitespace
main.py:41:25: W291 trailing whitespace
main.py:42:75: W291 trailing whitespace
main.py:43:1: W293 blank line contains whitespace
main.py:44:33: W291 trailing whitespace
main.py:45:33: W291 trailing whitespace
main.py:46:13: W291 trailing whitespace
main.py:47:10: W291 trailing whitespace
main.py:48:75: W291 trailing whitespace
main.py:49:1: W293 blank line contains whitespace
main.py:50:40: W291 trailing whitespace
main.py:52:1: W391 blank line at end of file

sorry i do not understand. can you clearify more? or give hint?

ok @leader2one PEP8(Python Enhancement Proposals) set some guideline while writing your code.
these guideline are the set of rules to follow while coding
style guide lines to write python code read more here..
flake8 is an external module helps to identify and validate these set of rules
Install flake8
pip install flake8

Run flake8
flake8 main.py

ok gimme a time i 'll solve this issue in the least time

here will be no change in th

ok   :+1:
First validate your code in your local
sync the main repository
commit your changes in local
then push your code to forked repo
and update your PR

here will be no change in th

ok 👍
First validate your code in your local
sync the main repository
commit your changes in local
then push your code to forked repo
and update your PR

thanks man. Today i learned good stuffs because of you. I solved this issue with autopep8


Feature/lrg xrefs

Requirements

Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion;
Review the contributing guidelines for this repository; remember in particular:

do not modify code without testing for regression
provide simple unit tests to test the changes
if you change the schema you must patch the test databases as well, see Updating the schema
the PR must not fail unit testing

Description
Change regex to capture all relevant LRG mappings.
Use case
Input data from HGNC can have multiple entries for 'Locus specific databases' while the current regex assumes it will only ever be LRG data.
The regex update ensures we correctly capture the LRG ID when it is available and ignore any other data from that column.
Benefits
If applicable, describe the advantages the changes will have.
All the relevant HGNC data for LRGs will be correctly parsed and stored in the xref database
Possible Drawbacks
If applicable, describe any possible undesirable consequence of the changes.
NA
Testing
Have you added/modified unit tests to test the changes?
The test data was updated to include a wider range of examples for the 'Locus specific databases' column
If so, do the tests pass/fail?
Updating the test data without any code change results in the test case failing.
With the proposed code change, the test case passes
Have you run the entire test suite and no regression was detected?
yes

Coverage decreased (-0.0004%) to 82.329% when pulling a6b9c73911aecddfbd27d787d17a255572a69a80 on feature/LRG_xrefs into a5551f68ceb46be624b779a6af8de35630d888e5 on master.


Efficient DMatrix copy of np.array

Calling fit/predict from python using a numpy array is extremely memory hungry.  It appears that another np.array is created and then a DMatrix is created.  This is causing memory usage to more than triple.
It would be great if a more conservative way of handling numpy arrays was implemented.  I tried using sparse arrays but this still caused huge memory spikes when converting to DMatrix.

Will add support for native numpy datatypes(double, float) to avoid a few spikes during conversion,

I wonder if there are any updates on the issue - has the support for numpy datatypes been added?
I'm trying to convert a large numpy array into a DMatrix and python dies with out of memory. Writing it into an svmlight light and reading it with DMatrix is an option, but it takes ages.

Has this been addressed? If not, does anyone have code as an example of the libsvm solution (or other suggestions)?

It looks like it has still not been addressed.


Any solution or replacement  for __builtin_ia32_addcarryx_u64 for ARM?

Hi,
I tried to compile Intel source for armv7-a, but this (-mssse3  + _addcarry_u64) combo is checkmated me. The source  is the VanitySearch, and I tried to compile it with NEON header(s), other few intinsics headers, from X86_64 cross to ARM, from native ARM, from native armv8-a etc.
The error everytime the same (this is just the firs one, and probably not the last one :) )
...
Int.h: In function ‘void imm_mul(uint64_t*, uint64_t, uint64_t*)’:
Int.h:233:32: error: ‘__builtin_ia32_addcarryx_u64’ was not declared in this scope
233 | #define _addcarry_u64(a,b,c,d) __builtin_ia32_addcarryx_u64(a,b,c,(long long unsigned int*)d);
|                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Int.h:261:7: note: in expansion of macro ‘_addcarry_u64’
261 |   c = _addcarry_u64(c, _umul128(x[1], y, &h), carry, dst + 1); carry = h;
...
I have already opened an issue there of course, but there is not much "traffic" as I see.. so probably here I am "closer to the fire".. :)
Thanks in advance!

Hi mr-c,
thank you for your really quick answer! I thought I find an easy way just implement some magic header file with builtin functions.. and voila!
Sorry for my poor knowledge! I guess the ASM way is way too much for my level (as you saw from my question :)).
Anyway, I really appreciate your time and your help!
Thank you!


bug: Error executing vim.schedule lua callback: .../.local/share/nvim/lazy/lazydev.nvim/lua/lazydev/buf.lua:151: bad argument #1 to 'ipairs' (table expected, got nil)

Did you check docs and existing issues?

[X] I have read all the lazydev.nvim docs
[X] I have searched the existing issues of lazydev.nvim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
0.10
Operating system/version
Arch Linux 6.9.3-arch1-1
Describe the bug
The plugin throws error when starting with nvim ~/.config/nvim/init.lua, but it works correctly when I am editing the init.lua in my repository directory. I think it throws when there isn't a lua directory e.g. ~/.config/nvim/lua/, e.g. when you have only single init.lua file there. Here is the error.
Error executing vim.schedule lua callback: .../.local/share/nvim/lazy/lazydev.nvim/lua/lazydev/buf.lua:151: bad argument #1 to 'ipairs' (table expected, got nil)
stack traceback:
	[C]: in function 'ipairs'
	.../.local/share/nvim/lazy/lazydev.nvim/lua/lazydev/buf.lua:151: in function ''
	vim/_editor.lua: in function <vim/_editor.lua:0>

Steps To Reproduce

delete lua dir if any rm -r ~/.config/nvim/lua/
start nvim with nvim ~/.config/nvim/init.lua

Expected Behavior
To not throw error and to work correctly.
Repro
-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  "folke/lazydev.nvim",
  -- add any other plugins here
  {
    "folke/lazydev.nvim",
    dependencies = {{ "bilal2453/luvit-meta" }},
    ft = "lua",
    opts = {
      library = { "luvit-meta/library" }
    }
  }
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here
-- nothing else

Should be fixed, but would be great if you can confirm!

It does not throw, but it is not working either... Also it is printing directories now. It works when I create the ~/.config/nvim/lua/ dir manually. See screenshots.

Just removed that debug.
Now I understand what you mean with init.lua. Will check

What does :=vim.lsp.buf.list_workspace_folders() show?

I think this is the problem: https://github.com/neovim/nvim-lspconfig/blob/master/lua/lspconfig/server_configurations/lua_ls.lua#L22
Your LuaLS is in single file mode, no workspace.
When you create the lua folder, you're in a workspace.

Although, even in that case it still works for me....

What does :=vim.lsp.buf.list_workspace_folders() show?

Empty table {}
I have added workaround to my config now to create the dir if it does not exists, so it's not a big deal.
Lazy.use {
  "folke/lazydev.nvim",
  -- dir = "~/dev/open-sos/lazydev.nvim",
  dependencies = {{ "bilal2453/luvit-meta" }},
  ft = "lua",
  opts = {
    library = { "luvit-meta/library" }
  },
  init = function()
    local luadir = vim.fn.expand("~/.config/nvim/lua/")
    if not vim.loop.fs_stat(luadir) then
      vim.fn.mkdir(luadir)
    end
  end
}

And this? :=vim.lsp.get_clients({name = "lua_ls"})[1].root_dir

nil,

Should work now with single file support

It is working now. Thank you!


fix event duplication, add example, add tests

Hello, thank you for this lib, it's very useful.
But looks like I found a bug in event handling.
I wrote 'in_range.rs' example, and it's not working as I expected.
With Poly-non-symetric Relation:
#[derive(Relation, Component)]
#[aery(Poly)]
struct InRange;

We can see 2 SetEvent and 4 UnsetEvent triggers, but I expected 2 SetEvent and 2 UnsetEvent:
2024-12-01T08:02:09.898181Z  INFO in_range: 3v1 is now in range of 4v1
2024-12-01T08:02:09.898416Z  INFO in_range: 4v1 is now in range of 3v1
2024-12-01T08:02:11.928483Z  INFO in_range: 4v1 is no longer in range of 3v1
2024-12-01T08:02:11.928670Z  INFO in_range: 3v1 is no longer in range of 4v1
2024-12-01T08:02:11.928774Z  INFO in_range: 3v1 is no longer in range of 4v1
2024-12-01T08:02:11.928861Z  INFO in_range: 3v1 is no longer in range of 4v1

If I add Symetric to relation:
#[derive(Relation, Component)]
#[aery(Poly, Symmetric)]
struct InRange;

Situation become even worse:
2024-12-01T08:07:19.816287Z  INFO in_range: 3v1 is now in range of 4v1
2024-12-01T08:07:19.816422Z  INFO in_range: 4v1 is now in range of 3v1
2024-12-01T08:07:19.816473Z  INFO in_range: 4v1 is now in range of 3v1
2024-12-01T08:07:19.816508Z  INFO in_range: 3v1 is now in range of 4v1
2024-12-01T08:07:21.917999Z  INFO in_range: 4v1 is no longer in range of 3v1
2024-12-01T08:07:21.918128Z  INFO in_range: 3v1 is no longer in range of 4v1
2024-12-01T08:07:21.918185Z  INFO in_range: 3v1 is no longer in range of 4v1
2024-12-01T08:07:21.918223Z  INFO in_range: 3v1 is no longer in range of 4v1
2024-12-01T08:07:21.918260Z  INFO in_range: 3v1 is no longer in range of 4v1
2024-12-01T08:07:21.918296Z  INFO in_range: 4v1 is no longer in range of 3v1

And after fix it looks like that:
2024-12-01T08:11:03.409970Z  INFO in_range: 3v1 is now in range of 4v1
2024-12-01T08:11:03.410154Z  INFO in_range: 4v1 is now in range of 3v1
2024-12-01T08:11:05.582783Z  INFO in_range: 4v1 is no longer in range of 3v1
2024-12-01T08:11:05.582881Z  INFO in_range: 3v1 is no longer in range of 4v1

Also added some tests to check this events behavior.
Please check examples and test to understand situation.
Hope together we can discuss and solve it, if I got something wrong.

Looks correct. I can review & merge when you're ready to take it out of draft.

Looks correct. I can review & merge when you're ready to take it out of draft.
Thanks.
I've identified some additional cases that might cause unexpected issues with non-sending. However, I don't have time to investigate them further right now. That's the reason of draft, I'll look into this later and update you.

@iiYese hey, I think It's ready for review now, i added additional target_has_host_as_target check in UnsetAsymmetric and wrote better tests for events.

@iiYese thanks, fixed review comments, and made Set command more safe (check if already exists)


update(mithril): Mithril adapter

Name
Link

Mithril
_https://github.com/maicol07/inertia-mithril_

The updated Mithril adapter for Inertia

Updated the link with the new package, updated for latest Inertia
Labeled the old Mithril adapter as "up to Inertia 0.1)

[x] My item is in the right category
[ ] My item has been added to the bottom of the list
[x] My item's name and description respects the conventions of the list
[x] I have read and followed the contributing guidelines

Thanks!


Bug: error "We expect a missing _needs_stub attribute from older versions of setuptools"

What version of gRPC and what language are you using?
I have tested using master, v1.38.0, and v1.36.1 of this repo.
What operating system (Linux, Windows,...) and version?
I have tried both Linux (Debian GNU/Linux rodete) and Mac OSX (11.5.1)
What runtime / compiler are you using (e.g. python version or version of gcc)
python 3.9.2 (Linux) and python 3.9.6 (Mac OSX)
What did you do?
I am trying to build using the flag GRPC_PYTHON_BUILD_SYSTEM_OPENSSL:
git submodule update --init
GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 python3 -m pip install .

What did you expect to see?
I would expect grpc to build with OpenSSL instead of BoringSSL
What did you see instead?
The following error:
CommandError: We expect a missing `_needs_stub` attribute from older versions of setuptools. Consider upgrading setuptools.

Please note the following:

On both Mac OSX and Linux I have upgraded setuptools to the most current version using python3 -m pip install setuptools (52.0.0 on Linux and 57.4.0 on Mac OSX).
This was building two months or so ago as expected, and this error was not being thrown, so I am not sure what changed.
I tried rolling back to versions v1.38.0 and v1.36.1 on Linux and the result was the same, so the issue could be in a dependency.
I was able to get grpc to compile on Linux and grpc/grpc:v1.38.0 by omitting the GRPC_PYTHON_BUILD_SYSTEM_OPENSSL flag

UPDATE: I believe I may have gotten this to work with the following commands:
python3 -m pip install Cython
apt-get install libupb-dev

I am not sure which of these fixed it, or why, but it seems to be working now.


[BUG] Flytekit imports tensorflow and pytorch

Describe the bug
Flytekit tensorflow and pytorch plugins do not really need tensorflow and pytorch, yet it is added as a dependency. This affects users developing non tensorflow/pytorch pipelines.
Expected behavior
Flytekit just brings in the plugins and the user is responsible in installing tensorflow or pytorch
Flyte component

[ ] Overall
[ ] Flyte Setup and Installation scripts
[ ] Flyte Documentation
[ ] Flyte communication (slack/email etc)
[ ] FlytePropeller
[ ] FlyteIDL (Flyte specification language)
[x] Flytekit (Python SDK)
[ ] FlyteAdmin (Control Plane service)
[ ] FlytePlugins
[ ] DataCatalog
[ ] FlyteStdlib (common libraries)
[ ] FlyteConsole (UI)
[ ] Other

Available in v0.14.0


Fix error when hidden directories are added by OS in model library

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
6 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.07%) to 96.902%

Files with Coverage Reduction
New Missed Lines
%

custom_components/powercalc/power_profile/library.py
6
93.26%

Totals

Change from base Build<PHONE_NUMBER>:
-0.07%

Covered Lines:
2627

Relevant Lines:
2711

💛  - Coveralls


Modify .gitignore for nested Eclipse files

When importing Vitro into Eclipse there are only top-level entries for .classpath, .project, and .settings.
Please change .gitignore to include the following so that nested projects' Eclipse files are also ignored.
//.classpath
//.project
/**/.settings

David, I can't find mention of the double slash in the git documentation. What does it mean? Can they all just use /**/? I.e.,
//.classpath
//.project
/**/.settings
Thanks.
Rebecca

I think that was the Markdown at work. Now enclosing in Markdown code tags:
`
/**/.classpath
/**/.project
/**/.settings
`

I've made the change to .gitignore, but you will need to remove them from your local repo and then push that change so that they get removed from the remote repo. Otherwise once they're there they won't go away.
Incidentally, I didn't see any of these files below the top-level.


:sparkles: Add profiler support to front proxy and virtual workspaces

Summary
Adds profiler address as command line argument
Fixes https://github.com/kcp-dev/kcp/issues/1836
Screenshot:

/ok-to-test

/lgtm
/approve

just a linter check error for the missing err check after the ListenAndServe call, else lgtm from my side as well 👍

/test lint

/lgtm


Admin Panel Modification

Admin Panel Modification

@ritesh-skyach We have URI in Currencies, in Blockchains and in Wallets under different names. I think it should be left only in one place, like in Blockchains.

@pkucherenk0 We need URI in both Blockchains and Wallets.
I will create a different PR to remove unwanted stuff from Currencies

@ritesh-skyach please continue on top of branch #1510
resolve the comments and push to wb1


nyx: init at 2.0.4

@dotlambda should be fixed now, thanks! It was some time ago, i last packaged python app in nixos, i can see a few things has changed on better since then, :)

Ran 0 tests in 0.000s

You can try to add something like
checkPhase = ''
  ./run_tests.py
'';

If you don't get the tests to work, please set doCheck = false and add a comment why.

I did not manage to get tests working, also i did not spend too much time to try, but i wrote a comment about error that test suite reports and it seems to be super error in code. I explicitly disabled tests with noCheck = true;

@GrahamcOfBorg build nyx

Success on aarch64-linux (full log)
Attempted: nyx
Partial log (click to expand)
Successfully installed nyx-2.0.4
/build/nyx-2.0.4
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/midx319llvzxkaxs4i1gj5kga1dgz766-nyx-2.0.4
strip is /nix/store/0pjsgkxz0rp5baycq5sp2s72lrr5q9sg-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/midx319llvzxkaxs4i1gj5kga1dgz766-nyx-2.0.4/lib  /nix/store/midx319llvzxkaxs4i1gj5kga1dgz766-nyx-2.0.4/bin
patching script interpreter paths in /nix/store/midx319llvzxkaxs4i1gj5kga1dgz766-nyx-2.0.4
checking for references to /build in /nix/store/midx319llvzxkaxs4i1gj5kga1dgz766-nyx-2.0.4...
wrapping `/nix/store/midx319llvzxkaxs4i1gj5kga1dgz766-nyx-2.0.4/bin/nyx'...
/nix/store/midx319llvzxkaxs4i1gj5kga1dgz766-nyx-2.0.4

Success on x86_64-linux (full log)
Attempted: nyx
Partial log (click to expand)
Successfully installed nyx-2.0.4
/build/nyx-2.0.4
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4
strip is /nix/store/4qvrxzxa535y8304mk195x50b6p9607d-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4/lib  /nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4/bin
patching script interpreter paths in /nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4
checking for references to /build in /nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4...
wrapping `/nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4/bin/nyx'...
/nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4

Success on aarch64-linux (full log)
Attempted: nyx
Partial log (click to expand)
/nix/store/midx319llvzxkaxs4i1gj5kga1dgz766-nyx-2.0.4

Success on x86_64-linux (full log)
Attempted: nyx
Partial log (click to expand)
Successfully installed nyx-2.0.4
/build/nyx-2.0.4
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4
strip is /nix/store/4qvrxzxa535y8304mk195x50b6p9607d-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4/lib  /nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4/bin
patching script interpreter paths in /nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4
checking for references to /build in /nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4...
wrapping `/nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4/bin/nyx'...
/nix/store/4rybky4xnwmdw22nysw4251kp7d96sc1-nyx-2.0.4


Incorrect region type

Allowing to select any dc location - including ones where sm is not available.

The code is currently using the catalog region dropdown picker -> https://github.com/terraform-ibm-modules/terraform-ibm-secrets-manager/blob/47d60e4a448731ab7c5f1582a842921ccfcbecd6/ibm_catalog.json#L90-L101
Chennai is the only region in that list that is not supported by Secrets Manager. Unfortunately to remove it, it would mean we would have to create and maintain our own custom dropdown. And in the past we have found it hard to maintain as services onboard to new regions. I'll bring this up with catalog team to see what our options are. For now, only option is a custom list

{
  "key": "region",
  "required": true,
  "options": [
  {
    "displayname": "Osaka",
    "value": "jp-osa"
  },
  {
    "displayname": "Sydney",
    "value": "au-syd"
  },
  {
    "displayname": "Tokyo",
    "value": "jp-tok"
  },
... here ...
  {
    "displayname": "Frankfurt",
    "value": "eu-de"
  },
  {
    "displayname": "London",
    "value": "eu-gb"
  },
  {
    "displayname": "Mardrid",
    "value": "eu-es"
  },
  {
    "displayname": "Dallas",
    "value": "us-south"
  },
  {
    "displayname": "Toronto",
    "value": "ca-tor"
  },
  {
    "displayname": "Washington DC",
    "value": "us-east"
  },
  {
    "displayname": "Sao Paulo",
    "value": "br-sao"
  }
  ]
},

That would be a similar order to the services, alphabetically by geography.


[Custom] Crash when used in combination with VideoCompress (https://github.com/jonataslaw/VideoCompress)

Hi,
When picking a video from library, i get a crash when trying to compress it with (https://github.com/jonataslaw/VideoCompress).
All other case works (taking video from camera, using https://pub.dev/packages/image_picker)
Expect
Compression still works
Is someone using VideoCompress ?
Thanks,
Nelson

Please provide all info about the package, like version info, device info, minimum usage code.

Closing with stale state.


Add rubocop-rails_config

https://github.com/toshimaru/rubocop-rails_config

Fixed in https://github.com/skipkayhil/rail_inspector/commit/2d9a0e3ea3bd9288f447cb2b0f11d99775bc2b05


Move regex and sentencepiece from extras_require to install_requires

Our Tokenizer modules have a dependency on these two packages. regex and sentencepiece should be moved to install_requires. Otherwise, ModuleNotFoundError will be triggered (if regex and sentencepiece are not installed) when they try to import texar.torch.

good catch. we may wanna update requirements.txt accordingly

I noticed that we put torch in extra_require as well. So it may be ok to leave regex and sentencepiece as they are (?) @huzecong

I noticed that we put torch in extra_require as well. So it may be ok to leave regex and sentencepiece as they are (?) @huzecong

If that is the case, we might need to mention that users need to install regex and sentencepiece to use our package in README.md.

I guess it's fair to have these in install_requires, because tokenizers is a feature that most people would use (as pre-trained models depend on them). This is contrary to Pillow which is only used if you load images with RecordData.
The reason we don't have torch in the list is because there are multiple version of PyTorch that goes with different CUDA versions (or CPU only). Instead of installing for the user and fail, it might be better to leave it to the user themselves.

Can we also add a version limit for the new requirements? And in setup.py as well?


Add awesome badge

This is purely a documentation add to help link up Bigtable community (I'm encouraging any lib I have on the list to add the badge to help point users to the list to encourage knowledge share).

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

~[ ] Make sure to open an issue as a bug/issue before writing your code!  That way we can discuss the change, evaluate designs, and agree on the general idea~
[X] Ensure the tests and linter pass
[X] Code coverage does not decrease (if any source code was changed)
[X] Appropriate docs were updated (if necessary)

~Fixes #<issue_number_goes_here>~ 🦕

@zrosenbauer appreciate the contribution 👍 and that list is awesome.
But, at this time our READMEs for our client libraries are auto-generated from a template, I'd like to avoid deviating from this approach to add a badge.

Anyway to add to the generation script? I can do the leg work. If not
possible no worries just trying to help connect Bigtable users 😎
On Fri, Feb 12, 2021 at 4:30 PM Benjamin E. Coe<EMAIL_ADDRESS>wrote:

@zrosenbauer https://github.com/zrosenbauer appreciate the contribution
👍 and that list is awesome.
But, at this time our READMEs for our client libraries are auto-generated
from a template, I'd like to avoid deviating from this approach to add a
badge.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/googleapis/nodejs-bigtable/pull/843#issuecomment-778491521,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA2TF7KUS5MUDEARRGDOMJDS6WTY3ANCNFSM4XN5OYFQ
.

--
Sent from Gmail Mobile

@zrosenbauer there's no easy way to do this right now, and in general we'd like to not have READMEs that are outliers.
What I can do, however, is share the list with some of my peers who work on the BigTable product, so that they can follow along with the list.

Perfect appreciate it. Would love to have some help maintaining and
building out.
On Fri, Feb 12, 2021 at 4:46 PM Benjamin E. Coe<EMAIL_ADDRESS>wrote:

@zrosenbauer https://github.com/zrosenbauer there's no easy way to do
this right now, and in general we'd like to not have READMEs that are
outliers.
What I can do, however, is share the list with some of my peers who work
on the BigTable product, so that they can follow along with the list.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/googleapis/nodejs-bigtable/pull/843#issuecomment-778497157,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA2TF7O5DDMJ7HYLBD6XXHTS6WVT5ANCNFSM4XN5OYFQ
.

--
Sent from Gmail Mobile


Problem with arrows symbols

Terms

[X] Before you openning this issue, i have checked if the issue has already been reported.

Bagisto Version(s) affected
1.5.1
Issue Description
when reloading the page some icons are broken
I am working in local
This happens to me on several occasions

Preconditions
...
Steps to reproduce
Reload the page and sometimes it happens
Expected Result
...
Actual Result
...
Screenshots
No response
Additional context
No response

I don't have any custom settings, since I installed the package this happens to me, but it doesn't happen all the time, but often.

Hello there,
Clear the cache and hard refresh then it will work fine.
If still facing the issue, you can take a reference from here


Use cifar10 recipe to predict issue

Hi!
I run cifar10 recipe.ipynb, and I get "ValueError" when executing model prediction, the error row is acc1 = float(np.sum(py == y)) / len(y).
I find that py.shape is not same as y.shape. I have run this code with several times and py.shape and y.shape always change.
I have no idea about this issue, can anyboy help me to solve it?
The following is model predict code:
prob = model3.predict(test_dataiter)
logging.info('Finish predict...')
# Check the accuracy from prediction
test_dataiter.reset()
# get label
# Because the iterator pad each batch same shape, we want to remove paded samples here

y_batch = []
for dbatch in test_dataiter:
    label = dbatch.label[0].asnumpy()
    pad = test_dataiter.getpad()
    real_size = label.shape[0] - pad
    y_batch.append(label[0:real_size])
    #print label.shape[0], pad, real_size, len(y_batch)
y = np.concatenate(y_batch)
print y
# get prediction label from
py = np.argmax(prob, axis=1)
print len(prob), prob.shape
print py.shape
print y.shape
acc1 = float(np.sum(np.equal(py,y))) / len(y)
logging.info('final accuracy = %f', acc1)

And the output result and error at one time is:
INFO:root:Finish predict...
[ 7.  6.  9. ...,  5.  1.  7.]
9936 (9936, 10)
(9936,)
(9952,)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-64-52b6cd0dd525> in <module>()
     20 print py.shape
     21 print y.shape
---> 22 acc1 = float(np.sum(np.equal(py,y))) / len(y)
     23 logging.info('final accuracy = %f', acc1)

ValueError: operands could not be broadcast together with shapes (9936,) (9952,)

Because of my carelessness,  I forgot to set round_batch=False in test iterator.


Split transformCounts to row and col specific functions

The current transformCounts contains operations for both samples (clr, hellinger etc.) and features (Z). In the future, we may like to add some that could be applied in either direction (rank index).

Splitting transformCounts into transformSamples and transformFeatures would be a more clear and informative naming scheme.

Can we consider changing the argument name "abund_values" into "assay" since this is what it essentially does - conceptually more clear?

My 2 cents:

I think the was discussed priviously, wasn't it? I think it would make much more sense. However, note that currently only Z transformation works in a rowwise manner and is not availavble through transformCounts. So the split is effectively alread in place. (transformCounts would need to be kept as an alias form transformSamples for backwards compatibility)
Why? All functions use either abund_values or exprs_values throughout multiple packages. In addition, the argument name assay is not clear enough, since for a new user it would suggest the assay values themselves to be supplied to such a function. assay_name would be better.
I am also not sure what is conceptually better by using assay(_name). The term assay is my mind a technical term, whereas abund_values is a conceptual name. So I am not sure what you mean exactly. What would improve? The technical understanding from a users point of view?

Yes we discussed this earlier but it has not been implemented while we got more experience with incorporating these things in workflows. It seems that we agree, so we could proceed with this split?
Right, for compatibility with other pkgs perhaps it is justified then indeed. For me it is easier to thinkg of which "assay" we are operating on (as these are assays anyway) and abund_values does not explicitly refer to that. But it is ok.

Sure go ahead with the implementation. I think this just a bit of rearranging and generalization need. I think the argument name has its merrits from the conceptual side of things

Great. Me or @tvborm will do this when time allows.

Very good that this is now implemented.
I just noticed that examples include ecological (sample-wise) transformations, being applied to features (see below).
Many of the transformations are ecologically motivated, and essentially never done for features. I propose to disable the use of such transformations for features, and update the examples accordingly.
More specifically,
Both transformSamples and transformFeatures can include

log10
pa

transformSamples can include

rank
relabundance
hellinger
clr

transformFeatures can include

Z

# If you want to do the transformation for features, you can do that by using
transformFeatures(x, method="hellinger", name="hellinger_features")
head(assay(x, "hellinger_features"))

Ok, I can do that, it shouldn't be big thing. The intention was to allow all kind of transformations. I didn't really think about the thing from this point of view

Ok great! We are helping the users by not allowing them to make very unconventional (and probably misinformed) choices.

Sorry I missed this, but this can be easily fixed.
Just remove the offending options from the generic and method and include a match call to match.arg, e.g. method <- match.arg(method, c("clr", "hellinger", "log10", "pa", "rank", "relabundance")) for transformSamples.
What I missed as well is the addition of transformSamples generic and method. transformCounts should be only a wrapper for transformSamples as discussed above

Seems good overall but Felix may better comment the generics and methods.

Closed via #102


[New game]: Whack a Mole

🎮 Game Request
Game logic and basic description:
The game is absolutely fun. It consists of 9 holes where a mole will appear and change its position continously. The player must tap on the mole to get points. The twist is there also will be a insectivorous plant which also will be moving with the mole. The game ends when the player taps on the insectivorous plant.
Point down the features
Game points:
The objective of the game is to score the highest by tapping on the mole correctly everytime and be causious of tapping on insectivorous plant since the game ends.
Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @akhilender-bongirwar !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

Hey @akhilender-bongirwar 👋!
@kunjgit here,
We have this annoucement to make 📢!!
We have updated our README 🚀
Make sure you follow proper guideline to raise your next issues !!
Make sure you join our Discord🕹 if you haven't 😇
Thank you 💗!

Hey @akhilender-bongirwar ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


Add support for Python 3.11, require NumPy 1.23+

Description
Contributes to https://github.com/rapidsai/build-planning/issues/3
This PR adds support for Python 3.11.
It also bumps uses of NumPy to numpy>=1.23, see https://github.com/rapidsai/build-planning/issues/3#issuecomment-1967952280.
Notes for Reviewers
This is part of ongoing work to add Python 3.11 support across RAPIDS.
The Python 3.11 CI workflows introduced in https://github.com/rapidsai/shared-workflows/pull/176 are optional... they are not yet required to run successfully for PRs to be merged.
This PR can be merged once all jobs are running successfully (including the non-required jobs for Python 3.11). The CI logs should be verified that the jobs are building and testing with Python 3.11.
See https://github.com/rapidsai/shared-workflows/pull/176 for more details.

CI logs look good. There is one conda job that is using Python 3.11 with CUDA 12, and it's skipped due to CUDA 12. I'm treating that as an acceptable pass, because there was a wheel job (not conda) that successfully ran with Python 3.11.

/merge

Thanks all! 🙏


SPIKE: Lazy imports for expensive 3rd party modules

Off the back of #142 : Look at lazy imports for 3rd party modules which are heavy to import and have niche/one-shot uses within ecoscope

Turns out we have this lazy loader as a transitive dependency through skimage.


Error: Cannot find module 'lodash' installing on a new sails app.

I created a new Sails application, followed the Quick Start instructions in the README.md and I see this on "sails lift":
info: Starting app...

module.js:338
    throw err;
    ^
Error: Cannot find module 'lodash'
    at Function.Module._resolveFilename (module.js:336:15)
    at Function.Module._load (module.js:278:25)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)

Info on my installation:
$ sails -v
0.11.0
$ grep sails package.json
    "grunt-sails-linker": "~0.9.5",
    "sails": "~0.11.0",
    "sails-auth": "^1.3.1",
    "sails-disk": "~0.10.0",
    "sails-permissions": "^1.3.6",
    "sails-redis": "^0.10.4"

After "npm install --save lodash" it works. However, each subsequent "sails lift" gives me an error about trying to insert the admin user every time:
Error: Error (E_UNKNOWN) :: Encountered an unexpected error
AdapterError: Record does not satisfy unique constraints

Looks like the application lifts, now I am trying to figure out how to use the /auth/local endpoint. Thanks for creating this!

What db adapter are you using?

I'm using 'sails-redis'

Created a new issue for the sails-redis adapter problem.
https://github.com/tjwebb/sails-permissions/issues/121
Closing this one.


Apple M2 CPU segfaults

I'm trying to compile and run acton programs on an Apple M2 CPU and many of them keep crashing with a segfault.
In all cases, we end up with a invalid cont pointer. Most points to 0xffffff0d1d0ca3ea for me but that's probably machine dependent, though you can look for it in
For example, here's a backtrace of one example:
* thread #7, stop reason = ESR_EC_DABORT_EL0 (fault address: 0x0)
    frame #0: 0x0000000100a65df8 test_net`net$$DNS$__init__(__self__=0x0000600001180d70, auth=0x00006000030840f0, c$cont=0xffffff0d1d0ca3ea) at net.c:277:15
    frame #1: 0x0000000100a652dc test_net`net$$l$4lambda$__call__(p$self=0x00006000032812c0, c$cont=0xffffff0d1d0ca3ea) at net.c:100:12
  * frame #2: 0x0000000100a956bc test_net`wt_work_cb(ev=0x0000000100cc39c0) at rts.c:1298:16
    frame #3: 0x0000000100b1e8c0 test_net`uv__run_check + 152
    frame #4: 0x0000000100b19acc test_net`uv_run + 300
    frame #5: 0x0000000100a9642c test_net`main_loop(idx=0x0000000000000005) at rts.c:1447:13
    frame #6: 0x00000001af4a826c libsystem_pthread.dylib`_pthread_start + 148

We can see how frame 1 has c$cont set to the bad value. How does that happen?
stepping back to the previous frame, we see the argument passed has the correct value:
(lldb) f 2
frame #2: 0x0000000100a956bc test_net`wt_work_cb(ev=0x0000000100cc39c0) at rts.c:1298:16
   1295	        clock_gettime(CLOCK_MONOTONIC, &ts1);
   1296	        wt_stats[wtid].state = WT_Working;
   1297
-> 1298	        $R r = cont->$class->__call__(cont, val);
   1299
   1300	        clock_gettime(CLOCK_MONOTONIC, &ts2);
   1301	        long long int diff = (ts2.tv_sec *<PHONE_NUMBER> + ts2.tv_nsec) - (ts1.tv_sec *<PHONE_NUMBER> + ts1.tv_nsec);
(lldb) p val
($WORD) $4 = 0x0000000100b97898

It seems that the problem stems from a mismatch in calling conventions. From https://developer.apple.com/documentation/apple-silicon/addressing-architectural-differences-in-your-macos-code:

The x86_64 and arm64 architectures have different calling conventions for variadic function —functions with a variable number of parameters. On x86_64, the compiler treats fixed and variadic parameters the same, placing parameters in registers first and only using the stack when no more registers are available. On arm64, the compiler always places variadic parameters on the stack, regardless of whether registers are available. If you implement a function with fixed parameters, but redeclare it with variadic parameters, the mismatch causes unexpected behavior at runtime

The last sentence highlights our problem, we have a function with fixed parameters, in my case the 4lambda function but it is "redeclared" as $Cont->call which is variadic. Rerunning the above from LLDB with breakpoints set and some slight debug changes to the program:
Process 66703 launched: '/Users/kll/terastream/acton-m2/test/stdlib_auto/test_net' (arm64)
Process 66703 stopped
* thread #3, name = 'Worker 1', stop reason = breakpoint 2.1
    frame #0: 0x0000000100039698 test_net`wt_work_cb(ev=0x00000001002677e0) at rts.c:1298:16
   1295	        clock_gettime(CLOCK_MONOTONIC, &ts1);
   1296	        wt_stats[wtid].state = WT_Working;
   1297
-> 1298	        $R r = cont->$class->__call__(cont, val);
   1299
   1300	        clock_gettime(CLOCK_MONOTONIC, &ts2);
   1301	        long long int diff = (ts2.tv_sec *<PHONE_NUMBER> + ts2.tv_nsec) - (ts1.tv_sec *<PHONE_NUMBER> + ts1.tv_nsec);
Target 0: (test_net) stopped.
(lldb) frame variable
(uv_check_t *) ev = 0x00000001002677e0
(int) wtid = 1
(timespec) ts_start = (tv_sec = 60519, tv_nsec = 171332000)
(timespec) ts1 = (tv_sec = 60519, tv_nsec = 171333000)
(timespec) ts2 = (tv_sec = 850045858, tv_nsec = 0)
(timespec) ts3 = (tv_sec = 0, tv_nsec = 0)
(long long) runtime = 0
($Actor) current = 0x00006000026003c0
($Msg) m = 0x0000600002100d70
($Cont) cont = 0x000000010013b8f0
($WORD) val = 0x000000010013b898
($R) r = {
  tag = $RDONE
  cont = NULL
  value = 0x000000016ff12e48
}
(long long) diff = 0
(lldb) register read
General Purpose Registers:
        x0 = 0x0000000000000000
        x1 = 0xffffff0d1d0ca3ea
        x2 = 0xffffff0d1d0ca3ea
        x3 = 0x0000000fffffc088
        x4 = 0x0000000000000400
        x5 = 0x0000000000000000
        x6 = 0x0000000000000000
        x7 = 0x0000000000000000
        x8 = 0x0000000000000001
        x9 = 0x000000010026f0d0  test_net`wt_stats + 240
       x10 = 0x00000000000000f0
       x11 = 0x00000000000f4240
       x12 = 0x000000000008d06d
       x13 = 0x00000000016e3600
       x14 = 0x00000001000d23cb  "%d"
       x15 = 0x0000000000000000
       x16 = 0x00000001af47ac08  libsystem_kernel.dylib`mach_boottime_usec
       x17 = 0x00000002095c1dd0  (void *)0x00000001af47ac08: mach_boottime_usec
       x18 = 0x0000000000000000
       x19 = 0x0000000100808800
       x20 = 0x0000000100808a38
       x21 = 0x000000016ff12eb8
       x22 = 0x00000000000f4240
       x23 = 0x0000000100808848
       x24 = 0x0000000100808a48
       x25 = 0x00000000ffffffff
       x26 = 0x0000000000000005
       x27 = 0x000000010012f018  test_net`inet_pton6.xdigits_u + 998
       x28 = 0x0000000000000000
        fp = 0x000000016ff12ea0
        lr = 0x1d45800100039678 (0x0000000100039678) test_net`wt_work_cb + 304 at rts.c:1295:9
        sp = 0x000000016ff12d40
        pc = 0x0000000100039698  test_net`wt_work_cb + 336 at rts.c:1298:16
      cpsr = 0x20001000

we see the bad value in register x1 & x2. Let's try changing them and step forward:

(lldb) register write x1 0x0000000000000001
(lldb) register write x2 0x0000000000000002
(lldb) s
Process 66703 stopped
* thread #3, name = 'Worker 1', stop reason = step in
    frame #0: 0x0000000100036974 test_net`$InitRoot$__call__($this=0x000000010013b8f0, val=0x0000000000000001) at rts.c:741:28
   738 	////////////////////////////////////////////////////////////////////////////////////////
   739 	$R $InitRoot$__call__ ($Cont $this, $WORD val) {
   740 	    typedef $R(*ROOT__init__t)($Actor, $Env, $Cont);    // Assumed type of the ROOT actor's __init__ method
-> 741 	    return ((ROOT__init__t)root_actor->$class->__init__)(root_actor, env_actor, ($Cont)val);
   742 	}
   743
   744 	struct $Cont$class $InitRoot$methods = {
Target 0: (test_net) stopped.
(lldb) frame variable
($Cont) $this = 0x000000010013b8f0
($WORD) val = 0x0000000000000001
(lldb) register read
General Purpose Registers:
        x0 = 0x000000010013b8f0  $InitRoot$cont
        x1 = 0x0000000000000001
        x2 = 0x0000000000000002
        x3 = 0x0000000fffffc088
        x4 = 0x0000000000000400
        x5 = 0x0000000000000000
        x6 = 0x0000000000000000
        x7 = 0x0000000000000000
        x8 = 0x000000016ff12e00
        x9 = 0x000000010003695c  test_net`$InitRoot$__call__ at rts.c:739
       x10 = 0x000000010013b000  $Iterator$set$methods + 72
       x11 = 0x000000016ff12d40
       x12 = 0x000000000008d06d
       x13 = 0x00000000016e3600
       x14 = 0x00000001000d23cb  "%d"
       x15 = 0x0000000000000000
       x16 = 0x00000001af47ac08  libsystem_kernel.dylib`mach_boottime_usec
       x17 = 0x00000002095c1dd0  (void *)0x00000001af47ac08: mach_boottime_usec
       x18 = 0x0000000000000000
       x19 = 0x0000000100808800
       x20 = 0x0000000100808a38
       x21 = 0x000000016ff12eb8
       x22 = 0x00000000000f4240
       x23 = 0x0000000100808848
       x24 = 0x0000000100808a48
       x25 = 0x00000000ffffffff
       x26 = 0x0000000000000005
       x27 = 0x000000010012f018  test_net`inet_pton6.xdigits_u + 998
       x28 = 0x0000000000000000
        fp = 0x000000016ff12d30
        lr = 0x00000001000396bc  test_net`wt_work_cb + 372 at rts.c:1298:16
        sp = 0x000000016ff12d20
        pc = 0x0000000100036974  test_net`$InitRoot$__call__ + 24 at rts.c:741:28
      cpsr = 0x20001000

(lldb) bt
* thread #3, name = 'Worker 1', stop reason = step in
  * frame #0: 0x0000000100036974 test_net`$InitRoot$__call__($this=0x000000010013b8f0, val=0x0000000000000001) at rts.c:741:28
    frame #1: 0x00000001000396bc test_net`wt_work_cb(ev=0x00000001002677e0) at rts.c:1298:16
    frame #2: 0x00000001000c28c0 test_net`uv__run_check + 152
    frame #3: 0x00000001000bdacc test_net`uv_run + 300
    frame #4: 0x000000010003a42c test_net`main_loop(idx=0x0000000000000001) at rts.c:1447:13
    frame #5: 0x00000001af4a826c libsystem_pthread.dylib`_pthread_start + 148
(lldb) ^C

we see how the called function reads its argument from the argument register, but the calling function passed them via the stack! This misalignment appears to be causing these segfaults. What to do?

a lisp dialect uses a bunch of predefined functions:
https://gitlab.com/embeddable-common-lisp/ecl/-/blob/4f8b4fab8bbd32c68f6d78ebbf104dc9f48e6309/src/c/cfun_dispatch.d
not sure if this is applicable to us or not..

Fixed by #823. Closing!


Danish as default language in installer

1. Why is this change necessary?
The Danish market requires Shopware customers to be able to set the default language for their shop to Danish.
2. What does this change do, exactly?
Allows a user to set Danish as the default system language upon install.
3. Describe each step to reproduce the issue or behaviour.
4. Please link to the relevant issues (if any).
https://issues.shopware.com/issues/NEXT-8602
This should also be merged to add the Danish flag: https://github.com/shopware/production/pull/110
5. Checklist

[ ] I have written tests and verified that they fail without my change
[x] I have squashed any insignificant commits
[x] I have created a changelog file with all necessary information about my changes
[ ] I have written or adjusted the documentation according to my changes
[x] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

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

Hey @wexotht, thanks for the PR : ) we will come back to you next week.

@J-Rahe did you have time to look at this? :) Could we push to have it included in the monday release?

@wexotht the release branch is split off two weeks before the release 😉 so for this PR it is already too late 🙈

@mitelg ohh okay :) Will a review or some test / feedback happen this or next week anyway? If everything is okay we will patch our shops and start the huge migration process to Danish as the default language for all our customers

@jakob-kruse what's the status of this one? :) Is there something that we need to correct or will this be included in the September release?
As far as I can see, the failing tests are not related to our changes

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/NEXT-16714
Please use this issue to track the state of your pull request.

Hello @wexotht
Your contribution will most likely be included in the next release.
Your PR will now be reviewed and tested before being put through our internal extended test suite and review process.
We will keep you informed whether something has to be done by you or when the PR is merged
If you have any further questions, feel free to ask.

Hey, thanks for your contribution :blue_heart:


Config guide updates

moved descriptions of traceMode and transactionSettings into main config file section
updated the traceMode description to hopefully make clear that while the agent does not set a default, the expected default behaviour (dictated by remote settings) is enabled, so customers shouldn't have to set it explicitly.

@bmacnaughton I'm getting ready to put something in the KB about our new transaction filtering feature and thought these changes would help clarify.

lgtm


Alert user to wasted recycled materials when bulldozing structures

With the recent updates to the way player resources are handled, it's now very possible for recycled materials to be wasted if the player's refined resources are close to full.

I just read this ticket and I realized it was about something else than I thought initially. I had thought this was some kind of early-game alert to inform a player that the building he just bulldozed did not recover any resources as he has no Recycling Facility. The message would be a subtle nod to the recycling mechanics, which would allow some sort of reimbursement when bulldozing structures. This then should encourage the player to build a Recycling Facility to reap the resource and Morale rewards.
But in fact, this issue seems to describe a situation in which the Recycling Facility is already present, but where the finished resources produced by the Recycling Facility on this turn would not be able to be transferred to Storage Tanks or Warehouses when processing the turn, leading to a loss of resources.
As the player is possibly unaware of the limits of his storage or has no current metrics, the player might want to bulldoze some structure because he misplaced it, or because the structure exploded and he wants to clean it up. Then the only option to interrupt this flow is show the dreaded alert popup as the action is already underway (the user has picked a RoboDozer and clicked on a structure to demolish).
Systems that could "train" a user in keeping an eye on storage space:

Give a voice/text notification if total Fluid storage/Warehouse storage is over 90%. (Could pehaps be unlocked by Research)
Maybe there is a case to be made for the popup, as I reckon a user should need to be interrupted when selecting a RoboDozer and clicking on his Command Center/CHAP, perhaps this alert could contain extra info on the availability of a Recycling Facility and the storage space currently available.
There might be scenarios where a player might want to sacrifice some resources and bulldoze a certain structure (e.g. disaster recovery after a meteor took out the recycling facility and some tubes)

Well, initially I thought that the recycling center would be needed but really if the user has an active smelter that's what they would need. The demolished remains of the structure would go through the smelter, separated out and refined again at a rate of (I don't remember if it's 90% return or 75% return). Something to that effect.
I think I have a task for alerting the user to storage filling up? (norpe, it's about diminishing resources). This could work in place of alerting the user that their action will result in wasted resources.
The idea here is less about a pop up dialog and more of a push notification type of deal. I'm actually going to move these to a separate release from 0.8.2 since it requires a the NotificationArea that I started work on.

All that stated, you do bring up good points. I have the resources HUD numbers flash when they're really low or if storage is running out. These could definitely be push notifications that are only along the side of the screen that the user can ignore if they so choose or open up to get a complete message.

Decided that this isn't really that necessary. If a user is bulldozing a structure it's either because it's destroyed, it's not needed anymore or they're in dire need of resources so there will be plenty of available storage left.
Will move to the 1.0.0 milestone as a polishing aspect of the UI and for further discussion.


Key Error in Setting up Osramlightify Groups and Lights

Home Assistant release (hass --version):
0.44
Description of problem:
This change breaks my Home Assistant setup. Each time I start HA the value of self._light_ids[0] seems to be incorrect but the error does not always happen with the same light. Maybe there's a discrepancy between the bridge and the states in HA. I've rolled back to 0.43.2 for now and the problem went away.
as reported by @duffrecords
Traceback (if applicable):
2017-05-10 13:31:46 ERROR (MainThread) [homeassistant.components.light] Error while setting up platform osramlightify
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity_component.py", line 155, in _async_setup_platform
    entity_platform.schedule_add_entities, discovery_info
  File "/opt/rh/rh-python35/root/usr/lib64/python3.5/asyncio/futures.py", line 358, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/opt/rh/rh-python35/root/usr/lib64/python3.5/asyncio/tasks.py", line 290, in _wakeup
    future.result()
  File "/opt/rh/rh-python35/root/usr/lib64/python3.5/asyncio/futures.py", line 274, in result
    raise self._exception
  File "/opt/rh/rh-python35/root/usr/lib64/python3.5/concurrent/futures/thread.py", line 55, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/light/osramlightify.py", line 60, in setup_platform
    setup_bridge(bridge, add_devices, add_groups)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/light/osramlightify.py", line 106, in setup_bridge
    update_lights()
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/util/__init__.py", line 303, in wrapper
    result = method(*args, **kwargs)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/util/__init__.py", line 303, in wrapper
    result = method(*args, **kwargs)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/light/osramlightify.py", line 97, in update_lights
    update_lights)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/light/osramlightify.py", line 268, in __init__
    super().__init__(group, update_lights)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/light/osramlightify.py", line 121, in __init__
    self.update()
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/light/osramlightify.py", line 282, in update
    light = self._bridge.lights()[self._light_ids[0]]
KeyError:<PHONE_NUMBER>890067646

Additional info:

@duffrecords
I started to look into it. I don't really see why the bridge and the list of groups get out of sync in your case. I expected it not to happen. A first quick fix instead of revert the PR would be to add the following to your lightify config:
light:
  - platform: osramlightify
    host: <IP_ADDRESS>
    allow_lightify_groups: false

It wouls be already interesting to know if this works, because also the non group related features have been changed a bit during PR #7376

I looked further into it. Forget the end of my last comment I don't think its true. Anyhow, i prepared a fix/workaround with some debug output. Its based on the current dev branch. I would need somebody (@duffrecords) with the error to test it and send me back the debug output.
The fix can be found in my fork
After installing it, plz turn on the debug output:
logger:
  default: warning
  logs:
    homeassistant.components.light.osramlightify: debug

And send me back the output.

I tried setting allow_lightify_groups to false but I was still seeing that KeyError.  I upgraded to 0.45.1 today and the error does not happen, as long as allow_lightify_groups is false.  I do have a couple of groups within the Lightify app that contain the same devices as other groups.  Could that have something to do with it?  I tried to follow the link to your fork but the page was not found.  Were those changes already merged?

Oh FU I probably deleted it resently. I restore it.
Am 24.05.2017 23:06 schrieb "Ian Young"<EMAIL_ADDRESS>
I tried setting allow_lightify_groups to false but I was still seeing that
KeyError. I upgraded to 0.45.1 today and the error does not happen, as long
as allow_lightify_groups is false. I do have a couple of groups within the
Lightify app that contain the same devices as other groups. Could that have
something to do with it? I tried to follow the link to your fork but the
page was not found. Were those changes already merged?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/7594#issuecomment-303851758,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFL2NCaw0dwkUN_g8s4mXqjGjl_Agxszks5r9JvfgaJpZM4NaXRx
.

Did you mean your fork of python-lightify or home-assistant?  This link is broken.

No i deleted the Branche with it. I hipe I can recover it when Im back
home.
Am 27.05.2017 04:32 schrieb "Ian Young"<EMAIL_ADDRESS>
Did you mean your fork of python-lightify or home-assistant? This link
https://github.com/deisi/home-assistant/tree/osramlightify_Fix%237594
is broken.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/7594#issuecomment-304421168,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFL2NBrpssUFAucOAYKw5oxR1WGEuyAjks5r94stgaJpZM4NaXRx
.

I added some debug logging to the update method of OsramLightifyGroup to find out what's happening:
        _LOGGER.debug("self._luminary.lights() = %s" % str(self._luminary.lights()))
        _LOGGER.debug("self._bridge.lights() = %s" % str(self._bridge.lights()))

Here is the result:
2017-05-31 14:14:54 DEBUG (Thread-3) [homeassistant.components.light.osramlightify] self._luminary.lights() = [9518399593890068536,<PHONE_NUMBER>890068598]
2017-05-31 14:14:54 DEBUG (Thread-3) [homeassistant.components.light.osramlightify] self._bridge.lights() = {}
2017-05-31 14:14:54 ERROR (MainThread) [homeassistant.helpers.entity] Update for light.living fails
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity.py", line 225, in async_update_ha_state
    None, self.update)
  File "/opt/rh/rh-python35/root/usr/lib64/python3.5/asyncio/futures.py", line 358, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/opt/rh/rh-python35/root/usr/lib64/python3.5/asyncio/tasks.py", line 290, in _wakeup
    future.result()
  File "/opt/rh/rh-python35/root/usr/lib64/python3.5/asyncio/futures.py", line 274, in result
    raise self._exception
  File "/opt/rh/rh-python35/root/usr/lib64/python3.5/concurrent/futures/thread.py", line 55, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/light/osramlightify.py", line 284, in update
    light = self._bridge.lights()[self._light_ids[0]]
KeyError:<PHONE_NUMBER>890068536

So self._bridge.lights() is not returning any items.

I can duplicate the behavior using the Python interpreter in the same virtualenv:
(homeassistant) bash-4.2$ python
Python 3.5.1 (default, Oct 21 2016, 21:37:19)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import lightify
>>> host = '<IP_ADDRESS>'
>>> bridge = lightify.Lightify(host)
>>> bridge.update_all_light_status()
>>> bridge.update_group_list()
>>> bridge.lights()
{}
>>>

The update_all_light_status() method returns immediately, which makes me think it is silently failing.  update_group_list(), however, takes a moment to finish and then bridge.groups() returns a dictionary of Group objects.

I turned on debugging and watched the variables in the update_all_light_status() method.  In the following code, num evaluates to 0:
            data = self.build_all_light_status(1)
            data = self.send(data)
            (num,) = struct.unpack("<H", data[7:9])

Since num = 0, this loop never executes:
            new_lights = {}
            ...
            for i in range(0, num):
                new_lights[addr] = light
            ...
            self.__lights = new_lights

and self.__lights is still equal to {}.  I can send you the binary data output if that helps.

2017-05-31 19:03:00 DEBUG (Thread-5) [lightify] sending "b'070002130000070201'"
2017-05-31 19:03:00 DEBUG (Thread-5) [lightify] 2
2017-05-31 19:03:00 DEBUG (Thread-5) [lightify] Length 1459
2017-05-31 19:03:00 DEBUG (Thread-5) [lightify] Expected 1459
2017-05-31 19:03:00 DEBUG (Thread-5) [lightify] received "1459 b'b305'"
2017-05-31 19:03:00 DEBUG (Thread-5) [lightify] received "1459 b'031300000702001d009ce371360a00002618840a010204920208000031c409fdfff7ff53747564696f204e0000000000000000000000000000000005c138390a00002618840a010204920208000031c409fffaefff53747564696f20450000000000000000000000000000000002a448390a00002618840a010204920208000014c40902ff00ff53747564696f205300000000000000000000000000000000939120870700002618840a010204920208000032c40902ff00ff53747564696f2057000000000000000000000000000000004f9ca3d1e80000261884401000512102000001640000010000ff7377697463685f73747564696f0000000000000000000000dcf3cec3020000261884020102049202000000645d1901fcffff426564726f6f6d204c616d700000000000000000000000001c3397c1020000261884020102049202020000645d19010000ff426564726f6f6d2057000000000000000000000000000000dbaeafdd050000261884020102049202020000645d19010000ff426564726f6f6d2045000000000000000000000000000000be49f4cce80000261884401000512102000001640000010000ff7377697463685f626564726f6f6d00000a0000000000000065d2aab30800002618840a0102049202000000645d19ffffffff46726f6e7420446f6f720000000000000000000000000000f6179cd1e80000261884401000512102000001640000010000ff7377697463685f66726f6e745f6472000100000000000000ef0038380a00002618840a010204920204000032c409ff8400ff4c6976696e6720526f6f6d20450000000000000000000000e86376380a00002618840a010204920204000032c40902ff00ff4c6976696e6720526f6f6d2057000000000000000000000058a3afd1e80000261884401000512102000001640000010000ff7377697463685f6c6976696e670000000b000000000000007d2d35850500002618840a010204920200000064c40902ff00ff42617468726f6f6d204d6972726f72000000000000000000f4cef6810500002618840a010204920240000014d007ff4a0aff4c6976696e6720526d20537465700000010000000000000040a2be340a00002618840a010204920201000032c40902ff00ff44696e696e6720526f6f6d20450000000000000000000000051988370a00002618840a010204920201000030c40902ff00ff44696e696e6720526f6f6d20570000000000000000000000e3e14a340a00002618840a010204920201000032c40902ff00ff44696e696e6720526f6f6d205300000000000000000000005679c7cfe80000261884401000512102000001640000010000ff7377697463685f64696e696e67000000010000000000000059dd49620200002618840a0102049202500000648e0a50ff00ff426f6f6b63617365204d6964646c6500000000000000000090c7735e0300002618840a010204920250000014c409ff4a0aff426f6f6b6361736520546f70000000000000000000000000a84230870500002618840a0102049202500000648e0a50ff00ff426f6f6b6361736520426f74746f6d0000000000000000008279470e0900002618840a010204920220000064c409f702ffff4b69746368656e2053310000000000000000000000000000cef9b5350a00002618840a010204920220000064c409f702ffff4b69746368656e2053320000000000000000000000000000ecf38e360a00002618840a010204920220000064c409f702ffff4b69746368656e204e310000000000000000000000000000388f81330a00002618840a010204920220000064c409ff01cfff4b69746368656e204e320000000000000000000000000000a179f1cae80000261884401000512102000001640000010000ff7377697463685f6b6974636865'"
2017-05-31 19:03:00 DEBUG (Thread-5) [lightify] received "£πq6
2017-05-31 19:03:00 DEBUG (Thread-5) [lightify] num: 0

Interesting...  I noticed the length of the command generated by build_all_light_status was 9 bytes so, in update_all_light_status, I changed the flag from 1 to a binary empty string:
-            data = self.build_all_light_status(1)
+            data = self.build_all_light_status("".encode('cp437'))

This returns an 8-byte command, instead of 9.  Passing that to the next function,
            data = self.send(data)

I get a 560-byte response, in which I can see the names of all my devices.  Previously, using 1 as the flag returned a 61-byte response that looked malformed.  Now, if I pass data to
            (num,) = struct.unpack("<H", data[7:9])

I get 29, which is the exact number of devices I have.  However, the response does not seem to break up into data according to this documentation:
https://github.com/noctarius/lightify-binary-protocol#packet_list_paired_devices
Here is the binary response:
b'\x03\x13\x00\x00\x07\x03\x00\x1d\x00\x01\x9c\xe3Studio N\x00\x00\x00\x00\x00\x00\x00\x00\x02\x05\xc1Studio E\x00\x00\x00\x00\x00\x00\x00\x00\x03\x02\xa4Studio S\x00\x00\x00\x00\x00\x00\x00\x00\x04\x93\x91Studio W\x00\x00\x00\x00\x00\x00\x00\x00\x05O\x9cswitch_studio\x00\x00\x00\x06\xdc\xf3Bedroom Lamp\x00\x00\x00\x00\x07\x1c3Bedroom W\x00\x00\x00\x00\x00\x00\x00\x08\xdb\xaeBedroom E\x00\x00\x00\x00\x00\x00\x00\t\xbeIswitch_bedroom\x00\x00\ne\xd2Front Door\x00\x00\x00\x00\x00\x00\x0b\xf6\x17switch_front_dr\x00\x0c\xef\x00Living Room E\x00\x00\x00\r\xe8cLiving Room W\x00\x00\x00\x0eX\xa3switch_living\x00\x00\x00\x0f}-Bathroom Mirror\x00\x10\xf4\xceLiving Rm Step\x00\x00\x11@\xa2Dining Room E\x00\x00\x00\x12\x05\x19Dining Room W\x00\x00\x00\x13\xe3\xe1Dining Room S\x00\x00\x00\x14Vyswitch_dining\x00\x00\x00\x15Y\xddBookcase Middle\x00\x16\x90\xc7Bookcase Top\x00\x00\x00\x00\x17\xa8BBookcase Bottom\x00\x18\x82yKitchen S1\x00\x00\x00\x00\x00\x00\x19\xce\xf9Kitchen S2\x00\x00\x00\x00\x00\x00\x1a\xec\xf3Kitchen N1\x00\x00\x00\x00\x00\x00\x1b8\x8fKitchen N2\x00\x00\x00\x00\x00\x00\x1c\xa1yswitch_kitchen\x00\x00\x1eN6TV Backlight\x00\x00\x00\x00'

I know that bytes 8 and 9 (or data[7:9]) represent the number of devices, and bytes 11-27 (data[12:28]) are the name of the first device, but I can't figure out the rest.

Die you try to update the Firmware of you bridge? Maybe they changes
something there at some point.
Am 02.06.2017 05:57 schrieb "Ian Young"<EMAIL_ADDRESS>
Interesting... I noticed the length of the command generated by
build_all_light_status was 9 bytes so, in update_all_light_status, I
changed the flag from 1 to a binary empty string:

       data = self.build_all_light_status(1)

       data = self.build_all_light_status("".encode('cp437'))

This returns an 8-byte command, instead of 9. Passing that to the next
function,
        data = self.send(data)

I get a 560-byte response, in which I can see the names of all my devices.
Previously, using 1 as the flag returned a 61-byte response that looked
malformed. Now, if I pass data to
        (num,) = struct.unpack("<H", data[7:9])

I get 29, which is the exact number of devices I have. However, the
response does not seem to break up into data according to this
documentation:
https://github.com/noctarius/lightify-binary-protocol#
packet_list_paired_devices
Here is the binary response:
b'\x03\x13\x00\x00\x07\x03\x00\x1d\x00\x01\x9c\xe3Studio N\x00\x00\x00\x00\x00\x00\x00\x00\x02\x05\xc1Studio E\x00\x00\x00\x00\x00\x00\x00\x00\x03\x02\xa4Studio S\x00\x00\x00\x00\x00\x00\x00\x00\x04\x93\x91Studio W\x00\x00\x00\x00\x00\x00\x00\x00\x05O\x9cswitch_studio\x00\x00\x00\x06\xdc\xf3Bedroom Lamp\x00\x00\x00\x00\x07\x1c3Bedroom W\x00\x00\x00\x00\x00\x00\x00\x08\xdb\xaeBedroom E\x00\x00\x00\x00\x00\x00\x00\t\xbeIswitch_bedroom\x00\x00\ne\xd2Front Door\x00\x00\x00\x00\x00\x00\x0b\xf6\x17switch_front_dr\x00\x0c\xef\x00Living Room E\x00\x00\x00\r\xe8cLiving Room W\x00\x00\x00\x0eX\xa3switch_living\x00\x00\x00\x0f}-Bathroom Mirror\x00\x10\xf4\xceLiving Rm Step\x00\x00\x11@\xa2Dining Room E\x00\x00\x00\x12\x05\x19Dining Room W\x00\x00\x00\x13\xe3\xe1Dining Room S\x00\x00\x00\x14Vyswitch_dining\x00\x00\x00\x15Y\xddBookcase Middle\x00\x16\x90\xc7Bookcase Top\x00\x00\x00\x00\x17\xa8BBookcase Bottom\x00\x18\x82yKitchen S1\x00\x00\x00\x00\x00\x00\x19\xce\xf9Kitchen S2\x00\x00\x00\x00\x00\x00\x1a\xec\xf3Kitchen N1\x00\x00\x00\x00\x00\x00\x1b8\x8fKitchen N2\x00\x00\x00\x00\x00\x00\x1c\xa1yswitch_kitchen\x00\x00\x1eN6TV Backlight\x00\x00\x00\x00'
I know that bytes 8 and 9 (or data[7:9]) represent the number of devices,
and bytes 11-27 (data[12:28]) are the name of the first device, but I
can't figure out the rest.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/7594#issuecomment-305682990,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFL2NPnE0GR2b8zJ8370HA1YcGHgm4Dyks5r_4gsgaJpZM4NaXRx
.

Yes, I updated the firmware before setting up Home Assistant. Which version are you using? This is what I have:
Gateway WiFi: <IP_ADDRESS>
Gateway Zigbee: <IP_ADDRESS>
Lightify A19 Tunable White: 01020492
Lightify Dimming Switch: 10005121
Lightify BR RGBW: 01020492
Lightify Flex RGBW: 01020492
Lightify A19 RGBW: 01020492

Is there a difference between the US and EU APIs?

Here is a different approach.  I remembered that when I set allow_lightify_groups to False, my lights were still detected, which means that something eventually populates bridge.__lights with the correct data.  Since OsramLightifyGroup.update() will produce a KeyError exception if no lights are defined yet, I wrapped that section of code in a conditional to avoid that scenario.
    def update(self):
        """Update group status."""
        super().update()
        self._light_ids = self._luminary.lights()
        _LOGGER.debug("self._luminary.lights() = %s" % str(self._luminary.lights()))
        _LOGGER.debug("self._bridge.lights() = %s" % str(self._bridge.lights()))
        if self._bridge.lights():
            light = self._bridge.lights()[self._light_ids[0]]
            self._brightness = int(light.lum() * 2.55)
            self._rgb = light.rgb()
            o_temp = light.temp()
            if o_temp == 0:
                self._temperature = None
            else:
                self._temperature = color_temperature_kelvin_to_mired(o_temp)
            self._state = light.on()
        else:
            _LOGGER.debug("bridge.lights() was empty. can't update lights.")

The first time I ran Home Assistant with this modification, it did not find my lights.  But then I restarted the service and, that time, it found all my lights and groups.  It seems like the module is trying to set up the groups before the individual lights have been discovered.  By inserting if self._bridge.lights():, it bypasses that step if it's not ready yet.  Eventually, the lights will be discovered and then the groups can be successfully updated.

Here is some abbreviated log output.  At first, the update function is called several times, during which it has discovered the groups, but not the lights:
2017-06-02 18:58:48 DEBUG (Thread-3) [homeassistant.components.light.osramlightify] bridge.lights() = {}
2017-06-02 18:58:48 DEBUG (Thread-3) [homeassistant.components.light.osramlightify] bridge.groups() = {'Living': <lightify.Group object at 0x7f1b09668b70>, 'Kitchen': <lightify.Group object at 0x7f1b08e59080>, 'Bedroom': <lightify.Group object at 0x7f1b08e5b3c8>, 'Dining': <lightify.Group object at 0x7f1b08e5b630>, 'Studio': <lightify.Group object at 0x7f1b39ede4e0>, 'Movie': <lightify.Group object at 0x7f1b08e49048>, 'Bookcase': <lightify.Group object at 0x7f1b08e592e8>}
2017-06-02 18:58:48 DEBUG (Thread-3) [homeassistant.components.light.osramlightify] self._luminary.lights() = [9518399593890068081,<PHONE_NUMBER>890068792,<PHONE_NUMBER>890068808,<PHONE_NUMBER>889892128]
2017-06-02 18:58:48 DEBUG (Thread-3) [homeassistant.components.light.osramlightify] self._bridge.lights() = {}
2017-06-02 18:58:48 DEBUG (Thread-3) [homeassistant.components.light.osramlightify] bridge.lights() was empty. can't update lights.
2017-06-02 18:58:48 DEBUG (Thread-1) [homeassistant.components.light.osramlightify] self._luminary.lights() = [9518399593889992263,<PHONE_NUMBER>890067893,<PHONE_NUMBER>890068110,<PHONE_NUMBER>890067329]
2017-06-02 18:58:48 DEBUG (Thread-1) [homeassistant.components.light.osramlightify] self._bridge.lights() = {}
2017-06-02 18:58:48 DEBUG (Thread-1) [homeassistant.components.light.osramlightify] bridge.lights() was empty. can't update lights.

So My Gateway Version is: <IP_ADDRESS>
Classic A60 RGBW: 01020412
Classic A60 TW: 01020412
And I dont know where you found the Zigbee version but I think it doesnt matter anyways. Because you have a newer version for the GW firmware I'm afraid to upgrade now ^^ Its working so nicely right now...

When I rerun you little interactive session I get:
import lightify
host = '<IP_ADDRESS>'
bridge = lightify.Lightify(host)
bridge.update_all_light_status()
bridge.lights()
Out[6]:
{9518399593889450265: <lightify.Light at 0x7f03dd59ec18>,
<PHONE_NUMBER>889457631: <lightify.Light at 0x7f03dd59eba8>,
<PHONE_NUMBER>889460213: <lightify.Light at 0x7f03dd59eac8>,
<PHONE_NUMBER>889466094: <lightify.Light at 0x7f03dd59ea58>,
<PHONE_NUMBER>902657040: <lightify.Light at 0x7f03dd59eb38>,
<PHONE_NUMBER>902701169: <lightify.Light at 0x7f03dd59ecf8>,
<PHONE_NUMBER>902706438: <lightify.Light at 0x7f03dd59e898>,
<PHONE_NUMBER>902729462: <lightify.Light at 0x7f03dd59e908>,
<PHONE_NUMBER>902731853: <lightify.Light at 0x7f03dd59e978>,
<PHONE_NUMBER>902734730: <lightify.Light at 0x7f03dd59ec88>,
<PHONE_NUMBER>903651718: <lightify.Light at 0x7f03dd59e9e8>}

and its also very fast at least I didn't realize any delay during the bridge.update_all_light_status() call. While the bridge.update_group_list() actually needs like 1 or 2 seconds.

Can you make a PR out of your little fix with the if self._bridge.lights():? I could then test it.

Okay, thats what I did:
https://github.com/deisi/home-assistant/tree/fix_group_update
(and now I try not to delete it ;) )
as far as I can see its working.
And here is all I did:
https://github.com/deisi/home-assistant/commit/b6ccbf5d67c94ef02499070172f5740551f64291
Is that what you meant?

Yes, that's essentially all I did.  I think your if not... return condition is cleaner and easier to read than the way I wrapped the rest of the lines in the if block.  Thanks!

Okay, then I will make a PR out of it.
Cheers
Ian Young<EMAIL_ADDRESS>writes:

Yes, that's essentially all I did.  I think your if not... return condition is cleaner and easier to read than the way I wrapped the rest of the lines in the if block.  Thanks!
--You are receiving this because you authored the thread.Reply to this email directly, https://github.com/home-assistant/home-assistant/issues/7594#issuecomment-307220779, or https://github.com/notifications/unsubscribe-auth/AFL2NOxnci5CoNfKT8UBVQNfiJco0q_gks5sCFwMgaJpZM4NaXRx.

The if condition mentioned above enables my Home Assistant service to retrieve the list of lights without crashing but I still cannot obtain this list using the Python interpreter.  I think it is getting a different binary response from the gateway than what is expected.  What result do you get when you run these commands?
>>> from lightify import Lightify
>>> gw = Lightify('<IP_ADDRESS>')
>>> data = gw.build_all_light_status(1)
>>> data
b'\x07\x00\x02\x13\x00\x00\x07\x02\x01'
>>> data = gw.send(data)
>>> data
b'n\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00\xbeY\xc1]\x02\x00\x00&\x18\x84\n\x01\x02\x04\x92\x02@\x06\x001\xdb\x08\xe8\xc0\xff\xffTV Backlight\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

This issue can be closed.  The problem is caused by the gateway sending multiple packets that weren't joined back together.  It's been fixed in issue 8733 and the update should be released soon.


type comparing is wrong of usage of Array.reduce with 2nd argument

Using Array.reduce with 2nd argument and annotating return type for 1st callback argument, Flow shows error message.
try flow
According to them, Flow detected its usage is callbackfn: (previousValue: U, currentValue: T, currentIndex: number, array: Array<T>) => U.
Its correct !!
But Flow said This parameter is incompatible.
This might be wrong.
In the detail of error message, Flow compared return type ReturnType to 2nd parameter e: string.
This parameter is incompatible:
9:   ): ReturnType { // annotate return type
        ^ object type. This type is incompatible with
8:     e: string          ^ string

But in this case, ReturnType should be compared to only 1st parameter, because of declaration is callbackfn: (previousValue: U, currentValue: T, currentIndex: number, array: Array<T>) => U
This is from 0.56.0 and 0.57.3 is the same.
// @flow
type ReturnType = {};

//not work
[].reduce(
  function(
  	p: ReturnType,
    e: string
  ): ReturnType { // annotate return type
    return {};
  }, {}
);

//this works
[].reduce(
  function(
  	p: ReturnType,
    e: string
  ) { // without annotation
    return {};
  }, {}
);

Can anyone give us an update on this one? This is a very annoying issue that prevents us from using reduce function with Flow.


Bug: quitting and reopening the app during a game excludes the player

I implemented this in order to have this behavior. What should be the correct behavior ?