Missing Error Handler on aliasHandler

Hi,
I encounter 'unhandled rejection' error when upgrade moleculer-web v0.6.3 to v.0.8.0
and I've found error handler is missing on aliasHandler,
In my situation,
in authorize function, return promise with rejection I've got unhandled rejection error
 return Promise.reject(new UnAuthorizedError(ERR_NO_TOKEN))

and my suggestion
src/index.js :392

        // If not, it handled request/response by itself. Break the flow.
       return true;
        })
        .catch(err => this.sendError(req, res, err));
},

Thanks, I'm fixing.

Not in alias,
rejection in authorize method,
I called action to service via broker
You may reproduce  this way,
const {
  UnAuthorizedError
} = ApiGateway.Errors

authorize (ctx, route, req, res) {
    if (req.needAuth !== 'required') {
        return ctx
      }
      let token
      if (req.headers.authorization) {
        let type = req.headers.authorization.split(' ')[0]
        if (type === 'Token') {
          token = req.headers.authorization.split(' ')[1]
        }
      }
      if (req.needAuth === 'required' && !token) {
        return Promise.reject(new UnAuthorizedError(ERR_NO_TOKEN))
      }
      // Verify JWT token
      return ctx.call('users.resolveToken', {
        token
      })
        .then(user => {
          return Promise.reject(new UnAuthorizedError(ERR_NO_TOKEN))
        })
}

and request any route.
and get
Unhandled rejection TokenExpiredError: jwt expired

By the error message, I think the problem is not in authorize, but in users.resolveToken. Could you show the source of this action?

resolveToken: {
      cache: {
        keys: ['token'],
        ttl: 60 * 60 // 1 hour
      },
      params: {
        token: 'string'
      },
      handler (ctx) {
        return new this.Promise((resolve, reject) => {
          jwt.verify(ctx.params.token, this.settings.JWT_SECRET, (err, decoded) => {
            if (err) {
              return reject(err)
            }
            resolve(decoded)
          })
        }).then(decoded => {
          if (decoded.user) {
            return User.findOne({
              where: {
                id: decoded.user
              }
            }).then(user => {
              return user.dataValues
            })
          }
        })
      }
    },

This is my resolveToken code

I know the error message is from jwtwebtoken package,
the problem is I can't handle the rejection error anywhere.
So, request are just pending when token is expired or invalid.
I just want to response error code and message.

The return reject(err) is called when the token is expired or invalid?

Yes,

I tried it but no unhandled rejection. Could you create a small repro repo?

https://github.com/theRichu/moleculer-web-unhandled
check this repo please

Thanks. The unhandled issue is fixed in the master branch. You can update & test it with npm i moleculerjs/moleculer-web.
By the way, the calling order changed and there is a side effect in your repo. The onBeforeCall & authorize are called before action middlewares. So 'GET /user/me': [auth.required(), 'users.me'] won't work because the authorize called sooner than auth.required().


Add windows CI

Tested build for windows https://www.appveyor.com/

Added it & the badge
https://ci.appveyor.com/project/kevinhikaruevans/uojs2


Bundle outdated with major and minor options

This feature adds the ability to specify a outdated command to show only the gems with a major or minor updates.
I was looking for this feature and found the issue https://github.com/bundler/bundler/issues/3805
@indirect, how can I improve this PR?

@indirect please review this

Actually, @cirdes, it would be awesome if you could add the version numbers to the specs, to decrease the likelihood of us breaking something accidentally in the future

This seems genuinely useful. Thanks!
@homu r+

:pushpin: Commit 9096ca9 has been approved by indirect

:hourglass: Testing commit 9096ca9 with merge 19b2dcc...

:sunny: Test successful - status

It would be great to add a --patch (or --tiny) flag, too. Patch level updates should be the safest to make, yet with this change we can only see the list of not the safest updates (minor and major upgrades).

@contentfree when you run outdated with no arguments, you should be seeing the patch level updates, because you use pessimistic version constraints, right? :grin:

Hmm... Gemfile fail on my part then ;)

That said, you raise a good point... it looks like #3805 actually expected the options --patch and --minor, with "no arguments" providing all possible updates. This pull request seems to implement the opposite, --major showing only major updates, and --minor showing only minor updates.
This PR provides "only major", "only minor", and "major, minor, and patch" (on no flags), but I think it would actually be more useful to provide "only patch" and "only patch and minor" as options, because no arguments already provides "patch, minor, and major". @RochesterinNYC what do you think about this?

@indirect: Exactly. I do use the pessimistic operator (most of the time…) but "~> 1.1" would show minor outdated with no flags.

I think having all three options would be ideal. Even if you were looking for major upgrades, sifting through the list of all upgrades available is worse than just seeing the exact list of major upgrades.

I thought we already added a --patch flag that will only show updates in the third, patch version section here? #4312

@indirect, this PR(#4249) provides "only major"(or at least major) for --major and "major and minor"(at least minor) for --minor.
The PR #4312 change the description from "at least" to "Only list".
The reason I didn't add the "--patch" is because it would be "major, minor and patch"(at least patch) that is equivalent to outdated without arguments

@cirdes I guess it's not clear to me whether whether --minor means "minor and major" or "minor and patch" or "minor only". I didn't really think about the options before accepting this PR, so I'm not sure if what we have now is the best choice. (Maybe it is! But I didn't think about it until now.)
@contentfree as @RochesterinNYC pointed out, we added a --patch flag!  It was not clear at all. I did that way because when I`m updating my gems using bundle outdated I just have to manually change the version of minor and major updates. So using bundle outdated --minor (at least) give me just what I want. I not sure if my approach is the best for everyone else but was based on my user case.

If you're looking for updates that only affect the minor and patch version sections, I think that bundle outdated --minor --patch might accomplish this. Please correct me if I'm wrong here.

@RochesterinNYC, I think you are right. It seems to be correct and clear.

I agree, that seems to make sense. Each flag includes only that type of update, they can be combined, and no flags includes all types.


Disabling zoom in and zoom out in jstree

I want to disable zooming functionality in my jstree, Any help please?
Thanks in advance!

There is no zooming functionality in jstree. If it is the browser function that you want to disable - this is not related to jstree and I am afraid I can not help. If I misunderstood - please clarify and I will reopen.


reporter health check endpoint and sentinel check

Description
Please include a summary of the changes and the related issue.
Please also include relevant motivation and context.
List any dependencies that are required for this change.
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.

Deployment

[ ] Should publish npm package
[ ] Should publish Docker image

lgtm! would you mind separating the pr for sentinel and reporter? I think it's better to keep sentinel pr opened until reporter is deployed

sounds good! I moved the healthcheck creation logic from Run to cmd because tests were failing when it's in Run (there is no clean up/shutdown logic for http server so tests try to add api/v1 path mutliple times)


spike: Investigate locking down the API

Describe what should be investigated or refactored
Right now, our API is publicly available at leapfrogai-api.DOMAIN.
There are several potential paths forward that we need to investigate:

Do not expose the API publicly. Only use it through our UI or other managed tools.
Use supabase to secure the api
Use keycloak to try to limit access to the API

This is resolved with the API keys


Convert to import/export definitions

This will allow color-convert to be tree-shakable, meaning only the conversions that are used are actually emitted into bundled code.
This should happen alongside #56.

You need help with that? Do you have a place to contact Josh?!!

You need help with that?

PR's are always welcome :)

Do you have a place to contact Josh?

Right here :)

Now we can move this package to ESM.


Command line app

You can make this an easily-installable command line app if you add a "bin" property to package.json. Here's an example for webtorrent: https://github.com/feross/webtorrent/blob/master/package.json#L11
Then users can get it without using git clone, just like this:
npm install proofreader -g   // installs a `proofreader` command line program
proofreader /path/to/file

The -g tells npm to install the program globally and add it to the PATH.

Done. Thanks for a detailed instruction!


when one to one field is set as primary key, stream decorator removes item as target

im using actstream to populate a stream with things like
guy posted whats up on group_feed
My issue is, for a certain type of group_feed, the group object has been changed to have this
org = models.OneToOneField(Organization, primary_key=True)
(this was done since devs were complaining that the org id should have the same PK as the org_feed)
Now when the @ stream decorator runs fetch_generic_relations() it cant find the generic relation and pops out as
guy posted whats up (note the missing feed)
ive confirmed this is only happening for feeds attached to an object with a onetoone field and primary key=true .
Whats even stranger is when I make a custom @ stream decorator to run fetch_generic_relations('')
everything runs fine. It doesnt appear if any of the if statements in stream are hitting true.
How is fetch_generic_relations() supposed to work? I keep reading through it and nothing seems to stick out to me as to where the gfk gets screwed up. Help?

Ive confirmed that this function is the problem
        print(qs.fetch_generic_relations('').first().target_object_id)
       #outputs a pk number
        print(qs.fetch_generic_relations().first().target_object_id)
      #outputs nothing

when they are literally right next to each other in the @ stream function

So the argument appears to be nullifying the funtions steps... but where in this function is the target_object_id being obliterated when there is no arg??

@justquick Was the error not explained properly?

👋 hi @KeynesYouDigIt -- turns out the "fix" for this at the moment is to do this in your settings.py:
ACTSTREAM_SETTINGS = {
    # yada yada
    'FETCH_RELATIONS': False,
}

it's more than likely an issue with Django's prefetch_related itself, not django-activity-stream. However, that means we lose the query optimisation in prefetching content objects (actor, action_object, and target).


can you provide your pip list ?

Here it is. pip_list.txt

Here it is. pip_list.txt

Thanks for your provide


chore(deps): update common-dev-assets digest to 41d5196

This PR contains the following updates:

Package
Update
Change

common-dev-assets
digest
45f17e6 -> 41d5196

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

/run pipeline

:tada: This PR is included in version 1.11.11 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


mobile/twitter layout with 2 rows

I updated the interval plot to be displayed in two rows regarding issue #21. This included increasing axis text size, putting a little bit of spacing back in between panels, and moving legend around. Final image (1600 x 900 size):

I updated this pipeline to have two new targets that have the two-row layout. There are still only two main source functions, one to create the interval plot itself and one to merge it with the legend. Here are resultant figures from targets p3_daily_interval_png and p3_daily_interval_2row_png respectively.

The one-row layout is the version currently in use on the evaluate-forecast pipeline on gitlab. For now, I believe we are not going to use the two row layout.


Visual Bug

Boundaries between Vanilla water source blocks & Aqueduct water blocks leave an opening due to Vanilla water blocks not rendering its texture on that side. Saw that this was also an issue on BTA. Is there a reason why the Aqueduct water model isn't the same height as vanilla?
Also there's no recipe(like BTA) for aqueducts at the moment. Nothing crafttweaker can't fix but I digress.

I'm actually not sure why this happens. Aqueduct water should render either like normal water or like a forge fluid with the water texture, which should be identical... although, actually, now that i think about it, it might be the fact that it's flowing.


[PE-D] Parameters formatting is inconsistent

If you specified id/{id_number} in the command format notes, you should use the same snake case format for all the command formats.
You should also use the same parameter name, unless ambiguous.
(e.g. can use index as long as its obvious what the index is referring to. If need to provide both order and item index in 1 command, then you should use order_index and item_index)

Labels: type.DocumentationBug severity.VeryLow
original: EuniceSim142/ped#8

The formatting has been specified in the user guide update.


Doesn't seem to work with latest Rakudo-star

$ perl6
To exit type 'exit' or '^D'
> use Redis;
(Any)
> my $redis = Redis.new("<IP_ADDRESS>:6379");
Too many positionals passed; expected 1 argument but got 2
  in method new at /home/extra/duelafn/Projects/rakudo-star-2016.10/install/share/perl6/site/sources/358C80A86477882188B39895417238E05C5D0866 (Redis) line 105
  in block <unit> at <unknown file> line 1

It is complaining about my $obj = self.bless(*, |%config); and works fine if you remove the first * parameter: my $obj = self.bless(|%config);

Sorry, I cannot test it now, could you create a pull request for this fix?


[FEATURE] command aliases / operation components

This is a tracking issue for two undeveloped feature request ideas.
One is a git-like command alias system. See git help config and jump to alias.* for details.
The other some way to define commands/operations/scripts/whatever that appear in a GUI for convenient execution.
In both cases, we should deeply consider team/sharing use cases.

One motivating use case comes from @finnigantime, where he wants to restart a pair of two services and wants to run one command or otherwise avoid listing both service names for this common operation in his development environment.


Replace the half-lock with helping strategy

This makes all the write operations lock-free too.
Also, as the helping strategy is based on that article in #34, that one probably can be closed too. And currently we also have some almost formal arguments about why things are correct.
Closes #8, #34 and #4.

Codecov Report

Merging #50 (56abc5d) into master (fbe2eee) will increase coverage by 1.04%.
The diff coverage is 90.77%.

@@            Coverage Diff             @@
##           master      #50      +/-   ##
==========================================
+ Coverage   89.02%   90.07%   +1.04%
==========================================
  Files          15       15
  Lines        1157      987     -170
==========================================
- Hits         1030      889     -141
+ Misses        127       98      -29

Impacted Files
Coverage Δ

src/weak.rs
75.00% <78.57%> (-8.34%)
:arrow_down:

tests/stress.rs
94.44% <82.35%> (+0.47%)
:arrow_up:

src/debt/list.rs
86.66% <86.66%> (ø)

src/debt/helping.rs
92.64% <92.64%> (ø)

src/debt/mod.rs
96.29% <96.29%> (ø)

src/debt/fast.rs
100.00% <100.00%> (ø)

src/lib.rs
96.00% <100.00%> (ø)

src/strategy/hybrid.rs
95.45% <100.00%> (+4.68%)
:arrow_up:

tests/random.rs
100.00% <100.00%> (ø)

src/strategy/rw_lock.rs
0.00% <0.00%> (-3.85%)
:arrow_down:

... and 5 more

Codecov Report

Merging #50 (56abc5d) into master (fbe2eee) will increase coverage by 1.04%.
The diff coverage is 90.77%.

@@            Coverage Diff             @@
##           master      #50      +/-   ##
==========================================
+ Coverage   89.02%   90.07%   +1.04%
==========================================
  Files          15       15
  Lines        1157      987     -170
==========================================
- Hits         1030      889     -141
+ Misses        127       98      -29

Impacted Files
Coverage Δ

src/weak.rs
75.00% <78.57%> (-8.34%)
:arrow_down:

tests/stress.rs
94.44% <82.35%> (+0.47%)
:arrow_up:

src/debt/list.rs
86.66% <86.66%> (ø)

src/debt/helping.rs
92.64% <92.64%> (ø)

src/debt/mod.rs
96.29% <96.29%> (ø)

src/debt/fast.rs
100.00% <100.00%> (ø)

src/lib.rs
96.00% <100.00%> (ø)

src/strategy/hybrid.rs
95.45% <100.00%> (+4.68%)
:arrow_up:

tests/random.rs
100.00% <100.00%> (ø)

src/strategy/rw_lock.rs
0.00% <0.00%> (-3.85%)
:arrow_down:

... and 5 more


Added logsumexp operation

Added logsumexp op for log semiring (to work in log space for sum product alg)

Will rebase before creating this pull request.


anoncreds-rs integration

#1110 was merged accidentally without prior rebase

Codecov Report
Attention: 46 lines in your changes are missing coverage. Please review.

Comparison is base (e177471) 0.05% compared to head (a9667ed) 0.05%.

Files
Patch %
Lines

aries/aries_vcx/src/handlers/issuance/issuer.rs
0.00%
10 Missing :warning:

...s_vcx/src/common/primitives/revocation_registry.rs
0.00%
7 Missing :warning:

aries/aries_vcx/tests/test_anoncreds.rs
0.00%
6 Missing :warning:

...vcx/src/protocols/issuance/holder/state_machine.rs
0.00%
5 Missing :warning:

aries/aries_vcx/tests/test_credentials.rs
0.00%
5 Missing :warning:

aries/aries_vcx_core/src/errors/mapping_others.rs
0.00%
5 Missing :warning:

...es_vcx/src/common/proofs/prover/prover_internal.rs
0.00%
3 Missing :warning:

...vcx/src/common/primitives/credential_definition.rs
0.00%
2 Missing :warning:

aries/aries_vcx/tests/test_primitives.rs
0.00%
2 Missing :warning:

...es_vcx/tests/utils/scenarios/proof_presentation.rs
0.00%
1 Missing :warning:

Additional details and impacted files
@@           Coverage Diff            @@
##            main   #1119      +/-   ##
========================================
- Coverage   0.05%   0.05%   -0.01%
========================================
  Files        475     475
  Lines      23870   23898      +28
  Branches    4273    4281       +8
========================================
  Hits          13      13
- Misses     23856   23884      +28
  Partials       1       1

Flag
Coverage Δ

unittests-aries-vcx
0.05% <0.00%> (-0.01%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Enable piping of config files to command line

e.g. flyway.user=myUser\nflyway.password=myPassword | flyway info
This will make Flyway more flexible, enabling workflows like encrypted config files: https://github.com/flyway/flyway/issues/1194#issuecomment-590963728

https://github.com/flyway/flyway/commit/16ec241bfee3f655a3330cde3edf5cec87f69019


Prometheus UI doesn't show metrics read from remote storage in the drop down

What did you do?
Set up pg_prometheus, pg_prometheus_adapter with prometheus. Configured for remote_read and remote_write config.yml
Followed instructions from : https://github.com/timescale/prometheus-postgresql-adapter
What did you expect to see?
Expected the remotely read metrics to show up in Prometheus UI. Only scraped metrics show up in the UI. Even in the Grafana integration with prometheus, only scraped metrics show up in auto complete.
What did you see instead? Under which circumstances?
Metrics read from remote storage don't show up. However, executed query to fetch metric using query editor. Results show up. The drop down doesn't show this metric at all.
Environment
Mac OS X

System information:
Darwin 16.7.0 x86_64

Prometheus version:
prometheus, version 2.0.0 (branch: master, revision: 607a6756172618ef199bf63f5413e68587f458da)

Prometheus configuration file:

# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
      source: 'codelab-monitor'

remote_write:
  - url: "http://<IP_ADDRESS>:9201/write"
    remote_timeout: 60s
remote_read:
  - url: "http://<IP_ADDRESS>:9201/read"
    remote_timeout: 60s
    read_recent: false

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'my_job'
    honor_labels: true
    scrape_interval: 60s
    scrape_timeout: 30s

    static_configs:
      - targets:
         - 'docker.for.mac.localhost:9091'

I'd rather ask the question to the timescale/prometheus-postgresql-adapter project whether or not they have validated their adapter with Prometheus 2.x.

Dupe of #3351


started_at wiped from metadata when a questionnaire is re-launched

Expected behaviour
When a questionnaire is re-launched the started_at date should remain
The started_at value should be set when the 1st page is posted (generally introduction)
Actual behaviour
When a questionnaire is re-launched the metadata is overwritten which wipes the started_at date.
Question:  Should our metadata be immutable?
The started_at value is set when the 1st answer is sent, rather than when the "Start survey" button is pressed
Steps to reproduce the behaviour
Launch from launcher and name a note of RU Ref and Collection Exercise SID
Answers some questions
Launch again from launcher using the same RU Ref and Collection Exercise SID

Can we rely on the start survey button always being present?

@bitdivision no, so the 1st form submit


cant find my rolling stock on the frames category

when i click on the frames category to change the names and numbers of my rolling stock, i get 4 of my tier 1 cars and 2 of my tier 2 cars, but at the top it shows that i have 28 cars. im confused why only a select few are showing up while the rest are not listed at all.

Fixed in 89ec9b9027cff813f10faefc8131d8467650ffa3


Move use cases to the website repo

Search before asking

[X] I had searched in the issues and found no similar issues.

Motivation
Use cases and images should be moved to https://github.com/apache/incubator-kvrocks-website, and remove the docs folder.
Also, add a document for how to submit use cases (logos) so that we don't have to manually maintain https://github.com/apache/incubator-kvrocks/issues/414.
Solution
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

Closed as done.

https://github.com/apache/incubator-kvrocks-website/pull/29
https://github.com/apache/incubator-kvrocks-website/pull/30
https://github.com/apache/incubator-kvrocks/pull/1181


Component: Combo button

There seems to be a proposal to separate menu buttons and split buttons (combo?)

AI apps has guidelines started

Separate menu overflow, looks like part of v11

https://github.com/carbon-design-system/carbon/issues/1903

Combo button, not sure what the status is

https://github.com/carbon-design-system/carbon/issues/3371

I could see these potentially being valuable to some teams with more complex experiences, but have not seen a recent example.


Declaration Request Cabinet

After authorization a person must be able to:

view current active declaration and declarations history Get Declaration Status/Details by patient #1920

make new declaration request Create declaration request online #1909

check declarations history Get declarations list by patient #1919

terminate declaration Terminate Declaration via Cabinet #1925

[x] design and spec the process of making declaration request from cabinet

[ ] implement

[ ] improve test scenarios

Request:
curl -X POST \
  https://dev.ehealth.world/api/cabinet/declaration_requests \
  -H 'authorization: Bearer SFB3SDNhZlBuZFJhNlZkcmZrUjU0UT09' \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/json' \
  -H 'postman-token: 8ff92cb4-d049-f745-ec57-f03bf5ca8255' \
  -d '{
  "person_id": "0895e21b-06e1-4a3c-8f23-daabf86adf7f",
  "employee_id": "376bc05d-4686-4ef3-94c9-23094c735e5b",
  "division_id": "4461d9c0-0111-4c11-98ba-3db14129c072"
}'

Response
{"meta":{"url":"http://api-svc.il/api/cabinet/declaration_requests","type":"object","request_id":"41ebe20a-4282-4b5b-960d-3bca273d5cd2#426","code":500},"error":{"errors":{"detail":"Internal server error"}}}

@AlekzandrV please retest

@AlekzandrV any results?


Fix race when initializing ringBufferRateLimiter

This closes https://github.com/mholt/caddy-ratelimit/issues/36.
Fixes a race condition between ringBufferRateLimiter creation and its insertion into a map. Do this by locking the entire map when we get or insert a ringBufferRateLimiter.
I have replaced use of sync.Map with a normal  map[string]*ringBufferRateLimiter and a sync.Mutex. They are passed around with a rateLimitersMap struct. I've factored out logic into methods of rateLimitersMap, which enables some careful use of defer rlm.mu.Unlock() to avoid leaving a lock held open on panic().
We didn't see a need for a sync.Map. The docs suggest against using it for type safety, and none of the suggested use cases apply. https://pkg.go.dev/sync#Map. Let me know if I'm misunderstanding the use case (very possible!).
I've removed the sync.Pool, for now. Since ringBufferRateLimiter creation and insertion is fully synchronized, I didn't see a need for it.
Note that some of the defensive refactoring is not strictly required--I have a change that preserves the existing data structures, but I think the suggested changeset is an overall improvement in maintainability. https://github.com/divviup/caddy-ratelimit/pull/1/commits/65ad951ea012a5410dff297efa9da6f769e20dc0.
Some discussion of the performance impact and profiles is here https://github.com/divviup/caddy-ratelimit/pull/1. TL;DR, no meaningful impact to CPU, memory, or latency. This implementation could be optimized by replacing the normal mutex with a RWMutex, but it would be a marginal improvement (if any) in exchange for much more complicated locking semantics.
I suggest waiting before merging this, while we let it sit in production for a while longer, to ensure the problem is fully fixed. I'll let it sit for about a week. In the mean time, this is ready for code review.

Hi, wow!! Thank you for this. Sorry for the lateness, I was out this weekend with the family. I'll look at this soon!

How have your instances been this last week, @inahga?
I'll sleep better once this is merged 🙂

How have your instances been this last week, @inahga?

I'll let you know by Monday, I was slow to deploy it this week.

@DzigaV We've run this in production for a week now, with no signs of leakage. Feeling pretty confident this fixed it.

That's great news!! Thank you for the contribution and the work required to get it figured out. Glad it's working :+1:


Second taskbar hides to the top of Monitor 1 (Stacked Monitors)

Describe the bug
On a stacked monitor setup, monitor 2's taskbar autohides to the top of monitor 1. This leaves the taskbar covering anything at the top of monitor 1.
Screenshots
Taskbar up

Taskbar down

Desktop:

OS: Windows 10
Version 20H2

I've got the same issue, and it seems that only the following styles cause this problem: Gradient, Opaque and Blur.
Switching to Default, Transparent or Acrylic is a solution for the moment.
OS: Windows 10
Version: 20H2
TaskbarX version: <IP_ADDRESS>

To be able to focus on major/current bugs I had to close all issues. The issues section has gotten very messy to a point that I couldn't follow it anymore. Most issues are duplicates, very old or are already fixed/solved. Feel free to reopen this issue if you still have this issue on the latest version of TaskbarX to get my attention. All feature requests have been put in a list here: 💡| Feature requests #870
I hope you understand ❤


Using system GTK theme

I'd like to have my application use the GTK theme configured by the user. Is this possible to do?
I've looked through the docs and the code, but couldn't find anything related.

Currently no such functionality is supported. Druid also does not integrate into system themes on any other platform. Theme-ing as a whole is not very fleshed out as it stands currently.
I was thinking semi-recently about integrating with system appearance, specifically GTK theme and I think it is definitely important. That said, given other important topics, theme-ing is fairly low priority to my understanding. If you want to poke at what it would take to have Druid be aware of the GTK theme then please feel free to start. Many things in Druid have not been of extremely high priority but have been achieved due to people deciding to put the work into them :)


Fix minDate Function

Fixing Error that placed Closure after the variable.
fixes #57

hey @coolsam726 any update in this?


find a solution to centralize RUSTFLAGS

Yep, my assessment as well. Dismissing this conversation for now, but, longer term, we should find a solution to centralize RUSTFLAGS
Originally posted by @problame in https://github.com/neondatabase/neon/pull/6764#discussion_r1492170303

Does this belong in storage team's backlog?  Should it be CI/CD team?

I'm "happy" with the situation we have right now.
IMO each team should be able to have high ownership & control of their build (same argument as for why each team should have high ownership & control of their deployment process).
Then again, it makes sense to have a central team (prob CI/CD) provide a build platform / interface. (Use the Dockerfile more?)


Segfaults when applying configuration

Describe the bug
Clicking "Apply" on the config window causes a segfault
To Reproduce

Start AITrack
Click "Configuration"
Make no changes
Click "Apply"
Segfault

Expected behavior
I expected it to write a config file and close the window.
Environment (please complete the following information):

Xubuntu 20.04
Logitech HD Pro Webcam C920 (which, as an aside, AITrack doesn't recognize, but that is a separate issue)
AITrack version: v0.6.4-alpha (Ubuntu branch)

Additional context
I'm happy to help debug / hack / etc. on this, I just wanted to get a bug report in to see if you have some ideas as to where to start.

And valgrind doth spake, saying:
(matt@bluebox) ~/workspace/code/headtracking/aitrack-linux (merge-v0.6.5-alpha-ubuntu)$ LD_LIBRARY_PATH=./onnxruntime-linux-x64-1.4.0/lib valgrind ./aitrack
==601061== Memcheck, a memory error detector
==601061== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==601061== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==601061== Command: ./aitrack
==601061==
--601061-- WARNING: unhandled amd64-linux syscall: 315
--601061-- You may be able to write your own handler.
--601061-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--601061-- Nevertheless we consider this a bug.  Please report
--601061-- it at http://valgrind.org/support/bug_reports.html.
Found ID: 0
[ WARN:0] global ../modules/videoio/src/cap_v4l.cpp (887) open VIDEOIO(V4L2:/dev/video1): can't open camera by index
[ WARN:0] global ../modules/videoio/src/cap_gstreamer.cpp (1758) handleMessage OpenCV | GStreamer warning: Embedded video playback halted; module v4l2src0 reported: Device '/dev/video1' is not a capture device.
[ WARN:0] global ../modules/videoio/src/cap_gstreamer.cpp (888) open OpenCV | GStreamer warning: unable to start pipeline
[ WARN:0] global ../modules/videoio/src/cap_gstreamer.cpp (480) isPipelinePlaying OpenCV | GStreamer warning: GStreamer: pipeline have not been created
[ WARN:0] global ../modules/videoio/src/cap_v4l.cpp (887) open VIDEOIO(V4L2:/dev/video1): can't open camera by index
Not found device1
[ WARN:0] global ../modules/videoio/src/cap_v4l.cpp (887) open VIDEOIO(V4L2:/dev/video2): can't open camera by index
[ WARN:0] global ../modules/videoio/src/cap_gstreamer.cpp (1758) handleMessage OpenCV | GStreamer warning: Embedded video playback halted; module v4l2src1 reported: Cannot identify device '/dev/video2'.
[ WARN:0] global ../modules/videoio/src/cap_gstreamer.cpp (888) open OpenCV | GStreamer warning: unable to start pipeline
[ WARN:0] global ../modules/videoio/src/cap_gstreamer.cpp (480) isPipelinePlaying OpenCV | GStreamer warning: GStreamer: pipeline have not been created
[ WARN:0] global ../modules/videoio/src/cap_v4l.cpp (887) open VIDEOIO(V4L2:/dev/video2): can't open camera by index
Not found device2
[ WARN:0] global ../modules/videoio/src/cap_v4l.cpp (887) open VIDEOIO(V4L2:/dev/video3): can't open camera by index
[ WARN:0] global ../modules/videoio/src/cap_gstreamer.cpp (1758) handleMessage OpenCV | GStreamer warning: Embedded video playback halted; module v4l2src2 reported: Cannot identify device '/dev/video3'.
[ WARN:0] global ../modules/videoio/src/cap_gstreamer.cpp (888) open OpenCV | GStreamer warning: unable to start pipeline
[ WARN:0] global ../modules/videoio/src/cap_gstreamer.cpp (480) isPipelinePlaying OpenCV | GStreamer warning: GStreamer: pipeline have not been created
[ WARN:0] global ../modules/videoio/src/cap_v4l.cpp (887) open VIDEOIO(V4L2:/dev/video3): can't open camera by index
Not found device3
[ WARN:0] global ../modules/videoio/src/cap_v4l.cpp (887) open VIDEOIO(V4L2:/dev/video4): can't open camera by index
[ WARN:0] global ../modules/videoio/src/cap_gstreamer.cpp (1758) handleMessage OpenCV | GStreamer warning: Embedded video playback halted; module v4l2src3 reported: Cannot identify device '/dev/video4'.
[ WARN:0] global ../modules/videoio/src/cap_gstreamer.cpp (888) open OpenCV | GStreamer warning: unable to start pipeline
[ WARN:0] global ../modules/videoio/src/cap_gstreamer.cpp (480) isPipelinePlaying OpenCV | GStreamer warning: GStreamer: pipeline have not been created
[ WARN:0] global ../modules/videoio/src/cap_v4l.cpp (887) open VIDEOIO(V4L2:/dev/video4): can't open camera by index
Not found device4
WARNING: Since openmp is enabled in this build, this API cannot be used to configure intra op num threads. Please use the openmp environment variables to control the number of threads.
   REQUEST
-1
"v0.6.5-alpha"
Disabling tracking shortcut
==601061== Invalid read of size 8
==601061==    at 0x14EE68: TrackerWrapper::update_distance_param(float) (in /home/matt/workspace/code/headtracking/aitrack-linux/aitrack)
==601061==    by 0x1345D6: Presenter::init_tracker(int) (in /home/matt/workspace/code/headtracking/aitrack-linux/aitrack)
==601061==    by 0x134D78: Presenter::save_prefs(ConfigData const&) (in /home/matt/workspace/code/headtracking/aitrack-linux/aitrack)
==601061==    by 0x154154: WindowMain::onSaveClick() (in /home/matt/workspace/code/headtracking/aitrack-linux/aitrack)
==601061==    by 0x70822FF: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.8)
==601061==    by 0x61DFBD0: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==601061==    by 0x61E0E5E: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==601061==    by 0x61E1034: QAbstractButton::mouseReleaseEvent(QMouseEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==601061==    by 0x612D2B5: QWidget::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==601061==    by 0x60EAA65: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==601061==    by 0x60F4342: QApplication::notify(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==601061==    by 0x7056939: QCoreApplication::notifyInternal2(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.8)
==601061==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==601061==
==601061==
==601061== Process terminating with default action of signal 11 (SIGSEGV)
==601061==  Access not within mapped region at address 0x0
==601061==    at 0x14EE68: TrackerWrapper::update_distance_param(float) (in /home/matt/workspace/code/headtracking/aitrack-linux/aitrack)
==601061==    by 0x1345D6: Presenter::init_tracker(int) (in /home/matt/workspace/code/headtracking/aitrack-linux/aitrack)
==601061==    by 0x134D78: Presenter::save_prefs(ConfigData const&) (in /home/matt/workspace/code/headtracking/aitrack-linux/aitrack)
==601061==    by 0x154154: WindowMain::onSaveClick() (in /home/matt/workspace/code/headtracking/aitrack-linux/aitrack)
==601061==    by 0x70822FF: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.8)
==601061==    by 0x61DFBD0: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==601061==    by 0x61E0E5E: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==601061==    by 0x61E1034: QAbstractButton::mouseReleaseEvent(QMouseEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==601061==    by 0x612D2B5: QWidget::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==601061==    by 0x60EAA65: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==601061==    by 0x60F4342: QApplication::notify(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==601061==    by 0x7056939: QCoreApplication::notifyInternal2(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.8)
==601061==  If you believe this happened as a result of a stack
==601061==  overflow in your program's main thread (unlikely but
==601061==  possible), you can try to increase the size of the
==601061==  main thread stack using the --main-stacksize= flag.
==601061==  The main thread stack size used in this run was 8388608.
==601061==
==601061== HEAP SUMMARY:
==601061==     in use at exit: 16,545,377 bytes in 204,514 blocks
==601061==   total heap usage: 714,227 allocs, 509,713 frees, 74,644,611 bytes allocated
==601061==
==601061== LEAK SUMMARY:
==601061==    definitely lost: 23,662 bytes in 29 blocks
==601061==    indirectly lost: 3,373 bytes in 137 blocks
==601061==      possibly lost: 73,680 bytes in 618 blocks
==601061==    still reachable: 16,282,654 bytes in 202,839 blocks
==601061==                       of which reachable via heuristic:
==601061==                         stdstring          : 350,118 bytes in 7,135 blocks
==601061==                         length64           : 3,720 bytes in 66 blocks
==601061==                         newarray           : 10,000 bytes in 67 blocks
==601061==                         multipleinheritance: 1,536 bytes in 1 blocks
==601061==         suppressed: 0 bytes in 0 blocks
==601061== Rerun with --leak-check=full to see details of leaked memory
==601061==
==601061== For lists of detected and suppressed errors, rerun with: -s
==601061== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Segmentation fault (core dumped)

Unfortunately, I don't have time to dig into this any more tonight. I'd love to fix it. Maybe this weekend if you don't get to it.

Access not within mapped region at address 0x0
Seems to be an attempt to access data on a null pointer.
The function in which the error occurs is TrackerWrapper::update_distance_param, which tries to access a pointer to Tracker called model and subsequently a pointer to PositionSolver called solver. I suspect one of these two pointers are null for some reason.
Can you confirm all the models are on the /usr/share/aitrack/models directory? It should contain the following files:
detection.onnx
lm_b.onnx
lm_f.onnx
lm_m.onnx

I ask this because the Tracker class constructor depends on the existence of these files.
There is also a log at ~/.local/share/aitrack/log.txt. There could be some sort of clue there.
You could also debug the application, are you familiar with debugging tools such as gdb?

That was the conclusion I came to in the 15 minutes I had to look at it.
All the models are in that directory, however, look at this:
(matt@bluebox) /usr/share/aitrack/models$ ls -l
total 26768
-rw------- 1 root root   568302 Sep 16 16:29 detection.onnx
-rw------- 1 root root 13500226 Sep 16 16:29 lm_b.onnx
-rw------- 1 root root  4842329 Sep 16 16:29 lm_f.onnx
-rw------- 1 root root  8494061 Sep 16 16:29 lm_m.onnx

Bet that has something to do with it...
(matt@bluebox) /usr/share/aitrack/models$ sudo chmod a+r *

and it's sorted - works great now.
It's always the foolish permissions. Sorry for the trouble.
If I have a chance, I'll try and improve this so that it complains properly rather than crashing.
For what it's worth, here's my resume: https://www.mattcaron.net/resume/
I'm not unskilled, just busy.
Thanks for your help.


Sophisticated arrays and associative arrays validator for both keys and values

I noticed that we're often doing many chains of validations for arrays and their values, and even more when it's a associative array and where keys are now crucial; let alone indenting (recursion) of that. Therefore, I think it would be extremely valuable to create a custom Laravel Validation Rule to help with this.
And then apply the rule everywhere in other packages and projects.

Should probably integrate the enum-array rule we made prior in as well

#120


User gps location

Can you provide us a small demo code where we can use this plugin so we can display user's current location.

Thanks for trying it out. I made you an example on the demo:
https://xon52.github.io/x5-gmaps/#setcenterofmaptocurrentlocation
And here's the file for that component:
https://github.com/xon52/x5-gmaps/blob/master/example/ExampleSetPosition.vue
In short, if you update the map options property it will update the map - so get your new location via the HTML5 Geolocation API, convert to an object in the form: {lat, lng}, and then update your map options property.


Deleted resources show up in search results

Retrieving a single deleted resource gives the expected 410 result, but in a search  deleted resources are included in the result bundle.
For example:
DELETE http://spark.furore.com/fhir/Patient/pat4
GET http://spark.furore.com/fhir/Patient/pat4    (results in 410)
GET http://spark.furore.com/fhir/Patient/           (still lists pat4)

Fixed on dstu2/develop with commit #cc53b47db7c349c9675adb1fa75184b576670b85


Search: How to treat language variants of search engines

Right now, we only have "Google" as the search engine. Is this google.com? images.google.com? google.de?

The way the reporting for search engines work does have breakdown by country and a primary. So there are Google and then each country that has a google domain for search e.g Google - Germany

Then we should update the xdm:searchEngine field accordingly. Right now, it's just a plain string, without any guidance.
https://github.com/adobe/xdm/blob/master/docs/reference/context/search.schema.md#xdmsearchengine
I think we should make it a hostname, using the hostname of the search engine as the key, together with a meta:enum that has the English language name, so that we would have google.de and Google – Germany pair.
@cdegroot-adobe can we get a list of known search engines?

@trieloff - sorry for the delay in responding.
I do not think we can have a meta:enum. The number of locale specific search engines it large and evolving, it is treated as dimensional data for the most part.
I can agree that we should improve the usage guidance.

[ ] Improve the description for searchEngine so there is consistant usage.


Fix code scanning alert - Using latest is prone to errors if the image will ever update. Pin the version explicitly to a re...

Tracking issue for:

[ ] https://github.com/mkosmo/jenkins-agent-docker/security/code-scanning/1

Pin to bullseye-jdk11


missing distribution text for Plazi's 03BD87A2C660A212FF52F3F7F35547D7.xml

via  review of Cullen and Aja -
$ preston cat 'zip:hash://sha256/5146700132c798f057756c6fde84a3d4c426bdc372dbec6ba18ce4125aa8353b!/treatments-xml-main/data/03/BD/87/03BD87A2C660A212FF52F3F7F35547D7.xml' > 03BD87A2C660A212FF52F3F7F35547D7.xml

however, in the resulting csv row (generated via preston plazi-stream), the distribution text, and range map, were missing:

see related 03BD87A2C660A212FF52F3F7F35547D7.xml
<document ID-DOI="http://doi.org/10.5281/zenodo.3739808" ID-GBIF-Dataset="b7e93c79-44a6-4d9c-8b78-dcb62033fb0d" ID-ISBN="978-84-16728-19-0" ID-Zenodo-Dep="3739808" approvalRequired="108" approvalRequired_for_illustrations="6" approvalRequired_for_matCits="24" approvalRequired_for_originalDoi="1" approvalRequired_for_taxonomicNames="29" approvalRequired_for_textStreams="2" approvalRequired_for_treatments="46" checkinTime="1585778501182" checkinUser="plazi" docAuthor="Don E. Wilson & Russell A. Mittermeier" docDate="2019" docId="03BD87A2C660A212FF52F3F7F35547D7" docLanguage="en" docName="hbmw_9_Hipposideridae_210.pdf.imf" docOrigin="Handbook of the Mammals of the World – Volume 9 Bats, Barcelona: Lynx Edicions" docTitle="Hipposideros tephrus Cabrera 1906" docType="treatment" docVersion="14" lastPageNumber="249" masterDocId="FF84FFDAC676A204FFF8FF9AFFEF4346" masterDocTitle="Hipposideridae" masterLastPageNumber="258" masterPageNumber="227" pageNumber="249" updateTime="1654111281024" updateUser="valdenar">
<mods:mods xmlns:mods="http://www.loc.gov/mods/v3">
<mods:titleInfo>
<mods:title>Hipposideridae</mods:title>
</mods:titleInfo>
<mods:name type="personal">
<mods:role>
<mods:roleTerm>Author</mods:roleTerm>
</mods:role>
<mods:namePart>Don E. Wilson</mods:namePart>
</mods:name>
<mods:name type="personal">
<mods:role>
<mods:roleTerm>Author</mods:roleTerm>
</mods:role>
<mods:namePart>Russell A. Mittermeier</mods:namePart>
</mods:name>
<mods:typeOfResource>text</mods:typeOfResource>
<mods:relatedItem type="host">
<mods:originInfo>
<mods:dateIssued>2019</mods:dateIssued>
<mods:dateOther type="pubDate">2019-10-31</mods:dateOther>
<mods:publisher>Lynx Edicions</mods:publisher>
<mods:place>
<mods:placeTerm>Barcelona</mods:placeTerm>
</mods:place>
</mods:originInfo>
<mods:titleInfo>
<mods:title>Handbook of the Mammals of the World – Volume 9 Bats</mods:title>
</mods:titleInfo>
<mods:part>
<mods:extent unit="page">
<mods:start>227</mods:start>
<mods:end>258</mods:end>
</mods:extent>
</mods:part>
</mods:relatedItem>
<mods:classification>book chapter</mods:classification>
<mods:identifier type="DOI">http://doi.org/10.5281/zenodo.3739808</mods:identifier>
<mods:identifier type="GBIF-Dataset">b7e93c79-44a6-4d9c-8b78-dcb62033fb0d</mods:identifier>
<mods:identifier type="ISBN">978-84-16728-19-0</mods:identifier>
<mods:identifier type="Zenodo-Dep">3739808</mods:identifier>
</mods:mods>
<treatment ID-DOI="http://doi.org/10.5281/zenodo.3810829" ID-Zenodo-Dep="3810829" LSID="urn:lsid:plazi:treatment:03BD87A2C660A212FF52F3F7F35547D7" httpUri="http://treatment.plazi.org/id/03BD87A2C660A212FF52F3F7F35547D7" lastPageNumber="249" pageId="22" pageNumber="249">
<heading pageId="22" pageNumber="249">
<subSubSection box="[170,249,3181,3242]" pageId="22" pageNumber="249" type="multiple">
<paragraph blockId="22.[168,1551,3180,3338]" box="[170,249,3181,3242]" pageId="22" pageNumber="249">
<figureCitation box="[170,249,3181,3242]" captionStart="Plate 18: Hipposideridae" captionStartId="18.[172,215,4473,4502]" captionTargetBox="[0,3699,0,4866]" captionTargetPageId="17" captionText="47. Short-tailed Leaf-nosed Bat (Hipposideros curtus), 49. Aellen’s Leaf-nosed Bat (Hipposideros marisae), 50. Schneider’s Leaf-nosed Bat (Hipposideros speoris), 51. Spurred Leaf-nosed Bat (Hipposideros calcaratus), 52. Fawn-colored Leaf-nosed Bat (Hipposideros ceruinus), 53. Cox’s Leaf-nosed Bat (Hipposideros coxi), 54. Cantor’s Leaf-nosed Bat (Hipposideros galeritus), 55. Aba Leaf-nosed Bat (Hipposideros abae), 56. Benito Leaf-nosed Bat (Hipposideros beatus), 57. Sundevall’s Leaf-nosed Bat (Hipposideros caffer), 58. Sooty Leaf-nosed (Bat Hipposiderosfuliginosus), 59. Lamotte’s Leaf-nosed Bat (Hipposideros lamottei), 60. Noack’s Leaf-nosed Bat (Hipposideros ruber), 61. Maghreb Leaf-nosed Bat (Hipposideros tephrus), 62. Dusky Leaf-nosed Bat (Hipposideros ater), 63. Bicolored Leaf-nosed Bat (Hipposideros bicolor), 64. Short-headed Leaf-nosed Bat (Hipposideros breviceps), 65. Least Leaf-nosed Bat (Hipposideros cineraceus), 66. Large Mindanao Leaf-nosed Bat (Hipposideros coronatus)" figureDoi="http://doi.org/10.5281/zenodo.3739814" httpUri="https://zenodo.org/record/3739814/files/figure.png" pageId="22" pageNumber="249">61.</figureCitation>
</paragraph>
</subSubSection>
<subSubSection box="[276,965,3181,3242]" pageId="22" pageNumber="249" type="vernacular_names">
<paragraph blockId="22.[168,1551,3180,3338]" box="[276,965,3181,3242]" pageId="22" pageNumber="249">
<vernacularName box="[276,965,3181,3242]" pageId="22" pageNumber="249">Maghreb Leaf-nosed Bat</vernacularName>
</paragraph>
</subSubSection>
<subSubSection box="[1031,1551,3181,3242]" pageId="22" pageNumber="249" type="nomenclature">
<paragraph blockId="22.[168,1551,3180,3338]" box="[1031,1551,3181,3242]" pageId="22" pageNumber="249">
<taxonomicName authorityName="Cabrera" authorityYear="1906" box="[1031,1551,3181,3242]" class="Mammalia" family="Hipposideridae" genus="Hipposideros" kingdom="Animalia" order="Chiroptera" pageId="22" pageNumber="249" phylum="Chordata" rank="species" species="tephrus">
<emphasis box="[1031,1551,3181,3242]" italics="true" pageId="22" pageNumber="249">Hipposideros tephrus</emphasis>
</taxonomicName>
</paragraph>
</subSubSection>
<subSubSection pageId="22" pageNumber="249" type="vernacular_names">
<paragraph blockId="22.[168,1551,3180,3338]" box="[169,1516,3256,3283]" pageId="22" pageNumber="249">
<emphasis bold="true" box="[169,271,3258,3283]" pageId="22" pageNumber="249">French:</emphasis>
<vernacularName box="[284,568,3256,3283]" pageId="22" pageNumber="249">Phyllorhine cendrée I</vernacularName>
<emphasis bold="true" box="[576,699,3258,3283]" pageId="22" pageNumber="249">German:</emphasis>
<vernacularName box="[710,1029,3256,3283]" pageId="22" pageNumber="249">Maghreb-Rundblattnase</vernacularName>
/
<emphasis bold="true" box="[1057,1181,3258,3283]" pageId="22" pageNumber="249">Spanish:</emphasis>
<vernacularName box="[1193,1516,3256,3283]" pageId="22" pageNumber="249">Hiposidérido de Magreb</vernacularName>
</paragraph>
<paragraph blockId="22.[168,1551,3180,3338]" box="[168,846,3308,3335]" pageId="22" pageNumber="249">
<emphasis bold="true" box="[168,502,3310,3335]" pageId="22" pageNumber="249">Other common names:</emphasis>
<vernacularName box="[511,846,3308,3335]" pageId="22" pageNumber="249">Ash Gray Leaf-nosed Bat</vernacularName>
</paragraph>
</subSubSection>
</heading>
<subSubSection pageId="22" pageNumber="249" type="reference_group">
<paragraph blockId="22.[988,1786,3408,3973]" pageId="22" pageNumber="249">
<emphasis bold="true" box="[988,1198,3408,3447]" pageId="22" pageNumber="249">Taxonomy.</emphasis>
<taxonomicName authorityName="Cabrera" authorityYear="1906" box="[1223,1702,3408,3447]" class="Mammalia" family="Hipposideridae" genus="Hipposideros" isUncertain="true" kingdom="Animalia" order="Chiroptera" pageId="22" pageNumber="249" phylum="Chordata" rank="species" species="tephrus">Hipposideros [sic] tephrus</taxonomicName>
a  brera, 1906,
<materialsCitation ID-GBIF-Occurrence="3753598303" box="[1226,1595,3461,3500]" pageId="22" pageNumber="249">
<collectingCountry box="[1226,1399,3461,3500]" name="Morocco" pageId="22" pageNumber="249">Mogador</collectingCountry>
,
<collectingCountry box="[1418,1590,3461,3500]" name="Morocco" pageId="22" pageNumber="249">Morocco</collectingCountry>
.
</materialsCitation>
</paragraph>
<paragraph blockId="22.[988,1786,3408,3973]" pageId="22" pageNumber="249">
<taxonomicName authorityName="Cabrera" authorityYear="1906" box="[990,1355,3513,3552]" class="Mammalia" family="Hipposideridae" genus="Hipposideros" kingdom="Animalia" order="Chiroptera" pageId="22" pageNumber="249" phylum="Chordata" rank="species" species="tephrus">Hipposideros tephrus</taxonomicName>
belongs to the
<taxonomicName baseAuthorityName="Noack" baseAuthorityYear="1893" box="[1696,1786,3513,3552]" class="Mammalia" family="Hipposideridae" genus="Hipposideros" kingdom="Animalia" order="Chiroptera" pageId="22" pageNumber="249" phylum="Chordata" rank="species" species="ruber">ruber</taxonomicName>
species group. It was previously considered a subspecies of H. coffer. Monotypic.
</paragraph>
</subSubSection>
<subSubSection pageId="22" pageNumber="249" type="distribution">
<paragraph blockId="22.[988,1786,3408,3973]" lastBlockId="22.[166,1780,3985,4655]" pageId="22" pageNumber="249">
<caption ID-DOI="http://doi.org/10.5281/zenodo.6470431" ID-Zenodo-Dep="6470431" httpUri="https://zenodo.org/record/6470431/files/figure.png" inLine="true" pageId="22" pageNumber="249" startId="22.[169,303,3985,4024]" targetBox="[166,958,3412,3967]" targetPageId="22">
<emphasis bold="true" box="[989,1227,3671,3710]" pageId="22" pageNumber="249">Distribution.</emphasis>
Extent of this species’ distribution is not yet known; recorded with certainty in
<collectingCountry box="[1219,1390,3776,3815]" name="Morocco" pageId="22" pageNumber="249">Morocco</collectingCountry>
,
<collectingCountry box="[1412,1562,3776,3815]" name="Senegal" pageId="22" pageNumber="249">Senegal</collectingCountry>
,
<collectingCountry name="Saudi Arabia" pageId="22" pageNumber="249">Saudi Arabia</collectingCountry>
, and
<collectingCountry box="[1160,1295,3829,3868]" name="Yemen" pageId="22" pageNumber="249">Yemen</collectingCountry>
. It is thought to be continuously distributed from
<collectingCountry box="[1491,1699,3881,3920]" name="Mauritania" pageId="22" pageNumber="249">Mauritania</collectingCountry>
and
<collectingCountry box="[989,1136,3934,3973]" name="Senegal" pageId="22" pageNumber="249">Senegal</collectingCountry>
E to
<collectingCountry box="[1247,1497,3934,3973]" name="South Sudan" pageId="22" pageNumber="249">South Sudan</collectingCountry>
,
<collectingCountry box="[1521,1685,3934,3973]" name="Ethiopia" pageId="22" pageNumber="249">Ethiopia</collectingCountry>
, and
<collectingCountry box="[169,303,3985,4024]" name="Eritrea" pageId="22" pageNumber="249">Eritrea</collectingCountry>
. However, boundary between this species and the morphologically identical H. coffer is not known
</caption>
.
</paragraph>
</subSubSection>
<subSubSection pageId="22" pageNumber="249" type="description">
<paragraph blockId="22.[166,1780,3985,4655]" pageId="22" pageNumber="249">
<emphasis bold="true" box="[168,511,4090,4129]" pageId="22" pageNumber="249">Descriptive notes.</emphasis>
Head-body 45-50 mm, tail
<quantity box="[1074,1280,4090,4129]" metricMagnitude="-2" metricUnit="m" metricValue="3.1" metricValueMax="3.5" metricValueMin="2.7" pageId="22" pageNumber="249" unit="mm" value="31.0" valueMax="35.0" valueMin="27.0">27—35 mm</quantity>
, ear
<quantity box="[1385,1589,4090,4129]" metricMagnitude="-2" metricUnit="m" metricValue="1.35" metricValueMax="1.5" metricValueMin="1.2" pageId="22" pageNumber="249" unit="mm" value="13.5" valueMax="15.0" valueMin="12.0">12—15 mm</quantity>
, hindfoot 6-9 mm. The Maghreb Leaf-nosed Bat has short, rounded wings. Muzzle is relatively short, with large but simple noseleaf that has two lateral leaflets. A frontal sac is present. Intemarial septum is not swollen and does not partially cover the nares. Ears are separate, and relatively small. Fur is fine and fluffy, gray or brown gray dorsally, paler ventrally; an orange morph also occurs that is typically reddish golden.
</paragraph>
</subSubSection>
<subSubSection pageId="22" pageNumber="249" type="biology_ecology">
<paragraph blockId="22.[166,1780,3985,4655]" pageId="22" pageNumber="249">
<emphasis bold="true" box="[168,320,4405,4444]" pageId="22" pageNumber="249">Habitat.</emphasis>
Inhabits riparian forest in arid savanna and woodland. Occurs in the
<collectingRegion box="[1677,1778,4405,4444]" country="Burkina Faso" name="Sahel" pageId="22" pageNumber="249">Sahel</collectingRegion>
zone and further south in Sudanian savanna.
</paragraph>
</subSubSection>
<subSubSection box="[168,1636,4510,4549]" pageId="22" pageNumber="249" type="food_feeding">
<paragraph blockId="22.[166,1780,3985,4655]" box="[168,1636,4510,4549]" pageId="22" pageNumber="249">
<emphasis bold="true" box="[168,529,4510,4549]" pageId="22" pageNumber="249">Food and Feeding.</emphasis>
The Maghreb Leaf-nosed Bat is likely to be insectivorous.
</paragraph>
</subSubSection>
<subSubSection pageId="22" pageNumber="249" type="breeding">
<paragraph blockId="22.[166,1780,3985,4655]" lastBlockId="22.[1882,3516,391,1176]" pageId="22" pageNumber="249">
<emphasis bold="true" box="[168,353,4563,4602]" pageId="22" pageNumber="249">Breeding.</emphasis>
Based on observations in northern
<collectingCountry box="[1062,1203,4563,4602]" name="Nigeria" pageId="22" pageNumber="249">Nigeria</collectingCountry>
(which probably refer to this species), a single young is bom in a restricted season: mating appears to take place in November at the end of the rainy season, with births in late April at the beginning of the rainy season. Females lactate for two months, until late June.
</paragraph>
</subSubSection>
<subSubSection pageId="22" pageNumber="249" type="activity">
<paragraph blockId="22.[1882,3516,391,1176]" pageId="22" pageNumber="249">
<emphasis bold="true" box="[1882,2203,498,537]" pageId="22" pageNumber="249">Activity patterns.</emphasis>
The Maghreb Leaf-nosed Bat roosts in a variety of situations including caves, and holes in the ground. Echolocation call includes a F component at c.140-150 kHz.
</paragraph>
</subSubSection>
<subSubSection pageId="22" pageNumber="249" type="biology_ecology">
<paragraph blockId="22.[1882,3516,391,1176]" pageId="22" pageNumber="249">
<emphasis bold="true" box="[1884,2883,657,696]" pageId="22" pageNumber="249">Movements, Home range and Social organization.</emphasis>
Maghreb Leaf-nosed Bats may roost in large colonies of up to 1000 individuals. Roosting colonies include adult males and females. At one cave in
<collectingCountry box="[2583,2729,763,802]" name="Nigeria" pageId="22" pageNumber="249">Nigeria</collectingCountry>
, males apparendy dispersed away from a large colony at the time of parturition, effectively resulting in the cave forming a maternity roost for the remaining females.
</paragraph>
</subSubSection>
<subSubSection pageId="22" pageNumber="249" type="conservation">
<paragraph blockId="22.[1882,3516,391,1176]" pageId="22" pageNumber="249">
<emphasis bold="true" box="[1884,2358,922,961]" pageId="22" pageNumber="249">Status and Conservation.</emphasis>
Classified as Least Concern on 7%♂ IUCN Red List. Due to its wide distribution and large populations, the Maghreb Leaf-nosed Bat is unlikely to become threatened in the near future.
</paragraph>
</subSubSection>
<subSubSection pageId="22" pageNumber="249" type="bibRefCitation_list">
<paragraph blockId="22.[1882,3516,391,1176]" pageId="22" pageNumber="249">
<emphasis bold="true" box="[1884,2090,1088,1117]" pageId="22" pageNumber="249">Bibliography.</emphasis>
Aellen (1952), Bernard & Happold (2013b), Harrison & Bates (1991), Hill (1963a), Koopman (1989), Koopman et al. (1995), Nader (1982), Vallo et al. (2008), Van Cakenberghe et al. (2017).
</paragraph>
</subSubSection>
</treatment>
</document>

thanks to work by @ajacsherman and @flsimoes , the HMW v0.4 https://github.com/jhpoelen/hmw/releases/tag/0.4 now contains the expected distribution text for 03BD87A2C660A212FF52F3F7F35547D7 :
[
{
  "docId": "03BD87A2C660A212FF52F3F7F35547D7",
  "docOrigin": "Handbook of the Mammals of the World – Volume 9 Bats, Barcelona: Lynx Edicions",
  "docISBN": "978-84-16728-19-0",
  "docName": "hbmw_9_Hipposideridae_210.pdf.imf",
  "docMasterId": "hash://md5/ff84ffdac676a204fff8ff9affef4346",
  "docPageNumber": 249,
  "derivedFrom": "zip:hash://sha256/bc1371478e91bc93f4f16c60b705755b0efcffa3b2e3922e4f7dffbd3e51fea2!/treatments-xml-main/data/03/BD/87/03BD87A2C660A212FF52F3F7F35547D7.xml",
  "name": "Hipposideros tephrus",
  "interpretedGenus": "Hipposideros",
  "interpretedSpecies": "tephrus",
  "interpretedAuthorityName": "Cabrera",
  "interpretedAuthorityYear": 1906,
  "commonNames": "Phyllorhine cendrée @fr | Maghreb-Rundblattnase @de | Hiposidérido de Magreb @es | Ash Gray Leaf-nosed Bat @en",
  "taxonomy": "Hipposideros [sic] tephrus a  brera, 1906 , Mogador , Morocco . Hipposideros tephrus belongs to the ruber species group. It was previously considered a subspecies of H. coffer. Monotypic.",
  "subspeciesAndDistribution": "Extent of this species’ distribution is not yet known; recorded with certainty in Morocco , Senegal , Saudi Arabia , and Yemen . It is thought to be continuously distributed from Mauritania and Senegal E to South Sudan , Ethiopia , and Eritrea . However, boundary between this species and the morphologically identical H. coffer is not known .",
  "descriptiveNotes": "Head-body 45-50 mm, tail 27—35 mm , ear 12—15 mm , hindfoot 6-9 mm. The Maghreb Leaf-nosed Bat has short, rounded wings. Muzzle is relatively short, with large but simple noseleaf that has two lateral leaflets. A frontal sac is present. Intemarial septum is not swollen and does not partially cover the nares. Ears are separate, and relatively small. Fur is fine and fluffy, gray or brown gray dorsally, paler ventrally; an orange morph also occurs that is typically reddish golden.",
  "habitat": "Inhabits riparian forest in arid savanna and woodland. Occurs in the Sahel zone and further south in Sudanian savanna.",
  "foodAndFeeding": "The Maghreb Leaf-nosed Bat is likely to be insectivorous.",
  "breeding": "Based on observations in northern Nigeria (which probably refer to this species), a single young is bom in a restricted season: mating appears to take place in November at the end of the rainy season, with births in late April at the beginning of the rainy season. Females lactate for two months, until late June.",
  "activityPatterns": "The Maghreb Leaf-nosed Bat roosts in a variety of situations including caves, and holes in the ground. Echolocation call includes a F component at c.140-150 kHz.",
  "movementsHomeRangeAndSocialOrganization": "Maghreb Leaf-nosed Bats may roost in large colonies of up to 1000 individuals. Roosting colonies include adult males and females. At one cave in Nigeria , males apparendy dispersed away from a large colony at the time of parturition, effectively resulting in the cave forming a maternity roost for the remaining females.",
  "statusAndConservation": "Classified as Least Concern on 7%♂ IUCN Red List. Due to its wide distribution and large populations, the Maghreb Leaf-nosed Bat is unlikely to become threatened in the near future.",
  "bibliography": "Aellen (1952) | Bernard & Happold (2013b) | Harrison & Bates (1991) | Hill (1963a) | Koopman (1989) | Koopman et al. (1995) | Nader (1982) | Vallo et al. (2008) | Van Cakenberghe et al. (2017)",
  "distributionImageURL": "",
  "verbatimText": "61. Maghreb Leaf-nosed Bat Hipposideros tephrus French: Phyllorhine cendrée I German: Maghreb-Rundblattnase / Spanish: Hiposidérido de Magreb Other common names: Ash Gray Leaf-nosed Bat Taxonomy. Hipposideros [sic] tephrus a  brera, 1906 , Mogador , Morocco . Hipposideros tephrus belongs to the ruber species group. It was previously considered a subspecies of H. coffer. Monotypic. Distribution. Extent of this species’ distribution is not yet known; recorded with certainty in Morocco , Senegal , Saudi Arabia , and Yemen . It is thought to be continuously distributed from Mauritania and Senegal E to South Sudan , Ethiopia , and Eritrea . However, boundary between this species and the morphologically identical H. coffer is not known . Descriptive notes. Head-body 45-50 mm, tail 27—35 mm , ear 12—15 mm , hindfoot 6-9 mm. The Maghreb Leaf-nosed Bat has short, rounded wings. Muzzle is relatively short, with large but simple noseleaf that has two lateral leaflets. A frontal sac is present. Intemarial septum is not swollen and does not partially cover the nares. Ears are separate, and relatively small. Fur is fine and fluffy, gray or brown gray dorsally, paler ventrally; an orange morph also occurs that is typically reddish golden. Habitat. Inhabits riparian forest in arid savanna and woodland. Occurs in the Sahel zone and further south in Sudanian savanna. Food and Feeding. The Maghreb Leaf-nosed Bat is likely to be insectivorous. Breeding. Based on observations in northern Nigeria (which probably refer to this species), a single young is bom in a restricted season: mating appears to take place in November at the end of the rainy season, with births in late April at the beginning of the rainy season. Females lactate for two months, until late June. Activity patterns. The Maghreb Leaf-nosed Bat roosts in a variety of situations including caves, and holes in the ground. Echolocation call includes a F component at c.140-150 kHz. Movements, Home range and Social organization. Maghreb Leaf-nosed Bats may roost in large colonies of up to 1000 individuals. Roosting colonies include adult males and females. At one cave in Nigeria , males apparendy dispersed away from a large colony at the time of parturition, effectively resulting in the cave forming a maternity roost for the remaining females. Status and Conservation. Classified as Least Concern on 7%♂ IUCN Red List. Due to its wide distribution and large populations, the Maghreb Leaf-nosed Bat is unlikely to become threatened in the near future. Bibliography. Aellen (1952), Bernard & Happold (2013b), Harrison & Bates (1991), Hill (1963a), Koopman (1989), Koopman et al. (1995), Nader (1982), Vallo et al. (2008), Van Cakenberghe et al. (2017)."
}
]


Play Audio In headphones from SD card using AMB82 mini

Hardware Environment
Amb82 mini
Related technical area
Audio
Is the feature request related to an un-fixed issue?
Yes
Describe the ideal solution/reault/output.
I have an amb82 mini board, I have connected audio jack to DAC and GND Pin and successfully streamed audio from vlc player of my laptop to my headphones connected to audio jack. Now I have an audio file , for example audio.mp3 placed in root directory of my sd card. I want that sd card audio file to play on headphones.
Additional remarks
I have an amb82 mini board, I have connected audio jack to DAC and GND Pin and successfully streamed audio from vlc player of my laptop to my headphones connected to audio jack. Now I have an audio file , for example audio.mp3 placed in root directory of my sd card. I want that sd card audio file to play on headphones.
I have checked existing/closed list of issues and the Contributing Guide.

[X] I confirm I have checked existing/closed list of issues and the Contributing Guide.

same request here, I need to play back some sound/voice files stored in SD card.

@h4hassanali seems like  this is a duplicate of #210
Let us close this issue and discuss in #210


does not work

hi
I installed the extension with config but it does not seem work at all.. any help ?

The extension doesn't require any config, it should use the compiled files that dbt generates.
Without any further insight in your setup it would be difficult to give you any hints (Win-Linux-Mac?, Docker/WSL?).

Thanks for you reply. sorry, I did not provide much details.
I am using Visual Studio Code and installed dbt power user extension in Win10.
I mean I associated  .sql files with the jinja-sql language by configuring in Preferences > Settings for configuration.


userspace: Additional checks in K_SYSCALL_MEMORY

This macros needed additional checks before invoking arch_buffer_validate.

size has to be greater than 0 since 0 is documented as undefined behavior.
We need to check for possible overflow, since a malicious user application could use a negative number that would be promoted to a big value that would cause a integer overflow when adding it to the buffer address, leading to invalid checks.

Hmm. So some of APIs actually allow passing in a zero length (e.g. the EEPROM API) and this is tested (in test_zero_length_write, which now fails the test case due to these changes).

Hmm. So some of our APIs actually allow passing in a zero length (e.g. the EEPROM API) and this is tested (in test_zero_length_write, which now fails the test case due to these changes).

the problem is that arch_buffer_validate is a low level API and AFAIU in some architectures size 0 is undefined behavior. Let me check these particular use cases.

@henrikbrixandersen I end up adding a redundant check in these APIs since I think it is better to have that 0 length check in that macro to avoid any undefined behavior.

@henrikbrixandersen I end up adding a redundant check in these APIs since I think it is better to have that 0 length check in that macro to avoid any undefined behavior.

There are many api's having the same problem with the length 0 check (flash, bbram, retained_mem, ...). It would be better to correct it at the arch_buffer_validate level.

@henrikbrixandersen I end up adding a redundant check in these APIs since I think it is better to have that 0 length check in that macro to avoid any undefined behavior.

There are many api's having the same problem with the length 0 check (flash, bbram, retained_mem, ...). It would be better to correct it at the arch_buffer_validate level.

if we change arch_buffer_validate to return false we will end up with the same problem, ultimately what it means to try to read / write from a 0 length memory ?
I can remove the  > 0  check there and continue how it is now, since the visible problem is mostly with huge or negative length that causes an overflow. But the fact that 0 length buffers can lead to undefined behavior in that function is really scary

@henrikbrixandersen I end up adding a redundant check in these APIs since I think it is better to have that 0 length check in that macro to avoid any undefined behavior.

There are many api's having the same problem with the length 0 check (flash, bbram, retained_mem, ...). It would be better to correct it at the arch_buffer_validate level.

if we change arch_buffer_validate to return false we will end up with the same problem, ultimately what it means to try to read / write from a 0 length memory ?

Writing/reading with 0 length memory in all cases I know means: do nothing. A well written driver will  not do anything in this case. In practice this will never be used. I don't understand why all drivers try to catch this early, this is just extra code that is never used in practice.

@henrikbrixandersen I end up adding a redundant check in these APIs since I think it is better to have that 0 length check in that macro to avoid any undefined behavior.

There are many api's having the same problem with the length 0 check (flash, bbram, retained_mem, ...). It would be better to correct it at the arch_buffer_validate level.

if we change arch_buffer_validate to return false we will end up with the same problem, ultimately what it means to try to read / write from a 0 length memory ?

Writing/reading with 0 length memory in all cases I know means: do nothing. A well written driver will not do anything in this case. In practice this will never be used. I don't understand why all drivers try to catch this early, this is just extra code that is never used in practice.
The arch_buffer_validate routine should accept len = 0 for any void *data. With data = NULL it should only accept len = 0.

I have dropped the check "> 0"  since there are APIs relying on it. Instead I changed ">= 0" that fix the real problem because some functions invoke this macro using signed type which will be promote to unsigned when invoking arch_buffer_validate.

@ceolin This change seems to have triggered many Coverity CID issues.

Same for me, size is usually unsigned.


test: update integration tests to check non-public schemas

This includes a big refactor on the integration test, to make it modular for multiplexing the workflow against various test cases.
This PR is missing the following, which may be just filed as separate issues:

Parallelization of the integration tests - this needs some thought (especially on how to collect all the output in a legible way)
Finishing up the Exodus tests - they won't pass in the current state because we do a total dump comparison between the source and destination. Exodus implies that only a subset of data gets migrated, so the test needs to support that.

Related to #398 and #397

#405 #404 were filed to address later.


[Sprint: 48, backport] XD-3023: Restore SSL to RabbitMessagBus

JIRA: https://jira.spring.io/browse/XD-3023
Prior to XD-2381, XD had its own version of RabbitConnectionFactoryBean, which
predated the Spring AMQP version.
XD-2381 switched the bus to use the Spring AMQP version but the configuration of
useSSL and sslProperties was lost (the XD version of the FB injected these
properties using @Value injection).
Restore these properties via the ConnectionFactorySettings configuration bean.
cherry-pick to 1.1.x

Rebased, merged.
master: https://github.com/spring-projects/spring-xd/commit/33d048892ce7959c892458cff87a2877b0ab8dfd
1.1.x: https://github.com/spring-projects/spring-xd/commit/1401b8bd28ac7fa297b3376a509e6a8dd88cb689


multicast-dns@5

Looks like there were no breaking API changes between v2 and v5.

all your prs out in 1.8.0 - i've added you as collab as well

Nice!
On Sun, Feb 14, 2016 at 02:58 Mathias Buus<EMAIL_ADDRESS>wrote:

all your prs out in 1.8.0 - i've added you as collab as well
—
Reply to this email directly or view it on GitHub
https://github.com/mafintosh/chromecasts/pull/18#issuecomment-183873923.


Introducing priors to convolutional dictionary learning

I'm using convolutional dictionary learning on noisy vibrational spectroscopy signals. I was wondering if it might be possible to modify ConvBPDNDictLearn with a regularization term, to enforce certain priors on the atoms? For example, we might be interested in setting the boundaries of the atoms to zero (to learn peak-like features), or have non-negative atoms. If so, how would I go about doing that? Thanks!

That shouldn't be too difficult. There are two main components to setting this up:

Define a custom convolutional dictionary update solver derived from sporco.admm.ccmod.ConvCnstrMODBase or sporco.fista.ccmod.ConvCnstrMOD.
Define a custom convolutional dictionary learning solver that incorporates the custom dictionary update solver.

For step 1, all you need to do is derive a custom solver class (from sporco.fista.ccmod.ConvCnstrMOD might be the simplest option) that overrides the eval_proxop method (or the ystep method if you're using one of the solvers in sporco.admm.ccmod) to enforce your custom requirements such as non-negativity of the atoms. Of course, this assumes that all of your additional priors can be implemented via a single proximal operator (which is fine for the non-negativity, for example). If this isn't the case, then the modifications could be substantially more involved, probably not possible using using the FISTA solver, and requiring a more complicated splitting for the ADMM solver.
For step 2, you could either derive a custom CDL solver from sporco.dictlrn.cbpdndl.ConvBPDNDictLearn, overriding the __init__ method so that the dstep attribute is an instance of your custom dictionary update solvers defined in step 1, or follow the example script showing how to use sporco.dictlrn.DictLearn as a generic dictionary learning solver.
Feel free to follow up if you run into problems or have any additional questions.

Closing the issue on the assumption that the question is resolved. Please re-open if you have additional questions.


Consider block expansion when looking for tokens on the same line

Need some more test cases for rules that look for tokens on the same line

This is going to need column numbers in jade-lexer to be released

v2.0.3 has started progress towards closing this issue


Get all view previews working

Some work, some don't.
Maybe due to way data is loaded for the previews.

PhotoClubsView doesn't work yet

PhotographersView is the only one that is still broken


Universal build not generated

According to the doc to manually setup Expecta, a build/Release-ios-universal path is created with the universal lib.
It seems it is not doing so, and only the iphoneos and iphonesimulator are created.
If it helps anybody with this issue, in order to do so, lipo can be used from /expecta/build:
lipo -create -output ./libExpecta.a ./Release-iphoneos/libExpecta.a ./Release-iphonesimulator/libExpecta.a

Hi @andres-ciano it looks like master currently requires the use of xcpretty as part of its build scripts. We're looking at making that optional, but in the meantime installing the xcpretty tool should generate the universal libraries you need. Sorry about this!

@tonyarnold
I think the README is incorrect.
The final destination for the framework is Products/ios/Expecta.framework.
Locally, I am seeing universal binaries created:
$ lipo -info Products/ios/Expecta.framework/Expecta
Architectures in the fat file: Products/ios/Expecta.framework/Expecta are: i386 x86_64 armv7 arm64
$ lipo -info Products/ios/libExpecta.a
Architectures in the fat file: Products/ios/libExpecta.a are: armv7 i386 x86_64 arm64

re: xcpretty I wondered about that.  I did see, however that the rake test task was using xcpretty already, so I made a bad assumption.

@tonyarnold
RE: the README - I will make a pull request on the README to show you where I think it is incorrect.

This is merged, closing :+1:


feat: add ui-predicate (rules editor)

Generic UI component to build ui-predicates (demo in storybook), like there:

See other well-known UIs that could be implemented using only ui-predicate :)

@kazupon oh! sorry! Updated :)


CocoaPods could not find compatible versions for pod "OneSignal"

Description:

In android the integration was successful. however in iOS after adding below line in podfile
pod 'react-native-onesignal',
:path => "../node_modules/react-native-onesignal/react-native-onesignal.podspec",
:inhibit_warnings => true
I am getting this error after pod install
[!] CocoaPods could not find compatible versions for pod "OneSignal":
In Podfile:
react-native-onesignal (from ../node_modules/react-native-onesignal/react-native-onesignal.podspec) was resolved to 3.2.12, which depends on
OneSignal (= 2.9.4)
None of your spec sources contain a spec satisfying the dependency: OneSignal (= 2.9.4).
Environment

"react-native-onesignal": "^3.2.12"
added it using npm and linking it with cocoapods

Steps to Reproduce Issue:

1.npm install --save react-native-onesignal
2. add this line to pod file
pod 'react-native-onesignal',
:path => "../node_modules/react-native-onesignal/react-native-onesignal.podspec",
:inhibit_warnings => true
3. run 'pod install'
Anything else:
(crash stacktraces, as well as any other information here)

@cfmitrah Please try to cd into the /ios directory and run pod repo update.
If that does not work, please post your Podfile

for any fellow travelers,
-->> https://github.com/OneSignal/OneSignal-Flutter-SDK/issues/55#issuecomment-459369818

I am getting this error:
[!] CocoaPods could not find compatible versions for pod "OneSignal":
 In Podfile:
 react-native-onesignal (from `../node_modules/react-native-onesignal`) was resolved to 3.4.2, which depends on
 OneSignal (= 2.11.2)

/bin/bash failed with return code: 31
return code: 1
None of your spec sources contain a spec satisfying the dependency: `OneSignal (= 2.11.2)`.

You have either:
 * out-of-date source repos which you can update with `pod repo update` or with `pod install --repo-update`.
 * mistyped the name or version.
 * not added the source repo that hosts the Podspec to your Podfile.

Note: as of CocoaPods 1.0, `pod repo update` does not happen on `pod install` by default.

When I run the following commands in Azure DevOps:
cd ios && rm Podfile.lock && pod deintegrate && cd .. && rm -rf node_modules && rm package-lock.json && npm install && cd ios/ && pod install && pod repo update
Is this too aggressive? Do I not need to run rm Podfile.lock && pod deintegrate? Would pod install be sufficient for a CI build tool configuration?


Grafana 10 Navigation Panel customization for Apps

Hi @mikhail-vl , sorry for the "wrong" use of Github's issues but I wanted to give back to your awesome project and tell you about something I just discovered.
In Grafana 10, they have re-organized and grouped some of the menus, like the Apps plugins under the "Apps" nav item.
Previously they showed in the root nav with a customized icon, which was (in my opinion) better, but you can still do it :
Basically you'll just have to edit the grafana.ini settings specifying in the navigation.app_sections the id of your app and the id of the menu (in my case, root, which is as before in the main navigation-menu), and optionally the weight.
[navigation.app_sections]
myorg-basic-app = root
myorg-dashboard-app = root -9999

You can find the ""documentation"" in this discussion right here.
https://github.com/grafana/grafana/discussions/58910#discussioncomment-5864203
Hope that'll help you with some of your customizations.
Thanks again for your awesome work and enormous amount of useful help and informations.

@centenico Thank you for letting us know. I was looking for it.
The official answer from the Grafana team was it was impossible to do. Looks like it's not anymore.
If you can edit it in the grafana.ini it should be possible to do with environment variables like
GF_NAVIGATION_APP_SECTIONS_myorg-basic-app=root

I will try and include it in the customization documentation.

Glad to have been helpful!
Have a good day.

@centenico Thank you!
The environment variable did not work. I updated configuration directly in the Dockerfile:
RUN sed -i 's|\[navigation.app_sections\]|\[navigation.app_sections\]\nvolkovlabs-app=root|g' /usr/share/grafana/conf/defaults.ini