Cwac cam2

The camera preview is stretching on orientation change from portrait to landscape using cwac cam2 version 4.0 . How to resolve the issue. Don't want the activity recreation on orientation change.

The camera preview is stretching on orientation change from portrait to landscape using cwac cam2 version 4.0 .

There is no version 4.0 of this library.
Beyond that, please follow the contribution guidelines and provide:

the Build.MANUFACTURER and Build.PRODUCT values for the hardware on which you are experiencing the problem
the code necessary to reproduce the problem (this could be one of the demo apps, or it could be some demo project of yours that you publish)
the steps necessary, using that code and that hardware, to reproduce the problem

I have placed  'com.commonsware.cwac:cam2:0.4.+'
in the gradle file. I am attaching the file for the code.
CustomFragment.docx
Manifest file.docx

Device Details:
Name : HTC 620G
O/S: Android Kitkat
Steps:

Open the application camera will open.
Now change the orientation from portrait to landscape or vice versa.
Look at the camera preview. You will experience the issue.

Please find the entire demo application which I have developed.
CameraDemoApplication.zip

As is noted in the documentation, I do not offer support for internal APIs ("While there are other public classes and methods in the library, ones that may be exposed as part of a public API in the future, they are not supported at the present time.").
If you can reproduce the problem using the documented and supported API, using the existing activities and fragments without modification, write back with instructions, and I can take a look at it and possibly reopen this issue.

Yes, If you try to change the orientation the black page comes then camera preview is oriented.Basically it destroys the view and recreate once again. I don't want to destroy the view.

Yes, If you try to change the orientation the black page comes then camera preview is oriented

I appear to have introduced a bug somewhere along the line, where dynamic configuration changes are broken on v0.6.0. Follow issue #217 for that.

I don't want to destroy the view.

You are welcome to write you own code using the camera API to do what you want. While I will work on fixing the bug from issue #217, how I fix that is my decision.


Tr/fix test warnings

Purpose
Fix warnings in tests
Fix warnings in tests, except for the find_restart warning, because fixing it causes the downgrade test to fail
Closes #901
To-do
I believe the following documentation that has an example use of common_diagnostics
is incorrect because it does not include a reference_date or start_date:
https://github.com/CliMA/ClimaLand.jl/blob/e6dedef548b213a4d6d755ae67bcd4ee224e9a3f/docs/src/diagnostics/users_diagnostics.md?plain=1#L120-L127
https://github.com/CliMA/ClimaLand.jl/blob/e6dedef548b213a4d6d755ae67bcd4ee224e9a3f/docs/src/diagnostics/developers_diagnostics.md?plain=1#L105-L113
common_diagnostics is called as:
function common_diagnostics(
    period,
    reduction,
    output_writer,
    start_date,
    short_names...;
    pre_output_hook! = nothing,
)

Content

Replace deprecated reference_date arg
The ClimaUtilities DataHandler, TimeVaryingInput, and EveryCalendarDtSchedule
function were called with reference_date as an argument, which is
deprecated. This commit replaces them with start_date, and replaces
other uses of reference_date as an arg to functions that pass the arg
to EveryCalendarDtSchedule.
Fix deprecated call to detect_restart_file
Fix warning in test for unused type declaration

[x] I have read and checked the items on the review checklist.

I believe the following documentation that has an example use of common_diagnostics
is incorrect because it does not include a reference_date or start_date:

I think you're right - could you update the calls in docs/ to take in start_date as part of this PR too?


MIROC6-tasmax.yaml fails clean-cmip6 validation with bad tasmax values for ssp126, ssp245, ssp370, ssp585

MIROC6-tasmax.yaml fails its end-to-end run in the clean cmip6 workflow with bad validation for the tasmax variable.
This is from run https://argo.cildc6.org/workflows/default/e2e-miroc6-tasmax-rnd98
Blocking progress on run #191
Log from ssp585:
Validating gs://clean-b1dbca25/cmip6/ScenarioMIP/MIROC/MIROC6/ssp585/r1i1p1f1/day/tasmax/gn/v20191016.zarr
Traceback (most recent call last):
  File "/argo/staging/script", line 44, in <module>
    tasks = dask.compute(*tasks)
  File "/opt/conda/lib/python3.9/site-packages/dask/base.py", line 570, in compute
    results = schedule(dsk, keys, **kwargs)
  File "/opt/conda/lib/python3.9/site-packages/dask/threaded.py", line 79, in get
    results = get_async(
  File "/opt/conda/lib/python3.9/site-packages/dask/local.py", line 507, in get_async
    raise_exception(exc, tb)
  File "/opt/conda/lib/python3.9/site-packages/dask/local.py", line 315, in reraise
    raise exc
  File "/opt/conda/lib/python3.9/site-packages/dask/local.py", line 220, in execute_task
    result = _execute_task(task, data)
  File "/opt/conda/lib/python3.9/site-packages/dask/core.py", line 119, in _execute_task
    return func(*(_execute_task(a, cache) for a in args))
  File "/argo/staging/script", line 29, in clear_memory_intensive_tests
    _test_temp_range(d, v)
  File "/opt/dodola/dodola/core.py", line 684, in _test_temp_range
    assert (ds[var].min() > 150) and (
AssertionError: tasmax values are invalid

Similar errors in logs for other ssps zarrs:
gs://clean-b1dbca25/cmip6/ScenarioMIP/MIROC/MIROC6/ssp126/r1i1p1f1/day/tasmax/gn/v20191016.zarr
gs://clean-b1dbca25/cmip6/ScenarioMIP/MIROC/MIROC6/ssp245/r1i1p1f1/day/tasmax/gn/v20191016.zarr
gs://clean-b1dbca25/cmip6/ScenarioMIP/MIROC/MIROC6/ssp370/r1i1p1f1/day/tasmax/gn/v20191016.zarr

Closed with PR #365


chore: Convert new relic integration views TestCase to normal test function

Thanks for submitting a PR! Please check the boxes below:

[x] I have run pre-commit to check linting
[ ] ~I have added information to docs/ if required so people know about the feature!~
[x] I have filled in the "Changes" section below?
[x] I have filled in the "How did you test this code" section below?
[x] I have used a Conventional Commit title for this Pull Request

Changes
I'm working through re-writing the TestCase classes into normal test functions. Rewrote the existing TestCase and replaced with fixtures instead of recreating everything. There are other PRs that are similar to this one.
How did you test this code?
I manually changed the tests one at a time to refactor them as I went then ran the full test suite afterwards. Also, I added assertions where I thought more were needed, for example missing response.data checks.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (37831a8) 95.99% compared to head (a6a103d) 35.45%.

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #3293       +/-   ##
===========================================
- Coverage   95.99%   35.45%   -60.54%
===========================================
  Files        1068      995       -73
  Lines       32721    28901     -3820
===========================================
- Hits        31411    10248    -21163
- Misses       1310    18653    +17343

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


Update Character “bass-note”

Automatically generated by Netlify CMS

👷 Deploy Preview for dynamic-cheesecake-5fbd8b processing.

Name
Link

🔨 Latest commit
aff3df517dd66083b143abf2130f8bd4b5b87aad

🔍 Latest deploy log
https://app.netlify.com/sites/dynamic-cheesecake-5fbd8b/deploys/62ec31a4dae5440009d54024


Consider expanding short-urls using api's instead of HTTP

According the the goo.gl url-shortener docs, discussing why use the API to expand urls instead of just making the request:

Of course, you could also just fetch http://goo.gl/fbsS and inspect the Location header in the response, but using the API has two advantages:

It won't update the short URL's click stats, so you can fetch a bunch of long URLs without worrying about messing up analytics.
If the URL fails to redirect (for example, if Google believes it points to malware), you'll get a machine-readable explanation of why.

..thinking through it, the URL which is returned may still redirect, so this doesn't fully alleviate the problem.

The reason why it's using redirect is because we want to support other URL shorteners.

Yes, and ordinary server redirects, so this is never going to be a full solution.
However, if we wanted to not impair the analytics of the urls we shorten, this is an option.

Closing since I think there is no action item.


Changes awsAccount to be and array awsAccounts.

Related to: https://issues.redhat.com/browse/APPSRE-6586
With this change we facilitate the run of pr-checks using the same image for several accounts. That will improve the build time for PRs and reduce the use of resources.

LGTM
Can you add a validation that there are items in the list? minItems IIRC

Done.


301 redirects and CORS issues

I'm getting the following error making request :(
I'm following guidelines set in the fetch api spec... any clue how to get around this?

XMLHttpRequest cannot load http://localhost:3000/auth/facebook?code={thecode} Redirect from 'http://localhost:3000/auth/facebook?code=[thecode]' to 'http://localhost:3000/omniauth/facebook?code=A[thecode]&resource_class=User' has been blocked by CORS policy: Request requires preflight, which is disallowed to follow cross-origin redirect.

# config/initializers/cors.rb
Rails.application.config.middleware.insert_before ActionDispatch::Static, Rack::Cors do
  allow do
    origins '*'

    resource '*',
      headers: :any,
      resource: '*',
      expose:  ['access-token', 'expiry', 'token-type', 'uid', 'client'],
      methods: [:get, :post, :put, :patch, :delete, :options, :head]
  end
end

You should need just rack-cors gem. Try to move the initialization to config/environments/development.rb:
 config.middleware.insert_before 0, Rack::Cors do
    allow do
      origins '*'
      resource '*',
          :headers => :any,
          :methods => [:get, :post, :delete, :put, :options],
          :expose  => ['access-token', 'expiry', 'token-type', 'uid', 'client'],
          :max_age => 0
    end
  end

Moreover enabling this in production is quite dangerous.

I'm having this issue too.
# config/initializers/cors.rb
config.middleware.insert_before ActionDispatch::Static, Rack::Cors do
  allow do
    origins '*'
    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options, :head]
  end
end

I've also tried the one mentioned above and no luck. Any other suggestions?
Thanks!

If anyone has a solution to this, I'm also experiencing it. It isn't holding up my development, but it'd be handy to have a workaround. I've seen references to setting the headers: to any, as it is in the code pasted above, but that doesn't seem to be fixing anything.

Hey, anyone found a solution to this? Seems like all my apps in development/production started facing this issue a couple of days ago. Have tried with all sorts of CORS settings but to no avail. In my logs it just shows:
INFO -- omniauth: (facebook) Callback phase initiated.
ERROR -- omniauth: (facebook) Authentication failure! invalid_credentials: OAuth2::Error,

+1, I also encounter this problem.
Redirect from 'https://www.facebook.com/v2.6/dialog/ ...' to  'https://www.facebook.com/login.php?...' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.


Update Alpine 3.10 -> 3.11; update pip, tzdata, gunicorn

In this PR I updated the Dockerfile from Alpine 3.10 to 3.11. Additionally pip was updated to avoid the error message of the outdated pip version. To set the correct local timezone (environment variable "TZ" must be set) tzdata was added.
Due to the bug (https://github.com/benoitc/gunicorn/issues/2091) I also had to update gunicorn.
Please test before merging.

I tested it. LGTM. Merging your PR.  Thanks for your contribution.


[WIP/Feedback] Design BigchainDB HTTP API v0.9

This morning @diminator and @sbellem had a discussion about the BigchainDB HTTP API.
From the discussion, the conclusion was drawn that in order to properly design the API, we should - instead of iteratively - a single document outlining the individual calls using HTTP as this methodology:

provides a better overview of actual endpoints to be implemented; and
allows us to plan and split tasks more efficiently.

Hence, for the rest of the day I hacked together a first draft of what the BigchainDB HTTP API could look like.
How to review
When your reviewing, see this rather as a proposal. It's here to be discussed with everyone. Things can and will change.
A few things upfront though:

All paths, responses, status codes, headers were assigned according to widely-accepted specifications and heuristics. Suggestions like: "I prefer X to be like schema Y" is therefore only acceptable as feedback if founded on a credible source (specification > blog posts  and so on - obviously!)
Reasoning for changes is provided in the message section of the commits. Read them.
The diff of the .rst file will very likely not give you a good overview of the changes. Pull the changes from this branch and render them in sphinx for reviewing/reading.

When merging this PR, we should have an HTTP API everyone is happy with :tada:.
Higher-level decisions taken in this proposal
All endpoint names use the plural of the resource name
Countering "endpoint madness"
A very simple rule:

Any entity that is retrievable with a unique key has its own top-level endpoint.

This only makes sense as REST mainly implements pathing after the following scheme:

/resource: List endpoint
/resource?manipulator=X: Filtered/manipulated list endpoint
/resource/id: Single endpoint
/resource/id?manipulator=X Filtered/manipulated single endpoint

Concretely, this means the following resources will have a top-level endpoint:

blocks
votes
transactions
statuses
assets
metadata

Keep in mind: Best practices advise strongly for a flat path hierarchy.
"But, Fulfillments and Conditions should have their own top-level endpoints!"
Theoretically they could. In fact, we could pretend that a condition's or fulfillment's unique key of retrieval is their URI. This would enable the following endpoints:

GET /conditions
GET /conditions/uri
GET /fulfillments
GET /fulfillments/uri

However, there has yet to be a use case found, where a HTTP API user would benefit from this. Hence in this proposal I thought about it, but didn't include it in the design.
~Retrieval of specific fields in a resource~
~I followed this very popular guide:~

~Limiting which fields are returned by the API~
~The API consumer doesn't always need the full representation of a resource. The ability select and chose returned fields goes a long way in letting the API consumer minimize network traffic and speed up their own usage of the API.~
~Use a fields query parameter that takes a comma separated list of fields to include. For example, the following request would retrieve just enough information to display a sorted listing of open tickets:~
~GET /tickets?fields=id,subject,customer_name,updated_at~

Changes made to the current HTTP API
201 Created for POST /transactions becomes 202 Accepted
https://www.ietf.org/rfc/rfc2616.txt 10.2.2 201 Created reads:

The origin server MUST create the resource before returning the 201 status code.

Since a transaction is not created before the POST request returns, we cannot use status code 201 to respond to the request. However (same document) 10.2.3 202 Accepted reads:

The request has been accepted for processing, but the processing has not been completed.
The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

Using the HTTP Location header, we redirect the client to the status endpoint to ask for the status of the creation.
Once the resource has been created, we use HTTP code 303 See Other, to notify the client about the updated resource and, using the  Location header, link back to the actual transaction /transactions/txid.
/transaction/{txid}/status becomes /statuses

The plural of status is statuses
/transaction/{txid}/status is not a RESTful path
Statuses do not only occur on transactions. In fact, a status is derived from a block, a transaction just inherits it from the block.

Therefore, an endpoint /status was introduced that allows to query any entity that is retrievable by a unique ID (block, transaction, asset, metadata, votes(not sure)).
Things to be done

[ ] Get feedback
[x] Find solution to the /unspents endpoint-problem
[x] Block retrieval by ID
[x] Block retrieval by transaction
[x] Asset retrieval by ID
[x] Asset list retrieval
[x] Asset history retrieval
[x] ~Metadata retrieval by ID~
[x] Include related context in statuses response (type, related resources)
[x] ~Votes retrieval by ID (use case missing)~
[x] Votes retrieval by Block ID
[x] Outline how to retrieve the timestamp of the block containing the transaction
[ ] Outline how to retrieve the timestamps of the votes for a certain block
[x] Consider resolvement of #835 (remove ?fields query strings)
[x] Consider changes made in #856 (remove metadata.id)
[x] ~Consider implementing get_spent functionality~
[x] Consider timestamp removal made in #817
[x] Consider resolving #906
[x] Consider changes made in #925 (Inputs and Outputs)
[x] Consider changes made in #945 (remove owners_before)
[x] Consider changes made in #963 (rename owners_after)

Things to better be discussed later

Sorting (timestamps are influx right now)
Pagination (easy to add later on)
How this proposal relates to a Interledger Common Web API (this is the BigchainDB™ API, lets separate concerns for now)
Retrieval of full blocks vs hyperlinked versions see comment
Websockets: see issue #862
Client-defined queries and indices see comment

Assuming the client-provided timestamp gets removed from the Transaction data model (via pull request #817), clients will want some way to get the other timestamps associated with a transaction:

the timestamp of the block containing the transaction
the timestamps of the votes on that block

I'm not sure how to design the endpoints to get those timestamps.

Assuming the client-provided timestamp gets removed from the Transaction data model (via pull request #817), clients will want some way to get the other timestamps associated with a transaction:

I've included these two requirements into the TODOs of this PR (original post).
Thanks.

Current coverage is 96.88% (diff: 100%)

Merging #830 into master will increase coverage by 0.15%

@@             master       #830   diff @@
==========================================
  Files            26         26
  Lines          1683       1700    +17
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           1628       1647    +19
+ Misses           55         53     -2
  Partials          0          0

Powered by Codecov. Last update 795467c...96d1f38

Retrieval of specific fields in a resource
I followed this very popular guide:
Limiting which fields are returned by the API
The API consumer doesn't always need the full representation of a resource. The ability select and chose returned fields goes a long way in letting the API consumer minimize network traffic and speed up their own usage of the API.
Use a fields query parameter that takes a comma separated list of fields to include. For example, the following request would retrieve just enough information to display a sorted listing of open tickets:
GET /tickets?fields=id,subject,customer_name,updated_at

See ticket #835. We cannot return partial payloads as long as we don't provide parts of a merkle tree for validation.
I'd propose, we remove the ?fields query string for now and return only full transactions.
When we're more advanced, we can add partial payloads by including merkle trees or eventually just use IPLD out of the box.
OK: @sbellem @diminator?

I'd propose, we remove the ?fields query string for now and return only full transactions.

:+1:

I'd propose, we remove the ?fields query string for now and return only full transactions.
When we're more advanced, we can add partial payloads by including merkle trees in a response or eventually just use IPLD out of the box.

Yes, agreed, and for the time being we can suggest to those really interested in more powerful querying capabilities, to pipe the data into a data store they control and/or trust which can support the advanced querying needed.
In other words, we can suggest that BigchainDB can be part of an ETL architecture, as the initial source of trusted data. The rest of the pipeline is the hands of the user.

Here is a fun little problem:
The whole purpose to have this query:
/transactions?fulfilled=false&owners_after={owners_after}
is to allow a client to figure out what unfulfilled conditions are left to fulfill for a certain public (owners_after) and respective private key.
Before, the combination of ?fields=conditions,txid and fulfilled=false, would have taken care of filtering the list transactions.conditions to a subset of conditions that were actually not fulfilled yet.
In #830, we realized that partial payloads are harder to verify though, meaning an expansion of conditions as well as its filtering for unfulfilled conditions cannot happen.
As a result, we're now returning a full transaction payload.
Now the problem with this is that a transaction can have for example (or any other combination):

1 fulfilled condition; and
N unfulfilled condition.

by requesting: /transactions?fulfilled=false&owners_after={owners_after}, we're hence not sending information about unfulfilled conditions anymore, meaning the request doesn't serve the use case anymore.
In #803 that exact problem was solved in a different way.
An endpoint /unspents was introduced that essentially returns the URL equivalent of a TransactionLink. From the standpoint of cryptographic-verification and RESTfulness, that endpoint was alright.
Now, it was however criticized for:

introducing a new top-level endpoint (an intermediate table) (/unspents)
using a language, we'd like to get rid of: unspents
introducing overhead in that it would take two requests to get the same information (txid, cid, and the condition itself)

The fact is though, in order to fulfill a condition in a TRANSFER transaction, we need exactly three pieces of information that one or multiple endpoints will have to deliver:

txid
cid
the condition itself

Therefore, I'd like to address the initial criticisms to reintroduce the endpoint again.
A few things up front:

Essentially we're returning a TransactionLink resource (it's pretty hard to run away from that fact tbh)
An adjective cannot be part of a resource name, but must always be a query parameter (e.g. /unfulfilled_conditions is embarrassingly unRESTful)
A TransactionLink is not a condition, in no way does it fit under /conditions
/conditions?fulfilled=false&owners_after={owners_after} isn't fulfilling the use case (there is no way of telling to which transaction the condition belongs + no cryptographic-verification can be provided)
Essentially TransactionLink links two transactions, but de-facto it really points from a fulfillment to a condition (we don't use it in any other way)

A few proposals:

Keep using /unspents

It's a known concept in the Blockchain world
It describes what you're actually getting
It's a noun
It cannot be retrieved by a unique key

/links

it's a noun
It's non-"intuitive", meaning a concept that is specific to BigchainDB
It describes what you're getting

/transactionlinks

It's two words mashed together (all cases should be avoided in the path, no _ or Ls

It's specific to BigchainDB

/transactions/links

It's not a real RESTful path
It has the same problems as /transactionlinks
It shares a namespace with /transactions, you're not getting what you're expecting

/outputs?fulfilled=false

It's not specific to BigchainDB
It kinda describes what you're getting (even though the actual "output" it the condition itself - one could argue though that output != condition as an output is always the combination of: transaction + lock one needs to provide a key for)
it's not in line with the Interledger lingo

If you have better ideas, let me know. I'm currently leaning towards /unspents or /outputs.

Thoughts on how to name the endpoint to get links to all the unfulfilled conditions associated with a public key:
What we'd get back would be a set of TransactionLinks, i.e. a set of (txid, cid) pairs (maybe as URIs). Those really should be called ConditionLinks because they're links to specific conditions, not transactions. (I realize we have an internal class named TransactionLink but it could be renamed.)
The endpoint could be, for example:
/conditionlinks?fulfilled=false&owners_after={owners_after}
It could be seen as a "convenience endpoint" that exists to make life easier for users.

The endpoint could be, for example:
/conditionlinks?fulfilled=false&owners_after={owners_after}

Agreed, from a user point of view, you would be asking:
"which conditions have I yet to fulfill"
In bitcoin lingo it's the same as:
"which outputs can I spent - ie create an input for"
I would probably want to hide the "links" part as you could treat is as a Hyperlinked response
Hence I am pro:
/conditions?fulfilled=false&owners_after={owners_after}

An endpoint like:
/conditions?fulfilled=false&owners_after={owners_after}
suggests that you'll get back a list of condition objects, but those, by themselves, wouldn't say which transaction they're in (txid), or which condition in that transaction (cid). I think you need the txid and cid to build a fulfillment for a condition.
Also, as discussed in issue #835, it seems like we're leaning towards returning whole transactions, rather than just transaction parts (such as conditions). Returning a (txid, cid) pair isn't exactly a transaction "part" so much as a pointer to a full transaction and a hint where to look in that transaction for an unfulfilled condition.

suggests that you'll get back a list of condition objects, but those, by themselves, wouldn't say which transaction they're in (txid), or which condition in that transaction (cid). I think you need the txid and cid to build a fulfillment for a condition.

It actually gives you the locations of the conditions - as specified by (txid, cid), which are the absolute paths for that condition. So I guess that's allright

Asset retrieval by ID
Metadata retrieval by ID

I just thought about this.
Initially, I thought there would be the two endpoints:

/assets/{asset_id}
/metadata/{metadata_id}

Now, both IDs in usage here are just uuidv4. When retrieving an asset or meta data, the user cannot check the payload, meaning the node could return something completely different then what was persisted. It's basically the same problem that was outlined in #835.
In noticed though, that with a little bit of query strings magic, these two endpoint's functionality can be used already:

/transactions?operation=CREATE&asset_id=1AAAbbb...ccc: Returns the original in the CREATE transaction (+ it's verifiable). Consensus of BigchainDB ensures us that it will always only return ONE asset.
/transactions?metadata_id={metadata_id} returns us a transaction including metadata of a certain id. Consensus ensures us, that there is always one of a kind persisted to the data.

As long as assets and metadata are not retrievable by their own hash therefore, we deliver them in the transaction itself. Implicitly, this means that for now there will be no /assets or /metadata endpoints returning ONLY the objects without the transaction.

Here is another question:
Is there any value in allowing the user to retrieve blocks labeled as INVALID?
For transactions, we say that only valid (or undecided) transaction's can be retrieved via the API.
This is due to the fact that a:

invalid transaction will never by included into a valid block
that a valid transaction will eventually end up in a valid block.

For blocks though, this obviously doesn't happen.
Blocks can be invalid, still they're part of the chain. They'll never get discarded.
Therefore, I'd like to argue that, in contrast to the retrieval of transactions, invalid blocks can be retrieved using the HTTP API.
Any thoughts on that?

Is everybody OK with that? Feedback? Please tell me if you have a better solution :).

I like this

the server through websockets

Agree.

the server through a /validate endpoint. The result is temporary - as the actual write occurs on a different time

:crying_cat_face:

REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol.

In fact, I was able to address the INVALID block question quite nicely. I'll update it to the commits, once I push them.

REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol.
In fact, I was able to address the INVALID block question quite nicely. I'll update it to the commits, once I push them

Afraid that doesn't solve the problem of users wanting to:

check if the transaction is valid before pushing to the network
check why the transaction was invalid after pushing to the network

check if the transaction is valid before pushing to the network

It's out of the scope of this PR (so I'd prefer if we discuss this somewhere else if necessary to discuss this further), but checking the validity of a transaction before pushing it to the network is part of the client's task.
The only thing the server can add to the validation of a transaction is to check for DoubleSpents (assuming we'll get rid of the uuid's in metadata and assets - which I think will happen).
Now, there is an argument to be made about if the server should expose functionality to check for "spents", as we right now only expose the reverse ("unspents" (lol btw., since we don't like to use the "spents" metaphor I think "DoubleSpents" is not appropriate anymore :D).
I think it should have a /spents-esque endpoint. If you want I can add it to the TODOs.

check why the transaction was invalid after pushing to the network

Websockets.

Now, there is an argument to be made about if the server should expose functionality to check for "spents",

What do you mean exactly here?
Getting every transaction that I ever spent?
Or getting the full spent history of an asset chain - starting at a certain transaction and going back in time?

the timestamp of the block containing the transaction

I was thinking about this a little bit.
I see two options here.
Option 1:
Outline in text how this is done doing a combination of calls on the API:

Call /transactions/tx_id to see if a transaction was included in a valid block
Call /blocks?tx_id=tx_id to see in which block the transaction was included
If a block was returned, use block.timestamp as the timestamp of the transaction.

This is already possible with the API that's being designed here, so it's just the question if we want to put this information-retrieval strategy into writting.
Option 2:
I looked into Custom HTTP Entity Headers.  Here is a definition:

Request and Response messages MAY transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header fields and an entity-body, although some responses will only include the entity-headers.

https://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html

This means, when doing a call to /transactions/tx_id, we could include a X-BigchainDB-Timestamp header into the response that would have been taken from the block.
The RESTful Cookbook gives useful advice:

Use custom headers for informational purposes.

In fact, the timestamp for a transaction is only informal. Per default the /transactions/tx_id endpoint only returns valid transactions meaning a timestamp should always retrievable.

Avoid using custom HTTP headers to change the behavior of HTTP methods

It doesn't change GET /transactions/tx_id's behavior.

If the information you are conveying through a custom HTTP header is important for the correct interpretation of the request or response, include that information in the body of the request or response or the URI used for the request. Avoid custom headers for such usages.

It's not. Any transaction returned is valid so any transaction has a timestamp. However a timestamp is not a vital part of a transaction. It can be completely ignored. In fact it can be ignored and Option 1. can be favored.
I'm leaning towards option 2. Still option 1 is and available and can be used if preferred.

There are some suggestions from @roderik and possibly others:

retrieve all asset (id's)
list the entire history of an asset
select or navigate in an asset: useful for selecting a specific event in a time series
order the asset history: since we do not rely on timestamps, a counter or timestamp could be provided by the client

Bonus points for

getting a list of assets with a json property matching x

I just realized that we should be thinking of owners_after more as like a parameter for a certain locking script that was persisted in a transaction.

Yes, this is part of the proposal to split up the attributes in an output script from the topology, the attributes are then good for indexing

select or navigate in an asset: useful for selecting a specific event in a time series

listener on asset, see #862

select or navigate in an asset: useful for selecting a specific event in a time series

can be done by simple client recipe (once ordering and pagination is provided)

getting a list of assets with a json property matching x

Custom indexing would be prohibitively complex, quoting @r-marques
"queryability and indexing are two different things. You can query data without it being indexed by a particular key. For instance mongodb has a hard limit of 64 secondary indexes and if you are using more then 20 you are probably doing something wrong. The overhead would just be to much"

Consider changes made in #856 (remove metadata.id)

metadata.id is removed, hence there is no specific ID to look for metadata besides the tx.id
Proposal to remove this endpoint? @TimDaub @libscott  @ttmc

Proposal to remove this endpoint? @TimDaub @libscott @ttmc

:+1:

I just got around to looking at the latest version of this proposal. Some comments:

For the GET /transactions endpoint, there's a proposal for a query parameter named fulfilled. Should that be changed to spent? I'm a bit confused about how our vocabulary has settled for version 0.9. Do "outputs get spent" or "conditions get fulfilled" or something else? @libscott can you comment?

There are a few places where the plural of transactions is written as "transaction's" (with an apostrophe) rather than "transactions", e.g. "A flag to indicate if transaction’s with fulfilled conditions should be returned."

Using the HTTP 303 See Other response for the status of a valid transaction/block seemed a bit odd at first, but on closer inspection, seems to be a good use of that standard.

I noticed some minor formatting and stylistic things that I would change, but it is not yet time to be bothering with such things.

The note at the top of the HTTP API docs page ("The HTTP client-server API is currently quite rudimentary...") can maybe be removed now.

getting a list of assets with a json property matching x

some steps for moving this forward:

provide an endpoint to get all assets: ie GET /transactions?operation=CREATE&is_asset=true, added the is_asset flag and one could narrow it further down by specifying public_keys
provide pagination (and maybe ordering, but that can be done client side)

suggestions @TimDaub ?

When returning a list of objects, do we return the full object or a url path to limit size? Imagine returning a list of blocks, blocks can be really big datastructures (with 1000+ transactions)... so that wouldnt be feasible to send in one go over the wire

Imagine returning a list of blocks, blocks can be really big datastructures (with 1000+ transactions)... so that wouldnt be feasible to send in one go over the wire

This relates to #835
For lists of URIs it would be possible to verify each object behind the URI separately, it becomes more tedious to verify that each URI belongs to the list...
comments? @TimDaub @ttmc @libscott @sbellem

Some notes:

Use Location in header or body? or both?
status code 303 might automatically redirect on the client, never showing the original response
does it make sense to have a single statuses for multiple objects?
include more info in the status: eg object type and related reference (for a tx, give the block_id if VALID
/votes/block_id isnt restful (using queryparams then yes). Alternative: /votes/vote_id is and /blocks/block_id/votes is restful.
asset list retrieval GET /transactions?operation=create&is_asset=true
Put everything in the response body and not only in the header. We'd like this to be a JSON API

Put everything in the response body and not only in the header.

I wonder why it won't return the transaction if it is in the backlog table (but not in a VALID or UNDECIDED block). That's what the get_transaction() method in the Bigchain class does. See https://github.com/bigchaindb/bigchaindb/blob/master/bigchaindb/core.py

This is interesting and I like to revive it. the status returned could be simply BACKLOG. It's good to know that your transaction is in the pool of unconfirmed transactions.

This means, when doing a call to /transactions/tx_id, we could include a X-BigchainDB-Timestamp header into the response that would have been taken from the block.

After review, the X-BigchainDB-Timestamp seemed a bit fuzzy. What does it mean?
For timestamps on transactions the user would care about a few things:

the first time the system sees the transaction (in the backlog or upon the first inclusion in an undecided block)
when the containing block was voted valid
maybe when included in every subsequent (possibly multiple invalid but only one valid) blocks

One proposal is to move this information to the /statuses/{tx_id} endpoint:
{
  "status": "<valid|invalid|undecided>",
  "_links": [
    {
      "block": "/block/<block_id_invalid>",
       "status": "/statuses/<block_id_invalid>"
    },
    {
      "block": "/block/<block_id_valid>",
       "status": "/statuses/<block_id_valid>"
    },
    {
      "vote": "/votes/<vote_1>"
    },
    {
      "vote": "/votes/<vote_2>",
    },
  ]
}

We agreed to go with the language of "unspent outputs" rather than "unfulfilled outputs"
A transaction can have many outputs, and it's possible that some are spent but not others. (They must all be for the same asset --- they can have different amounts and conditions.) That is, it's possible for a transaction to be partially "spent". How shall we handle the intermediate cases between all outputs unspent, and all outputs spent?

Remove all mention of GENESIS blocks from the HTTP API.

I can make the changes too.

+1

Noticed in our implementation that whenever we return a 404, we also return a json payload with
{
  "message": "Not found",
  "status": 404
}

AFAIK the spec doesn't really define this, and seems somewhat redundant. Did we have a discussion about this at some point?
cc @sbellem.

AFAIK the spec doesn't really define this, and seems somewhat redundant. Did we have a discussion about this at some point?

Good point
See more granular messages in the GET /votes tests
https://github.com/bigchaindb/bigchaindb/pull/1031/files#diff-e8747065feb7bc8df82da2650da680f4R132
We should indeed adapt something uniform and document it

I replaced all usages of the :param domain with :query in https://github.com/bigchaindb/bigchaindb/pull/830/commits/1007bf9b582dfd8e3c863b7867b4e05f48328234 (was there a reason :param was used instead @diminator?).

I replaced all usages of the :param domain with :query in 1007bf9 (was there a reason :param was used instead @diminator?).

not sure, I think this was introduced by @TimDaub

Turns out I didn't realize they were actually url parameters (and not query strings). I've removed 1007bf9.

For the GET /transactions endpoint, there's a proposal for a query parameter named fulfilled. Should that be changed to spent? I'm a bit confused about how our vocabulary has settled for version 0.9. Do "outputs get spent" or "conditions get fulfilled" or something else? @libscott can you comment?

Yes, this endpoint doesn't make any sense so it's going to be /outputs?unspent=...&public_key=....

Yes, great!
On Tue, Jan 17, 2017, 19:24 Sylvain Bellemare<EMAIL_ADDRESS>wrote:

@sbellem requested changes on this pull request.
In docs/server/source/drivers-clients/http-client-server-api.rst
https://github.com/bigchaindb/bigchaindb/pull/830#pullrequestreview-17058946
:

:type tx_id: hex string

Example request:

.. literalinclude:: samples/get-tx-id-request.http

 :language: http

Example response:

.. literalinclude:: samples/get-tx-id-response.http

 :language: http

:resheader Content-Type: application/json

:statuscode 200: A transaction with that ID was found.
:statuscode 404: A transaction with that ID was not found.

Following #1038 https://github.com/bigchaindb/bigchaindb/issues/1038,
we need to add a query string 'status', such that by default only VALID
transactions are queried. If a consumer wishes to query transactions that
may be in the BACKLOG, or in an UNDECIDED block, a 'status' query
parameter must be provided, e.g.:
GET /transaction/{id}?status=backlog
GET /transaction/{id}?status=undecided
GET /transaction/{id}?status=valid
the last case being equivalent to the default, when no status is provided.
@diminator https://github.com/diminator @libscott
https://github.com/libscott @TimDaub https://github.com/TimDaub could
you please confirm?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bigchaindb/bigchaindb/pull/830#pullrequestreview-17058946,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACoXNdSsFfGSbc2hg2Z3iDPwT4fthuuCks5rTQdwgaJpZM4K0Jzq
.

After discussions with @TimDaub and @sbellem we are merging the spec as is, currently the feature delta is to return http 202 on POST of a transaction, I am working on this now. Great job everyone!


fix: remove h-auto from Modal class

Hello, the class md:h-auto creates a bug where the content that overflows the height of the page is not seen.
Of course the bug only happens if display window is larger than md.
You can try to put extra text in your modal example till it exceeds the window height. When removing md:h-auto, this problem disappears as the class is h-max

Hey, thank you for that PR, I will refactor modal component soon

Thanks 😃


PDF JIS Z 8301: contributors table issues

Source issue: https://github.com/metanorma/metanorma-jis/issues/9
Original PDF:

Generated PDF:

To do:

[x] remove Contributors from adoc (replace by {blank}}
[x] set table unnumbered
[x] set fixed columns width in adoc
[x] remove borders in XSLT
[x] set justify alignment
[x] set center alignment for table header

@Intelligent2013 the "justify alignment" is generally difficult at the PDF stage because the names are aligned (2-6 chars) according to surname / given name. We have to use the semantics of the surname / given name for alignment.
They can be arranged in the following patterns.
あ: surname
い: given name
あ　　　い
あ　　　い　い
あ　　　いいい
あ　あ　い
あ　あ　い　い
あ　あ　いいい
あああ　い
あああ　い　い
あああ　いいい

Metanorma supports 'Semantic spans' (https://www.metanorma.org/author/topics/document-format/text/#semantic-spans)
For adoc:
| (部会長) | span:surname[酒井]span:givenname[信介] | 横浜国立大学

presentation XML:

		酒井
		信介

To do:

[ ] update adoc - add span tags for all rows
[ ] update JIS XSLT - add spaces in  and  in clause[@type = 'contributors']/table.

Done:


dpi_scale problem

Contour Terminal version
Contour Terminal Emulator 0.3.13-master-e60326e5
Installer source
Github: source code cloned
Operating System
Arch
Architecture
x86-64
Other Software
No response
Steps to reproduce
set dpi_scale to 2 in config file
Expected Behavior
No response
Actual Behavior

Additional notes
For comparison dpi_scale equal to 1

I propose to remove that. Users should use don't size to configure don't size. This is a legacy workaround when dpi scale on Mac was really hard to understand for me wrt Qt and retina displays
I would suggest to get rid of this logic all together instead. What do you think?
If there are future DPI issues, we should actually fix those.

I propose to remove that. Users should use don't size to configure don't size. This is a legacy workaround when dpi scale on Mac was really hard to understand for me wrt Qt and retina displays
I would suggest to get rid of this logic all together instead. What do you think?
If there are future DPI issues, we should actually fix those.

sure, we can get rid of this configuration entry. I was just trying to look how it will affect this issue https://github.com/contour-terminal/contour/issues/1022

She used dpi_scale: 1.0. I don't think so. 🤔

She used dpi_scale: 1.0. I don't think so. 🤔

I was thinking that dpi_scale can affect this bug and decided to check how it will look if I have double dpi


[Bug]: Not getting alerts displayed on checkout page

What happened?
I am not getting a alert on the checkout page when the user does not check the agree to terms checkbox.
What did you expect to happen?
I expected to see a yellow alert box appear if the user does not check the agree to terms checkbox and also expected to see red text under the checkbox if the checkbox is not checked.
Version
3.4.x
What browser are you seeing the problem on?
Firefox
Relevant log output
No response

Hi
Sorry, think I solved this issue in the end.

Ok great. I’m going to close this off then.


Update ingress class selector value

Default HTTP application routing add ingress controller with "addon-http-application-routing-nginx-ingress" selector.
Ingress resource annotations class selector should be updated as "addon-http-application-routing-nginx-ingress".

@Mahifernando : Thanks for your contribution! The author, @lachie83, has been notified to review your proposed change.

Thanks for the contribution, @Mahifernando.
@lachie83 If this is a valid update, can you add a sign-off tag, please?

#please-close


installing errors

this is happening, Any Ideas?

Sorry this is not tested on windows. I have no idea to solve it. I cant guarantee this works on windows

ok, thanks!

I'll close this issue too out-of-date. Have a nice day.

Hi i have the same problem on raspberry pi 3, any suggestions?


[presenter] no way to exit fullscreen mode with pointer

I hit esc while in presenter mode and found myself looking at the stack with no sidebars or anything else
https://github.com/dxos/dxos/assets/3398896/e4f5d394-d115-4e16-825d-029d1057635f

Resolved by #7468


Multi-tenancy breaks advanced custom navigation items

Package
filament/filament
Package Version
v3.1.27
Laravel Version
v10.38.2
Livewire Version
v3.3.3
PHP Version
PHP 8.3.0
Problem description
When adding multi-tenancy to a new panel and then customizing the navigation through the ->navigation function it breaks the multi-tenancy functionality.
You can't switch between teams & visiting the '/admin' route is giving a error:
Missing required parameter for [Route: filament.admin.pages.dashboard] [URI: admin/team/{tenant}] [Missing parameter: tenant].
It looks like it has something to do with the :href="filament()->getUrl($tenant)" inside the tenant-menu.blade.php file.
Expected behavior
To have the navigation changed and the switching between tenants work.
Steps to reproduce
Install new panel, add multi-tenancy and add some custom navigation through the ->navigation function in the AdminPanelProvider.php
Reproduction repository
https://github.com/pixelastronauts/filament-tenancy-navigation-bug
Relevant log output
No response

Found the problem. It's not having the right 'Dashboard' route defined inside the navigation.
Changing ->url(fn (): string => Dashboard::getUrl()) to ->url(route('filament.admin.pages.dashboard', ['tenant' => Filament::getTenant()])) is fixing the problem.
Despite that both return the same url?

->url(Dashboard::getUrl()) also works

Should have fixed the underlying issue


Add set scene service calls to yeelight

Description:
Adds service calls to execute set_scene method for yeelight. It allows to turn device right away, in desired state.
Pull request with documentation for home-assistant.io (if applicable): https://github.com/home-assistant/home-assistant.io/pull/10248
Checklist:

[X] The code change is tested and works locally.
[X] Local tests pass with tox. Your PR cannot be merged unless tests pass
[X] There is no commented out code in this PR.
[X] I have followed the [development checklist][dev-checklist]

If user exposed functionality or configuration variables are added/changed:

[X] Documentation added/updated in home-assistant.io

Can be merged when build passes.

@rytilahti please have a look too.

Rebase on newest dev. @rytilahti Can you take a look ?


running a default gulp task in terminal causes high CPU and battery life

I am calling $ gulp and when it runs, my battery life of my mac is considerably decreased ( about an hour and a half vs. 5 hours without running it ).  this is only if I call gulp as the constant default task and not if I manually call gulp css.
I am running El Capitan 10.11.1 on a 2.8gHZ i7 with 16gb of memory.
Here is my file:
var gulp = require('gulp');
var gutil = require('gulp-util');
var ftp = require('vinyl-ftp');
var runSequence = require('run-sequence');
// CSS
var postcss = require('gulp-postcss');
var autoprefixer = require('autoprefixer');
var precss = require('precss');
//var minifyCSS = require('gulp-minify-css');

// define the default task and add the watch task to it
gulp.task('default', ['deploy', 'css'], function() {
	gulp.watch('src/css/*.css', {debounceDelay: 2000}, ['css']);
	gulp.watch('**',  {debounceDelay: 2000}, ['deploy']);
});

// css
gulp.task('css', function () {
	var processors = [
	autoprefixer({ browsers: ['> 5%'] }),
	precss
	];

	return gulp.src('src/css/*.css')
	.pipe(postcss(processors))
	.pipe(gulp.dest(''));
});

// FTP
// conn data commented out

gulp.task('reset', function(cb) {
	runSequence('clean', 'deploy', cb);
});

gulp.task('deploy', function() {
    var globs = [
    '**',
    ];

    return gulp.src(globs, { base: '.', buffer: false })
        .pipe(conn.newer('path')) // only upload newer files
        .pipe(conn.dest('path'))
        .pipe(conn.mode('path', '0664'));
    });

gulp.task('clean', function(cb) {
	conn.rmdir('path', cb);
});

hey I noticed you have watch setup in your default task. That would cause your battery down faster than it normally would, since it continually runs in the background. The css task doesn't trigger watch, so you won't see the same batter consumption from running gulp css explicitly.

Your "css" task is meant to process your css files one time, whereas your "default" task depends on both the "css" and "deploy" tasks, along with 2 gulp.watch calls. Most of the processing power, if you leave the default gulp task running, is on these file watchers. They're constantly listening in for any changes made to the css files. If you leave it running, then yeah, this is the cause of the battery drain.

So essentially, there is no way for me to run gulp watch without excessive battery strain?  I guess I understand why watching a specific file would cause strain, but why is it so much?  It's not like I'm monitoring hundreds of folders!
Is there any way to run a watch - like "gulp watch css" and have it only monitor and not strain?

I'm not sure what you mean by "only monitor and not strain" but I have an idea.
Since gulp is called by "gulp [list of tasks]", your "gulp watch css" would mean you have both a "watch" task and a "css" task. I think you want something like "gulp watchCSS" where you only have one task to watch your css. That's doable. But whether it will reduce processor use, and therefore battery use, I'm not sure.
Even as gulp is watching files, it depends on what it does as soon as a file changes. If you're constantly updating CSS or changing many CSS files at once, then yeah, gulp will be doing whatever actions you assigned on each modification. Say you're converting LESS and SASS to CSS each time, then that's even more processor power being used.
I would recommend watching your CPU usage, RAM, and all the processes with Activity Monitor, since you said you're on a Mac.

This is a known problem with the gulp 3.x watcher - this is fixed in gulp 4.0


Expose actualClampedPosition for Points

Here's the scenario which came up on the forum:
You're trying to draw a polyline from the air to the ground so it looks something like this:

You can't use polylines clamped to ground because one of the points is in the air. One way to do it is to use sampleTerrainMostDetailed to get the actual terrain height and just use that as the other point.
// Plane position
var position = Cesium.Cartesian3.fromDegrees(-122.0744619, 44.0503706, 1600);
var groundPosition = new Cesium.Cartographic(-2.1305346621060743, 0.7688285707007808);

var promise = Cesium.sampleTerrainMostDetailed(viewer.terrainProvider, [groundPosition]);
Cesium.when(promise, function(updatedPositions) {
    var finalGroundPos = Cesium.Cartographic.toCartesian(groundPosition);
    viewer.entities.add({
        polyline : {
            positions : [position,finalGroundPos],
            width : 10,
            material : new Cesium.PolylineArrowMaterialProperty(Cesium.Color.RED)
        }
    });
});

But then this doesn't work well if the point on the ground is moving. So to achieve something like this:

I created a point that was clamped to ground and used its position as the end point of the line. But that position doesn't take into account the clamping to ground. So I had to dig it out of the private API:
var PointViz = viewer.dataSourceDisplay._defaultDataSource._visualizers[4];
var pos = new Cesium.BoundingSphere();

viewer.entities.add({
    polyline : {
        positions : new Cesium.CallbackProperty(function(time) {
            PointViz.getBoundingSphere(groundPoint,pos);
            return [position, pos.center];
            //return [position, groundPoint.position.getValue(time)];
    }, false),
        width : 10,
        material : new Cesium.PolylineArrowMaterialProperty(Cesium.Color.RED)
    }
});

Here it is running in Sandcastle.
It seems like the Billboard at least does keep track of its actual clamped position:
https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Scene/Billboard.js#L916-L929
If it doesn't degrade performance it would be nice to expose this for points (especially if it's already computed every time the point updates). It would be a really easy way/fast way to get terrain height at any location in real time.
(I tried to look if there was an issue about this already but I couldn't anything. If there's already a way to accomplish this feel free to close).

Cool.  I use the first method, just get the actual terrain height and use that as the other point.  And it  also works well if the point on the ground is moving. Actually, my two points are both moving.  Just request the point height all the time. Something like this:

I read the original problem slightly differently, namely that the ground location wasn't known but needed to be determined by performing a ray intersection with the terrain surface.  All of this being slightly complicated by the coordinate system transformations required to go from some local CS for the laser to world coordinates for the direction vector.  A scanning laser vs. a target pointing laser.

@OmarShehata the best method for achieving something like this is to position = viewer.scene.globe.pick(viewer.scene.camera.getPickRay(mousePosition)) to get a rough position while the mouse is moving, then you can call sampleTerrainMostDetailed to get the final accurate position once the position is set.
You never want to dig into the private API like that.  There are usually ways to accomplish what you are trying to do using the public API.

Congratulations on closing the issue! I found these Cesium forum links in the comments above:
https://groups.google.com/d/msg/cesium-dev/YsH-gLKVepo/DZp44sZsAgAJ
If this issue affects any of these threads, please post a comment like the following:

The issue at https://github.com/AnalyticalGraphicsInc/cesium/issues/6995 has just been closed and may resolve your issue. Look for the change in the next stable release of Cesium or get it now in the master branch on GitHub https://github.com/AnalyticalGraphicsInc/cesium.

I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome.
:earth_africa: :earth_americas: :earth_asia:


App crash when select another photo

Device: Ipad Air 2
IOS: 9.3
Orientation: Landscape
let picker = DKImagePickerController()
            picker.assetType = .allPhotos
            picker.maxSelectableCount = 1
            picker.didSelectAssets = { (assets: [DKAsset]) in
                if let asset = assets.first {
                        asset.fetchOriginalImage(true, completeBlock: { (image, object) in
                        })

                }
            }

App crash when I select the second photo.
Error message:

Terminating app due to uncaught exception 'UIApplicationInvalidInterfaceOrientation', reason: 'Supported orientations has no common orientation with the application, and [UIAlertController shouldAutorotate] is returning YES'

Sorry, I have fixed it. Please close it. Thank :)

Let me know if you have any questions 😄


Move user code to separate libraries

With the addition of LoRa the codebase has gotten significantly larger. In terms of project structure it would help to have the project split by libraries. I'm envisioning that all the code a user adds lives in their own folder in lib and all the generated CubeMX code lives in the root Src and Inc, excluding main.c.

Remove timestamp libraries created as part of #67 that should have been deleted before merge.

Add launch.json and settings.json to .gitignore and remove from project

Fix medium-high severity errors from static code analysis


Save console URL from provisioner gardenerClusterDomain label

Description
Currently KEB only saves the dashboard URL in instance state after the provisioning has finished successfully, using the runtime_ConsoleUrl label set by compass-runtime-agent in director.
The /runtimes API, and the kcp runtimes and kcp kubeconfig CLI commands rely on the dashboard URL to display the shoot name, or to fetch kubeconfig by given shoot.
As a result, only the successfully provisioned runtimes have their corresponding shoot names displayed. kubeconfig cannot be downloaded by shoot name for failed clusters.
Changes proposed in this pull request:

KEB gets console URL by gardenerClusterDomain label set on the runtime in Director. This label is set by provisioner as the first step of the provisioning operation
Query and save the dashboard URL in Provision_Initialization step even during the provisioner operation is in progress.

/retest

Closing in favor of a more general solution implemented in the near future.


feedback: Context files with ollama

Version
Cody 1.12.0
Areas for Improvement

[ ] UI/UX
[ ] Onboarding
[ ] Docs
[X] Chat
[ ] Commands
[ ] Context
[ ] Response Quality
[ ] Other

What needs to be improved? Please describe how this affects the user experience and include a screenshot.
If I try to add @files in the chat it does not work with Ollama. Apparently the files are not send to the LLM as it does not know about the files.
Describe the solution you'd like to see
The @files should be send to the LLM.
Describe any alternatives that could be considered
No response
Additional context
No response

#3881 may help with this.


Tools for doing administrative tasks: reviewing, asking for help, filling in metadata

This stems from wanting a bank of good-quality, tested questions, but there are a few other uses that could work similarly.
I'd like an interface for working through a queue of questions/exams that need attention in some way. You'd be shown items that need attention, and to clear the queue you can either do whatever needs doing and remove the item from the queue, or say that you don't want to handle a particular item yourself and leave it for someone else.
Reasons for making queues:

Testing/proofreading before use or inclusion in a question bank.
Filling in metadata such as tags, taxonomy, etc.
Requesting help

Scopes for queues:

Within a project (for private material where you want other project members to check your work)
For a single user (add questions to a "look at later" list)
Global (a public question bank; asking for help from anyone)

A queue has:

people who are allowed to add to the queue (providers)
people who are allowed to handle items in the queue (handlers)
a passage of text for handlers describing what to do
an ordered list of editor items, each with an associated text note from the person who added it

Queues are now in


[HxTooltip?] Disposing JS module in DisposeAsync causes JSException

Can confirm that this is because of the InvokeVoidAsync call inside a DisposeAsync (the exception itself is thrown when reloading the page). If I attempt to use the module for an InvokeVoidAsync call before disposing it inside the component's DisposeAsync, I get:

Browser console essentially reports the same thing:

It's very possible I'm doing something very wrong to cause this, but I'm really not well-versed enough in Blazor to even make guesses as to what's going on.

@KliqxTV Could you please provide us with minimal reproduction steps, or even better, a repository demonstrating the issue?


feat: Get Redis keys count lego

Implements https://github.com/unskript/Awesome-CloudOps-Automation/issues/84
Description
Created lego for getting redis keys count by given pattern.
Testing
Tested lego on sandbox

Hello @abhishek-unskript, can you or somebody in the team please check my changes?

Jayasimha.

Thanks Yuriy!
On Tue, Oct 25 2022 at 2:15 PM, Yuriy Skrypnyk @.***>
wrote:

Hello @abhishek-unskript https://github.com/abhishek-unskript, can you
or somebody in the team please check my changes?
—
Reply to this email directly, view it on GitHub
https://github.com/unskript/Awesome-CloudOps-Automation/pull/90#issuecomment-1290962428,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARU55NGSOIFTL5CMHQ4BCMDWFAPU7ANCNFSM6AAAAAAROHGJNM
.
You are receiving this because you were mentioned.Message ID:
@.***>


Linux friendly

While installing hr on a linux machine, I found that mux didn't work the way I wanted it to - these commits make things a little more compatible. Open to other ideas here! :D

I'm closing this because it's old and I don't want it on my list anymore. Feel free to reopen/merge/whatever! ❤


"Poster" throws error

I am trying to integrate libpostal with R using the package Poster. I have successfully installed libpostal and Poster in my machine. However i could not use any methods like poster::city("hansastrasse 84, 24118 kiel") or  poster::house("hansastrasse 84, 24118 kiel") . and the error is
Error in get_elements_(x, 5) :
attempt to set index 10/10 in SET_STRING_ELT
Could you please help me out ?

I'll look into it,

Thanks a ton !

Try with the latest version?

@DannyChristy ?

Whelp, this seems fixed at my end.


NFT Exchange: Add Network to Bid/Ask Requests

This update adds a network param to the bid and sell endpoints

Task linked: CU-246bd7q UI: Add Network to Bid/Ask Requests


StSubunitInfoRef

Hi,
This is less of an issue, and more of a question about how the input of the state machine StSubunitInfoRef is supposed to work.  I see that in FB_PackML_BaseModule.initialize() you write to this input of the state machine, but it is not read anywhere, and i can't see what the state machine is doing with that information. Infosys has no documentation about this. Could you explain what is happening to those subunits?
thank you

Checking into this will advise


remove unused env from gh workflow tests

remove unused env from gh workflow tests

Codecov Report

Merging #1177 (552e4a9) into main (166ef02) will decrease coverage by 2.91%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1177      +/-   ##
==========================================
- Coverage   51.77%   48.85%   -2.92%
==========================================
  Files         246      246
  Lines       13986    14033      +47
==========================================
- Hits         7241     6856     -385
- Misses       6745     7177     +432

Impacted Files
Coverage Δ

lnbits/extensions/boltz/mempool.py
32.75% <0.00%> (-50.00%)
:arrow_down:

lnbits/extensions/boltz/crud.py
29.23% <0.00%> (-49.24%)
:arrow_down:

lnbits/extensions/boltz/utils.py
23.52% <0.00%> (-41.18%)
:arrow_down:

lnbits/extensions/boltz/boltz.py
17.91% <0.00%> (-39.31%)
:arrow_down:

lnbits/wallets/cln.py
19.00% <0.00%> (-29.76%)
:arrow_down:

lnbits/wallets/lndrest.py
17.09% <0.00%> (-29.06%)
:arrow_down:

lnbits/wallets/lndgrpc.py
22.72% <0.00%> (-27.93%)
:arrow_down:

lnbits/extensions/boltz/views_api.py
31.40% <0.00%> (-18.19%)
:arrow_down:

...nbits/wallets/lnd_grpc_files/lightning_pb2_grpc.py
38.22% <0.00%> (-12.25%)
:arrow_down:

lnbits/wallets/lnd_grpc_files/router_pb2_grpc.py
40.54% <0.00%> (-11.49%)
:arrow_down:

... and 7 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


lemma and palea

Existing def:
lemma (PO:0009037): In a grass floret, the lower of two bracts enclosing a flower. [source: APWeb:Glossary, GR:pj]
Proposed def: A flower bract that is part of a spikelet and is the lower of two bracts enclosing a spikelet floret.
Comment: Found in Poaceae such as Zea mays. If you are annotating to this structure for Zea mays or other grasses, please also add an annotation to the corresponding spikelet type. Choose the most specific term possible from: spikelet (PO:0009051), ear spikelet (PO:0006320), ear pedicellate spikelet (PO:0006348), ear sessile spikelet (PO:0006349), tassel spikelet (PO:0006309), tassel pedicellate spikelet (PO:0006312), tassel sessile spikelet (PO:0006311).
Was part_of Poaceae floret, but made part_of spikelet, because it is a bract, and by definition, bracts are not part of a flower.
Reported by: rlwalls2008
Original Ticket: obo/plant-ontology-po-term-requests/381

Revised definitions slightly:
palea (PO:0009038)
Was: A flower bract (PO:0009034) that is the upper/distal of the two bracts (PO:0009055) enclosing a (PO:0009082) spikelet floret.
Revised:  The upper (distal), usually smaller, of the pair of flower bracts (PO:0009034) enclosing a (PO:0009082) spikelet floret.
lemma (PO:0009038):
Was: A flower bract (PO:0009034) that is the lower of the two bracts (PO:0009055) enclosing a (PO:0009082) spikelet flore
Revised: The lower, usually larger, of the pair of flower bracts (PO:0009034) enclosing a (PO:0009082) spikelet floret.


reserved identifier violation

I would like to point out that an identifier like "__SOUNDPIPE_H__" does not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

Thank you for pointing that out! I fixed it.

Thanks for your small source code improvement.
Are there any more update candidates to consider?


fix: input adornments josep feedback

Description
On TextField mockup, Josep recommended to remove any hover/focus interaction for input adornments.

Replaced IconButton by simple icons with cusor: pointer behaviour on hover
Removed IconButton integration from input AdornmentWrapper
Input stories, removed IconButton as adornment

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Documentation] Basic blockchain operations

Summary
One of the items requested by participants of TestNet is a documentation on basic operations such as creating/importing addresses, sending tokens, etc.
Issue

#451

Type of change
Select one or more:

[ ] New feature, functionality or library
[ ] Bug fix
[ ] Code health or cleanup
[x] Documentation
[ ] Other (specify)

Testing

[ ] Unit Tests: make go_develop_and_test
[ ] LocalNet E2E Tests: make test_e2e
[ ] DevNet E2E Tests: Add the devnet-test-e2e label to the PR. THIS IS VERY EXPENSIVE, so only do it after all the reviews are complete.
[x] Documentation changes: make docusaurus_start

Sanity Checklist

[ ] I have tested my changes using the available tooling
[ ] I have commented my code
[ ] I have performed a self-review of my own code; both comments & source code
[ ] I create and referenced any new tickets, if applicable
[ ] I have left TODOs throughout the codebase, if applicable

I put it under "operate".
@Olshansk should be g2g now!


Feat: Add dockerimage + playwrite headless + auth

Added auth + headless playwrite to https://github.com/altryne/chatGPT-telegram-bot/pull/18

This is awesome! I have to try it, I'm not in love with adding u/p directly , but this definitely lowers the bar for installing something like this

This is great @stjohn96 !
Thanks for adding the auth code, i'm gonna test your branch

Thanks for testing @sebaplaza
@stjohn96 thank you! Could you add a readme entry on this docker? And merge conflicts ?
I'll merge after

@stjohn96 @altryne i resolved merge conflicts in https://github.com/altryne/chatGPT-telegram-bot/pull/18

@sebaplaza @altryne Im going close this PR in favour of https://github.com/altryne/chatGPT-telegram-bot/pull/18


Fix default reduce value on Pool_fuse

The default value is given in lowercase while the if code inspects for uppercase. This causes to raise an NotImplementedError when not passing reduce value explicitly

Seems like this repo is no longer being maintained


Vero

JSON schemas for Vero's 6 email webhook events and 2 customer events.
Adapter for these schemas can be found here.

This is awesome @misterpig! Thanks so much.

@misterpig has signed the Software Grant and Corporate Contributor License Agreement

@chuwy please review

Scheduling. Any feedback on @chuwy's questions would be great.


Captured HTML Zoomed in By 50%

After updating packages recently, I noticed the screen captured html is now zoomed in by 50%. I can use the zoom out feature on chrome (cmd + -) to get the scale right after I reach 50% zoom.
I do have a workaround with this line: document.body.style.zoom = '0.5'; but that's not ideal. Any help would be appreciated. Thanks
Current package versions:
 "dependencies": {
    "@emotion/react": "^11.8.1",
    "@emotion/styled": "^11.8.1",
    "@mui/icons-material": "^5.4.2",
    "@mui/material": "^5.4.3",
     ... ,
    "html-screen-capture-js": "^2.0.3",
    "mui-datatables": "^4.1.2",
    "react": "^17.0.2",
    "react-dom": "^17.0.2",
    "react-router-dom": "^5.2.0",
    "react-scripts": "5.0.0",
    "typescript": "^4.5.5"
}

  "devDependencies": {
    ... ,
    "postcss": "^8.4.6",
    "tailwindcss": "^3.0.23"
  },

@jcgentr Can you locate where the zoom comes from?

@jcgentr I understand the reason. Let's say you have a 100px div, and you zoom the browser to 200. The div now appears as a 200px div, and this is how it's captured.

@jcgentr Thanks. As a temporary workaround, I guess you can just set the zoom on the html root element to 1.

@jcgentr Thanks, we'll look into it.

I'm getting this only on Chrome, all other browsers including Firefox and Safari render it at 100%, Chrome zooms to 200%. Any ideas?


Example Folder

I would love to start using this plugin. Please could you create an example folder with the use of this provider and a sample dummy password file etc so I can see a working example?

Hi @e-moshaya ,
I'll take time today in order to generate an example.

Hi, in #35 you'll find example. let me know if it's good for you


change(notification): simplify (?) the formatting of the reminder

I thought this might clean things up a bit, sort of in response to #22
before

after

@danielma am I supposed to be able to merge this? I don't see a merge button.

Oh. I had to accept the invitation first.


Fix map in place and provide alternative scrolling

This PR fixes the map on Desktop and disables map zoom scrolling.
Context: https://onswebsite.slack.com/archives/C027PAPSN5C/p1643368394557099?thread_ts=1643365487.815419&cid=C027PAPSN5C

This one wasn't accounted for DAC and might be controversial but I believe we wanted to do that anyway.

Now rebased on master.

Superseded by #153.


docs(readme): add badges

:tada: This PR is included in version 1.1.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Proposal: Folder for init scripts within dist / FreeBSD service script

As providing a base framework for deploying Caddy in production becomes a larger interest to many people, I've created a directory called dist/init/ to have a place to provide init scripts for various systems.
I've also added a FreeBSD service script I wrote myself to get Caddy running on FreeBSD.
If you're ok with it, I'd be glad to see more people adding init scripts for sysvinit, systemd and upstart as already discussed in various bug reports.

 You should sign our Contributor License Agreement in order to get your pull request merged.

So, I think I really like this idea. It's out of the way of the main source code and we can just bundle it up in tarballs/zip files to distribute.
My questions/concerns about the scripts in this folder in general (not just the BSD script you've proposed):

Will most Caddy users find the scripts contained in here useful and actually employ them?
Will the users be able to use these without a tutorial? I don't really want to go down this rabbit hole, but maybe a paragraph in the readme would be sufficient?
Do we officially support these? Once we venture into the realm of sysadmin and distribute "official" scripts/configs, it becomes our responsibility to make sure they work, and it's not a burden I'm willing to take on. I mean, you are welcome to do that if you want.
Will we be able to get scripts/configs/whatever for all the popular systems?

@mholt Sorry for my late response. Your concerns are all valid so let's try to find a solution to this:

I really think there are two groups of Caddy users: The first ones may develop their web applications using Caddy as it does not require any installation and only few configuration effort; as well as hosting beginners that are relatively unexperienced. These probably won't use it as starting Caddy by it's CLI command will fit their needs. But for more sophisticated users that want to deploy Caddy in production not having a service script that manages Caddy and restarts it after system reboots and so on might be a concern using it. In fact @DenBeke and @justrjlewis also invested some effort in creating startup scripts for FreeBSD and Ubuntu (Upstart). At the current point I think the most users will actually test-drive Caddy (at least until it hits 1.0) but as it will evolve, more people likely will use it in production as I think there are real benefits choosing Caddy over Apache or nginx. So long story short: Today likely not the most users will employ those scripts but in the future definitively.
I think a paragraph in README.md would be a good idea to point people to this directory. I currently think of this directory more like a collection of scripts for later usage when packaging Caddy for the various distributions rather than trying to convince people using them right now though they could and some will likely do.
Generally, once created properly, those scripts will likely keep working for a long time without even having to touch them because of their low complexity - at least if you don't break your command line interface ;-) I think we have to generally support them, at the latest when we distribute specific packages for distribution as many distros' packaging guidelines require init scripts for daemons. I'd also support it by keeping it up to date as good as possible, probably enhancing it and doing general Q&A (I think there won't be much more), as long as I'm able to do it in my spare time ;-)
Let me list the large init systems in use today: On Linux it is sysvinit (legacy), Upstart (seems like all distros using upstart are migrating to systemd) and systemd. On FreeBSD it's only rc.d, I'm not sure about Open- and NetBSD. To not have the burden of maintaining init scripts for distributions that are thousands of years old, we should focus on systemd (@klingtnet already posted one here https://github.com/mholt/caddy/issues/388#issuecomment-162213580 ), maybe Upstart for currently used Ubuntu LTS as I know @DenBeke has a working script and rc.d, which I could provide.

For my two cents, I think having such a folder would still be in keeping with the ethos of Caddy being an easy to use, everyman web server.
The readme update could have a disclaimer specifically stating that the scripts are community contributed and maintained, but are provided to act as a good starting point for people that want to use Caddy in a production environment.
p.s. Yes, I would be willing to help with rc.d support.  I've almost read the entire freebsd handbook. lol

Thanks for this. Let's go forward with it, since it's just on the side for now. Please add a paragraph to the readme for this folder to explain what file to use for which system.

@dprandzioch I've just given you push rights so you can maintain this. Thanks!


[WIP] Add tutorial for differential exon usage

Still to do

[x] Add Zenodo link when update finished
[ ] Test the tutorial
[ ] Fix issues like in #544
[ ] Add workflow

@bebatut what is the status of this 4 year old PR? still planning on finishing it? need help? close? :)

@pavanvidem do you think the differential exon usage tutorial would be useful ?

I think we can close this. There is already a very detailed alternative splicing analysis tutorial.

Great. I close it. Thanks for the answer @pavanvidem


[ACS][CallAutomation] Latest feedback update with Python SDK

Latest update to Python SDK including feedback changes

Updated with latest Swagger V4. This does not add actual new features (only generating to latest swagger). New api features will be done seperately.
Changelog updated to include GA release, and change version to 1.1.0.b
Changed variable name to match GA release
Overall docstring updated for typo, and missing docstring.
All Boolean to be bool instead of Optional[bool]. All Boolean is expected to be either true or false (by default, false)
Various typo fixes

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-communication-callautomation


Typo in README.md

Bug report
In the instructions for integrating UNUserNotificationCenter:
- (void)userNotificationCenter:(UNUserNotificationCenter *)center willPresentNotification:(UNNotification *)notification withCompletionHandler:(void (^)(UNNotificationPresentationOptions options))completionHandler
{
  completionHandler(UNAuthorizationOptionSound | UNAuthorizationOptionAlert | UNAuthorizationOptionBadge);
}

This works however it is only correct because luckily the first 3 options in the UNAuthorizationOptions enum are identical in value to the elements of UNNotificationPresentationOptions.  The completionHandler should be called like so:
completionHandler(UNNotificationPresentationOptionBadge | UNNotificationPresentationOptionSound | UNNotificationPresentationOptionAlert)

@JamesPerlman thanks for raising the issue!
This issue is solved in #172


Fix travis bundler version error

rvm ruby-head bundle bundler 2.0.1.
bundler version in gemspec is just development_dependency so I think this is safe and ok.
Thank you.

Hello, it looks like this was resolved by targeting newer Rubies and specifying bundler 2+ in the gemspec. OK to close this?


Fail to parse out broker configuration

Good afternoon. I am having trouble connecting to my office's kafka cluster. I started with code like this:
const kafka = require('kafka-node');
const HighLevelConsumer = kafka.HighLevelConsumer;
const client = new kafka.Client('zookeeper-01:2181', 'super-client-id');
const consumer = new HighLevelConsumer(
        client,
        [
            { topic: 'a-super-great-topic' }
        ],
        {
            groupId: 'the-super-grouper'
        }
    );
consumer.on('message', function(message) {
  console.log(message);
})

When I run my node server I get the following output:
bld-kafka-03.f4tech.com-1457105355761:bld-kafka-03.f4tech.com:9092
^

SyntaxError: Unexpected token b
    at Object.parse (native)
    at /Users/pairing/projects/unicorny/great-fun-time-webserver/node_modules/kafka-node/lib/zookeeper.js:241:40
    at /Users/pairing/projects/unicorny/great-fun-time-webserver/node_modules/node-zookeeper-client/index.js:165:26
    at Object.async.whilst (/Users/pairing/projects/unicorny/great-fun-time-webserver/node_modules/node-zookeeper-client/node_modules/async/lib/async.js:627:13)
    at /Users/pairing/projects/unicorny/great-fun-time-webserver/node_modules/node-zookeeper-client/node_modules/async/lib/async.js:623:23
    at /Users/pairing/projects/unicorny/great-fun-time-webserver/node_modules/node-zookeeper-client/index.js:145:21
    at Object.callback (/Users/pairing/projects/unicorny/great-fun-time-webserver/node_modules/node-zookeeper-client/index.js:582:17)
    at ConnectionManager.onSocketData (/Users/pairing/projects/unicorny/great-fun-time-webserver/node_modules/node-zookeeper-client/lib/ConnectionManager.js:562:35)
    at emitOne (events.js:90:13)
    at Socket.emit (events.js:182:7)

I took a look at the source code of zookeeper.js and it is reading from zookeeper at /brokers/id/3. Zookeeper returns the following output:
bld-kafka-03.f4tech.com-1457105355761:bld-kafka-03.f4tech.com:9092
cZxid = 0x581c3b3d2d
ctime = Fri Mar 04 08:29:15 MST 2016
mZxid = 0x581c3b3d2d
mtime = Fri Mar 04 08:29:15 MST 2016
pZxid = 0x581c3b3d2d
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x151b3de38f221d8
dataLength = 66
numChildren = 0

So my broker isn't defined a json document. Is there a way to configure kafka-node to parse the broker information differently?

That's very odd. The kafka data structure in zookeeper should be in JSON. What version of Kafka is this?


Bug: CVE records that have ' in their body cannot be submitted

Root cause: https://github.com/RedHatProductSecurity/cvelib/issues/47


REF: Split artifacts into smaller outputs / Update to v1.3.0

Splits the artifacts of this package into smaller outputs, so development artifacts aren't exported to downstream packages.
The david-dev package is created, which is what downstream users should include in host requirements.
The david package now only contains the david binary. This is backwards compatible with the current recipe because the shared library is still installed. However, new builds of downstream recipes will need to be migrated to the david-dev package. An automated migration is probably not needed because existing packages should not break.
The libdavid{{ so_major }} package is now the export. It only contains the versioned shared objects.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Closes #12

Thanks @carterbox! LGTM. I'm assuming we need this for better compat in some other feedstock. Do you have a reference or a link we can leave here? Thanks!

It's not for better compat. It because I have a general interest in shrinking the size of downloads for packages in the dependency tree of my scientific software. I'm starting with the AV1 codec packages because I think they're neat and they mostly follow unix shared library naming conventions.

Thanks!


FileNotFoundException on subscribing to private channel

Hello, thank you very much for this package.
I am successfully able to subscribe to the public channels and receive events that are sent from the pusher debug console.
The exception is thrown when I am trying to subscribe to private channels.
I have in the backend written in laravel. I'm not a back end developer so I could not debug if the problem is on the back end.
I pass the required auth endpoint and also the request headers to PusherAuth.
When I try to connect to the pusher cancel and subscribe to a private channel I get this file not found exception which points to the auth endpoint URL as below
D/PusherPlugin( 8418): onCancel args: null
D/PusherPlugin( 8418): init
D/PusherPlugin( 8418): connect
D/PusherPlugin( 8418): subscribe (private)
D/PusherPlugin( 8418): bind (BroadcastNotificationCreated)
I/flutter ( 8418): CONNECTING
I/flutter ( 8418): CONNECTED
D/PusherPlugin( 8418): onError : java.io.FileNotFoundException: https://<my-url>/broadcasting/auth
W/System.err( 8418): com.pusher.client.AuthorizationFailureException: java.io.FileNotFoundException: https://<my-url>/broadcasting/auth
W/System.err( 8418): 	at com.pusher.client.util.HttpAuthorizer.authorize(HttpAuthorizer.java:146)
W/System.err( 8418): 	at com.pusher.client.channel.impl.PrivateChannelImpl.getAuthResponse(PrivateChannelImpl.java:127)
W/System.err( 8418): 	at com.pusher.client.channel.impl.PrivateChannelImpl.toSubscribeMessage(PrivateChannelImpl.java:90)
W/System.err( 8418): 	at com.pusher.client.channel.impl.ChannelManager$1.run(ChannelManager.java:140)
W/System.err( 8418): 	at com.pusher.client.util.Factory$1.run(Factory.java:109)
W/System.err( 8418): 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
W/System.err( 8418): 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
W/System.err( 8418): 	at java.lang.Thread.run(Thread.java:764)
W/System.err( 8418): Caused by: java.io.FileNotFoundException: https://<my-url>/broadcasting/auth
W/System.err( 8418): 	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:251)
W/System.err( 8418): 	at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getInputStream(DelegatingHttpsURLConnection.java:210)
W/System.err( 8418): 	at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getInputStream(Unknown Source:0)
W/System.err( 8418): 	at com.pusher.client.util.HttpAuthorizer.authorize(HttpAuthorizer.java:128)
W/System.err( 8418): 	... 7 more
I/flutter ( 8418): java.io.FileNotFoundException: https://<my-url>/broadcasting/auth
W/OkHttpClient( 8418): A connection to <my-url> was leaked. Did you forget to close a response body?

I cannot add the real URL above in the logs so added .
The laravel code does not have any auth  endpoint set, so according to the laravel docs the default is /broadcasting/auth.
Any help is appreciated.

It did look to me like your Pusher.init('...', PusherOptions(auth: PusherAuth('url', headers: {}), cluster: 'ap3'), enableLogging: true) setting is not quite right at the moment.

@jinseokoh  So its a problem with setting a right auth endpoint?

@rvamsikrishna As I haven't experienced such error with this package, probably your current private auth setting is not correct. Check out the example code in the following PR. Hope you find it useful.
https://github.com/kakajansh/echo/pull/24

W/System.err(20778): 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) W/System.err(20778): 	at java.lang.Thread.run(Thread.java:919) W/System.err(20778): Caused by: java.io.FileNotFoundException: https://meroswasthya.org/broadcasting/auth W/System.err(20778): 	at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:259) W/System.err(20778): 	at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getInputStream(DelegatingHttpsURLConnection.java:211) W/System.err(20778): 	at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:30) W/System.err(20778): 	at com.pusher.client.util.HttpAuthorizer.authorize(HttpAuthorizer.java:128) W/System.err(20778): 	... 7 more I/flutter (20778): Error: java.io.FileNotFoundException: https://meroswasthya.org/broadcasting/auth Channel error
I have similar issue . Is your issue fixed? Public channel works fine something is not correct with authorization


Protocols/ABCs for stdlib collections like list/set etc including immutable versions

basically there should be an immutable version of list, and Sequence is missing members like __add__ so it doesn't fit that description

What if they were called Listy or ListLike, if it was called List one might mistake it for actual list.

A ProtocolOf type, that would de-nominalize something, like:
class A:
    a: int
class B:
    a: int
a: ProtocolOf[A] = B()

Would solve part of this issue.
And use-site variance would solve most of the rest of it.
How much value is there in an immutable list as well as a covariant list? ie, just use list[Out[int]]


[WIP] v2

https://github.com/muukii/Pixel/projects/2

[ ] Enhancement the code for state-management with using Verge
[ ] Crop-UI supports rotation
[ ] Investigate performance

TODO

[x] CropView supports super small image (smaller than scroll view bounds)

https://whimsical.com/v2-architecture-LDTmmZN4tyEYaUG6vfSwfF

Support Muukii
Hi, I'm working on open-source software with a lot of time.
Please help me continue my work. I appreciate it.
https://github.com/sponsors/muukii

progress:
working on crop function
https://user-images.githubusercontent.com/1888355/109421765-0b2b6b80-7a1c-11eb-8b0e-f6bc98228dc7.mp4

test comment

created a small wrapper for SwiftUI
struct DemoCropView: View {
  let editingStack: EditingStack

  var body: some View {
    ZStack {
      Color.black
        .ignoresSafeArea()
      SwiftUICropView(editingStack: editingStack)
        .onAppear {
          editingStack.start()
        }
    }
  }
}

Now supports creating an overlay with SwiftUI

Current progress: implementing drawings

CropViewController

Aspect ratio

https://user-images.githubusercontent.com/1888355/112652956-4db45c80-8e91-11eb-96ab-1d60b27cf7d8.mp4


Trying to write specs for auth-service.ts

I'm trying to write specs for auth-service.spec.ts to try and get familar for writing specs for services in angular2, and also as a way to get familar with angularfire2.  So far I have:
import {
  expect,
  it,
  describe,
  beforeEach,
  beforeEachProviders,
  inject
} from '@angular/core/testing';

import {
  AuthProviders,
  FirebaseAuth,
  FirebaseAuthState
} from 'angularfire2';

import { AuthService } from './auth-service';

describe('AuthService', () => {
  let authService;

  beforeEachProviders(() => [
    AuthProviders,
    FirebaseAuth,
    FirebaseAuthState,
    AuthService
  ]);

  beforeEach(inject([AuthService], (a) => {
    authService = a;
  }));

However, I get the following error when I run npm test:

ReferenceError: FirebaseAuthState is not defined
at webpack:///src/core/auth/auth-service.spec.ts:24:4 <- karma.entry.js:56366:10
at Object. (webpack:///~/@angular/core/testing/testing.js:121:36 <- karma.entry.js:41231:52)
at ContextKarma.loaded (http://localhost:9876/context.js:151:12)
Error: No provider for AuthService!
Error: DI Exception
at NoProviderError.BaseException [as constructor] (webpack:///~/@angular/core/src/facade/exceptions.js:27:0 <- karma.entry.js:10253:24)
at NoProviderError.AbstractProviderError [as constructor] (webpack:///~/@angular/core/src/di/reflective_exceptions.js:43:0 <- karma.entry.js:11793:17)
at new NoProviderError (webpack:///~/@angular/core/src/di/reflective_exceptions.js:80:0 <- karma.entry.js:11830:17)
at ReflectiveInjector_.throwOrNull (webpack:///~/@angular/core/src/di/reflective_injector.js:786:0 <- karma.entry.js:11693:20)
at ReflectiveInjector.getByKeyDefault (webpack:///~/@angular/core/src/di/reflective_injector.js:814:0 <- karma.entry.js:11721:26)
at ReflectiveInjector.getByKey (webpack:///~/@angular/core/src/di/reflective_injector.js:777:0 <- karma.entry.js:11684:26)
at ReflectiveInjector.get (webpack:///~/@angular/core/src/di/reflective_injector.js:586:0 <- karma.entry.js:11493:22)
at webpack:///~/@angular/core/testing/test_injector.js:55:46 <- karma.entry.js:40942:72
at Array.map (native)
at TestInjector.execute (webpack:///~/@angular/core/testing/test_injector.js:55:0 <- karma.entry.js:40942:30)
at Object. (webpack:///~/@angular/core/testing/test_injector.js:149:28 <- karma.entry.js:41036:56)
at ContextKarma.loaded (http://localhost:9876/context.js:151:12)

I've loaded the FirebaseAuthState provider using beforeEachProviders, so I don't know why I'm getting this error.

Hey @rjbergerud
There's actually a bit of setup required in order to test Firebase related/dependent services. One of the main challenges is that Firebase doesn't provide a mocking library to ease setup and execution. The best resources are the angularfire2 specs themselves.
In your example, some of your imports from @angular2/core are deprecated — you no longer need to import angular versions of jasmine methods like it, describe, expect etc. and IIRC beforeEachProviders is also deprecated.
import { addProviders, inject } from '@angular/core/testing';

import {
  defaultFirebase,
  FIREBASE_PROVIDERS
} from 'angularfire2';

import { AuthService } from './auth-service';

// CONFIG taken from angularfire2 auth spec
// You can use your own Firebase config here
const CONFIG = {
  apiKey: "AIzaSyBVSy3YpkVGiKXbbxeK0qBnu3-MNZ9UIjA",
  authDomain: "angularfire2-test.firebaseapp.com",
  databaseURL: "https://angularfire2-test.firebaseio.com",
  storageBucket: "angularfire2-test.appspot.com",
};

describe('AuthService', () => {
  let authService;

  beforeEach(() => {
    addProviders([
      FIREBASE_PROVIDERS,
      defaultFirebase(CONFIG),
      AuthService
    ]);

    inject([AuthService], (service: AuthService) => {
      authService = service;
    })();
  });

  it('should be defined', () => {
    console.log('authService:', authService);
    expect(authService).toBeDefined();
  });
});

Hey, thanks @r-park for explaining the fixes.  Where do you go to keep abreast of updates?  I've been following the testing guide https://angular.io/docs/ts/latest/guide/testing.html and some out-of-date tutorials, but the guide is still very incomplete.

For now — until things stabilize — I keep an eye on the angular2 issue tracker and changelog.

Hey, I'm still trying to learn good practices for mocking objects, so I have a question: why mock FirebaseAuth and not AuthProviders?


Network policies only take effect when pods are assigned to the same node

I configured it according to the network policy demonstrated in the official document, and found that sometimes it takes effect and sometimes it does not. After investigation, I finally found that this example only takes effect when busybox and nginx are assigned to the same node, and it does not take effect if they are not on the same node.
url: https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy/
As shown in the figure, the first part is completely done according to the demonstration of the official document, just to keep the busybox container without '--rm', which can be seen through the command 'kubectl get pod, node -o wide', the first part busybox and nginx are always on the 'worker-130' node, and the expected result is correct. However, in the second part, I forcibly dispatched nginx to 'worker-131' and immediately lost the connection.

What did you expect to happen?
Network policies should not only take effect when the test container and the container under test are on the same node.
How can we reproduce it (as minimally and precisely as possible)?
There are screenshots above
Anything else we need to know?
No response
Kubernetes version
1.24.4
OS version
Ubuntu 20.04.5
Install tools
kubeadm
Container runtime (CRI) and version (if applicable)
runtime: containerd 1.6.16
Related plugins (CNI, CSI, ...) and versions (if applicable)
cni: calico 3.24.1
IPpool：

@AbelHugh I will try to recreate a similar setup and reproduce, but could you send some more details? Do you have any firewall running? Are your nodes bare-metal, or are you using some kind of containers for your setup (e.g. KIND)? Could you share the output of ip route on your nodes? Also logs from calico-node pods could be helpful...
Finally, is there a specific reason you need IPIP mode 'CrossSubnet'? Would it be possible to change it to 'Always' and try again?

We haven't managed to reproduce the issue on our end, closing it as it's inactive since May. Feel free to reopen with more info if you're still facing it.


Move exceptions to BatchResult

I am coming up with this solution again. If we decide to merge #60, we should consider merging this one as well.
Based on how the BatchRequest trait is created, it turns out that the current BatchResult-BatchException solution is not really efficient.
Moving everything to the BatchResponse (again) makes it easier to collect everything in one place and think later about exceptions.
This solution also allows to wrap existing batch objects in cases a client supports parallel execution (like in case of guzzle6)
I also think that the API is easier to read this way. We can also forget about the @internal docblock we added because Exceptions cannot be cloned.
To sum up, there are plenty of advantages to move exceptions to the BatchResult object.
What do you think?

:+1:

yeah, really looks simpler. so lets do this. should we keep a BatchException that can be used when at least one request in the batch failed and that gives access to the BatchResult? or do we just say when you batch then you need to manually check each response as there never ever will be exceptions thrown?

I would say the BatchException should still be there.