text:
Add Pillow as dependency

I noticed resqpy.tomography imports PIL, which is not available in the project's dependencies. This will lead to an import error if the module is used in a fresh environment.
This PR tries to fix that by adding the library to the main list of dependencies. An alternative could be to add it as an optional extra, under "extras_requires".
It looks like the Python Imaging Library PIL is no longer maintained, and Pillow is the actively used fork, so suggesting putting that into our dependencies.
I've added resqpy.tomography to the TOC too, as presumably we want this to appear in the docs.
I believe it's not used in any unit tests, and is missing from the documentation table of contents, which is why the CI suite did not pick this up.

Codecov Report

Merging #142 (d4c673e) into master (0b18f88) will decrease coverage by 0.22%.
The diff coverage is n/a.

:exclamation: Current head d4c673e differs from pull request most recent head 8eaa623. Consider uploading reports for the commit 8eaa623 to get more accurate results

@@            Coverage Diff             @@
##           master     #142      +/-   ##
==========================================
- Coverage   42.00%   41.78%   -0.23%
==========================================
  Files          51       51
  Lines       21489    21493       +4
==========================================
- Hits         9026     8980      -46
- Misses      12463    12513      +50

Impacted Files
Coverage Δ

resqpy/olio/vector_utilities.py
38.39% <0.00%> (-8.93%)
:arrow_down:

resqpy/olio/grid_functions.py
11.86% <0.00%> (-8.61%)
:arrow_down:

resqpy/well.py
50.59% <0.00%> (-0.01%)
:arrow_down:

resqpy/model.py
62.68% <0.00%> (+0.07%)
:arrow_up:

Continue to review full report at Codecov.

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

Alternatively, we could pull the tomography module out of resqpy and keep it as a bp internal module – I'm undecided what is best, let's discuss.

As discussed - decided to move tomography module elsewhere for now.

authors: andy-beer codecov-commenter connortann

repo: bp/resqpy


text:
Add the genesis block from within the Ledger

It's not correct to add it within the BlockStorage, because then we lose track whether the block was just added, or if it was loaded from disk. The difference is important, because the Ledger keeps track of UTXOs based on newly-added blocks to the ledger (and the serialized UTXO on disk).
Required for https://github.com/bpfkorea/agora/pull/194

Thank you!

Not a fan of this to be honest. The isEmpty method seems to be single-purpose. After initialization, it will always return true, which is a red flag.
The two options I can think of is:

Hard-error if the storage was not previously initialized and force the user to call an init method. This is less user friendly, interacts badly with tests, but is more configurable.
Provide a delegate that is called on first initialization.

Yes I agree. Let's go with the second option. Maybe we can come up with something better later.

source: gharchive/pull-request

repo: bpfkorea/agora

license: MIT

license_type: permissive

license_source: github-api


text:
Convert inlined locations to USDT

This is a PoC to start the conversation about converting inline information from the DWARF into USDT probe.
This PR adds a new executable src/inline2usdt that takes a program as an argument and adds a .note.stapsdt section with the location of all functions and their inlined instances encoded as USDT.
Listing the USTD of a patched binary looks like this with bpftrace:
$ sudo build/src/bpftrace -l 'usdt:./hello-patched:*'
usdt:./hello-patched:inline:say_hi
usdt:./hello-patched:symbol:__do_global_dtors_aux
usdt:./hello-patched:symbol:_dl_relocate_static_pie
usdt:./hello-patched:symbol:_fini
usdt:./hello-patched:symbol:_init
usdt:./hello-patched:symbol:_start
usdt:./hello-patched:symbol:deregister_tm_clones
usdt:./hello-patched:symbol:frame_dummy
usdt:./hello-patched:symbol:register_tm_clones
usdt:./hello-patched:symbol:say_hello
usdt:./hello-patched:symbol:say_hi

Notice how the provider of the first USDT is inline, meaning it locates an inline instance of say_hi.
Running bpftrace on each USDT looks like this:
$ sudo build/src/bpftrace -e 'usdt:./hello-patched:* { print(probe) }' -c ./hello-patched
Attaching 12 probes...
usdt:./hello-patched:symbol:_start
usdt:./hello-patched:symbol:_init
usdt:./hello-patched:symbol:frame_dummy
usdt:./hello-patched:symbol:register_tm_clones
usdt:./hello-patched:inline:say_hi
hi
hello
usdt:./hello-patched:symbol:say_hello
usdt:./hello-patched:symbol:__do_global_dtors_aux
usdt:./hello-patched:symbol:deregister_tm_clones
usdt:./hello-patched:symbol:_fini

Checklist

[ ] Language changes are updated in man/adoc/bpftrace.adoc
[ ] User-visible and non-trivial changes updated in CHANGELOG.md
[ ] The new behaviour is covered by tests

Two quick thoughts:

Do you have rough numbers for amortized space overhead per USDT entry?
How about sorting USDT entries in section? So that consumers can binary search.

1. Do you have rough numbers for amortized space overhead per USDT entry?

I ran it on my vmlinux 6.4 image: it found 295,598 locations for a total of 20,867,012 bytes in the .note.stapstd section. So it takes about 70 bytes per entry.

2. How about sorting USDT entries in section? So that consumers can binary search.

That can be done!

I ran it on my vmlinux 6.4 image: it found 295,598 locations for a total of 20,867,012 bytes in the .note.stapstd section. So it takes about 70 bytes per entry.

Great, not bad at all! Any idea what it'd be if ~6 function args are encoded as well?

Using DTRACE_PROBE1 to generate a USDT entry with 1 argument, I counted 10 bytes used to describe and locate the argument. Let's round it up to 16 bytes per argument, which gives us ~4.5 MiB extra data in the .note.stapstd section!

Not bad at all.

authors: danobi ttreyer

repo: bpftrace/bpftrace


text:
Update readme.md

Please delete this line before submitting, Pull request TITLE should look like this: [Resource] -> [Resource Section In Docs]
Resource Name - Edit this line
Edit this line with Small Description about new added resource
Link: www.linkToResource
Checklist:

[ ] I have performed a self-review of submitted resource and its follows the guidelines of the project.

Closing

authors: Alaev javierjops


text:
Fix: remove another special character to the hash

Also, don't use yarn 3

Tested and it worked

repo: brafdlog/caspion


text:
CORS

Hi, i've been trying to run Cerberus with CORS activated. But seemingly there is nothing i can do to enable the Cross Domain. All the requests are being blocked.
Any Clue? =\

What errors are you getting? I've added a CORS filter enabled which should allow everything you would need.

It's working with the api/auth
But when i try to use the obtained token to api/protected, i get the following server error:
Browser:
Failed to load resource: the server responded with a status of 401 (Unauthorized)
(index):1 XMLHttpRequest cannot load http://10.10.11.20:8080/api/protected. Response for preflight has invalid HTTP status code 401
Server message:
2015-12-11 18:12:32.874 DEBUG 6934 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : DispatcherServlet with name 'dispatcherServlet' processing OPTIONS request for [/api/error]
2015-12-11 18:12:32.883 DEBUG 6934 --- [nio-8080-exec-1] s.w.s.m.m.a.RequestMappingHandlerMapping : Looking up handler method for path /error
2015-12-11 18:12:32.884 DEBUG 6934 --- [nio-8080-exec-1] s.w.s.m.m.a.RequestMappingHandlerMapping : Returning handler method [public void org.springframework.web.servlet.handler.AbstractHandlerMethodMapping$EmptyHandler.handle()]
2015-12-11 18:12:32.886 DEBUG 6934 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Null ModelAndView returned to DispatcherServlet with name 'dispatcherServlet': assuming HandlerAdapter completed request handling
2015-12-11 18:12:32.886 DEBUG 6934 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Successfully completed request

@SlySurfer This should be fixed now.

source: gharchive/issue

authors: SlySurfer brahalla

repo: brahalla/Cerberus

license: mit

license_source: bigquery


text:
Show datatype_tags under datatype page

We should list all datatype_tags used by various application under the new datatype page. We should also list applications for each datatype_tags that uses it.
We should also allow super-admin to edit datatype name / desc, and maybe add descriptions for each datatype tags to show how it's used.

+1

This has been implemented

authors: francopestilli soichih

repo: brain-life/warehouse


text:
Error 500 when we open a PR in the GIN Brainglobe/test-data repo

We get an Error 500 when we try to open a PR n the GIN Brainglobe/test-data repo.
For now we are bypassing this by pushing directly to master, but we may want to figure out why the error is happening.

I've given you and @alessandrofelder admin permissions on the repo to see if that changes anything?

Thanks - doesn't seem to have helped unfortunately. I still get the same error now trying to open a PR from https://gin.g-node.org/BrainGlobe/test-data/src/add-brainreg-test-data to master

@niksirbi suggests that this may be because the GIN web interface is renownedly buggy, and similar (albeit not the same) issue have been reported over the last couple of years and unfortunately don't seem to have been active much since :cry:

Should we close this? it's not really a brainglobe-workflows issue.

Should we close this? it's not really a brainglobe-workflows issue.

Agreed.

authors: adamltyson alessandrofelder sfmig

repo: brainglobe/brainglobe-workflows


text:
Fix/pr 466 max arias full width container

Deployed to https://beghp.github.io/gh-pages-rc-12It fixes #406 - [x] an issue linked to the PR

Thanks @max-arias
I checked it's fixed and nothing is broken (desktop & mobile).

FYI issues discussed are fixed, but we need to update this branch with master

@max-arias
Thanks for resolving comments but could you also address this comment https://github.com/brainhubeu/react-carousel/pull/467#discussion_r422203939 ?
I just resolved the conflicts.

@piotr-s-brainhub Yup, that should be fixed 👍

@humbak
could you re-review?

I think we have it!

@max-arias
I checked it fixes the problem and it doesn't break anything (desktop & mobile).
On mobile, in the flex example, the images are shrunk horizontally which doesn't look good but it's related to another issue and It works better than previously (I checked that on mobile, as well, flex makes a blank space in production docs).

authors: humbak max-arias piotr-s-brainhub

repo: brainhubeu/react-carousel


text:
V2 beta

[ ] an issue linked to the PR

Warnings

:warning:

MODULE : node_modules/valid-url
| LICENSE : MIT*
| LICENSE_FILE : node_modules/valid-url/LICENSE
| REPOSITORY: https://github.com/ogt/valid-url
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/trim
| LICENSE : MIT*
| LICENSE_FILE : node_modules/trim/Readme.md
| REPOSITORY: undefined
| PUBLISHER : TJ Holowaychuk
| EMAIL : tj@vision-media.ca
| URL : undefined

:warning:

MODULE : node_modules/rx-lite
| LICENSE : Apache License, Version 2.0
| LICENSE_FILE : node_modules/rx-lite/readme.md
| REPOSITORY: https://github.com/Reactive-Extensions/RxJS
| PUBLISHER : Cloud Programmability Team
| EMAIL : undefined
| URL : https://github.com/Reactive-Extensions/RxJS/blob/master/authors.txt

:warning:

MODULE : node_modules/rx-lite-aggregates
| LICENSE : Apache License, Version 2.0
| LICENSE_FILE : node_modules/rx-lite-aggregates/readme.md
| REPOSITORY: https://github.com/Reactive-Extensions/RxJS
| PUBLISHER : Cloud Programmability Team
| EMAIL : undefined
| URL : https://github.com/Reactive-Extensions/RxJS/blob/master/authors.txt

:warning:

MODULE : node_modules/rc
| LICENSE : (BSD-2-Clause OR MIT OR Apache-2.0)
| LICENSE_FILE : node_modules/rc/LICENSE.APACHE2
| REPOSITORY: https://github.com/dominictarr/rc
| PUBLISHER : Dominic Tarr
| EMAIL : dominic.tarr@gmail.com
| URL : dominictarr.com

:warning:

MODULE : node_modules/xhr/node_modules/process
| LICENSE : MIT*
| LICENSE_FILE : node_modules/xhr/node_modules/process/LICENSE
| REPOSITORY: https://github.com/shtylman/node-process
| PUBLISHER : Roman Shtylman
| EMAIL : shtylman@gmail.com
| URL : undefined

:warning:

MODULE : node_modules/potrace
| LICENSE : GPL-2.0
| LICENSE_FILE : node_modules/potrace/LICENSE
| REPOSITORY: https://github.com/tooolbox/node-potrace
| PUBLISHER : mattmc
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/object-component
| LICENSE : MIT*
| LICENSE_FILE : node_modules/object-component/Readme.md
| REPOSITORY: undefined
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/node-forge
| LICENSE : (BSD-3-Clause OR GPL-2.0)
| LICENSE_FILE : node_modules/node-forge/LICENSE
| REPOSITORY: https://github.com/digitalbazaar/forge
| PUBLISHER : Digital Bazaar, Inc.
| EMAIL : support@digitalbazaar.com
| URL : http://digitalbazaar.com/

:warning:

MODULE : node_modules/map-stream
| LICENSE : Custom: https://github.com/dominictarr/event-stream
| LICENSE_FILE : node_modules/map-stream/LICENCE
| REPOSITORY: https://github.com/dominictarr/map-stream
| PUBLISHER : Dominic Tarr
| EMAIL : dominic.tarr@gmail.com
| URL : http://dominictarr.com

:warning:

MODULE : node_modules/jsonify
| LICENSE : Public Domain
| LICENSE_FILE : node_modules/jsonify/README.markdown
| REPOSITORY: https://github.com/substack/jsonify
| PUBLISHER : Douglas Crockford
| EMAIL : undefined
| URL : http://crockford.com/

:warning:

MODULE : node_modules/json-schema
| LICENSE : AFLv2.1,BSD
| LICENSE_FILE : node_modules/json-schema/README.md
| REPOSITORY: https://github.com/kriszyp/json-schema
| PUBLISHER : Kris Zyp
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/indexof
| LICENSE : MIT*
| LICENSE_FILE : node_modules/indexof/Readme.md
| REPOSITORY: undefined
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/glob-to-regexp
| LICENSE : BSD*
| LICENSE_FILE : node_modules/glob-to-regexp/README.md
| REPOSITORY: https://github.com/fitzgen/glob-to-regexp
| PUBLISHER : Nick Fitzgerald
| EMAIL : fitzgen@gmail.com
| URL : undefined

:warning:

MODULE : node_modules/font-awesome
| LICENSE : (OFL-1.1 AND MIT)
| LICENSE_FILE : node_modules/font-awesome/README.md
| REPOSITORY: https://github.com/FortAwesome/Font-Awesome
| PUBLISHER : Dave Gandy
| EMAIL : dave@fontawesome.io
| URL : http://twitter.com/davegandy

:warning:

MODULE : node_modules/expand-template
| LICENSE : (MIT OR WTFPL)
| LICENSE_FILE : node_modules/expand-template/LICENSE
| REPOSITORY: https://github.com/ralphtheninja/expand-template
| PUBLISHER : LM
| EMAIL : ralphtheninja@riseup.net
| URL : undefined

:warning:

MODULE : node_modules/exif-parser
| LICENSE : MIT*
| LICENSE_FILE : node_modules/exif-parser/LICENSE.md
| REPOSITORY: https://github.com/bwindels/exif-parser
| PUBLISHER : Bruno Windels
| EMAIL : bruno.windels@gmail.com
| URL : undefined

:warning:

MODULE : node_modules/css-select/node_modules/domutils
| LICENSE : BSD*
| LICENSE_FILE : node_modules/css-select/node_modules/domutils/LICENSE
| REPOSITORY: https://github.com/FB55/domutils
| PUBLISHER : Felix Boehm
| EMAIL : me@feedic.com
| URL : undefined

:warning:

MODULE : node_modules/html-dom-parser/node_modules/domhandler
| LICENSE : BSD*
| LICENSE_FILE : node_modules/html-dom-parser/node_modules/domhandler/LICENSE
| REPOSITORY: https://github.com/fb55/DomHandler
| PUBLISHER : Felix Boehm
| EMAIL : me@feedic.com
| URL : undefined

:warning:

MODULE : node_modules/eslint-plugin-import/node_modules/doctrine
| LICENSE : BSD
| LICENSE_FILE : node_modules/eslint-plugin-import/node_modules/doctrine/LICENSE.BSD
| REPOSITORY: https://github.com/eslint/doctrine
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/css-select
| LICENSE : BSD*
| LICENSE_FILE : node_modules/css-select/LICENSE
| REPOSITORY: https://github.com/fb55/css-select
| PUBLISHER : Felix Boehm
| EMAIL : me@feedic.com
| URL : undefined

:warning:

MODULE : node_modules/react-live/node_modules/create-react-context
| LICENSE : MIT*
| LICENSE_FILE : node_modules/react-live/node_modules/create-react-context/LICENSE
| REPOSITORY: https://github.com/thejameskyle/create-react-context
| PUBLISHER : James Kyle
| EMAIL : me@thejameskyle.com
| URL : undefined

:warning:

MODULE : node_modules/component-props
| LICENSE : MIT*
| LICENSE_FILE : node_modules/component-props/Readme.md
| REPOSITORY: https://github.com/component/props
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/component-inherit
| LICENSE : MIT*
| LICENSE_FILE : node_modules/component-inherit/Readme.md
| REPOSITORY: https://github.com/component/inherit
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/component-bind
| LICENSE : MIT*
| LICENSE_FILE : node_modules/component-bind/Readme.md
| REPOSITORY: https://github.com/component/bind
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/callsite
| LICENSE : MIT*
| LICENSE_FILE : node_modules/callsite/Readme.md
| REPOSITORY: undefined
| PUBLISHER : TJ Holowaychuk
| EMAIL : tj@vision-media.ca
| URL : undefined

:warning:

MODULE : node_modules/better-assert
| LICENSE : MIT*
| LICENSE_FILE : node_modules/better-assert/Readme.md
| REPOSITORY: https://github.com/visionmedia/better-assert
| PUBLISHER : TJ Holowaychuk
| EMAIL : tj@vision-media.ca
| URL : undefined

:warning:

MODULE : node_modules/async-foreach
| LICENSE : MIT*
| LICENSE_FILE : node_modules/async-foreach/LICENSE-MIT
| REPOSITORY: https://github.com/cowboy/javascript-sync-async-foreach
| PUBLISHER : "Cowboy" Ben Alman
| EMAIL : undefined
| URL : http://benalman.com/

:warning:

MODULE : node_modules/@mikaelkristiansson/domready
| LICENSE : MIT*
| LICENSE_FILE : node_modules/@mikaelkristiansson/domready/LICENSE
| REPOSITORY: https://github.com/mikaelkristiansson/domready
| PUBLISHER : Mikael Kristiansson
| EMAIL : undefined
| URL : undefined

  Generated by :no_entry_sign: dangerJS against 423d18efbeea7b3acb881cf4bb84c578efb01528

Warnings

:warning:

MODULE : node_modules/valid-url
| LICENSE : MIT*
| LICENSE_FILE : node_modules/valid-url/LICENSE
| REPOSITORY: https://github.com/ogt/valid-url
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/trim
| LICENSE : MIT*
| LICENSE_FILE : node_modules/trim/Readme.md
| REPOSITORY: undefined
| PUBLISHER : TJ Holowaychuk
| EMAIL : tj@vision-media.ca
| URL : undefined

:warning:

MODULE : node_modules/rx-lite
| LICENSE : Apache License, Version 2.0
| LICENSE_FILE : node_modules/rx-lite/readme.md
| REPOSITORY: https://github.com/Reactive-Extensions/RxJS
| PUBLISHER : Cloud Programmability Team
| EMAIL : undefined
| URL : https://github.com/Reactive-Extensions/RxJS/blob/master/authors.txt

:warning:

MODULE : node_modules/rx-lite-aggregates
| LICENSE : Apache License, Version 2.0
| LICENSE_FILE : node_modules/rx-lite-aggregates/readme.md
| REPOSITORY: https://github.com/Reactive-Extensions/RxJS
| PUBLISHER : Cloud Programmability Team
| EMAIL : undefined
| URL : https://github.com/Reactive-Extensions/RxJS/blob/master/authors.txt

:warning:

MODULE : node_modules/rc
| LICENSE : (BSD-2-Clause OR MIT OR Apache-2.0)
| LICENSE_FILE : node_modules/rc/LICENSE.APACHE2
| REPOSITORY: https://github.com/dominictarr/rc
| PUBLISHER : Dominic Tarr
| EMAIL : dominic.tarr@gmail.com
| URL : dominictarr.com

:warning:

MODULE : node_modules/xhr/node_modules/process
| LICENSE : MIT*
| LICENSE_FILE : node_modules/xhr/node_modules/process/LICENSE
| REPOSITORY: https://github.com/shtylman/node-process
| PUBLISHER : Roman Shtylman
| EMAIL : shtylman@gmail.com
| URL : undefined

:warning:

MODULE : node_modules/potrace
| LICENSE : GPL-2.0
| LICENSE_FILE : node_modules/potrace/LICENSE
| REPOSITORY: https://github.com/tooolbox/node-potrace
| PUBLISHER : mattmc
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/object-component
| LICENSE : MIT*
| LICENSE_FILE : node_modules/object-component/Readme.md
| REPOSITORY: undefined
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/node-forge
| LICENSE : (BSD-3-Clause OR GPL-2.0)
| LICENSE_FILE : node_modules/node-forge/LICENSE
| REPOSITORY: https://github.com/digitalbazaar/forge
| PUBLISHER : Digital Bazaar, Inc.
| EMAIL : support@digitalbazaar.com
| URL : http://digitalbazaar.com/

:warning:

MODULE : node_modules/map-stream
| LICENSE : Custom: https://github.com/dominictarr/event-stream
| LICENSE_FILE : node_modules/map-stream/LICENCE
| REPOSITORY: https://github.com/dominictarr/map-stream
| PUBLISHER : Dominic Tarr
| EMAIL : dominic.tarr@gmail.com
| URL : http://dominictarr.com

:warning:

MODULE : node_modules/jsonify
| LICENSE : Public Domain
| LICENSE_FILE : node_modules/jsonify/README.markdown
| REPOSITORY: https://github.com/substack/jsonify
| PUBLISHER : Douglas Crockford
| EMAIL : undefined
| URL : http://crockford.com/

:warning:

MODULE : node_modules/json-schema
| LICENSE : AFLv2.1,BSD
| LICENSE_FILE : node_modules/json-schema/README.md
| REPOSITORY: https://github.com/kriszyp/json-schema
| PUBLISHER : Kris Zyp
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/indexof
| LICENSE : MIT*
| LICENSE_FILE : node_modules/indexof/Readme.md
| REPOSITORY: undefined
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/glob-to-regexp
| LICENSE : BSD*
| LICENSE_FILE : node_modules/glob-to-regexp/README.md
| REPOSITORY: https://github.com/fitzgen/glob-to-regexp
| PUBLISHER : Nick Fitzgerald
| EMAIL : fitzgen@gmail.com
| URL : undefined

:warning:

MODULE : node_modules/font-awesome
| LICENSE : (OFL-1.1 AND MIT)
| LICENSE_FILE : node_modules/font-awesome/README.md
| REPOSITORY: https://github.com/FortAwesome/Font-Awesome
| PUBLISHER : Dave Gandy
| EMAIL : dave@fontawesome.io
| URL : http://twitter.com/davegandy

:warning:

MODULE : node_modules/expand-template
| LICENSE : (MIT OR WTFPL)
| LICENSE_FILE : node_modules/expand-template/LICENSE
| REPOSITORY: https://github.com/ralphtheninja/expand-template
| PUBLISHER : LM
| EMAIL : ralphtheninja@riseup.net
| URL : undefined

:warning:

MODULE : node_modules/exif-parser
| LICENSE : MIT*
| LICENSE_FILE : node_modules/exif-parser/LICENSE.md
| REPOSITORY: https://github.com/bwindels/exif-parser
| PUBLISHER : Bruno Windels
| EMAIL : bruno.windels@gmail.com
| URL : undefined

:warning:

MODULE : node_modules/css-select/node_modules/domutils
| LICENSE : BSD*
| LICENSE_FILE : node_modules/css-select/node_modules/domutils/LICENSE
| REPOSITORY: https://github.com/FB55/domutils
| PUBLISHER : Felix Boehm
| EMAIL : me@feedic.com
| URL : undefined

:warning:

MODULE : node_modules/html-dom-parser/node_modules/domhandler
| LICENSE : BSD*
| LICENSE_FILE : node_modules/html-dom-parser/node_modules/domhandler/LICENSE
| REPOSITORY: https://github.com/fb55/DomHandler
| PUBLISHER : Felix Boehm
| EMAIL : me@feedic.com
| URL : undefined

:warning:

MODULE : node_modules/eslint-plugin-import/node_modules/doctrine
| LICENSE : BSD
| LICENSE_FILE : node_modules/eslint-plugin-import/node_modules/doctrine/LICENSE.BSD
| REPOSITORY: https://github.com/eslint/doctrine
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/css-select
| LICENSE : BSD*
| LICENSE_FILE : node_modules/css-select/LICENSE
| REPOSITORY: https://github.com/fb55/css-select
| PUBLISHER : Felix Boehm
| EMAIL : me@feedic.com
| URL : undefined

:warning:

MODULE : node_modules/react-live/node_modules/create-react-context
| LICENSE : MIT*
| LICENSE_FILE : node_modules/react-live/node_modules/create-react-context/LICENSE
| REPOSITORY: https://github.com/thejameskyle/create-react-context
| PUBLISHER : James Kyle
| EMAIL : me@thejameskyle.com
| URL : undefined

:warning:

MODULE : node_modules/component-props
| LICENSE : MIT*
| LICENSE_FILE : node_modules/component-props/Readme.md
| REPOSITORY: https://github.com/component/props
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/component-inherit
| LICENSE : MIT*
| LICENSE_FILE : node_modules/component-inherit/Readme.md
| REPOSITORY: https://github.com/component/inherit
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/component-bind
| LICENSE : MIT*
| LICENSE_FILE : node_modules/component-bind/Readme.md
| REPOSITORY: https://github.com/component/bind
| PUBLISHER : undefined
| EMAIL : undefined
| URL : undefined

:warning:

MODULE : node_modules/callsite
| LICENSE : MIT*
| LICENSE_FILE : node_modules/callsite/Readme.md
| REPOSITORY: undefined
| PUBLISHER : TJ Holowaychuk
| EMAIL : tj@vision-media.ca
| URL : undefined

:warning:

MODULE : node_modules/better-assert
| LICENSE : MIT*
| LICENSE_FILE : node_modules/better-assert/Readme.md
| REPOSITORY: https://github.com/visionmedia/better-assert
| PUBLISHER : TJ Holowaychuk
| EMAIL : tj@vision-media.ca
| URL : undefined

:warning:

MODULE : node_modules/async-foreach
| LICENSE : MIT*
| LICENSE_FILE : node_modules/async-foreach/LICENSE-MIT
| REPOSITORY: https://github.com/cowboy/javascript-sync-async-foreach
| PUBLISHER : "Cowboy" Ben Alman
| EMAIL : undefined
| URL : http://benalman.com/

:warning:

MODULE : node_modules/@mikaelkristiansson/domready
| LICENSE : MIT*
| LICENSE_FILE : node_modules/@mikaelkristiansson/domready/LICENSE
| REPOSITORY: https://github.com/mikaelkristiansson/domready
| PUBLISHER : Mikael Kristiansson
| EMAIL : undefined
| URL : undefined

  Generated by :no_entry_sign: dangerJS against d3352e6c65ccece3d5c28e43eeaaad9f30d73d5f


text:
Sidekiq 4.1?

Does this Gem currently support Sidekiq 4.1?
In desperate need for a rate limiter and no other gems I have found seem to support 4.x yet.

Yes. I am using it in 4.1 without a problem

authors: krisquigley webdestroya


text:
Dev stuff

Setup devtools;
Bump shadow-cljs version;

Rebased with master and bumped shadow-cljs version to 2.0.61 - way less warnings now, just a single one actually :)

yeah! it is improving fast :)

authors: mhuebert pedrorgirardi

repo: braintripping/re-view


text:
Measuring script (measure.py) and files.csv - possible improvements

As mentioned in #45 (improper place) I think, that there are possible improvements

I think I will make the mode a use input (same as the light selection), that way the user can select the correct mode when starting the script. What do you think?

It will be great option - I've unintentional changed code many times by missclicks :D

I will also add the standby usage to the script.

It would be great, because every model has power draw between 0,3W and 0,5W so it is slightly more than 0W (in case using multiple lights total will be quite more).
I have some thoughts about optimization in script (eg. in HS mode mired step could be bigger, but britghness step sholud probably be lower) , but I have to analyze more .csv files
It looks like the maximum brightness could be 255 and it would be better to find the matching values so that the script ends up using the highest brightness (like many users use lights in reality).
Maybe the finished .csv files can also be optimized post factum (it depends on the algorithms used by the integration) - I think it would be enough to cut out a few lines containing the same power values, but apart from the first and last in the series.

See #48. I have made several improvements to the script. Let me know how this works on your machine.

New script does not work for me
Windows7 environment:
Traceback (most recent call last):
  File "c:/homeassistant-powercalc/measure/measure.py", line 159, in <module>
    def get_questions(light_list) -> list[dict]:
TypeError: 'type' object is not subscriptable

but in Linux looks nearly the same - same problem with line 159

Which python version do you use?

Win7 3.8.10 (highest possible in Windows 7),
Ubuntu also 3.8.10 (preinstalled as I'm only ordinary computer user ;P but I can try to update to 3.9.x)

@nepozs Yes it was an issue with Python 3.8, I am running 3.9. It should also work with 3.8 now.
Regarding the update time of shelly, do you experience other behaviour with the new version of the script compared to the old one? Or did you also experience this with the "old" script?

I've noticed it today only by accident, my earlier Shelly test were in different environement, so the conditions are incomparable (I mean manual test with other powermeter).
The inaccuracy can be caused by the bulbs themselves, as I stated before - most model have variable power factor when it changes current draw, so measurment should wait till power factor stabilize.

When light changes are small, inaccuracy may be neglected, so I can see solution - script just must wait once per loop - in case MODE_HS I mean saturation loop (I'm sure - each loop should wait about 3-4 secs when saturation chanes from max to min) and maybe hue loop (not sure - I must analyze file first, and it will be ready tomorrow, but I think it will be unnecesary as every loop starts with minimal saturation).
In MODE_COLOR_TEMP this pause shoud be applied when mired changes from max to min.

Last script version - b2cfbc3
Tested with Python 3.8.10 @ Ubuntu and probably works (I mean it starts), but issues as described in previous post exists.
BUT
I've found something more - there is some kind of problem with autodetermine minmireds and maxmireds - script in mode MODE_COLOR_TEMP starts form 0 value and goes to infinity.
As I have only one Shelly Plug S I'm not able to do parallel tests.

@nepozs I did also whitness the same behaviour in my setup.
I think we should wait longer than 2 seconds between the big changes in loops.
i.e. when brightness goes from 255 to 1, and saturation from 255 to 1. etc.
Let's say we wait 10 seconds so the power can settle.
The wait time between each small step can stay 2 seconds, or we can maybe decrease to 1 seconds.

I've found something more - there is some kind of problem with autodetermine minmireds and maxmireds - script in mode MODE_COLOR_TEMP starts form 0 value and goes to infinity.

Yes this is something I added in the new version of the script. The Hue bridge provides min and max values for mired, when this is not provided I use 150-500.
https://github.com/bramstroker/homeassistant-powercalc/blob/master/utils/measure/measure.py#L108
Not sure why infinity is used in your case. Could be related to Jiawen bulb.
I think I should set the max mired to 500 when it is higher than 500 or not available.

It could be Jiawen bulb issue but as you know every test/measurement takes long time.
As I have only one Shelly Plug S I'm not able to do parallel tests.

I think we should wait longer than 2 seconds between the big changes in loops.
i.e. when brightness goes from 255 to 1, and saturation from 255 to 1. etc.
Let's say we wait 10 seconds so the power can settle.

Yes, but I think that this pause is needed only in case of big saturation change (and brightness, but it is "most outside" loop so it will never happen).
And so I think change places of saturation and hue loops can help slightly.

Not sure why infinity is used in your case. Could be related to Jiawen bulb.

Yes, maybe it's just Jiawen related, but I couldn't replace the measured light bulbs every time (it's just my normal home environment, so it's a hassle).

@nepozs I have made some changes.

Sat/hue loops reversed. First sat is increased, and inside each sat the hue is increased.
For every sat change the script waits 10 seconds now.
Prevented the mired range to go above 500 or below 150.

Not sure why you got zero readings yet. Could you please try with the new version of the script first to see if this helps?

I gave my shelly plug to a colleague so he could also do some readings for missing Hue lights. However he is on holiday right now and only returning in 1.5 weeks, so I am unable to test the script with a real power meter right now and see if I have the same behaviour as you with the 0 readings.

I have also added two constants SLEEP_TIME_HUE and SLEEP_TIME_SAT where you can tweak the sleep settings easily

I have also added two constants SLEEP_TIME_HUE and SLEEP_TIME_SAT where you can tweak the sleep settings easily

Great, it will improve the ability of measurement  non-standard models.

Not sure why you got zero readings yet. Could you please try with the new version of the script first to see if this helps?Not sure why you got zero readings yet. Could you please try with the new version of the script first to see if this helps?

There may be some kind of connectivity issue with Shelly, I tried to run a self-modified script and the next attempt was successful (partially - forgot to set longer pauses but no zero reads), or it just could be my mistake when I've tried to verify values with additional powermeter.
I will try to return to measurements soon (they have very low WAF ;P as she was unable to normal use lights in bedroom last two days).
I have also a problem with a neighbor who does renovations some weeks and causes power outages nearly every day, so it is hard to
More bad news: last Hue  bridge firmware update (1945091050  from may 2021)
https://www.philips-hue.com/pl-pl/support/release-notes/bridge
leads to incompatibility with bulbs from Ikea and maybe other manufacturers - there is new undocumented pairing procedure, but using touchlink by paired remote I'm able to repair only bulbs which were not deleted from bridge before, so I have to prepare additional fixture with very long cable to try direct touchlink pairing with bridge.

More bad news: last Hue bridge firmware update (1945091050 from may 2021)
https://www.philips-hue.com/pl-pl/support/release-notes/bridge
leads to incompatibility with bulbs from Ikea and maybe other manufacturers - there is new undocumented pairing procedure, but using touchlink by paired remote I'm able to repair only bulbs which were not deleted from bridge before, so I have to prepare additional fixture with very long cable to try direct touchlink pairing with bridge.

I did not have any pairing issues with the bridge before, but I am only using official hue lights and some gledopto led controllers. No issues, but I did never unpair any lights yet. There is nothing in the changelog about pairing in the may release. How do you control your lights now when they are not paired to the bridge anymore?

How do you control your lights now when they are not paired to the bridge anymore?

I don't do. They are my spare bulbs (just there were plans to use them in different location, but I wasn't sure - so some are still paired but offline and some unpaired - and some of them are different model so I wanted to measure them, but there is problem with repairing).
It is of course possible to control lights without bridge using  not paired remote  - Hue Dimmer (old), Tust ZYCT-202 and all Ikea remotes have ability to work independent, but there is no support for  color-mode (except Ikea 5-button but only with Ikea bulbs), it is possible even  to pair 2 remotes together in such mode (I'm sure: 2 Hue Dimmer - old model can pair together and Ikea remote with probably any Ikea remote also could do it).
Hue Tap has no ability to work without bridge (as it is ZGP) and I haven't tried Hue Button (so I don't know, but there is in specs: "bridge required").

I did not have any pairing issues with the bridge before,
I had, it was in 2015 (there is information in link above when exactly), but I was at the beginnig Zigbee way :D so when they broked compatibility I had returned Hue bridge and bulbs to the shop. I was too fast - they rapaired it some weeks later.
But I started to look for something instead of Philips, so that's why I have so much Ikea equipment.

I suppose now it is just Zigbee3 related - so I must try direct Touchlink pairing.
BTW I was using also Gledopto but with Ikea gateway (they don't call it bridge), but now I don't have this hardware.

I am sure - Windows7 is completely useless - there is working script, but not Shelly (after a lost day I noticed the same power value in all measurements as described earlier).
I am at different location, a computer with Linux Mint is available, so I'll try to use it.

@nepozs Do you still have open questions / issues. Or can I close this issue?

As of today - no questions, but I've been on holidays, so I haven't used new script to much.
I have to prepare some major changes in computer hardware, so further measurements will be delayed.

It is something wrong with the script or Shelly (last firmware or maybe used library?), I've got completly unreliable results in color_temp mode (trying to measure Ikea LED1537R6) and in brightness mode (Hue White 1600) h_s mode untested as i takes to much time.
Python 3.8.10 (this version, as standard in current stable linux), Ubuntu 20.04.2 LTS
Sometimes it has 0W standy readings, sometimes much greater than expected (I've tested manually by power meter stable standby power draw, and also max power).
Also HA UI looks weird (but I think bulb is controlled properly).
https://user-images.githubusercontent.com/56661567/129818913-0ea5ef22-8f2a-463b-b35a-70bee92d4e86.mp4

@nepozs Hmm that's a pitty.
I did not change any underlying libraries and the script hasn't changed that much.
Looks like the brightness level is resetting to 0 every loop which is very strange.
Do you also have the full output log from the CLI console? Which is saying "Changing light to:". Maybe we can than have an indication what is wrong.
Also could you try with an old version of the script? See here for an overview with all the commits in the file https://github.com/bramstroker/homeassistant-powercalc/commits/master/utils/measure/measure.py. Just copy the commit hash and checkout that commit. For example git checkout 07da802d99671ef5217ac3414f0d2a3ac12e9f94.
Maybe you could also try to measure with a bulb which you did in the past. To see if you got similar readings as before. To make sure it is not a problem with this specific bulb LED1537R6 which shelly has problems with.

Console looks normal (it is dedicated computer, so I will copy it later, but there is  notjhing strange).
I will try to measure already measured bulb and when it fails  I have a copy of old script version (used last time, but I don't know commit version).
It really looks like in color-temp mode it does not increase brighness properly, but response from aiohue looks normal, maybe it is really problem with specific model? but from HA the same bulb is controlled OK

The second problem - with brightess only mode (Signify/Philips bulb) only last measure looks strange - it is understated.

It is some kind of problem with script or Shelly for sure - it looks like mean or median.
I have updated Shelly firmware recently and my earlier observations regarding the speed of measurement concerned a very old firmware and may now be completely wrong - now it looks like every change Shelly needs abuot 5 seconds to stabilize/show proper value.
Measuring standby usage. Waiting for 10 seconds...
Start taking measurements for color mode:  color_temp
Waiting 10 seconds...
Changing light to:  {'bri': 1, 'ct': 153}
Measured power:  0.0

Changing light to:  {'bri': 1, 'ct': 163}
Measured power:  0.58

Changing light to:  {'bri': 1, 'ct': 173}
Measured power:  0.58

Changing light to:  {'bri': 1, 'ct': 183}
Measured power:  0.5

Changing light to:  {'bri': 1, 'ct': 193}
Measured power:  0.45

Changing light to:  {'bri': 1, 'ct': 203}
Measured power:  0.45

I have my shelly sensor lended out to a friend which is also going to do some measurements, but he is on holiday atm, so it will be 2 weeks before I have the Shelly again. Than I can try to see if I get the same behaviour.
Did you try with the old version of measure script already? Which you still had a copy of and you were sure it was working correctly before?
Maybe there is something changed in the update ratio of shelly in new firmware, which would really be a "disaster"

I have increased sleep times, so the script is now extremly slow, but it does not help.
(and I'm trying to measure bulb which I plan to return to the shop, because it does not satisfy my requirements, so I try to get the data for possible future manual editing).
I will test old script version later.

Thanks for the update and your efforts

And one thing more: it was an accumulation of problems - it was some kind problem (brightness not going up) with this specific bulb LED1537R6 - I will test another piece, because reason is still unknown for me...

Strange that the LED1537R6 is not reacting as expected. I also noticed sometime 0 readings at the beginning when measuring myself. Will have a look into this when I have my Shelly back.
For me it also took 3 hours I think. Not really a big deal because I Just leave it running in another room. You could try decreasing the sleep time to less than 2 second, but not sure about the accuracy.

I also noticed sometime 0 readings at the beginning when measuring

It is set to 9 seconds now, because I thought that can help with zero readings but it didn't.

Strange that the LED1537R6 is not reacting as expected.

It could be that this specific bulb is just faulty - as I remember there was some kind of problem with firmware update with some old models (Ikea nad Osram), but all which updates was faulty I have marked as "faulty/old firmware", but this one was marked as "OK with new firmware".
To be sure, that there is no interference between Zigbee networks I've switched off now 2 additional networks working in paralel with Hue  bridge (I was sure, tahat they use different channels, but it is really strange).

Update - I have fond another pieces LED1537R6, but still without success.
Script (current version) works as expected with different lights (I've measured yesterday Muller-licht and Ledvance without problems, despite standby zero readings) , but not LED1537R6 - brightness not going up…
Next step if I have time will be test LED1537R6 using old script.

Very strange that brightness is not changing for LED1537R6. How about when you are using the official HUE app?
When you see "Changing light to:  {'bri': 1, 'ct': 183}" this means the HUE api is called with brightness 1 and color_temp 183. That is al my script does. So when this is not working correctly it is definitely a bug in de Hue API, Hue bridge or firmware.

I'm using now quite old script - version with select bulb by entering number and looks like it it works, I've set 6 seconds pause, so it should be ready in about 2 hours, there are some known problem (first value distorted, but it can be corrected by hand).

The only difference I can see is in LUT file are extreme mired values
new script 250 - 454
1,440,0.95
1,450,0.95
1,454,0.95
6,250,0.95
6,260,0.95

and old script 240 - 470 (it is wider, but values are divisible bu 10)
1,460,0.73
1,470,0.73
4,240,0.8
4,250,0.8

Good to know the old version is working correctly and the new version has issues. Than it must be caused by some code changes I did.
We need to figure out which commit caused the problems, but this is not so easy, especially since other models work correctly with current script version.
Please have a look here. https://github.com/bramstroker/homeassistant-powercalc/commits/master/utils/measure.
I have marked the exact commit in which a big rewrite of the script has happened.

You can click on the commit hash and than "browse files". There you can download that version of the file. Of you can checkout the commit locally using the git client.
Or use this links:

Big rewrite version: https://github.com/bramstroker/homeassistant-powercalc/tree/71f779273a3a7058485c947d03dd5f0573748f90/utils/measure
Version just before it: https://github.com/bramstroker/homeassistant-powercalc/tree/4d6c6412e520522c5281c417392c8f394b758e33/utils/measure

I am curious to know if the problem was introduced in this version. When this is not the case you can do the same trick by walking further up / down the timeline, until the exact commit was found in which the issue was introduced. When this is pinpointed I know what lines of code did change and hopefully will be able to figure out the solution.

I will try to test it next days (I've prepared to measure some new Ikea models and I will try to use current script version).

Update.
I could'n wait with measure Ikea GU10 RGBW as this bulb has seriously broken glass #115 so trying to find working script with LED1537R6  will be more delayed…
But there is serious (and probably not new) problem with Shelly - it can't measure power if power draw is lower than 0,5W (really border is somewhere about 0.4W but I don't have an artificial load able to work at 230V~ to test it reliably).
So there is really needed script which could measure group of bulbs (I have splitters 1x E27 -> 2x E27 and 1x E27 -> 3x E27 so I just can buy more E27 ->  GU10 converters and more bulbs).

@nepozs Closing this issue now. I am working on a new measure script #141 with a lot improvements. It will also allow to use home assistant to control the lights and directly shelly to get power.

authors: bramstroker nepozs

repo: bramstroker/homeassistant-powercalc


text:
Unable to use Home Assistant Groups with Nesting

When I try and use Home Assistant Groups along with the nesting feature in powercalc to try and automatically populate my home Hue lighting configuration the powercalc integration fails to load.
Sample code created from a combination of examples from the powercalc integration readme.md
  - platform: powercalc
    create_group: All Lights Energy
    entities:
     - create_group: Downstairs Lights Energy
       entities:
         - create_group: Living Room Lights Energy
           include:
             group: light.hue_living_room_lights
         - create_group: Kitchen Lights Energy
           include:
             group: light.kitchen_lights
     - create_group: Upstairs Lights Energy
       entities:
         - create_group: Bedroom Lights Energy
           include:
             group: light.bedroom
         - create_group: Bedroom2 Lights Energy
           include:
             group: light.bedroom2

Can't get the code to format properly in here sorry :(

I have formatted the code. Just did a quick test with creating a light group in the UI and referring to that with the include group, and this is working fine for me.
I also don't see an issue with the yaml in first glance.
When the integration breaks the error logs should definitely give some pointer on to what is wrong. Did you already check the logs?

Thanks for the feedback. I checked the logs as far as I know how (sorry bit a newb to HA). I've just seen that there seems to be a verbose logs option for this. I'll see if I can enable that and see what's going on.

Really sorry all. I turned on debug logs and it looks like the issue is because 3 of my groups had only Hue lights in that weren't detected by powercalc and that then caused the thing not to load. I've currently removed the groups from the scope of the integration. I'll look to setup some manual configs and see if this fixes it. Sorry...

No problem, glad you figured it out. Closing this issue. Let me know if you have any other questions.


text:
App closes immediately

Describe the bug
App immediately closes upon opening
To Reproduce
Steps to reproduce the behavior:

Tap app icon to open
App attempts to open
App closes immediately before anything loads

Expected behavior
App opens, get brought to main page
Screenshots

Smartphone

Device: Pixel 8 Pro
OS: GrapheneOS (Android 14, Build 2024080500)
Version: Flexify 1.1.65

This has already been resolved in later versions. Try to update the app

What would the newest version be? F-Droid shows 1.1.65 as the newest

F-droid is notoriously slow with updates. Newest version is 1.1.78, you can install updates using the releases page https://github.com/brandonp2412/Flexify/releases/tag/1.1.78
https://github.com/brandonp2412/Flexify/issues/95#issuecomment-2257344357

That worked. Allowed me to update the app which allowed me to open the app. Can start tracking my gains again.
Thank you!

authors: OsmoticAbsorption dqnne


text:
🛑 Dev Charite gateway-iop-connection is down

In 084a811, Dev Charite gateway-iop-connection (https://dev-ids.health-x.charite.de/health/4) was down:

HTTP code: 500
Response time: 126 ms

Resolved: Dev Charite gateway-iop-connection is back up in eeab6dc after 12 minutes.

repo: braunma/dataloft-endpoint-monitor


text:
Pedido de Transferência do Repositório brutils-python para a Organização Cumbuca Dev

Olá, pessoas da Organização brazilian-utils :)
Antes de mais nada, queremos expressar nossa imensa gratidão a todas as pessoas que contribuíram, compartilharam e apoiaram o projeto brutils-python até aqui. Este repositório tem um significado muito especial para nós da Cumbuca Dev. Foi através dele que demos nossos primeiros passos como comunidade e começamos a concretizar nossa missão de levar pessoas de grupos minoritários para o mercado de trabalho em T.I., com base em aprendizado prático e colaboração Open Source.
Quando começamos a contribuir com o brutils-python, o projeto tinha apenas dois mantenedores e um volume limitado de commits. Desde que assumimos parte do esforço de organização e divulgação, vimos o repositório ganhar visibilidade significativa, com:

Crescimento expressivo em estrelas ⭐ no GitHub;
Aumento no número de contribuições, downloads e de pessoas colaboradoras;
Ampliação do alcance, impactando tanto iniciantes quanto pessoas experientes na área.

O impacto do brutils-python em nosso trabalho
Desde que começamos a colaborar com o repositório, ele não apenas cresceu em visibilidade, mas também transformou-se em um canal de aprendizado e capacitação para muitas pessoas:

Aprimoramos a organização do repositório, incluindo documentação mais acessível, issues abertas para iniciantes e maior visibilidade para contribuições.
Realizamos palestras e workshops práticos (tutoriais e sprints) sobre o projeto em meetups e eventos como Python Brasil e LatinoWare. Aqui estão alguns registros de palestras onde mencionamos o brutils-python:
- 71º Python Floripa no MeLi: "Cumbuca Dev: Ensinando com Open Source"
- PySul 2024: "Como e Porque aprender a programar com Open Source"
- PyBR 2024: "Como e Porque aprender a programar com Open Source"
- Entre outros momentos não registrados, mas que foram igualmente significativos para nossa comunidade.

Essas ações nos ajudaram a:

Capacitar iniciantes para colaborar em projetos reais de código aberto.
Mostrar como o Open Source pode ser uma ferramenta inclusiva de aprendizado e ascensão profissional.
Aumentar a visibilidade do brutils-python dentro e fora da comunidade Python.

Esse movimento reforçou algo que sempre acreditamos: Open Source é uma ferramenta poderosa para transformar vidas e criar oportunidades. Por meio do brutils-python, conseguimos:

Ensinar habilidades práticas de programação a iniciantes, especialmente pessoas que nunca haviam contribuído para Open Source antes;
Fomentar a inclusão na tecnologia, dando visibilidade a talentos de grupos sub-representados;
Conectar nossa comunidade com oportunidades de mentoria, networking e aprendizado contínuo.

A proposta de mudança
Agora, gostaríamos de dar mais um passo importante: transferir o repositório brutils-python para a organização da Cumbuca Dev no GitHub. Essa mudança será fundamental para:

Centralizar nossos esforços organizacionais, consolidando os projetos sob nossa marca e ampliando a identidade da Cumbuca Dev;
Facilitar a busca por sponsors, tornando o projeto mais visível para empresas interessadas em investir em iniciativas de impacto social e tecnológico;
Garantir maior sustentabilidade do repositório, com uma base de mantenedores(as) ampliada e maior capacidade de engajamento da comunidade.

Importante ressaltar que a Brazilian Utils continuará sendo referenciada como a base e origem deste projeto, exatamente como sempre foi. Reconhecemos e valorizamos profundamente o trabalho de quem deu os primeiros passos no brutils-python, e levaremos esse legado conosco, promovendo a história e os valores que ele carrega.
Sabemos que a transferência também inclui o registro no PyPI, que atualmente está em nome de @luizberti. Pedimos gentilmente que considerem colaborar conosco nesse processo, para que possamos manter a consistência e confiabilidade do projeto.
Pedidos de ação
Para viabilizar a mudança, gostaríamos de confirmar alguns pontos com vocês:

Membros da Organização Brutils*, vocês estão ok com a transferência do repositório para a organização Cumbuca Dev no GitHub?
@luizberti , você está ok com a mudança de acesso no PyPI? Caso sim, poderia mudar a permissão da Camila para admin?

Este repositório tem sido um marco para nós e para as pessoas que impactamos. Juntos, podemos fazer ainda mais: ensinar mais pessoas, criar mais oportunidades, e fortalecer nossa missão de inclusão e acessibilidade em T.I.
Se houver mais alguma dúvida, preocupação ou ajuste necessário, estamos à disposição para conversar! Este projeto é um marco para nós, e estamos animadas com as possibilidades de impacto que ele ainda pode gerar na comunidade Python e na vida de outras pessoas.
Com carinho e gratidão,
Time Cumbuca Dev
*Membros da Organização Brutils: @alexrochas, @andreoav, @camilamaia, @guilhermecomum, @hyanmandian, @Leonardo18, @lucassveloso, @luizberti, @melissawm, @rodineijf.

Olá, pessoal da Cumbuca Dev,
Primeiramente, gostaria de expressar minha profunda gratidão por todo o trabalho incrível que vocês têm feito com o brutils-python. É impressionante ver como a dedicação de vocês transformou o projeto em uma ferramenta de aprendizado, inclusão e impacto na comunidade Python. Todas as ações que vocês mencionaram – desde palestras e workshops até a melhoria da documentação e a organização do repositório – são um testemunho do poder do Open Source em unir pessoas e criar oportunidades.
Entendo perfeitamente a motivação por trás do pedido de transferência do repositório para a organização da Cumbuca Dev. No entanto, acredito que o brutils-python é parte integrante do ecossistema da organização Brazilian Utils, que foi criada justamente para unificar e padronizar implementações dessa biblioteca em várias linguagens, mantendo uma identidade única.
Inclusive, neste ano de 2025, estou planejando retomar o trabalho na biblioteca principal, com foco em melhorar ainda mais a experiência de todas as linguagens suportadas. Um dos passos será atualizar o site oficial para incluir não apenas a documentação do JavaScript, mas também de todas as outras linguagens onde a Brazilian Utils está presente. Além disso, tenho como objetivo promover uma unificação de métodos e APIs entre os projetos, respeitando, claro, as características de cada linguagem. Desta forma, assim que alguem aprender a usar a biblioteca em uma linguagem terá facilidade em utilizá-la em qualquer outra, graças a uma API de uso semelhante.
Dito isso, a força do Open Source está justamente na colaboração de pessoas e comunidades diferentes, e é exatamente isso que torna o brutils-python tão especial. O trabalho de vocês exemplifica essa essência e nos inspira a continuar buscando maneiras de melhorar o projeto e sua gestão coletiva.
Gostaria de reforçar que estamos totalmente abertos a trabalhar juntos para aprimorar ainda mais o brutils-python e encontrar formas de facilitar a participação de outras comunidades, como a de vocês, no desenvolvimento do projeto. Se há melhorias que vocês acreditam que possam fortalecer nossa colaboração ou maximizar o impacto do projeto, estamos à disposição para conversar e implementar.
Mais uma vez, agradeço imensamente a vocês por todo o impacto positivo que trouxeram para o brutils-python e a comunidade ao redor dele. Espero que possamos continuar construindo algo grandioso juntos!

authors: antoniamaia hyanmandian

repo: brazilian-utils/brutils-python


text:
Ignore Hash Per Domain

Does it depend on a specific browser?
No response
Related to a problem?
You have option to disable all dupe-prevention per domain. But you don't offer ability to ignore Hash per domain. With most sites, i need to treat some urls with different hash as a dupe. But on a couple of sites, i need to treat same url with different hash as a not a dupe.
Describe the solution you'd like
Ability to enable hash per domain (or per base url).
Describe alternatives you've considered
No response
Additional context
This affects Azure cloud, in which all pages are just a different hash.
Will the API support this feature?

[x] I don't know what this means

Will the API support this feature?
* [x]  I don't know what this means

New features require the webextension API, which is similar for all browsers (with some variations) to support the request for such a new feature. Sometimes people ask for features that go beyond the API, and most of them become impossible, so it is requested that before requesting a new feature, understand this. Exactly as explained in the instruction:

I confirm that the suggested feature requested is within the possibilities of what the Chrome extensions API allows (https://developer.chrome.com/docs/extensions/reference/).

Regarding specific URL behaviors, I'm working on it, according to the task list:

https://github.com/brcontainer/prevent-duplicate-tabs/issues/1

Thanks

Thanks!
On Fri, Jun 21, 2024, 10:38 AM Guilherme Nascimento <
@.***> wrote:

Will the API support this feature?

[x]  I don't know what this means

New features require the webextension API, which is similar for all
browsers (with some variations) to support the request for such a new
feature. Sometimes people ask for features that go beyond the API, and most
of them become impossible, so it is requested that before requesting a new
feature, understand this. Exactly as explained in the instruction:
I confirm that the suggested feature requested is within the possibilities
of what the Chrome extensions API allows (
https://developer.chrome.com/docs/extensions/reference/).

Regarding specific URL behaviors, I'm working on it, according to the task
list:

#1 https://github.com/brcontainer/prevent-duplicate-tabs/issues/1

Thanks
—
Reply to this email directly, view it on GitHub
https://github.com/brcontainer/prevent-duplicate-tabs/issues/42#issuecomment-2183169606,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMV6UUKOX3BS3UPLGES5YJ3ZIRQKJAVCNFSM6AAAAABJHIDZQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBTGE3DSNRQGY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Note that for now you can enable the option HASH:

If disabled (off) it's ignore hash in URLs, then this http://foo/bar#baz will be equivalent to this http://foo/bar

authors: brcontainer johnaweiss

repo: brcontainer/prevent-duplicate-tabs


text:
Bring node editing front and center (maybe literally)

For better editing experience, let's make sure that the user can have an immersive prompt editing experience. When they are editing a prompt (or maybe a node), they feel like they can focus on that prompt only. Related #1474.

Declaring victory 🚢

repo: breadboard-ai/breadboard


text:
Clarify handling of use_trampoline in sdk-common structs

There is one struct in particular that uses this behind a feature flag:
https://github.com/breez/breez-sdk-greenlight/blob/12980553a1ca1f6cd4d73e1128cb468276c578b6/libs/sdk-common/src/lnurl/specs/pay.rs#L128-L147
Question:

Should sdk-common remove the liquid feature flag and instead only contain truly common structs and code?

If so, should there be a separate LnUrlPayRequestWithTranpoline (or similar) in the GL SDK repo?

Alternatively, is the current approach ok and we should keep it?

Let's discuss below.

Is it possible to have LnUrlPayRequest in sdk greenlight and LnUrlPayRequest in sdk liquid, but they're different structs? That would be my preferred option.

IMO the feature flag in sdk-common is overkill. We should instead place only common code in sdk-common. What's implementation-specific should live in the implementation-specific repo (for example a new struct with use_trampoline in the GL SDK repo).

Is it possible to have LnUrlPayRequest in sdk greenlight and LnUrlPayRequest in sdk liquid, but they're different structs? That would be my preferred option.

I don't think so, as lnurl_pay lives in sdk-common and it has to know which request struct to reference.

I don't think so, as lnurl_pay lives in sdk-common and it has to know which request struct to reference.

Is it? I can't find it.

There might be another option here too.
use_trampoline could be a configuration-time setting instead. That would mean it applies to all payments. Then this problem would no longer exist, because the field would not be necessary on a specific payment. What do you think @roeierez?

You're right, lnurl_pay is not in sdk-common but instead implemented (slightly differently) in Liquid and GL SDK repos.
Then your idea could well work. The GL SDK repo lnurl_pay could reference its own request struct with use_trampoline, the Liquid one could reference the sdk-common request struct without use_trampoline.

I think the whole problem is that the udl interface has leaked into the sdk-common. We should leave there only "business-logic" or business models.
So I don't see any issue in creating two different structures and two different udl definitions.

I think the whole problem is that the udl interface has leaked into the sdk-common.

With udl definitions you mean the rust structs that are also defined in the udl? (asking because the udl file is still in sdk-bindings)

Despite being more error-prone than your suggestions, the current approach of using feature flags—#[cfg(feature = "liquid")] and #[cfg(not(feature = "liquid"))]—to include or exclude fields from shared structs is imo adequate.
I am not sure if this is worth doubling the work over, we can add validation tests for sdk-common w/ & w/o liquid feature on the CI to catch any issues.
I'm open to any solutions that does not double the work managing these structs.

I think the whole problem is that the udl interface has leaked into the sdk-common.

With udl definitions you mean the rust structs that are also defined in the udl? (asking because the udl file is still in sdk-bindings)

I am referring to the fact that the LnUrlPayRequest is defined in sdk common but is not used there anywhere, it is only used in sdk-core and liquid project. So in fact we can create for both of these referring projects their own LnUrlPayRequest. Not only that the LnUrlPayRequest is the interface implementation (udl file) so no reason both will share the same interface (or at least no reason to require that). Both interfaces have different motivation to change (different implementations).

authors: JssDWt erdemyerebasmaz ok300 roeierez

repo: breez/breez-sdk-greenlight


text:
add release note

Hi how about using milestone and add some release note to HikariCP release cycle?
thanks

@brettwooldridge , It would be nice to have some release notes for 3.4.0 or have it in the change log here https://github.com/brettwooldridge/HikariCP/blob/dev/CHANGES. Thanks.

repo: brettwooldridge/HikariCP


text:
Useless call to DriverDataSource.shutdown() when HikariDataSource.close()

HikariDataSource.close() makes a call to DriverDataSource.shutdown() whose body is empty (noop). DriverDataSource being a final class - there is no chance anyone except the Hikari maintainers extend this class or change the method implementation.
Conclusion: code would be cleaner and easier to maintain if that useless call to `DriverDataSource.shutdown()'  is removed.

@brenuart Already covered. refactor.  Don't start reviewing the refactor, its still like clay. :grinning:

Sorry - wasn't aware of any refactoring work in progress :-(
Just wanted to share my findings...

@brenuart I appreciate it the reviews.

authors: brenuart brettwooldridge


text:
where is the seq_color21_small data?

Hello, Thanks for your great work. But when I run the code, I meet one question.
When i run this command in terminal line:
./scripts/real.sh seq_color21_small 0 30
I find the problem  as below.

So, I need to change the params seq_color21_small  to the specify classes path in your google drive dataset?
Such as : bash scripts/real.sh torf_data_v0/studybook/ 0 30. ?
Looking foraward to your reply.
Thanks so much!

repo: breuckelen/torf


text:
Transaction Filter Offcanvas position

Is your feature request related to a problem? Please describe.
Transaction Filter Offcanvas from top is a poor user experience
Describe the solution you'd like
Default the React Bootstrap Offcanvas component to fly out from the left, vs. the top.
Consider LocalStorage option to choose Top/Bottom/Left/Right for A/B Testing
Describe alternatives you've considered
Modal Pop-Over for A/B testing
Additional context
Research how to override default H/W dimensions for component
Current Behavior from TOP:

Increased Offcanvas Overlay size to View Port  = 100%
(https://getbootstrap.com/docs/5.2/utilities/sizing/)
Revisit if there's a need to reduce View Port sizing and an ability to A/B Offcanvas placement in future iterations.


text:
support loading password from Chef Vault

fixes #358

@popsikle @shortdudey123 @shayangz @brianbianco @ryangreer can y'all give this a look?

@atheiman sorry for the delay I know that can be frustrating when you contribute and it takes a while to get to it. I will take a look.

Looks like we only got a single spec error to fix now which is related to the change you made: https://travis-ci.org/brianbianco/redisio/jobs/360276061#L660 can you look at either fixing the code or the test?

ahh thats frustrating, foodcritic told me to use data_bag_item rather than Chef::DataBagItem.load in the library file. But it turns out data_bag_item is not mixed into libraries.
I'll either require it or go back to how i had it and tell foodcritic to cut it out

Hi
We have just adopted this cookbook and are aiming to rebaseline it, as part of this we are closing down all prs older than 1 year.
If you still need this change please open a new PR and we will assess this as part of our rebaseline
Thanks for your understanding
Sous-Chefs

authors: Xorima atheiman majormoses

repo: brianbianco/redisio


text:
Animate the play/pause button in the bar as well

Closes #446
I moved the logic for forwarding/reversing the animation controller to _updateState() to catch all changes to controller.value.isPlaying regardless of how they were triggered.
I haven't made corresponding changes to the Cupertino controls, should I do that as well?

Here's a screen recording:
https://user-images.githubusercontent.com/44171190/109390369-86ecc180-7911-11eb-835a-027d58381410.mp4

Nice :D
thanks a lot for the video as well.
We can merge that now, but I would prefer also having the code change in cupertino controls as well.
I wanted to look into merging as much as possible from cupertino and material controls. Ideally so that such changes are easily made for both without code duplication.

I wanted to look into merging as much as possible from cupertino and material controls. Ideally so that such changes are easily made for both without code duplication.

Agree. There seems to be a lot of code duplication going on, with some features being only available in one implementation. If you want I can take a look at merging the implementations :)

Superseeded by #450, which covers all uses of play/pause buttons.

authors: miDeb nstrelow

repo: brianegan/chewie


text:
Test against JDK 9, 10, 11

Relates to issue #705

Forgot to pull before creating this PR. There are some failures. Will fix in a few minutes.

Thanks @busbey for the review

repo: brianfrankcooper/YCSB


text:
跳过检查包含CQ码或URL的消息

目前插件可能会检查URL 这会导致部分消息（例如图片）会被撤回

谢谢，我晚上改一下

bridge

---- 回复的原邮件 ----

发件人
***@***.***>

日期
2023年03月25日 12:00

收件人
***@***.***>

抄送至
***@***.***>

主题
[bridgeL/nonebot-plugin-ayaka-prevent-bad-words] 跳过检查包含CQ码或URL的消息 (Issue #2)

目前插件可能会检查URL 这会导致部分消息（例如图片）会被撤回
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: <bridgeL/nonebot-plugin-ayaka-prevent-bad-words/issues/2@github.com>

谢谢大佬

仍然会被撤回 这是日志
04-29 22:31:00 [INFO] nonebot_plugin_gocqhttp | 收到群 [QQGroup](114514) 内 a(114514) 的消息: [CQ:image,file=b0aac94770e1d47d6c961b918a232b3c.image,subType=0,url=https://gchat.qpic.cn/gchatpic_new/114514/3926392446-2494407682-B0AAC94770E1D47D6C961B918A232B3C/0?term=2mp;is_origin=0] (-8101563)
04-29 22:31:00 [SUCCESS] nonebot | OneBot V11 | [message.group.normal]: Message -8101563 from 114514@[群:114514] "[CQ:image,file=b0aac94770e1d47d6c961b918a232b3c.image,subType=0,url=https://gchat.qpic.cn/gchatpic_new/114514/3926392446-2494407682-B0AAC94770E1D47D6C961B918A232B3C/0?term=2mp;is_origin=0]"
04-29 22:31:00 [INFO] nonebot | Event will be handled by Matcher(type='message', module=src.plugins.nonebot_plugin_permission)
04-29 22:31:00 [INFO] nonebot | Matcher(type='message', module=src.plugins.nonebot_plugin_permission) running complete
04-29 22:31:00 [INFO] nonebot | Event will be handled by Matcher(type='message', module=nonebot_plugin_matcher_block)
04-29 22:31:00 [INFO] nonebot | Matcher(type='message', module=nonebot_plugin_matcher_block) running complete
04-29 22:31:00 [INFO] nonebot | Event will be handled by Matcher(type='message', module=ayaka.adapters.nb2.ob11)
04-29 22:31:00 [INFO] nonebot | Event will be handled by Matcher(type='message', module=ayaka.adapters.nb2.qqguild_patch)
04-29 22:31:00 [INFO] nonebot | Matcher(type='message', module=ayaka.adapters.nb2.qqguild_patch) running complete
04-29 22:31:01 [INFO] nonebot | Matcher(type='message', module=ayaka.adapters.nb2.ob11) running complete

authors: LittleChest bridgeL


text:
Bridge.ready is implemented incorrectly

if (typeof Bridge.global.jQuery !== "undefined") {
    Bridge.global.jQuery(delayfn);
} else {
    if (typeof Bridge.global.document === "undefined" || Bridge.global.document.readyState === "complete" || Bridge.global.document.readyState === "loaded") {
        delayfn();
    } else {
        Bridge.on("DOMContentLoaded", Bridge.global.document, delayfn);
    }
}

This is part of the implementation of Bridge.ready. If you look closely you'll notice that the check is for readyState === "complete", however DOMContentLoaded actually gets raised once the state becomes interactive, which is before it becomes complete.
Therefore it is possible to have the following situation:

Page begins loading
readyState = interactive
DOMContentLoaded is raised
I add a dynamic <script> tag to the page, pointing to some transpiled code
The script loads and attempts to initialize a Bridge assembly
The script contains a Main method
The Main method gets passed to Bridge.ready
Bridge.ready checks the readyState and since it's not equal to complete it goes into the else
The Main method is now subscribed to DOMContentLoaded, however we were already past that, so it will NEVER be invoked
I am sad

Basically just make it check for interactive instead.

Can you create test case in deck which is demonstrated the described situation?

Not possible, I need to give you one javascript file that dynamically loads a javascript file made by Bridge.NET.

Actually I was able to make a Deck.NET example. There you go:
https://deck.net/862aeb3a9b22c783a52ff79e875832b4
Current Output
During Demo.Main: interactive
Right before introducing Demo2: interactive
Expected Output
During Demo.Main: interactive
Right before introducing Demo2: interactive
During Demo2.Main: interactive
You can achieve the expected output by removing //@ jQuery = undefined; which will allow Bridge.NET to rely on jQuery for it's ready method. However when jQuery is not present, Bridge.NET will rely on it's own implementation of the ready method which is incorrect, as explained above.

I'd say that's a defect not a feature :P

The issue has been fixed and merged, it will make it to the next bridge release, pointed by this issue's milestone (currently 16.6.0)!

authors: TriEdgeAI fabriciomurta vladsch

repo: bridgedotnet/Bridge


text:
Set up 'global' style build.

We have set up a 'npm' style build system modeled after the 'React-Router' repository's 'npm' build. It would be nice to also have a 'global' style build. See the 'React-Router' package.json and their 'build/global' directory.
Once we have a global build set up, we could use that for issue #14  (Using global build in 'gh-pages' branch.)

Does "global style build" mean a version which isn't a CommonJS module?
I found myself wanting this a moment ago -- I'm rewriting Mosaic to be React this weekend, and replacing the jQuery lazy load with react-waypoint, but I'm not fancy enough for the CommonJS module stuff yet.
Anyway, removing the var React = require('React') and the module.exports = Waypoint worked, but it would be good to just be able to use the official bower/npm build.

Does "global style build" mean a version which isn't a CommonJS module?

Yes, exactly.
To be honest, I think you'd be best off just setting up webpack. They have a pretty full-featured webpack react starter that should get you up and running pretty quickly.

@flarnie is this still important? I'm trying to close out old and inactive issues, and this hasn't been touched in a while.
Also, hi! We miss you!

Closing. Even though this would be convenient, I don't think we should support this use-case.

authors: flarnie lencioni tdooner trotzig

repo: brigade/react-waypoint


text:
rev gatk-public dependency to 4.alpha.2-67-gce8ce3a-20161024.213859-1

This version includes the fix for the QSS VCF header bug

@droazen please review

looks good to me.  wait for the tests and +1

authors: lbergelson takutosato

repo: broadinstitute/gatk-protected


text:
Add option to show variants from UTR regions

The browser currently loads only variants located in CDS regions. There should be an option to include variants from UTR regions in the variant table and plots.

Regions displayed in the transcript track are also filtered to only the CDS feature type. UTR regions should be included when this option is selected.

Replaced by #523.

repo: broadinstitute/gnomad-browser


text:
First draft of Toolbox use cases

This PR includes the following examples:

Get variant count

Get variant count by AF for a release
Get variant count by AF for a gene interval

Filter to variants by VEP annotations

Filter to LOF variants
Filter to pLOF variants that we used to compute constraint metrics

Get 'freq' for specific genetic ancestry groups

Get 'freq' for multiple groups for an (gene) interval
Get 'freq' for a specific group and a specific variant

I also removed the "setup.py" because it caused problems while starting a cluster, we have 'setup.py' in gnomad_methods, but we don't have it in gnomad_qc, do we really need it here?

I also removed the "setup.py" because it caused problems while starting a cluster, we have 'setup.py' in gnomad_methods, but we don't have it in gnomad_qc, do we really need it here?

this file is needed to create a python package with this repo, right? so we would want to keep it

I also removed the "setup.py" because it caused problems while starting a cluster, we have 'setup.py' in gnomad_methods, but we don't have it in gnomad_qc, do we really need it here?

this file is needed to create a python package with this repo, right? so we would want to keep it

I will try to solve the cluster issue when it circles back.

authors: KoalaQin ch-kr

repo: broadinstitute/gnomad-toolbox


text:
Not Work downlink

Hi @brocaar
I have two nodes one  with RN2903 and other with RFM95
The two work perfect in OTAA, doing the join and the TX  but we cant receive the downlink from our server
We have tried with TTN server and everything works good, we did the join and TX and then we tried the Downlink and it worked, is it any difference between ttn server and this version of LoRa server to consider?
Thanks

Hi @sabas1080 could you add logs of LoRa Gateway Bridge, LoRa Server and LoRa App Server to this issue? Could you also let me know which gateway + packet_forwarder version you're using? That makes it easier for me to help you debugging this issue :-)

Hi @brocaar, I also have the same issue here. I use  iC880A Concentrator and https://github.com/TheThingsNetwork/packet_forwarder as the packet forwarder.
Here's few logs from app server & gateway bridge:
App server:
time="2017-01-22T11:58:32Z" level=info msg="downlink queue item deleted" id=22
time="2017-01-22T11:58:32Z" level=info msg="data-down item requested by network-server, but queue is empty" dev_eui=0004a30b001b2d10
time="2017-01-22T11:59:09Z" level=info msg="handler/mqtt: publishing data-up payload" topic="application/c99df5f485d7ab21/node/0004a30b001b2d10/rx"
time="2017-01-22T11:59:09Z" level=info msg="data-down item requested by network-server, but queue is empty" dev_eui=0004a30b001b2d10
time="2017-01-22T11:59:25Z" level=info msg="handler/mqtt: data-down payload received" topic="application/c99df5f485d7ab21/node/0004a30b001b2d10/tx"
time="2017-01-22T11:59:25Z" level=info msg="downlink queue item enqueued" dev_eui=0004a30b001b2d10 id=23
time="2017-01-22T11:59:46Z" level=info msg="handler/mqtt: publishing data-up payload" topic="application/c99df5f485d7ab21/node/0004a30b001b2d10/rx"
time="2017-01-22T11:59:47Z" level=warning msg="queue item discarded as it exceeds max payload size" dev_eui=0004a30b001b2d10 max_payload_size=51 payload_size=60 reference=1485086365600
time="2017-01-22T11:59:47Z" level=info msg="downlink queue item deleted" id=23
time="2017-01-22T11:59:47Z" level=info msg="data-down item requested by network-server, but queue is empty" dev_eui=0004a30b001b2d10
time="2017-01-22T12:00:10Z" level=error msg="handler/mqtt: mqtt connection error: EOF"
time="2017-01-22T12:00:25Z" level=info msg="handler/mqtt: connected to mqtt broker"
time="2017-01-22T12:00:25Z" level=info msg="handler/mqtt: subscribling to tx topic" topic="application/+/node/+/tx"
time="2017-01-22T12:01:01Z" level=info msg="handler/mqtt: publishing data-up payload" topic="application/c99df5f485d7ab21/node/0004a30b001b2d10/rx"
time="2017-01-22T12:01:01Z" level=info msg="data-down item requested by network-server, but queue is empty" dev_eui=0004a30b001b2d10
time="2017-01-22T12:01:38Z" level=info msg="handler/mqtt: publishing data-up payload" topic="application/c99df5f485d7ab21/node/0004a30b001b2d10/rx"
time="2017-01-22T12:01:38Z" level=info msg="data-down item requested by network-server, but queue is empty" dev_eui=0004a30b001b2d10
time="2017-01-22T12:02:15Z" level=info msg="handler/mqtt: publishing data-up payload" topic="application/c99df5f485d7ab21/node/0004a30b001b2d10/rx"
time="2017-01-22T12:02:15Z" level=info msg="data-down item requested by network-server, but queue is empty" dev_eui=0004a30b001b2d10
time="2017-01-22T12:02:52Z" level=info msg="handler/mqtt: publishing data-up payload" topic="application/c99df5f485d7ab21/node/0004a30b001b2d10/rx"
time="2017-01-22T12:02:52Z" level=info msg="data-down item requested by network-server, but queue is empty" dev_eui=0004a30b001b2d10
time="2017-01-22T12:03:29Z" level=info msg="handler/mqtt: publishing data-up payload" topic="application/c99df5f485d7ab21/node/0004a30b001b2d10/rx"
time="2017-01-22T12:03:29Z" level=info msg="data-down item requested by network-server, but queue is empty" dev_eui=0004a30b001b2d10
time="2017-01-22T12:23:36Z" level=info msg="handler/mqtt: data-down payload received" topic="application/c99df5f485d7ab21/node/0004a30b001b2d10/tx"
time="2017-01-22T12:23:36Z" level=info msg="downlink queue item enqueued" dev_eui=0004a30b001b2d10 id=24
time="2017-01-22T12:23:49Z" level=info msg="handler/mqtt: data-down payload received" topic="application/c99df5f485d7ab21/node/0004a30b001b2d10/tx"
time="2017-01-22T12:23:49Z" level=info msg="downlink queue item enqueued" dev_eui=0004a30b001b2d10 id=25

time="2017-01-22T11:58:02Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:53420 protocol_version=1 type=PullData
time="2017-01-22T11:58:02Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:53420 protocol_version=1 type=PullACK
time="2017-01-22T11:58:32Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:38444 protocol_version=1 type=PushData
time="2017-01-22T11:58:32Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:38444 data="QGoaASaAAgAB0/PcKz4iD8T/zkRgonxb" mac=fb10b827ebe4f14e
time="2017-01-22T11:58:32Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:38444 data="QGoaASaAAgAB0/PcKz4iD8T/zkRgonxb" mac=fb10b827ebe4f14e
time="2017-01-22T11:58:32Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T11:58:32Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T11:58:32Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:38444 protocol_version=1 type=PushACK
time="2017-01-22T11:59:03Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:40507 protocol_version=1 type=PullData
time="2017-01-22T11:59:03Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:40507 protocol_version=1 type=PullACK
time="2017-01-22T11:59:09Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:37396 protocol_version=1 type=PushData
time="2017-01-22T11:59:09Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:37396 data="QGoaASaAAwABwim/V7sz31JS/nk+gBLP" mac=fb10b827ebe4f14e
time="2017-01-22T11:59:09Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:37396 data="QGoaASaAAwABwim/V7sz31JS/nk+gBLP" mac=fb10b827ebe4f14e
time="2017-01-22T11:59:09Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T11:59:09Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T11:59:09Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:37396 protocol_version=1 type=PushACK
time="2017-01-22T11:59:46Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushData
time="2017-01-22T11:59:46Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:60906 data="QGoaASaABAABx71DkrFwj2+eniK6Phxe" mac=fb10b827ebe4f14e
time="2017-01-22T11:59:46Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:60906 data="QGoaASaABAABx71DkrFwj2+eniK6Phxe" mac=fb10b827ebe4f14e
time="2017-01-22T11:59:46Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T11:59:46Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T11:59:46Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushACK
time="2017-01-22T12:00:03Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:57490 protocol_version=1 type=PullData
time="2017-01-22T12:00:03Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:57490 protocol_version=1 type=PullACK
time="2017-01-22T12:00:10Z" level=error msg="backend: mqtt connection error: EOF"
time="2017-01-22T12:00:23Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushData
time="2017-01-22T12:00:23Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:60906 data="QGoaASaABQABj1+Qlv2+whjdAujmk47P" mac=fb10b827ebe4f14e
time="2017-01-22T12:00:23Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:60906 data="QGoaASaABQABj1+Qlv2+whjdAujmk47P" mac=fb10b827ebe4f14e
time="2017-01-22T12:00:23Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T12:00:23Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T12:00:23Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushACK
time="2017-01-22T12:00:25Z" level=info msg="backend: connected to mqtt broker"
time="2017-01-22T12:00:25Z" level=info msg="backend: re-registering to gateway topics" topic_count=1
time="2017-01-22T12:01:00Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushData
time="2017-01-22T12:01:00Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:60906 data=QGoaASaABgABqkexEpICDjwEGMAXmdtB mac=fb10b827ebe4f14e
time="2017-01-22T12:01:00Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T12:01:00Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushACK
time="2017-01-22T12:01:03Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:42823 protocol_version=1 type=PullData
time="2017-01-22T12:01:03Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:42823 protocol_version=1 type=PullACK
time="2017-01-22T12:01:38Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushData
time="2017-01-22T12:01:38Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:60906 data="QGoaASaABwABfYdulAY6QGl1HMs/oPvh" mac=fb10b827ebe4f14e
time="2017-01-22T12:01:38Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T12:01:38Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushACK
time="2017-01-22T12:02:03Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:53637 protocol_version=1 type=PullData
time="2017-01-22T12:02:03Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:53637 protocol_version=1 type=PullACK
time="2017-01-22T12:02:15Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushData
time="2017-01-22T12:02:15Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:60906 data=QGoaASaACAABGwKHhsWYab2czRCzLDtN mac=fb10b827ebe4f14e
time="2017-01-22T12:02:15Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:60906 data=QGoaASaACAABGwKHhsWYab2czRCzLDtN mac=fb10b827ebe4f14e
time="2017-01-22T12:02:15Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T12:02:15Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T12:02:15Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushACK
time="2017-01-22T12:02:52Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushData
time="2017-01-22T12:02:52Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:60906 data="QGoaASaACQABwA+eAlhIPEvoP/FgrIOm" mac=fb10b827ebe4f14e
time="2017-01-22T12:02:52Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:60906 data="QGoaASaACQABwA+eAlhIPEvoP/FgrIOm" mac=fb10b827ebe4f14e
time="2017-01-22T12:02:52Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T12:02:52Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T12:02:52Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushACK
time="2017-01-22T12:03:03Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:54145 protocol_version=1 type=PullData
time="2017-01-22T12:03:03Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:54145 protocol_version=1 type=PullACK
time="2017-01-22T12:03:29Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushData
time="2017-01-22T12:03:29Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:60906 data=QGoaASaACgABe4M6p2H0pHPcHA7fYFqY mac=fb10b827ebe4f14e
time="2017-01-22T12:03:29Z" level=info msg="gateway: rxpk packet received" addr=115.178.193.41:60906 data=QGoaASaACgABe4M6p2H0pHPcHA7fYFqY mac=fb10b827ebe4f14e
time="2017-01-22T12:03:29Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T12:03:29Z" level=info msg="backend: publishing packet" topic="gateway/fb10b827ebe4f14e/rx"
time="2017-01-22T12:03:29Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:60906 protocol_version=1 type=PushACK
time="2017-01-22T12:04:03Z" level=info msg="gateway: received udp packet from gateway" addr=115.178.193.41:42042 protocol_version=1 type=PullData
time="2017-01-22T12:04:03Z" level=info msg="gateway: sending udp packet to gateway" addr=115.178.193.41:42042 protocol_version=1 type=PullACK

Unfortunately I accidentally deleted the lora server logs because I re-created the container.
Thanks in advance!

The LoRa App Server warning might explain your issue 😉
time="2017-01-22T11:58:32Z" level=warning msg="queue item discarded as it exceeds max payload size" dev_eui=0004a30b001b2d10 max_payload_size=51 payload_size=60 reference=1485086303624

LoRaWAN has a max-payload size per data-rate. Please see the "LoRaWAN regional parameters" spec for these values per data-rate. Also note that in the latest LoRa Server version, you can specify if your setup uses a repeater or not. In the latter case, the max-payload can be increased (this info is also in the LoRaWAN regional parameters" spec.
(I'm not sure if TTN has a validation on this, this might explain the difference in behaviour)

Thanks for your response! So the problem should be in the application and not on the lora server and gateway, right?
I'm also wondering whether the reference should be unique or not.

@alwint3r yes I suppose so. You could use the same reference for every payload, however it might be confusing at your side as it is used in case of errors and acknowledgements (in case of confirmed data down)

@brocaar Thanks for the info. I'll tell you later whether it's solved or not.

I think the downlink issue is solved for me. I used shorter reference and reduced the payload size and it's working fine now. Thank you!

Hi
Update to
lora server v0.13.3
lora gateway bridge v2.1.2
lora app server v0.2.0
and work in RFM95
Thanks @brocaar

Hi, @alwint3r !
How did you manage to find these logs?
I'm running loraserver on a Raspberry Pi 3 with an image generated by loraserver-pi-gen.
Even though everything is working fine, I can't find any logs.
All directories in /var/log/ are empty or have empty log files.
Thanks!

repo: brocaar/loraserver


text:
Guard-mode wechselt nicht

Hallo,
Leider funktioniert es nach der Aktualisierung immer noch nicht. Ich habe ein Update auf die aktuelle version gemacht. Bei mir möchte ich den Status in Abhängigkeit meiner Alarmanlage wechseln. Mit meinem Workaround (Adapter Neustarten) klappt es.

Hallo @tofrie ,
bei mir funktioniert es einwandfrei. Kannst du mir bitte die Logs zusenden?

@tofrie Kann es vielleicht sein, dass es nach einiger Zeit nicht mehr geht? Sprich wenn du nun die Alarmanlage scharf schaltest
und nachher wieder unscharf, sollte der Modus auch bei der Eufy-Station korrekt wechseln.
Das Problem könnte sein, dass der Adapter nach einiger Zeit die Verbindung mit der Eufy-Station verliert und dies nicht mitbekommt und denkt er sei immer noch verbunden (die Verbindung ist ja stateless - UDP).

Damit ich dir logs schicken kann muss der Debugmodus aktiv sein oder? Ich würde mich am Wochenende noch einmal dran setzen. Das Skript funktioniert eigentlich ganz einfach. Wird die Alarmanlage scharf geschaltet, wird eufy auf abwesend geschaltet und das ganze umgekehrt.

Ja. Mittlerweile habe ich die Ursache gefunden. Gebe dir hier Bescheid sobald auch dieser Bug behoben wurde.

@tofrie Habe gerade die neue Version (0.0.8) publiziert. Kannst du einen Test fahren und mir Bescheid geben? :)
Danke!

Ich habe es ein paar mal getestet. Bis jetzt funktioniert es. Ich würde dir morgen ein finales Feedback geben. Vielen Dank schon einmal 👍

Es lief heute ohne Probleme. Es scheint der Fehler ist gelöst. Super Arbeit!

authors: bropat tofrie


text:
SamplerCollector::run 会在main函数前运行，daemon后可能导致问题

SamplerCollector::run 会在main函数前运行，daemon后可能导致问题， 有什么方法可以延迟该线程的创建吗？

原因在 #208 有提到一些。

repo: brpc/brpc


text:
this converted to undefined

Description
When using pre-compiled versions of scripts, for example Modernizr, and many jQuery plugins, thi is always replaced with undefined in the compiled JavaScript.
Expected behavior
I'm not sure what should be done here, but I think that when this is encountered it should be left alone, and the wrapping function should be bound to the window context.
Actual behavior
Here is an example:
window.Modernizr = function (window, document, undefined) {
    // Some code here
}, this, this.document);

is converted to:
window.Modernizr = function (window, document, undefined) {
    // Some code here
}, undefined, undefined.document);

Environment

Brunch: 2.77
Node: 6.0.0
NPM: 3.8.6
Operating system: OS X 10.11.4

package.json contents
{
  "devDependencies": {},
  "dependencies": {
    "auto-reload-brunch": "^2.7.0",
    "autoprefixer": "^6.3.6",
    "babel-brunch": "^6.0.0",
    "babel-preset-es2015": "^6.3.13",
    "babel-preset-react": "^6.3.13",
    "brunch": "^2.7.0",
    "clean-css-brunch": "^2.0.0",
    "css-brunch": "^2.0.0",
    "hmr-brunch": "^0.1.0",
    "javascript-brunch": "^2.0.0",
    "postcss-brunch": "^0.5.0",
    "sass-brunch": "^2.6.2",
    "uglify-js-brunch": "^2.0.0"
  }

brunch config contents
exports.config = {
  // See http://brunch.io/#documentation for docs.
  files: {
    javascripts: {
      joinTo: {
        "js/app.js": /^app\/assets\/js/,
        "js/plugins.js": /^app\/assets\/plugins/,
        "js/polyfills.js": /^app\/assets\/polyfills/,
        "js/vendor.js": /^app\/assets\/vendor/,
      },
      order: {
        before: [
        'app/assets/js/vendor/jquery-*',
        'app/assets/js/vendor/jquery-ui.js',
        'app/assets/js/vendor/jquery.*',
        'app/assets/js/vendor/*.js'
        ]
      }
    },
    stylesheets: {
      joinTo: {
        "css/styles.css": /^app\/assets\/sass/
      }
    }
  },

  conventions: {
    assets: /^(app\/assets\/static)/
  },

  paths: {
    // Dependencies and current project directories to watch
    watched: [
      "app/assets"
    ],

    // Where to compile files to
    public: "public/assets"
  },

  // Configure your plugins
  plugins: {
    babel: {
      // Do not use ES6 compiler in vendor code
      ignore: [
        /app\/assets\/js\/vendor/
      ],
      presets: [
        'es2015'
      ],
    },
    sass: {
      mode: 'native'
    },
    postcss: {
      processors: [
        require('autoprefixer')
      ]
    }
  }
};

I know this isn't an ideal simple setup, this is an iteration of an app from a really horrible old gulp setup.

Looks like it's caused by Babel processing these files — which shouldn't actually happen with the plugins.babel.ignore, something must be off here... (If you are up to it, you can open an issue on https://github.com/babel/babel-brunch regarding this, a small repo that demonstrates the issue would be ideal.)
In general though, files not matched by the vendor convention are going to be (tried to be) compiled. Babel's ignore is more to let you bypass babel for some of your app code. With vendor files, you will probably never need to have these compiled, so might be worth to set it:
  conventions: {
    vendor: /(^bower_components|node_modules|app\/assets\/js\/vendor)[\\\/]/
  }

@paulmillr can this be closed?

authors: designermonkey goshakkk

repo: brunch/brunch


text:
Provide Globals As a Required Package Simiar to externals of Webpack

Is there a way to provide globals as a required package similar to externals of Webpack?
For example, we can add React from CDN via a script tag. However, npm packages requiring React would give error while bundling because there is no React package installed. It should be somehow possible to expose global React to them.

Currently there is none.
Also, I'm not 100% sure, but if React from CDN is loaded before your bundle, won't the React bundle create its own require? Therefore not giving a chance for Brunch to bootstrap its own `require?

+1

Also, I'm not 100% sure, but if React from CDN is loaded before your bundle, won't the React bundle create its own require? Therefore not giving a chance for Brunch to bootstrap its own `require?

The problem is during package building (not loading in the browser).

authors: ferhatelmas goshakkk robert-zaremba