making Config configurable programmatically

The idea is that I want to be able to do:
    brigade = Brigade(
        inventory=SimpleInventory("../hosts.yaml", "../groups.yaml"),
        dry_run=True,
        config=Config(raise_on_error=False),
    )

I like the idea of this. However, one potential issue I see is that people can set their own config keys in this way. That might cause a problem if we introduce that key as a "real" config value in a later release.
This could be handled by only allowing keys that exist in CONF.
Or perhaps allowing users to set their own config keys in this way by using a prefix like _ or similar. That way we could also load "private" keys if someone sent in a yaml files containing those to the config.

However, one potential issue I see is that people can set their own config keys in this way. That might cause a problem if we introduce that key as a "real" config value in a later release.

Well, that's true for any class. They could do the same in any other class.

Or perhaps allowing users to set their own config keys in this way by using a prefix like _ or similar

I have been thinking about this and struggling with a decent solution. I think we shouldn't support what you suggest. We can provide "functions" to help configure an application (maybe even generalize the Config class so it can be reused) but what we are talking about is the object we pass to brigade so we shouldn't allow misuse. I'd suggest merging this as is and then discuss on a different PR a generic config class for users and a set of functions to let them configure their in a similar way as brigade can be configured.
In summary, I am merging this one and open an issue to track this new feature :)


[WIP]:px4_fmuv5x: Basic config for ethernet.

Needs an update for nuttx, because f7 ethernet setup hangs in
a busy wait because MAC does not reset without a clock.(Hw not yet fixed)

Completed in https://github.com/PX4/Firmware/pull/12666


keybase-gui: 1.0.25-20170714172717.73f9070 -> 1.0.33-20171003193427.d…

…9ceb86ac
Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] Linux

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

#30098


Bug: Type collision

Hasura let's you specify big integers that are exposed on the GraphQL endpoint with type bigint.
Given that bigint is a reserved word in typescript (see here), the following generated code breaks:
export type bigint=any

It gives a Type alias name cannot be 'bigint' error.
Possible solution
To work around this scalars can be defined like GraphQL codegen does:
export type Scalars = {
  ID: string,
  String: string,
  Boolean: boolean,
  Int: number,
  Float: number,
  uuid: string,
  bigint: any,
};

So that they are used like this: Scalars["bigint"].
As a cool addition, you can make scalar types configurable e.g.
{
  uuid: "string",
}

So they are typed correctly and you don't loose type inference due to the use of any

Now you can pass custom types with the -S or --scalar flag


spyder on linux won't auto load numpy and others

From<EMAIL_ADDRESS>on 2010-05-29T14:11:25Z
I saw that when you run spyder on windows it auto loads some modules.
I'd like to be able to determine which modules are auto loaded to the
interactive console.
Would be great to have some configure options where I can specify the
import names like:
import numpy as np
import matplotlib as mpl
import rpy as r
etc. etc.
Thanks,
Oz
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=224

From pierre.raybaut on 2010-05-31T01:17:32Z
There is absolutely no difference between the Windows and GNU/Linux versions of Spyder.
Actually this is exactly the same code that is running on both operating systems.
Try entering the following command to show all available options:
$ spyder --help
You'll have the same options as in Windows start menu's shortcuts.
Status: Done

From<EMAIL_ADDRESS>on 2010-05-31T07:56:24Z
Thanks, I missed it !


Add env vars to configure the smol runtime threadpool size and name

I read the thread at #690 and this seemed like an easy change to make.
I tried to find a good balance between accurate-but-verbose (ASYNC_STD_RT_POOL_SIZE, ASYNC_STD_RT_THREAD_NAME) and concise-but-generic (RT_THREADS, RT_NAME).
Would people want to be able to optionally include the thread number in the thread name? I'm not certain why they would want to, but I believe I've seen that in other threadpools.  If so, the thread name variable might include some substitution placeholder.
docs:

I think we would want to document this in the top level docs and the task docs.
This looks good from my side, but it changes things, such that we now allog configuration, would like to get some feedback from @skade and @yoshuawuyts before merging

Added docs and a screenshot.
I was unsure if the documentation should explain the difference between parallelism and concurrency in an async environment, or trust that the reader understand that ASYNC_STD_NUM_THREADS isn't the ceiling on concurrency

Thank you @jbr lets get this in and see how it works out


Move settings to individual feature directories

This saves us having to muck around in the options page every time we change a feature. Each feature now has a settings.json file included in the folder which tells the system what to put on the options page, what the default value of the setting is, and what to do when the setting is various values.
This is a large change, so I wanted to do it through a PR instead of whacking it straight into master in case we want to change anything before it goes in.

Cool, I can take a look. FYI - I won't get a chance to experiment with this/review for probably another 10-12 hours from when I submitted this comment.

@blargity I wouldn't let #135 and #136 hold back the scheduled release of 0.3.5 on Wed. These changes are important but they are transparent to the user, so if it takes the team a little bit longer to review and this doesn't go out until 0.3.6 I think that it should be okay.

I haven't had a chance to experiment with the build yet, but this shouldn't have any conflict with #135. But, I also don't see anything auto building/populating the feedChanges.js file yet.
I don't have python skills to make the proposed changes myself, but it looks like it should be simple enough to add the appropriate try...catch statement in the feedChangesjs file if the python script finds that the settings.json file contains a reference to injectScript.
Or maybe there could be a seperate entry that is in the settings.json template by default and if a dev doesn't want or need to use the mutationObserver, they can delete the entry to save some overhead by avoiding a needless try...catch statement in the feedChange.js file
And as you said before, feedChange.js can just be another build artifact that could be added to .gitignore.

Yup, that's right @Niictar, this is just the changes for settings.
My plan was to get those right while you were refactoring the feedChanges.js file, then when you were done generate that out as well. I'll be able to do the rest tonight if you're happy with the settings stuff. I may leave it as a PR until after launch, or might just launch tonight so we have a bit more time to test this stuff before it hits primetime.

Poked around with this and gave it a quick test and it seems good to me. The only thing a little discombobulating was that the features appear in the options page in a different order than before (now it's alphabetical) which I don't see as a bad thing. It worked fine with the refactor from #135 merged in as well, so unless you hear back from anyone else, this is probably good to go!

Oh, I found an issue. Egens introduced inside the /src/main.js file
injectJSString("ynabToolKit.options= {" + Array.from(kango.storage.getKeys(), el=> el + " : " + kango.storage.getItem(el) + ", ").reduce((a, b) => a + b, "") + "}")

Several parts of Days of Buffering is expecting that object present and it breaks without that line present after ynabToolKit = {} is injected in /src/main.js.

@Niictar is it necessary to remove this string? It's global tweak to help features get their options.

@egens, Nope, it's not necessary to remove it. I'll add it back in and move the stuff I make back to ynabToolKit.settings.
Thanks for the pickup @Niictar, I'll sort that out.

Actually just figured out why it was a problem and why I removed it originally. Safari doesn't let us access the kango APIs synchronously.
I'll refactor it to be async and we should be good then.

Alrighty, DoB works for me at this point. The async code is harder to follow but thankfully we won't have to edit it that often. Does this work better for you guys?

Guys, more bad news about safari:
http://caniuse.com/#feat=arrow-functions
So I'm currently going through and replacing all => with nice ugly function(el) {return ... ; } I'm tempted to ES6 parse as part of our build script! lol

I decided to go ahead and release 0.3.5 tonight so this can be a part of 0.3.6 without slowing us down and we can have a bit of time to play with it ourselves before release.
I'll merge if you guys are happy with what you see now.

Just pulled the latest updates to this PR. Things look good.

Great, I'll merge it on in and Python a-go-go to Act changes.


create ecl search from ecl string api

combination of eclSearch and eclToIMQ with error handling

already covered by adding an ecl string to node_api/public/eclSearch


Prevent double forward slashes in download URLs

For this asset, the given repo URL ends with a forward slash: https://github.com/brunosxs/SMRT-Godot/
That generates a download URL that has two slashes: https://github.com/brunosxs/SMRT-Godot//archive/1.0b.zip
This should be fixed either by stripping the trailing slash from the repo URL, or ensure not to prefix another slash if there's one already (first solution likely simpler).

BTW the submission page gives an example with a trailing slash too: https://github.com/<user>/<project>/


Couple of questions on serenity interactions, tasks.

Hi everyone,
My issues:

So I have a feeling like serenity js is missing some of the most basic interactions. Not only I mean the obvious gaps like Hover.over(target: Target), but some more complicated ones like:

Click.on(target: Target).if(condition: boolean),
Expect.target(target: Target).Class.toContain(expectedClass: string),
Expect.targets(targets: TargetArray).Text.toEqual(expectedTextForEveryTarget: string), etc.
So I do have to create all the interactions myself, which makes me write protractor code anyway and I'm just starting to miss all the screenplay pattern concept, as it is looking more and more like good old page object pattern.

In the issue above I've presented the type TargetArray (equivalent of ElementArrayFinder in protractor), but I don't see such invention in serenity js. It would be super useful when you have a grid or something and you need to validate values from this grid.

I completely stopped using tasks, as complexity of the project was increasing, because it was much more nicer to create API-like interactions, such as:

ValidateGrid.Rows.ToHaveValues.BiggerThan(value: number)
And creating tasks just not allow me to do such a thing.

What are your thoughts? Am I just missing something?
Regards,
Jacek

Hi @emosGambler!
The recently released Serenity/JS 2.0 ships with additional interactions, such as Hover.
Other examples from your original post can be addressed as follows:
Conditional logic
The following logic:
Click.on(target: Target).if(condition: boolean),

can be expressed as:
import { Check, equals } from '@serenity-js/assertions';
// other imports

actor.attemptsTo(
  Check.whether(something, equals(true))
    .andIfSo(Click.on(target) /* , ... other tasks */)
    /* optionally */ .otherwise(/*... tasks if condition not meet */)
);

using:

an interaction to Check
expectations from the @serenity-js/assertions module

Asserting on CSS classes
The following logic:
Expect.target(target: Target).Class.toContain(expectedClass: string)

can be expressed as:
import { CSSClasses } from '@serenity-js/protractor';
import { Ensure, contain } from '@serenity-js/assertions';

actor.attemptsTo(
  Ensure.that(CSSClasses.of(target), contain(expectedClass)),
);

using:

question about the CSSClasses
expectations from the @serenity-js/assertions module

Asserting on text of multiple elements
The following logic:
Expect.targets(targets: TargetArray).Text.toEqual(expectedTextForEveryTarget: string)

can be expressed as:
import { Ensure, equals } from '@serenity-js/assertions';
import { Text } from '@serenity-js/protractor';

actor.attemptsTo(
  Ensure.that(Text.ofAll(targets), equals([ 'text of element 1', 'text of element 2' ]))
)

using:

question about the Text.ofAll elements
expectations from the @serenity-js/assertions module

Hope this helps!
Jan


fail to install requirement

I meet this error when I use pip install -r requirements.txt in an empty environment:
ERROR: Cannot install -r requirements.txt (line 28) and robot-gym 1.0.0 (from git+https://github.com/TimSchneider42/robot-gym.git@d745c9018c5acc872bedfa4589c7b5bda3c296b1) because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested robot-gym 1.0.0 (from git+https://github.com/TimSchneider42/robot-gym.git@d745c9018c5acc872bedfa4589c7b5bda3c296b1)
    sisyphus-env 1.0.0 depends on robot-gym 1.0.0 (from git+https://github.com/TimSchneider42/robot-gym.git)

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts

This problem could be solved by removing robot-gym in requirement.txt. Changing the git version constraint also solve it.

Thanks for raising this issue! I followed your recommendation and removed robot-gym from requirements.txt completely.

Besides, I just found another running problems. The code need to run such as:
python main.py new -e ball_f02h0 --total-episodes 10000 -i mutual_information

But the README now is lack of parameter 'new' or 'resume'

You are right, "new" is missing in the readme in all of the commands. I fixed it now.


clean up and fix publish script

Change

fixed publish script to work with submodule
did some clean up to remove useless files

@xlc @tj4laminar just wanna double check this folder eth-rpc-adapter/docker is not used by anything, right? I remember it was for some very early testing, so I removed it

Yeah I think should be fine.


release new tag to support bower

Great package, thanks!
Currently when installed via bower the package is being fetch without bower.json file. Please release a new tag with bower.json included.
Check the tree at 0.0.10 state - it has no bower.json https://github.com/aishek/jquery-animateNumber/tree/v0.0.10
Thanks!

I've released new tag with bower.json included. Also added jquery-animateNumber to npm registry.
@okendoken everything is fine now?

@aishek yep, all is good. Thank you!


Frontend Backend communication flow research

Acceptance Criteria

Document the communication flow between frontend and storage

Document the API endpoints needed

Design document: https://docs.google.com/document/d/1aoL5s-1X4AB7NKxSE-6hbOlTIueow2EitdnaEYcDaAA/edit

when storage content is pulled

when storage updates are issued

Link to subfeature: https://jinaai.productboard.com/feature-board/planning/features/7115710


Arcade ExcludeFromSourceBuild and auto-exclusion issues

In the preview8 update, projects which should have been detected as tests (R2RTests, ILCompiler.ReadyToRun.Tests, pretest) were not and had to be removed with patches.  We are also still seeing failures of ExcludeFromSourceBuild in SDK, and F#.  Investigate these issues and fix in Arcade.

Closing dupe due to GitHub weirdness, see #1736.


Update docker compose

Updated docker-compose-smile-traefik.yml and docker-command-smile-traefik.sh has been saved to box folder


Where is the Factory reset code?

where is the sinobit equivalent of BBC-MicroBit-First-Experience-1460979530935.hex?
https://support.microbit.org/support/solutions/articles/19000021613-first-experience-demo-program

It seems to me that copying
https://github.com/sinobitorg/software/blob/master/Test%20code/Mbed-LED-Matrix.hex
to the MINI drive on the sino:bit restores the behavior as delivered.
I don't know if this is equivalent to the MicroBit demo program, though.


Add X509_PUBKEY_set0_public_key()

This is needed to support central (server-side) key generation in CMP.
There the clients expresses its desire to obtain a public key of a given type by providing a "public key" structure that just has the wanted parameters but no actual encoded data,
as specified in https://datatracker.ietf.org/doc/html/rfc4210#appendix-D.4:
   crm[1].certReq       present
      certTemplate
      -- MUST NOT include actual public key bits, otherwise
      -- unconstrained (e.g., the names need not be the same as in
      -- crm[0]).  Note that subjectPublicKeyInfo MAY be present
      -- and contain an AlgorithmIdentifier followed by a
      -- zero-length BIT STRING for the subjectPublicKey if it is
      -- desired to inform the CA/RA of algorithm and parameter
      -- preferences regarding the to-be-generated key pair.

This is implemented by extraction of code from X509_PUBKEY_set0_param().
On this occasion, partly refactor ASN1_STRING handling in libcrypto.

(y)

This should be ossl_asn1_.....

Ah, right - done.

(The asn1_string_to_time_t should have also been done this way..) - Not really part of this PR..

I have a script that can do such simple renaming automatically.
Done, in a separate commit.

Thank you @t8m for reviewing and approving #18667 and some further recent PRs.
May I ask to also have a look at this one?

@slontis, since you gave good comments on this PR, can you please give the 2nd approval?


Fixed actors tests failures with Cosmos DB

Actor tests are currently failing on master when running against Cosmos DB (example)
TLDR
The issue was caused by a combination of two bugs, including one that was fixed in #6186.

#6186 brought in a new version of components-contrib which fixed a critical bug in Cosmos DB, where etags (and first-write-wins) were being ignored in transactional operations (possible data loss)
A separate, prior bug in the runtime caused the actor reminders metadata document to be stored with the incorrect partition key. This was not much of a problem (although could have facilitated race conditions), until the bug above in Cosmos DB was fixed.

Detailed description
The issue was caused by two bugs that, while both present, "neutralized" each other (but with potential for critical failures).
First bug
As part of dapr/components-contrib#2427, the companion PR to #6186, a bug was fixed in the Cosmos DB component.
In transactional operations (the Multi() method), when adding an upsert operation to the batch, the options object which contains options such as the ETag to use and whether to use first-write-wins was not actually added to the batch operation:
https://github.com/dapr/components-contrib/pull/2747/files#diff-72645ea5cedbaa35da8ead1ddfa8dfe4f1a0fb08a7dc3f105975ae77ff965f35R531-R556
It's unclear when this bug was added, but I can find it in the source code for Dapr 1.9 too: https://github.com/dapr/components-contrib/blob/release-1.9/state/azure/cosmosdb/cosmosdb.go#L394
Although the bug was fixed without much thinking, I realize now that was a critical bug: it caused upsert operations within a transaction to succeed regardless of etags and first-write-wins. This has likely been causing data loss.
Second bug
The second bug is in the runtime. When retrieving the actor reminders metadata document, the query did not contain the partition key. Tthis is the code from release-1.10:
https://github.com/dapr/dapr/blob/release-1.10/pkg/actors/actors.go#L1358-L1360
The Cosmos DB component behaves so if the partition key is missing, it uses the key name as partition key. In this case, the Get operation was trying to retrieve the document with partition key actors||actor_type||metadata.
However, when the reminders metadata document was stored, its partition key was actors||actor_type. From release-1.10, stateMetadata is the same for both the reminders and metadata documents:
https://github.com/dapr/dapr/blob/release-1.10/pkg/actors/actors.go#L1459
Because the partition key was missing, the reminders metadata document was always returned empty.
The two together
When storing a reminder, the flow is:

Retrieve the metadata and reminders documents
Update the state in-memory
Save the metadata and reminders documents

The save operations use both an etag and first-write-wins. When both are set, state store components behave this way (as certified by conformance tests):

if an etag is set and not-empty, they will only save if the etag matches
if an etag is unset or empty, they will save only if the document doesn't exist (first-write-wins)

This is where the issues popped up for Cosmos DB:

In step 1, the runtime retrieved the metadata document, but because the Get operation used the wrong partition key (actors||actor_type||metadata) (bug 2), it was returned empty. The runtime had thus no etag for the metadata document.
In step 3, the runtime was saving the metadata document with the empty etag and first-write-wins, using the partition key actors||actor_type (and key actors||actor_type||metadata).
Because the etag was empty, a write should have failed due to first-write-wins: a document with that key and partition key actors||actor_type already existed.
However because of Bug 1, Comsos DB was ignoring first-write-wins (as well as etags), so it just overwrote whatever metadata document could find with the key actors||actor_type||metadata and partition key actors||actor_type.

/ok-to-test


Ecto.Changeset.no_assoc_constraint/3 doesn't generate errors with PostgreSQL

Environment

Elixir version (elixir -v): 1.3.4
Database and version (PostgreSQL 9.4, MongoDB 3.2, etc.): PostgreSQL 9.1.19
Ecto version (mix deps): 2.0.6
Database adapter and version (mix deps): postgrex 0.12.1
Operating system: Ubuntu Linux

Setup
defmodule User do
  use Ecto.Schema

  schema "users" do
    has_many :transactions, Transaction
  end
end

defmodule Transaction do
  use Ecto.Schema

  schema "transactions" do
    belongs_to :user, User
  end
end

# create user
user = Repo.insert! %User{}

# create transaction for that user
Repo.insert! %Transaction{user: user}

# delete user
user
|> Ecto.change
|> Ecto.no_assoc_constraint(:transactions)
|> Repo.delete

Current behavior
Raises a Ecto.ConstraintError
Expected behavior
Sets an error in the changeset.

Thank you for the report. Can you please show me your migration code as well?

Actually, nevermind, I totally know where the issue is. :) It is related to your PG version.
Can you please try running Ecto's PG test suite? Something like this: MIX_ENV=pg mix test. You may see failures related to constraints, if so, they are due to the parsing code here: https://github.com/elixir-ecto/ecto/blob/master/lib/ecto/adapters/postgres/connection.ex#L30-L54

@ThijsWouters I started a branch that runs 9.2 tests on CI and I was able to reproduce the failures: https://github.com/elixir-ecto/ecto/pull/1845
I am working on a fix. :)

Great, thanks!

I tried it and it works now. Thank you!!


Make the last step a step in Mirroring a repo sect

To make it more clear that the final push is required, it might be better to number that step as well. Combined with the extra? line break between the terminal commands in step 3 and "As with a bare clone..." it was confusing at first glance.

Why:
Closes [issue link]

What's being changed:

Check off the following:

[x] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

@jacola
Thanks so much for opening a PR! I'll get this triaged for review :zap:

#11747


consistent variable names and capitalization

Let's try to agree on the variable names and capitalization rules for all terms in the library. PEP8 is a good place to start, but it may be reasonable to break those rules for some terms.
I don't expect that we can come to agreement on everything in this issue, but let's at least write down the terms and rules for which we do agree and change the code to reflect whatever consensus emerges.
A wiki would probably be a good place to put the results.
In no particular order, here are some problems that I'm aware of:

Acronyms such as DNI, GHI, DHI, AOI.

Beam irradiance and similar could be Eb, beam, beam_irrad, irrad_beam. I know that at least two those are currently in use.

diffuse, sky_diffuse, diffuse_ground, In_Plane_SkyDiffuse, aoi_projection, etc.

airmass, AM, or am? I think we may be using all three. How do we use a modifier like relative or absolute?

lat, latitude

tz, TZ

surf_az, surfazi, surfaceazimuth

Variables that are closely tied to a particular equation (see many of the pvsystem functions).

temp, T, Tcell.

Vmp, V_mp, vmp, v_mp.

Fixing this without breaking things requires good tests.

I would use existing conventions like PEP8 because this is easier for new contributors. For variable names I like the convention table of pylint: http://pylint-messages.wikidot.com/messages:c0103
Pylint is a program to check your code. It marks all lines where you broke the rules. You can integrate pylint in many IDEs or editors (http://docs.pylint.org/ide-integration) or use it as a standalone tool to check your modules.
Breaking the rules makes it more difficult for contributors from other projects.
But it's your project, if the convention is clear I will keep to the code.

I'll put a few of my preferences here, going from perhaps least to most controversial.
Everything that is not an acronym or a complicated variable in an equation should be lower case. This is just good PEP8, and most of the code actually follows this already. Of the list above, the only change would be that In_Plane_SkyDiffuse becomes in_plane_skydiffuse or similar.
Airmass should just be called airmass since it's one word and it's not that long.
Up to about 10 characters, I prefer longer names to shorter names. So, I prefer to spell out words like latitude and longitude.
I like diffuse_ground over e.g. diff_gr, but I like surf_az over surface_azimuth. I can't justify this.
I would make most (all?) acronyms lowercase, including dni, ghi, aoi, tz, etc.
Use of terms like V_mp should minimized, but it's probably unavoidable for complicated variables in complicated equations and I'm not sure what the appropriate rules should be.
We may also consider that rules for parameters and returned values could be different than rules for the code. Abbreviations and acronyms can make code more readable.
@uvchik It's very much a community project, a few of us just have push privileges.

It would be great, if we could agree on naming conventions! And we could have something like a table of definitions in the wiki or documentation.
In a first step these definitions coul be used by developers.
As an idea, they could possibly also be used by users in the future, if we would switch to dataframe inputs for some functions or a different kind of api. This would enable us to include som e "magic" functions, e.g the signature of the ominous globalinplane function could look like this:
def globalinplane(df, surface_tilt, surface_azimuth, diffuse_model='perez',
                  decomposition_model=None):
    """Determine GPOA from either GHI and DHI or from GHI only

    Parameters
    ---------------
    df : pandas.DataFrame
          A DataFrame containing all necessary columns acoording to naming conventions
          (maybe surface_tilt and surface_azimuth could also be contained in the df,
           e.g. for tracking systems.)
    decomposition_model : None or str
          The model to use if only GHI is given in the DataFrame
    ....
    """"

This function could look which columns are in the DataFrame and compute all necessary columns (e.g. if time is given as local time, compute utc or true solar time).
From my experience this is usefull for beginners because there are quite a lot of simulation steps required to calculate GPOA from GHI (maybe convert times, decomposition in direct and diffuse, diffuse model, ground reflection, direct tilted, ...?).
This is just an idea, not sure about the difficulties. There may be some complexity when implementing something like this (more on the definitions, not necessarily from a programmers point of view) and maybe this is difficult to explain to users.

For pylint we could include a pylintrc in the repository.

Yes, I would really like to see some new high level functions that utilize the API and standardizing names will make this much easier. I'll suggest a new issue(s) for scoping out those functions, though.
I'm ok with adding a pylintrc or similar file, but I want to be pragmatic about this. I think that using good PEP8 practices for API-relevant things is a lot more important than removing extra spaces from the end of lines or putting spacings between every operation or after item in list (which can often reduce readability, in my opinion). I think that the important PEP8 rules are too often drowned out by many silly violations. Maybe you all have had better experiences and can show me the way.

I agree with @wholmgren, that it is easier to read the code if the variables are spelled out. Abbreviations are okay for often used phrases like diffuse but we should avoid them. Maybe we could create a table with the most important variable names, so that we and all new developers get an overview of how the naming works. Example: Variables-and-style-rules

I really like the rules, even though my own rule would be different. But everybody has his own preferences and discussions about these rules can be very long. I my experience it is very useful to follow PEP8, because you get used to that style. After a while it was a lot easier for me to read foreign PEP8-code then non-PEP8-code. The less exceptions, the less discussion, the less confusion.

I definitely like the idea of @bmu to write a magic globalinplane function, but could you create a new issue (feature) for that.

The table is a good start. Can you keep going with your specific suggestions for the rest of the parameters discussed above? I'll add mine after that. I think we all agree that we should follow pep8 but that still leaves room to differ on some parameters.

Hi Folks, I agree with the conversation above, and think that for the majority of the time we should be sticking to PEP8.
However, another topic came into this thread, which is to look at implementing a dataframe input method for the functions. This is a topic that came up earlier in the project, that we decided to steer away from, though it could be revisited. I've opened up a new issue to talk about this  #39

I think the variables should be lower case but I'm not sure with the keys of the DataFrame. They could be camel case. It might make things even clearer in the documentation but I'm not sure. I updated the wiki. What do you think? Please add or comment.

a question:
Alternatively to the wiki the variables could be added to the documentation or dedicated module where variables will be defined as a dictionary or table...
Offeres the possibility to use it in the documentation or even the code.

@uvchik The wiki looks nice, and I'll add some comments there. I would say that we should try to be consistent between function parameters and the DataFrame keys. I think most people would wonder why the function outputs are formatted differently than the inputs, but I could be wrong about that. Trying to stay consistent also makes it possible to use the **DataFrame technique discussed in #39.
@dacoex I don't fully understand your comment, but we can add a table of variable definitions to the sphinx documentation. Let's wait to come to agreement on most of them before doing this.

Here's a PVPMC page that's worth reviewing, although I do not suggest that we follow these definitions for our code.

I removed the 'key' column. So variable names and key names will be the same.
We have to decide whether we want the 'e_*' or not.
I totally agree that the result of this discussion should be added to the documentation.
@wholmgren This is a basic decision. Do we want variable names that are close the symbols used in equations or do we want longer "talking" variable names. I prefer the longer names.

I also prefer the longer names.
On Wed, Mar 25, 2015 at 3:12 AM ukrien<EMAIL_ADDRESS>wrote:

I removed the 'key' column. So variable names and key names will be the
same.
We have to decide whether we want the 'e_*' or not.
I totally agree that the result of this discussion should be added to the
documentation.
@wholmgren https://github.com/wholmgren This is a basic decision. Do we
want variable names that are close the symbols used in equations or do we
want longer "talking" variable names. I prefer the longer names.
—
Reply to this email directly or view it on GitHub
https://github.com/pvlib/pvlib-python/issues/37#issuecomment-85969916.

I really dislike e_* form of irradiance names. e doesn't mean irradiance to
me, it means energy generated with volts and amps.
I'm a lazy typist, but there are so many common notations for irradiance, i
think it is probably better to write them out. Me, I prefer ghi, dhi, dni,
poa_global, poa_beam, poa_diffuse but could see spelling out the
abbreviations if the consensus went that way.
On Wed, Mar 25, 2015 at 6:45 AM, Will Holmgren<EMAIL_ADDRESS>wrote:

I also prefer the longer names.
On Wed, Mar 25, 2015 at 3:12 AM ukrien<EMAIL_ADDRESS>wrote:

I removed the 'key' column. So variable names and key names will be the
same.
We have to decide whether we want the 'e_*' or not.
I totally agree that the result of this discussion should be added to the
documentation.
@wholmgren https://github.com/wholmgren This is a basic decision. Do
we
want variable names that are close the symbols used in equations or do we
want longer "talking" variable names. I prefer the longer names.
—
Reply to this email directly or view it on GitHub
https://github.com/pvlib/pvlib-python/issues/37#issuecomment-85969916.

—
Reply to this email directly or view it on GitHub
https://github.com/pvlib/pvlib-python/issues/37#issuecomment-86031950.

I like poa*. Feel free to edit/add to the wiki.

I would add a "_rad" if an angle is in radiant and not degree, but I wouldn't add a "_deg" for degree.

@uvchik that seems reasonable. Do we have any pvlib functions that use radians for inputs and outputs?

The updated table looks good. I like the longer dni_extra, the item-modifier pattern used in airmass_[relative|absolute] (most other variables are now listed this way), and the solar_zenith since we use "solar" more often than "sun".

If you're only seeing this via email, now is a good time to look at @uvchik's updated table and let us know what you think. @uvchik and I have dominated the discussion here, but I don't want all of pvlib-python's naming conventions to be determined by our preferences.

I agree with your conventions, especially to use longer "talking" names. Here are my thoughts on some of the the bold ones (I have no preference for the other bold ones) in the wiki page and some other comments:
tz or timezone
I am not sure, if this is a good name in general, as we can have time stamps given as UTC, really related to a time zone, local time (without DST), mean solar time, true solar time, ...?  This is not meant as a philosophical comment, but is an everyday problem from my experience, so we should be able to handle all of these formats (at least in the future, for now maybe it is ok to define, that all times should be given as UTC).
Maybe time_reference (it should be decided by a native speaker ;-)?
dni_et
I like extra, should be used as index for all extraterrestrial irradiances. not sure if "direct" is a good name for extraterrestrial irradiance. However it is important to separate "normal", "horizontal" or "poa" extraterrestrial for some models (this was often a source of error for me, because I didn't cached which one was meant in the models).
global, direct and diffuse in general
Maybe it is better to have a more general rule, e.g to to use g (global), d (diffuse) and b (direct or beam) and than an index. Indices could be normal, hor (horizontal), tilted and poa (which is a special case, if it is not clear / not important if it is tilted or normal, e.g. for single axis tracking).
However, I am not sure on this rule, because the names would be different from the usual ones like DNI (would be b_normal) , GHI (would be g_hor), ... (but it would be more systematic).

I prefer to use the common names like dni and ghi and beside that use systematic names like poa_diffuse, poa_global. But i could live with both variants.
I don't know how to bring about a decision.

tz and timezone: There was a lot of discussion in #47 concerning how pvlib should handle time zones and/or time references. I believe that the conclusion is that it's ok to rely heavily on the pandas functionality and thus keep using the idea of timezones instead of inventing a new concept such as a time_reference (at least for now). So, we are back to deciding on tz vs timezone and, unless there are objections, we are going to go with tz since that's what pandas uses.
I appreciate @bmu's desire to make the ghi, dni, and so on more systematic, but I agree with @uvchik's preference for common names.
I moderately support @jforbess's proposal for v_mpp, i_oc etc. since they're so commonly used and often so long otherwise. Perhaps non-native english speakers have other abbreviations and would prefer longer, more explicit names?

English abbreviations are common even for non-native speakers (at least in Germany), I think. For the radiation names, the only really common names are GHI and DNI (or ghi and dni). v_mpp, p_mpp and so on, sounds good to me.

Made some small updates to the wiki. We'll go with @jforbess's abbreviated names.

Added more parameters. I'm open to last-minute appeals for cell/module parameters: Voc vs. voc vs. v_oc or Rs vs. rs vs. r_s etc. The only thing I don't like is V_oc since that requires using the shift key twice.
@jforbess you previously had a strong opinion about e_* for irradiance names. What about for effective irradiance?

I prefer poa_beam_eff, rather than eff_poa_beam, if that's the question. I
haven't thought hard about how it flows through modeling, but I would want
access to poa adjusted for shading, soiling, IAM, and spectrum each
individually for model development, don't you think? Not sure if you
consider shading and soiling as appropriate to adjust poa in this way,
because I think it makes some sense physically, but not completely.
PVsyst supplies this through a ratio of Shd_Loss_Factor or similar, rather
than providing POA_adj for each factor. Though I guess they also do provide
lost kWh due to most of those factors.
On Mon, Jun 22, 2015 at 11:25 AM, Will Holmgren<EMAIL_ADDRESS>wrote:

Added more parameters. I'm open to last-minute appeals for cell/module
parameters: Voc vs. voc vs. v_oc or Rs vs. rs vs. r_s etc. The only thing
I don't like is V_oc since that requires using the shift key twice.
@jforbess https://github.com/jforbess you previously had a strong
opinion about e_* for irradiance names. What about for effective
irradiance?
—
Reply to this email directly or view it on GitHub
https://github.com/pvlib/pvlib-python/issues/37#issuecomment-114170926.

Sorry, I was thinking of it in the context of the SAPM's effective irradiance parameter.

I think this issue can be closed. The last one for 0.2 so far.

I'll close it with the expectation that it will be reopened or a similar issue will be created for undiscovered inconsistencies.

Just a quick question:
for the ration poa_global to ghi do you prefer:
Transposition factor (PVSyst Glossary ) or poa_gain

Transposition factor
From: DaCoEx<EMAIL_ADDRESS>Sent: Tuesday, January 05, 2016 6:52 AM
To: pvlib/pvlib-python
Subject: [EXTERNAL] Re: [pvlib-python] consistent variable names and capitalization (#37)
Just a quick question:
for the ration poa_global to ghi do you prefer:
Transposition factor (PVSyst Glossary )http://files.pvsyst.com/help/transposition_factor.htm or poa_gain
—
Reply to this email directly or view it on GitHubhttps://github.com/pvlib/pvlib-python/issues/37#issuecomment-169006234.

I also prefer transposition factor.

Interesting. I see too much risk of mixing its abbreviation (TF) with thin-film.
Shall we add it to the list, then?

We try to avoid abbreviations in pvlib, so I don't think it's a problem. There is a function in irradiance.py that would need updating. It currently uses poa_ratio.

ok, but it's a very long column name either ' transposition factor'

We have a lot of long variable/column names. Only the most obvious quantities are abbreviated. Most (all?) of the people that originally participated in this discussion supported longer names over abbreviations.

OK, so assign it to me and I will add it when finalising
https://github.com/pvlib/pvlib-python/pull/103


Define next steps

Myself and @wdduncan can help out here but it would be good to have an idea of the plan moving forward, and some more documentation of the 3 different schema files and their intended purposes.
(Sorry for the vague ticket, I will update later, wanted to file before forgetting)

I am about to file some initial tickets for first steps, and we can also flesh this out at our first call on Dec. 9 (pending).

We now have other tickets and a new repo. @cmungall can you please close this issue?


Allow to insert only year of citation with Zotero plugin

The most commonly ways of citing a paper are citing the full author at the end of the sentence or citing only the year:
[....] (Müller et al., 2015)
[...] as shown by Müller et al. (2015)
The second option is currently not possible with the Zotero plugin. In Libre Office you can click on the citation you wish for and edit it, so only the year is shown.

Hello!
@JohannesWiesner, I have ticket #62172 with your proposal.
Thank you for report.


Standalone Radius dashboard

Overview of feature request
As a developer or IT operator, when deploying an application using Radius, I would like Radius to also deploy a single-container simple dashboard that displays a visualization of my application graph data so that I may view a summary of my application's architecture. Additionally, I would like the option to opt-out of this dashboard deployment.
As a developer or IT operator, I would like the application graph visualization in the Radius dashboard to be automatically updated as changes are made to the applications and their resources, so that I can always have an up-to-date view of our architecture without needing to manually curate my software catalog.
Acceptance criteria
Step 1. Deploy an application and its resources, along with connections and routes using Radius.
Step 2. After running rad run to start the application, receive a network address for the application graph dashboard after the application resources and dashboard have completed deployment.
Step 3. Navigate to the application graph dashboard and view application graph visualization.
Additional context
Recommend implementing with Backstage in conjunction with #6952
AB#10767

Will the front-end architecture include reusable web components for use outside of the Radius host site? For example, I'd like to prefer to use one or more Backstage plugins and possibly never have to use the custom Radius front-end website.

Will the front-end architecture include reusable web components? For example, I'd love to see one or more Backstage plugins and never have to host or use the custom Radius website. In theory, Radius could just ship with a host for Backstage and build the front-end on top of it.


Errors on imports with .ts extension

There are quite a few errors, but I believe this is due to default export.
I will send a PR to fix these, but it may take some time as they are a bit numerous!

As it says "An import path can only end with a .ts extension when allowImportingTsExtensions is enabled", I think it is OK if you change ts.config, but I personally don't recommend it

I think it's ok to remove the extensions. Thank you for your help.😄

I am doing a code cleanup for the whole repo. So I think it will be better for me to address this issue along the way.

OK 👍

Fixed in #14

👍 👍


PDF Archive used in the Training Corpus

Is it possible to download an archive of the PDFs used to train GROBID?

Hello Christopher,
Sure the full set of PDFs is available online via Amazon S3 service. Please send me an email<EMAIL_ADDRESS>for the information for downloading them.


Add distributive condition to Assign util

Fixes #821 by adding support for components with union prop types.
https://www.typescriptlang.org/docs/handbook/advanced-types.html#distributive-conditional-types

Thanks, @jjenzz!


Upload file binary data

This PR:

Uses binary data to orchestrate multi part file uploads.
Is final version of https://github.com/Azure/azure-sdk-for-java/pull/29277
Is based on https://github.com/Azure/azure-sdk-for-java/pull/29797 and https://github.com/Azure/azure-sdk-for-java/pull/29805

API change check
API changes are not detected in this pull request.


Compile error

First, thank you for you to release this good project. I can't wait to run it on my PC, but I got this error below:
src/direct_edge_imu/src/rosPub.h:41:37: fatal error: quadrotor_msgs/Odometry.h: No such file or directory
#include "quadrotor_msgs/Odometry.h"
It seems that this error also happened in dense_new project, and it is commented out.
Thank you!!!!

I have added this header in the source files.

It works!
Actually, it also has a small compiler error and I fix it by myself.
In SlamSystem::para2eigen(), cur_P0 doesn't exist.
By the way, it seems that there is no visualization.


PTFE-821 Add commit message and labels

Hello martins926,
My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.
Status report is not available.

Waiting for approval
The following approvals are needed before I can proceed with the merge:

the author

one peer


Migration failed with package alias in package.json

Command
update
Is this a regression?

[ ] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
No response
Description
If package.json contains an npm package alias such as "@types/ol-ext": "npm<EMAIL_ADDRESS> the command ng update fails with error Migration failed: 404 Not Found - GET https://registry.npmjs.org/@types%2fol-ext - Not found
Minimal Reproduction

create a package alias by running npm i -D @types/ol-ext@npm:@siedlerchr/types-ol-ext
run ng update ng update

Exception or Error
Migration failed: 404 Not Found - GET https://registry.npmjs.org/@types%2fol-ext - Not found

in angular-errors.log i can see

[error] HttpErrorGeneral: 404 Not Found - GET https://registry.npmjs.org/@types%2fol-ext - Not found
    at C:\Users\[...]\node_modules\npm-registry-fetch\lib\check-response.js:95:15
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async RegistryFetcher.packument (C:\Users\[...]\node_modules\pacote\lib\registry.js:90:19)
    at async Promise.all (index 8)
    at async C:\Users\[...]\node_modules\@angular\cli\src\commands\update\schematic\index.js:656:36
    at async callRuleAsync (C:\Users\[...]\node_modules\@angular-devkit\schematics\src\rules\call.js:77:18)

Your Environment
Angular CLI: 18.2.3
Node: 20.13.1
Package Manager: npm 10.8.2
OS: win32 x64

Angular: 18.2.3
... animations, cdk, cli, common, compiler, compiler-cli, core
... forms, localize, material, platform-browser
... platform-browser-dynamic, router

Package                          Version
----------------------------------------------------------
@angular-devkit/architect        0.1802.3
@angular-devkit/build-angular    18.2.3
@angular-devkit/core             18.2.3
@angular-devkit/schematics       18.2.3
@angular-devkit/schematics-cli   18.2.3
@schematics/angular              18.2.3
rxjs                             7.8.1
typescript                       5.4.5
zone.js                          0.14.10

Anything else relevant?
No response

Duplicate of https://github.com/angular/angular-cli/issues/25224


Can't include library in a multiplatform project with JVM and JS (IR) targets

Execution failed for task ':core:compileKotlinMetadata'.
> Could not resolve all files for configuration ':core:metadataCompileClasspath'.
   > Could not resolve com.ionspin.kotlin:bignum:0.3.8.
     Required by:
         project :core
      > The consumer was configured to find a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'common'. However we cannot choose between the following variants of com.ionspin.kotlin:bignum:0.3.8:
          - androidNativeArm32ApiElements-published
          - androidNativeArm64ApiElements-published
          - androidNativeX64ApiElements-published
          - androidNativeX86ApiElements-published
          - iosArm32ApiElements-published
          - iosArm64ApiElements-published
          - iosSimulatorArm64ApiElements-published
          - iosX64ApiElements-published
          - jsIrApiElements-published
          - jsLegacyApiElements-published
          - jvmApiElements-published
          - jvmRuntimeElements-published
          - linuxApiElements-published
          - linuxArm32HfpApiElements-published
          - linuxArm64ApiElements-published
          - linuxMips32ApiElements-published
          - linuxMipsel32ApiElements-published
          - macosArm64ApiElements-published
          - macosX64ApiElements-published
          - mingwX64ApiElements-published
          - mingwX86ApiElements-published
          - tvosArm64ApiElements-published
          - tvosSimulatorArm64ApiElements-published
          - tvosX64ApiElements-published
          - watchosArm32ApiElements-published
          - watchosArm64ApiElements-published
          - watchosSimulatorArm64ApiElements-published
          - watchosX64ApiElements-published
          - watchosX86ApiElements-published
        All of them match the consumer attributes:
          - Variant 'androidNativeArm32ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'android_arm32' but the consumer didn't ask for it
          - Variant 'androidNativeArm64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'android_arm64' but the consumer didn't ask for it
          - Variant 'androidNativeX64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'android_x64' but the consumer didn't ask for it
          - Variant 'androidNativeX86ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'android_x86' but the consumer didn't ask for it
          - Variant 'iosArm32ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'ios_arm32' but the consumer didn't ask for it
          - Variant 'iosArm64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'ios_arm64' but the consumer didn't ask for it
          - Variant 'iosSimulatorArm64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'ios_simulator_arm64' but the consumer didn't ask for it
          - Variant 'iosX64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'ios_x64' but the consumer didn't ask for it
          - Variant 'jsIrApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'js':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.js.compiler' with value 'ir' but the consumer didn't ask for it
          - Variant 'jsLegacyApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'js':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.js.compiler' with value 'legacy' but the consumer didn't ask for it
          - Variant 'jvmApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares an API of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides its elements packaged as a jar but the consumer didn't ask for it
                  - Provides release status but the consumer didn't ask for it
          - Variant 'jvmRuntimeElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a runtime of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides its elements packaged as a jar but the consumer didn't ask for it
                  - Provides release status but the consumer didn't ask for it
          - Variant 'linuxApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'linux_x64' but the consumer didn't ask for it
          - Variant 'linuxArm32HfpApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'linux_arm32_hfp' but the consumer didn't ask for it
          - Variant 'linuxArm64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'linux_arm64' but the consumer didn't ask for it
          - Variant 'linuxMips32ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'linux_mips32' but the consumer didn't ask for it
          - Variant 'linuxMipsel32ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'linux_mipsel32' but the consumer didn't ask for it
          - Variant 'macosArm64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'macos_arm64' but the consumer didn't ask for it
          - Variant 'macosX64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'macos_x64' but the consumer didn't ask for it
          - Variant 'mingwX64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'mingw_x64' but the consumer didn't ask for it
          - Variant 'mingwX86ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'mingw_x86' but the consumer didn't ask for it
          - Variant 'tvosArm64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'tvos_arm64' but the consumer didn't ask for it
          - Variant 'tvosSimulatorArm64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'tvos_simulator_arm64' but the consumer didn't ask for it
          - Variant 'tvosX64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'tvos_x64' but the consumer didn't ask for it
          - Variant 'watchosArm32ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'watchos_arm32' but the consumer didn't ask for it
          - Variant 'watchosArm64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'watchos_arm64' but the consumer didn't ask for it
          - Variant 'watchosSimulatorArm64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'watchos_simulator_arm64' but the consumer didn't ask for it
          - Variant 'watchosX64ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'watchos_x64' but the consumer didn't ask for it
          - Variant 'watchosX86ApiElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a usage of 'kotlin-api' of a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
                  - Provides release status but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'watchos_x86' but the consumer didn't ask for it
        The following variants were also considered but didn't match the requested attributes:
          - Variant 'iosArm32MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'iosArm64MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'iosSimulatorArm64MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'iosX64MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'jsIrRuntimeElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'js':
              - Incompatible because this component declares a usage of 'kotlin-runtime' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'jsLegacyRuntimeElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'js':
              - Incompatible because this component declares a usage of 'kotlin-runtime' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'macosArm64MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'macosX64MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'metadataApiElements' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'common':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'tvosArm64MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'tvosSimulatorArm64MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'tvosX64MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'watchosArm32MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'watchosArm64MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'watchosSimulatorArm64MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'watchosX64MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)
          - Variant 'watchosX86MetadataElements-published' capability com.ionspin.kotlin:bignum:0.3.8 declares a library, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for non-jvm)

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

I've created a new mutliplatform JVM/JS(IR) project with kotlin 1.8.0 and 1.8.20 and bignum 0.3.8 and had no problems running it. Could you try doing that and see if you can replicate the issue? If you can please reopen this. Thanks.
I have one question though, I noticed you didn't use the template for submitting an issue, could you please share why?

I did the same and then slowly copied the settings over from my project and found the issue:
kotlin.mpp.enableCompatibilityMetadataVariant=true
A deprecated setting in our gradle.properties!
Thanks for the help.
As for the issue template I didn't have the energy left to read it at that point which I guess is often the case once you give up on a problem and resort to creating a issue 😅

Glad to hear you got it resolved!


Please add ComputeNode.bat to DC_ComputeNode

the DC_ComputeNode branch will serve as the package for compute nodes - it needs to have the computenode.bat batch file to initalize the computenode for ignite distributed computes
please add the file to version control on the DC_ComputeNode branch.

i dont understand why the fix or close notes dont work! very frustrating. sorry.


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_2a_lqvja6i/clone/recipe/meta.yaml:15: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_2a_lqvja6i/clone/recipe/meta.yaml:21: missing_wheel: For pypi packages, wheel should be present in the host section
WARNING: /tmp/abs_2a_lqvja6i/clone/recipe/meta.yaml:25: python_build_tool_in_run: The python build tool setuptools is in run depends
ERROR: /tmp/abs_2a_lqvja6i/clone/recipe/meta.yaml:42: missing_documentation: The recipe is missing a doc_url or doc_source_url
ERROR: /tmp/abs_2a_lqvja6i/clone/recipe/meta.yaml:42: missing_dev_url: The recipe is missing a dev_url
WARNING: /tmp/abs_2a_lqvja6i/clone/recipe/meta.yaml:42: missing_description: The recipe is missing a description
Errors were found


Collection hub build pipeline prototype

We'd like to deliver an example collection hub build pipeline to simplifying collection lifecycle management.  Eventually, we'll teach kabanero to react to GitHub events to drive this pipeline.

The same issue that @stephenkinder raised on the Collections board was closed by him with this comment: https://github.com/kabanero-io/collections/issues/171#issuecomment-560597448
Should this issue also be closed until it is decided what needs to be done. I don't want time and effort to be wasted doing this is it is deemed not needed at the moment.


Decide if we are still paying 5-0 runs or not and update text

Removed. We're not doing this any more.


Encrypt files with provided key & change encrypt content to take public key

This pull request changes the api of encryptContent to take a public key as an option instead of a private key to allow us to encrypt content for other parties.
It also includes @bodymindarts's pull request #429 which adds the ability to specify a public key for which to encrypt a file in the putFile options object.
I've also added unit test coverage for these changes.
You can test this by running the unit tests and linking this into an app and specifying a 3rd party public key.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: bodymindarts:x: larrysalibraYou have signed the CLA already but the status is still pending? Let us recheck it.

@bodymindarts Would love if you'd take a look at this too if you have a chance!

It certainly lgtm.  +1 for adding a test case!

@yknl Going to go ahead and merge this since @bodymindarts was so kind as to take a look. Thanks @bodymindarts


Support querying multiple sources

If multiple sources are available for a given argument, try to query
them sorted by the speed index, until one is sucessful. This change
introduces a SourceException type, to catch all exceptions ocurring
while querying a source (i.e. connection issues).
Solves OSPCRE-322

Added all CRE for reviewing. If everything is okay we can merge.


fptest.LogQuery causes test failure

Hi, the current implementation of fptest.LogQuery use Get APIs (e.g., gnmi.GetConfig). Get APIs use t.Fatal when there is an error. This means that logging statements can cause test failure which is not desirable and can be confusing. Here is an example that LogQuery causes the test fail at the setup stage.
https://github.com/openconfig/ondatra/issues/65
Can you please address this issue?

I'm looking at the LogQuery and I don't see where it calls t.Fatal. Can you show me where precisely?
https://github.com/openconfig/featureprofiles/blob/210dba59a5879f7be01af6005dcb62388198d2ac/internal/fptest/log.go#L103


My TWA is crashing multiple times.

My TWA is crashing multiple times. I am including some error text from play console dashboard. I am not android developer so I can not understand these errors.
Input dispatching timed out (Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up.)

android.support.customtabs.trusted.LauncherActivity

Input dispatching timed out (AppWindowToken{ac22d4d token=Token{d4e34e4 ActivityRecord{7a3d077 u0 com.example.kott/android.support.customtabs.trusted.LauncherActivity t2139}}}, Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up.)

android.support.customtabs.trusted.LauncherActivity

java.lang.RuntimeException:
  at android.view.InputChannel.nativeReadFromParcel (Native Method)
  at android.view.InputChannel.readFromParcel (InputChannel.java:148)
  at android.view.IWindowSession$Stub$Proxy.addToDisplay (IWindowSession.java:804)
  at android.view.ViewRootImpl.setView (ViewRootImpl.java:755)
  at android.view.WindowManagerGlobal.addView (WindowManagerGlobal.java:359)
  at android.view.WindowManagerImpl.addView (WindowManagerImpl.java:93)
  at android.app.ActivityThread.handleResumeActivity (ActivityThread.java:3834)
  at android.app.ActivityThread.handleLaunchActivity (ActivityThread.java:3009)
  at android.app.ActivityThread.-wrap11 (Unknown Source)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1700)
  at android.os.Handler.dispatchMessage (Handler.java:106)
  at android.os.Looper.loop (Looper.java:192)
  at android.app.ActivityThread.main (ActivityThread.java:6748)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:556)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:867)

android.app.RemoteServiceException:
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1922)
  at android.os.Handler.dispatchMessage (Handler.java:102)
  at android.os.Looper.loop (Looper.java:145)
  at android.app.ActivityThread.main (ActivityThread.java:6946)
  at java.lang.reflect.Method.invoke (Native Method)
  at java.lang.reflect.Method.invoke (Method.java:372)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:1404)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1199)

java.lang.RuntimeException:
  at android.view.InputChannel.nativeReadFromParcel (Native Method)
  at android.view.InputChannel.readFromParcel (InputChannel.java:148)
  at android.view.InputChannel$1.createFromParcel (InputChannel.java:39)
  at android.view.InputChannel$1.createFromParcel (InputChannel.java:37)
  at com.android.internal.view.InputBindResult.<init> (InputBindResult.java:68)
  at com.android.internal.view.InputBindResult$1.createFromParcel (InputBindResult.java:112)
  at com.android.internal.view.InputBindResult$1.createFromParcel (InputBindResult.java:110)
  at com.android.internal.view.IInputMethodManager$Stub$Proxy.startInputOrWindowGainedFocus (IInputMethodManager.java:723)
  at android.view.inputmethod.InputMethodManager.startInputInner (InputMethodManager.java:1353)
  at android.view.inputmethod.InputMethodManager.onPostWindowFocus (InputMethodManager.java:1606)
  at android.view.ViewRootImpl$ViewRootHandler.handleMessage (ViewRootImpl.java:4130)
  at android.os.Handler.dispatchMessage (Handler.java:106)
  at android.os.Looper.loop (Looper.java:192)
  at android.app.ActivityThread.main (ActivityThread.java:6748)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:556)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:867)

java.lang.SecurityException:
  at android.os.Parcel.readException (Parcel.java:1620)
  at android.os.Parcel.readException (Parcel.java:1573)
  at android.app.ActivityManagerProxy.getIntentSender (ActivityManagerNative.java:4126)
  at android.app.PendingIntent.getActivity (PendingIntent.java:311)
  at android.app.PendingIntent.getActivity (PendingIntent.java:272)
  at android.support.customtabs.b.a (Unknown Source)
  at android.support.customtabs.b.a (Unknown Source)
  at android.support.customtabs.trusted.LauncherActivity.a (Unknown Source)
  at android.support.customtabs.trusted.LauncherActivity$a.a (Unknown Source)
  at android.support.customtabs.d.onServiceConnected (Unknown Source)
  at android.app.LoadedApk$ServiceDispatcher.doConnected (LoadedApk.java:1223)
  at android.app.LoadedApk$ServiceDispatcher$RunConnection.run (LoadedApk.java:1240)
  at android.os.Handler.handleCallback (Handler.java:739)
  at android.os.Handler.dispatchMessage (Handler.java:95)
  at android.os.Looper.loop (Looper.java:148)
  at android.app.ActivityThread.main (ActivityThread.java:5582)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:726)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:616)

java.lang.NullPointerException:
  at android.app.ActivityThread.handleStopActivity (ActivityThread.java:4844)
  at android.app.ActivityThread.-wrap29 (ActivityThread.java)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1845)
  at android.os.Handler.dispatchMessage (Handler.java:102)
  at android.os.Looper.loop (Looper.java:148)
  at android.app.ActivityThread.main (ActivityThread.java:7325)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:1230)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1120)

android.view.WindowManager$BadTokenException:
  at android.view.ViewRootImpl.setView (ViewRootImpl.java:772)
  at android.view.WindowManagerGlobal.addView (WindowManagerGlobal.java:298)
  at android.view.WindowManagerImpl.addView (WindowManagerImpl.java:91)
  at android.app.ActivityThread.handleResumeActivity (ActivityThread.java:4185)
  at android.app.ActivityThread.handleLaunchActivity (ActivityThread.java:3311)
  at android.app.ActivityThread.access$1000 (ActivityThread.java:211)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1705)
  at android.os.Handler.dispatchMessage (Handler.java:102)
  at android.os.Looper.loop (Looper.java:145)
  at android.app.ActivityThread.main (ActivityThread.java:6946)
  at java.lang.reflect.Method.invoke (Native Method)
  at java.lang.reflect.Method.invoke (Method.java:372)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:1404)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1199)

java.lang.IllegalArgumentException:
  at android.os.Parcel.readException (Parcel.java:1971)
  at android.os.Parcel.readException (Parcel.java:1913)
  at android.app.IActivityManager$Stub$Proxy.reportSizeConfigurations (IActivityManager.java:9969)
  at android.app.ActivityThread.reportSizeConfigurations (ActivityThread.java:3093)
  at android.app.ActivityThread.handleLaunchActivity (ActivityThread.java:3036)
  at android.app.ActivityThread.handleRelaunchActivity (ActivityThread.java:4921)
  at android.app.ActivityThread.-wrap19 (Unknown Source)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1702)
  at android.os.Handler.dispatchMessage (Handler.java:105)
  at android.os.Looper.loop (Looper.java:164)
  at android.app.ActivityThread.main (ActivityThread.java:6944)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.Zygote$MethodAndArgsCaller.run (Zygote.java:327)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1374)

backtrace:
  #00  pc<PHONE_NUMBER>04ab94  /system/lib/libc.so (tgkill+12)
  #01  pc<PHONE_NUMBER>048333  /system/lib/libc.so (pthread_kill+34)
  #02  pc<PHONE_NUMBER>01de0d  /system/lib/libc.so (raise+10)
  #03  pc<PHONE_NUMBER>019511  /system/lib/libc.so (__libc_android_abort+34)
  #04  pc<PHONE_NUMBER>01718c  /system/lib/libc.so (abort+4)
  #05  pc<PHONE_NUMBER>00c62d  /system/lib/libcutils.so (__android_log_assert+112)
  #06  pc<PHONE_NUMBER>02586f  /system/lib/libhwui.so
  #07  pc<PHONE_NUMBER>027277  /system/lib/libhwui.so
  #08  pc<PHONE_NUMBER>02aa09  /system/lib/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+80)
  #09  pc<PHONE_NUMBER>00e429  /system/lib/libutils.so (android::Thread::_threadLoop(void*)+140)
  #10  pc<PHONE_NUMBER>069e2d  /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+80)
  #11  pc<PHONE_NUMBER>047e03  /system/lib/libc.so (__pthread_start(void*)+22)
  #12  pc<PHONE_NUMBER>01a181  /system/lib/libc.so (__start_thread+6)

Hey @jitendra1607
Interesting issue. Do you mind pasting the contents of your /app/build.gradle file so I can try and help.
Cheers.

Hey, I'd recommend using either bubblewrap, which is a command line tool for generating TWAs or the more hands android-browser-helper instead of this project. They're the recommended, up to date way of making TWAs, this project is mostly deprecated (see the top bit of the README). (llama-pack is what bubblewrap used to be called, we should update that.)

Seems like may be best to stick with WebView, to avoid code updates every few months, unknown crashes and of course the "running in Chrome toast." In addition, sharing the same state as the browser can also be confusing, I don't native device features for now so WebView is probably the best solution until TWAs are better supported.  I like the small package size but too many other issues. I look forward to giving this a try again down the line.  Thanks for all the hard work so far!

Thanks for the feedback, @AlexBorsody
I agree that, as library matures, we'll have less issues and the need to update will become more sparse.
Though, It's fair to say that, once a developer creates an app and uploads to a store, they need to update it with some frequency. It may be cause the minimum target SDK requirement changed or because an underlying library was updated with bug fixes. This is also true with the WebView, as it has its own support library.
In most cases, updating will mean updating the support library version, rebuilding and uploading the new version. Bubblewrap reduces the amount of work needed and provides commands that could, for instance, be integrated into a CI (bubblewrap update and bubblewrap build). Uploading the new version to the store is still manual. We hope to automate that even more in the future.
Moving from the old custom-tabs-client library to android-browser helper does require more steps than the usual. But once the application is moved, updates should be streamlined.
Regarding unknown crashes, we're working on tracking and fixing those - from the ones mentioned on this issue, some may have already been fixed on the android-browser-helper library - that's why we recommend updating. Others, like this one, are harder to reproduce and fix, and seem to be tied to the OS itself, and not to the Trusted Web Activity (meaning that if the app was 100% native or used the WebView, they'd still see the issue).
Any further details on those issues, such as the devices where the issue is happening and how often they happen further help us understand what is causing the crash and prioritize fixing it. If possible, a reproduction case is the best (but, from what I've seen in those crashes, not possible in most cases)
We're working on improving the Running in Chrome toast.

Thanks for all your hard work guys and for the helpful resources. Really appreciate it! :muscle:

I have a suggestion, till then this TWA thing matures we can have global
exception handler to catch all exception. Then this handle should open
chrome browser with PWA link. This way users will have working app somehow.
On Tue, 26 May, 2020, 19:19 André Cipriani Bandarra, <
<EMAIL_ADDRESS>wrote:

Thanks for the feedback, @AlexBorsody https://github.com/AlexBorsody
I agree that, as library matures, we'll have less issues and the need to
update will become more sparse.
Though, It's fair to say that, once a developer creates an app and uploads
to a store, they need to update it with some frequency. It may be cause the minimum
target SDK requirement changed
https://developer.android.com/distribute/best-practices/develop/target-sdk
or because an underlying library was updated with bug fixes. This is also
true with the WebView, as it has its own support library
https://developer.android.com/jetpack/androidx/releases/webkit.
In most cases, updating will mean updating the support library version,
rebuilding and uploading the new version. Bubblewrap
https://github.com/GoogleChromeLabs/bubblewrap reduces the amount of
work needed and provides commands that could, for instance, be integrated
into a CI (bubblewrap update and bubblewrap build). Uploading the new
version to the store is still manual. We hope to automate that even more in
the future.
Moving from the old custom-tabs-client library to android-browser helper
does require more steps than the usual
https://developers.google.com/web/android/trusted-web-activity/android-browser-helper-migration.
But once the application is moved, updates should be streamlined.
Regarding unknown crashes, we're working on tracking and fixing those -
from the ones mentioned on this issue, some may have already been fixed on
the android-browser-helper library - that's why we recommend updating.
Others, like this one https://issuetracker.google.com/issues/62427912,
are harder to reproduce and fix, and seem to be tied to the OS itself, and
not to the Trusted Web Activity (meaning that if the app was 100% native or
used the WebView, they'd still see the issue).
Any further details on those issues, such as the devices where the issue
is happening and how often they happen further help us understand what is
causing the crash and prioritize fixing it. If possible, a reproduction
case is the best (but, from what I've seen in those crashes, not possible
in most cases)
We're working on improving the Running in Chrome
https://bugs.chromium.org/p/chromium/issues/detail?id=1068106&q=component%3AUI>Browser>Mobile>TrustedWebActivities&can=2
toast.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleChromeLabs/svgomg-twa/issues/104#issuecomment-634036701,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFJOGSBTN3IG3OLTMSJGFJ3RTPCF7ANCNFSM4MYBCHYA
.

Closing the issue. Please, report an issue on https://github.com/GoogleChrome/android-browser-helper if this still a problem.