Document example for generateMutationOp

First of all this is a great library!
I'm having trouble integration the generation of mutations with apollo. On the documentation it refers to generateMutationOp (https://genql.dev/docs/usage/integrate-with-other-graphql-clients) but the variables seem to have a weird indexing. v1, v2 etc. I found multiple issues references to this but I haven't been able to decrypt how it is suppose to work. It would be great of this could be documented with an example. I'm currently using the following workaround:
   const mutationSelection = {
      createOrUpdateObject: {
        __args: {
          input: {
            id: '1',
            ...data
          }
        },
        object: {
          id: true,
          field1: true,
          field2: true
        },
        errors: {
          field: true,
          message: true
        }
      }
    };

    type f = FieldsSelection<Mutation, typeof mutationSelection>;
    const {query, variables } = generateMutationOp(mutationSelection);
    return this.apollo.mutate<f>({
      mutation: gqltag(query),
      variables: variables ? {'input': Object.values(variables)[0]} : {}
    });

Found some related issues but they have not been able to help me further.
https://github.com/remorses/genql/issues/143
https://github.com/remorses/genql/issues/130

Ah my bad. I was testing out something else that broke it. Passing variables variables directly to apollo works as expected...
Just leaving my code example for anyone that might have the same issue in the future:
const mutationSelection = {
  createOrUpdateObject: {
    __args: {
      input: {
        id: '1',
        ...data
      }
    },
    object: {
      id: true,
      field1: true,
      field2: true
    },
    errors: {
      field: true,
      message: true
    }
  }
};

type f = FieldsSelection<Mutation, typeof mutationSelection>;
const {query, variables } = generateMutationOp(mutationSelection);
return this.apollo.mutate<f>({
  mutation: gqltag(query),
  variables: variables
});


Remove trailing comma from _NCProperties attribute value.

If NCPROPERTIES_EXTRA (see configure.ac) is defined
but is null or empty, then an extra comma is being generated
at the end of _NCProperties global attribute.
Soln: check for null/empty NCPROPERTIES_EXTRA value.

Thanks dennis, looks good! I'll try to get the GitHub actions wired in this week.


get_model_from_arch_str

Describe the Question
is there a function for getting the model instance from the cell string? this function will be very useful for nas with training method?

Yes, we do have.
Please see README at here

wow. thank you!


Need better instructions for make build on windows

Downloading and running the prebuilt Windows binary results in the following error in browser:

Reviewing #97 here, it seems the filepath code was designed for Linux systems, resulting in the error. I wanted to implement the fix in the static.go file myself, so I downloaded the source code for the program, made the change, then ran the make build command from a PowerShell window, resulting in the below error:
make build
yarn install v1.22.22
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.57s.
cd ./ui && yarn build --modules-folder /ui/node_modules
yarn run v1.22.22
$ react-scripts build --modules-folder /ui/node_modules
'react-scripts' is not recognized as an internal or external command,
operable program or batch file.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
make: *** [Makefile:6: assets] Error 1

...which triggered me to think "oh duh, I forgot to npm install", so I ran that, which resulted in this next output:
npm install
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/@material-ui/core
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/@material-ui/icons
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Conflicting peer dependency<EMAIL_ADDRESS>npm ERR! node_modules/@material-ui/core
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/@material-ui/icons
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR!
npm ERR! For a full report see:
npm ERR! C:\cache\_logs\2024-04-20T20_55_18_711Z-eresolve-report.txt

npm ERR!

Run `npm audit` for details.

Finally I try the make build command again:
make build
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.53s.
cd ./ui && yarn build --modules-folder /ui/node_modules
yarn run v1.22.22
$ react-scripts build --modules-folder /ui/node_modules
'react-scripts' is not recognized as an internal or external command,
operable program or batch file.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
make: *** [Makefile:6: assets] Error 1

Same issue as before, react-scripts is not installed. After some digging online, the NOT ideal solution is to globally install react-scripts using the command npm i -g react-scripts@latest --force followed by the make build again:
make build
yarn install v1.22.22
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.54s.
cd ./ui && yarn build --modules-folder /ui/node_modules
yarn run v1.22.22
$ react-scripts build --modules-folder /ui/node_modules
Creating an optimized production build...
Failed to compile.

Module not found: Error: Can't resolve '@material-ui/lab/Alert' in 'C:\Users\chalu\Desktop\asynqmon-master\ui\src\views'

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
make: *** [Makefile:6: assets] Error 1

Something is off here, because now it seems it's sending me down a rabbit hole of installing all of the packages.json packages to a global scope, one at a time. npm install install is not doing what it's supposed to.
Can someone try following the documentation in a Windows 10 environment and let me know what I'm missing here?

For further context, I've also tried to manually running the backend server with go run main.go --port 8085, and then attempting to run the frontend server with npm run start which results in a giant output of issues, and a browser window that all looks like the following:

Unless I'm missing something obvious here, the package just simply doesn't work on Windows.

Oh, and I forgot that the packages.json needs to modify export to set at this line in order to work on Windows:
![image](https://github.com/hibiken/asynqmon/assets/40477419/78e3584a-7367-4be4-968c-8a741e6871be)


feat(Table): Sticky columns

CSS for #572

Moved all background and borders logic from rows to cells.
Left borders only for expanded content since wits content can be anything.
Added sticky columns to Additional features tables (not to all of them).
Added JS to handle shadow for sticky columns.
Fixed JS for columns selection, now they actually work.

I recommend to review HTML with this flag turned on in GitHub:

@mayank99 @FlyersPh9 is there anything else you want me to fix or can I get an approval?

Waiting for this but otherwise looks good:

Can we remove iui-cell from the html example then? Looks confusing.

I think we can. It doesn't feel right to use iui-cell in random place. Maybe I should also remove those :not(.iui-expanded-content)?

Oh shoot. I missed this one, will do right now.


Support syntax highlighting of detail section in CompletionItems

Fixes #34188
Allows Completion items to mark a language for syntax highlighting on the .detail field

Closing as out of date


support for validation of EEG datatype, needed for BEP006

The code still needs more work and validation, so please don't merge yet. Furthermore, BEP006 is not yet final. But having the PR here will attend others that work has already be done (and hopefully they will contribute).

For the CI in bids-examples to work we would need to merge this PR and release a new version of the bids-validator. I'm hesitant to do this before at least merging the EEG BEP into the main spec (see my email on how to speed that part up).
On the other hand just merging the PR without releasing would make creating ad hot quick fix releases difficult.
But there is hope. CircleCI is building web version of the validator for every PR (for example https://circleci.com/gh/INCF/bids-validator/1123). You can find it in the Artifacts tab (you need to be logged in to see the tab).

we should make this conditional in the validator. This starts in bin/bids-validator with

.boolean('bep006')
.describe('bep006', 'Enable support for BIDS extension protocol 006.')

When you merge https://github.com/robertoostenveld/bids-validator/pull/15 we should be ready to merge this one as well.

When you merge robertoostenveld#15 we should be ready to merge this one as well.

@chrisfilo: Done, however codeclimate CI doesn't like my fix of (path[1] == 'eeg' && bep006) and complains that I should simplify the logical expression:
    if (
        (path[0].includes('.nii') && ['anat', 'func', 'dwi'].indexOf(path[1]) !=-1 ) ||
        (path[0].includes('.json') && (path[1] == 'meg' || (path[1] == 'eeg' && bep006)))
    ){
        isCorrectModality = true;
    }

Mmh I have no idea how to simplify this logical expression (=pleasing codeclimate). It will only get worse with more and more added BEPs, because e.g., BEP010 will add its own line right below :-)
Personally, I find it very readable and obvious, so I don't know why codeclimate has issues with it.
var isCorrectModality = false;
if (
    (path[0].includes('.nii') && ['anat', 'func', 'dwi'].indexOf(path[1]) !=-1 ) ||
    (path[0].includes('.json') && (path[1] == 'meg' || (path[1] == 'eeg' && bep006)))
    (path[0].includes('.json') && ['meg'].indexOf(path[1]) !=-1) ||
    (path[0].includes('.json') && (['eeg'].indexOf(path[1]) !=-1)  && BIDS.options.bep006)
){
    isCorrectModality = true;
}

@nellh @jasmainak perhaps one of you can help?

@sappelhoff it's a bit of trial and error to make codeclimate happy :-) Can you give me push access? I can give it a shot later today or tomorrow if @nellh doesn't beat me to it.

Same comment here. I suspect that's what's causing BIDS-examples to fail. I had to iterate quite a bit between these two repos when I wrote the MEG validator ...


tidal-hifi: 5.1.0 -> 5.6.0

Description of changes

Add myself (@spikespaz) to maintainers-list.nix.
Add myself (@spikespaz) as a maintainer for tidal-hifi.
Update package tidal-hifi from 5.1.0 to 5.6.0.
Add wrapper flag to tidal-hifi for NIXOS_OZONE_WL.
Set meta.mainProgram for tidal-hifi.

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Can you please fix the merge conflict?

Can you please fix the merge conflict?

I honestly don't even know how. It only shows on GitHub, and not on my local copy (which is up to date with nixpkgs/master). Should I just use the GH web UI to do it? Is there something I need to pull? I have never seen such a thing on GH's UI before.

Your fork's master branch is out of sync with the one in NixOS/nixpkgs.
Your master branch of your local copy probably points to the outdated one of your fork.
You can either add NixOS/nixpkgs as additional remote in git, or hit the sync button ("Sync fork") in the default page of your fork at https://github.com/spikespaz/nixpkgs

I will try to respond to your questions you added via edit to your original comment later today or maybe tomorrow!

Result of nixpkgs-review pr 249018 run on x86_64-linux 1

1 package built:

tidal-hifi

Sorry for the late reply. Been quite busy.

Are pull requests supposed to be made to nixpkgs/nixos-unstable, nixpkgs-unstable, or master? The CONTRIBUTING.md only mentions how to handle release branches for backporting.

Changes made to the unstable channel go through master.
See "Flow of merged pull requests" in the CONTRIBUTIONS.md and https://nixos.org/manual/nixpkgs/stable/
Let me know if you have any thoughts on how to make it clearer :)

Why does the unstable channel seem to be at tidal-hifi 5.5.0? The master branch (I assumed where PRs are supposed to be made, and rebase from) is at 5.1.0, which is why I'm confused about the conflict.

I double-checked this now.

Anyhow!
Thank you very much and welcome to nixpkgs :)


Fix typo in README: import “form” → “from”

Thanks @roryokane ! Probably not the only typo in the readme. :-)


feat: Pattern Module for Azure Update Manager

Description
This PR adds the pattern module for Azure Update Manager.
The pattern creates multiple maintenance configurations and assigns them to ARC Servers/Azure VMs based on tags. The pattern also creates and assigns Azure Policies in the subscription to mandate maintenance configuration related Tags on Virtual machines on creation and do necessary config changes to be compatible with Azure Update Manager.
Closes #1144
Pipeline Reference

Pipeline

Type of Change

[ ] Update to CI Environment or utilities (Non-module affecting changes)
[ ] Azure Verified Module updates:

[ ] Bugfix containing backwards-compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:

[x] Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
[ ] The bug was found by the module author, and no one has opened an issue to report it yet.

[x] Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
[ ] Breaking changes and I have bumped the MAJOR version in version.json.
[ ] Update to documentation

Checklist

[x] I'm sure there are no other open Pull Requests for the same update/change
[x] I have run Set-AVMModule locally to generate the supporting module files.
[x] My corresponding pipelines / checks run clean and green without any errors or warnings

Hey @akhilthomas011 ,
Firstly, thanks for your work on this PR!
We have made some changes to the AVM CI, detailed below, which means we need you to update your fork to pull in these latest changes and re-run your tests to show they still are passing prior to approving and merging this PR, as we don't and it fails once merged the publishing of your module will fail and will be blocked going forward until the test pass again via additional PRs.
Changes to CI That Have Been Made That You Need To Take Action On

https://github.com/Azure/bicep-registry-modules/pull/3745

Adds WAF Security PSRule Checks using this custom baseline of rules (/avm/utilities/pipelines/staticValidation/psrule/.ps-rule/cb-waf-security.Rule.yaml)
Action Required By You:

Ingest/pull-in these changes into your PR branch and re-run your tests to ensure they pass

If any issues with the rules and you think it should apply, please ping/reach out to the core team

Any questions reach out to the AVM Core Team by tagging us in your PR here or internally via Teams
Thanks
Jack (AVM Core Team)

@jtracey93 - I have pulled-in the new changes to my PR. It passed the validations.


'cargo update' all the things

Also add a test directly calling getrandom.

@bors r+

:pushpin: Commit 3d15e4744151b339afc38b1bc5c01caf8da2b943 has been approved by RalfJung

:hourglass: Testing commit 3d15e4744151b339afc38b1bc5c01caf8da2b943 with merge 9c41b8b1cbde7c0af4802d44f28921c77fbbb7f9...

:sunny: Test successful - checks-actions
Approved by: RalfJung
Pushing 9c41b8b1cbde7c0af4802d44f28921c77fbbb7f9 to master...


feat: archive datamanager

Description
New sdk endpoint to archive and dearchive a datamanager see asana card
When a compute task try to use an archived data_manager in raises an invalid context error.
How has this been tested?

unit tests

Checklist

[x ] changelog was updated with notable changes
[ ] documentation was updated

Connected-PR

substra-backend #521 -> this PR
orchestrator #54
substra sdk #35

/e2e --refs orchestrator=feat/archive-datamanager,substra=feat/archive-datamanager

End to end tests: :hourglass_flowing_sand: STARTING

/e2e --refs orchestrator=feat/archive-datamanager,substra=feat/archive_datamanager

End to end tests: :hourglass_flowing_sand: STARTING

Thank you for your contribution! Unfortunately, due to organisational and roadmap changes, this item has been deprioritised. We currently have no bandwidth to cope with the code drift between the current code state in the last release and this PR, therefore we are closing it.


Chaging the parameter name from --hub-name

See https://github.com/microsoftdocs/azure-docs/issues/25777  This sample command line contains the incorrect parameter name "--hub-name" the actual parameter name is "--name".

@Alberto-Vega-MSFT : Thanks for your contribution! The author, @dominicbetts, has been notified to review your proposed change.

@Alberto-Vega-MSFT  Please close this PR - the command as it stands is correct. See my comment on the original issue. Thanks.


python.pkgs.setuptools: 36.7.1 -> 38.2.3

Motivation for this change
Things done

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

[ ] NixOS
[ ] macOS
[X] other Linux distributions

[ ] 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"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

According to the changelog, this may break some packages:

In order to support deterministic builds, Setuptools no longer allows packages to declare install_requires as unordered sequences (sets or dicts).

Job running at https://hydra.nixos.org/eval/1415387

The test runner is also fixed it seems, causing a lot of failures due to missing test dependencies.

All I particularly want is #701: Fixed duplicate test discovery on Python 3. which is present in 36.7.2. If it's a pain to upgrade all the way to 38.2.3, maybe we could just up to 37.0.0 perhaps

If it's a pain to upgrade all the way to 38.2.3

No, its not. But as with basically every setuptools upgrade, it requires some work. In this case, its fixing several expressions. Not many, really.

This commit is now in staging and it's breaking the tests of some packages (https://hydra.nixos.org/eval/1416829?#tabs-now-fail), for example, cloud-init: https://hydra.nixos.org/build/65655898. What is the cause of such failures? Why were they not broken before?

In the checkPhase we run python setup.py test. Packages can provide an option on how to deal with such situation. At some point setuptools introduced python -m unittest by default. This was however only working with Python 3. Now, it seems it also functions with Python 2 packages. I don't see it anywhere mentioned in the changelog, but it is a good change.
Therefore, the cause of failing packages is that now they have to have their test dependencies defined or doCheck put to false, or else they will fail to build.

Also, regarding merging such change while there are failures. Packages that break require a small fix that maintainers can do. Let me send out a mail to the list to clarify why there is some breakage.

OK, thanks, the breakage is small enough to deal with in staging.

For the reference, here is what has been broken when this change has reached master:
https://hydra.nixos.org/eval/1417673?filter=.x86_64-linux&compare=1417366
and here is a recent status:
https://hydra.nixos.org/eval/1418287?filter=.x86_64-linux&compare=1417366
(Of course not all breakage is due to the update.)


[Tracing] Jaeger: Add support of ElasticSearch as a backend for traces.

The target of this pull request is to provide a minimal production storage for Istio traces out of the box.
I know that there is a WIP (#9508) to adopt jaeger operator that will be available as a part of Istio Operator (expected for 1.2).
This feature enables people want to move to production before that release to have an option to backend their traces by ElasticSearch without having to change helm charts.
Usage:
Update you values file as following:
## Enable tracing
tracing:
 enabled: true
 jaeger:
   span_storage_type: elasticsearch
   es:
     server_urls: http://myelasticsearch-instance.com
     #username:
     #password:

Test:
Tested on the top of Istio 1.1.2 using a managed version of ElasticSearch 6.5.
Documentation:
Configuration options will be added to https://istio.io/docs/tasks/telemetry/distributed-tracing/jaeger/ once the pull request is validated.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: rafik8
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: andraxylia
If they are not already assigned, you can assign the PR to them by writing /assign @andraxylia in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

install/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Hi @rafik8. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/ok-to-test

@rafik8: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
c3000c4530bacdd918f8111a01e7c6e13c5526d7
link
/test e2e-simpleTests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@rafik8: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
c3000c4530bacdd918f8111a01e7c6e13c5526d7
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@rafik8: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
c3000c4530bacdd918f8111a01e7c6e13c5526d7
link
/test istio-pilot-multicluster-e2e

prow/istio-integ-k8s-tests.sh
c3000c4530bacdd918f8111a01e7c6e13c5526d7
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@mandarjog @GregHanson, could you comment on this? Thanks

@rafik8 I'm just seeing this PR now, as I attempt a sweep through the outstanding PRs. I think the proper place for such a PR is the (new) istio/installer repo. As we are cutting the 1.2 release this week, we would need to decide on the operator v. this kind of patch soon.  Do you mind opening a PR against that new repo for discussion? Please include @objectiser in such a discussion.

@douglas-reid Was hoping to discuss this on tomorrow's call.
Now thinking that your previous suggestion, about managing production installation of Jaeger outside Istio, would be the best approach. So demo/test environment could just use the embedded all-in-one configuration/template, but for production scenarios Istio would be configured to point to an externally setup Jaeger instance by setting the global.tracer.zipkin.address property.
When the istio-operator work is more advanced, we could still explore how it would make use of other operators.
If this approach is taken, we just need to document (1) where to find instructions for setting up production Jaeger instance, and (2) how to point Istio at it.


Unable to release GPU memory after training Keras model

In order to preform a object detection like task, I used a CNN. I am using a custom generator that follows this example
My machine is a MacOS High Sierra 10.13.6, yet I am running my code using Google Colab's GPU so my machine's performances has nothing to do with the issue(right ?). It should be noted that I have tested my code on another platform (FloydHub's Tesla K80 GPU) and had the same problem.
I am using

Keras 2.2.4
Tensorflow backend 1.13.1
Python (3.7)
CUDA release 10.1, V10.1.168
GPU model and memory:  Tesla K80 (up to my knowledge, this is what google uses on Colab)

I run out of GPU memory quickly, when passing my model's training in a for loop (looking for optimal hyper-parameters) the program stops on Out Of Memory Error after the first iteration. Before the beginning of the first epoch and shortly before the loading arrow for the first epoch appears, the GPU usage jumps to a value of 98%. I put a gc.collect() , del model and K.clear_session() in the end of my training in order to release memory for the next model but it seems to have no effect on GPU which remains at 98% before eventually crashing my notebook.
---------------------------------------------------------------------------
ResourceExhaustedError                    Traceback (most recent call last)
<ipython-input-75-31b4f9e0b883> in <module>()
     15 models={}
     16 compile_model(model,OPTIMIZER,LOSS,METRICS,LR,MOMENTUM,DECAY)
---> 17 allinone2(Hist,model,Data,VAL_SPLIT,OPTIMIZER,LOSS,METRICS,LR,MOMENTUM,DECAY,BATCH_SIZE,EPOCHS,PARAMS,True)

9 frames
<ipython-input-71-125d04498229> in allinone2(Hist, model, Data, validation_split, optimizer, loss, metric, lr, momentum, decay, batch_size, epochs, params, showbboxs)
      2   if TPU :
      3       model = tf.contrib.tpu.keras_to_tpu_model(model,strategy=tf.contrib.tpu.TPUDistributionStrategy(tf.contrib.cluster_resolver.TPUClusterResolver(TPU_WORKER)))
----> 4   train_gen,validation_gen,Hist = fit(model,Hist,Data,VAL_SPLIT,BATCH_SIZE,EPOCHS,PARAMS)
      5   Save_model(SAVE_DIR,name_json="model",nameh5="model",save=SAVE_MODEL)
      6   training_results(Hist,str(validation_split)+str(batch_size)+str(epochs),savefig=SAVE_FIG)

<ipython-input-64-efd2c5419ad6> in fit(model, Hist, Data, validation_split, batch_size, epochs, params)
     17                    validation_steps = lenvalidation // batch_size,
     18                    callbacks=[Hist],
---> 19                    validation_data = validation_gen
     20                    )
     21

/usr/local/lib/python3.6/dist-packages/keras/legacy/interfaces.py in wrapper(*args, **kwargs)
     89                 warnings.warn('Update your `' + object_name + '` call to the ' +
     90                               'Keras 2 API: ' + signature, stacklevel=2)
---> 91             return func(*args, **kwargs)
     92         wrapper._original_function = func
     93         return wrapper

/usr/local/lib/python3.6/dist-packages/keras/engine/training.py in fit_generator(self, generator, steps_per_epoch, epochs, verbose, callbacks, validation_data, validation_steps, class_weight, max_queue_size, workers, use_multiprocessing, shuffle, initial_epoch)
   1416             use_multiprocessing=use_multiprocessing,
   1417             shuffle=shuffle,
-> 1418             initial_epoch=initial_epoch)
   1419
   1420     @interfaces.legacy_generator_methods_support

/usr/local/lib/python3.6/dist-packages/keras/engine/training_generator.py in fit_generator(model, generator, steps_per_epoch, epochs, verbose, callbacks, validation_data, validation_steps, class_weight, max_queue_size, workers, use_multiprocessing, shuffle, initial_epoch)
    215                 outs = model.train_on_batch(x, y,
    216                                             sample_weight=sample_weight,
--> 217                                             class_weight=class_weight)
    218
    219                 outs = to_list(outs)

/usr/local/lib/python3.6/dist-packages/keras/engine/training.py in train_on_batch(self, x, y, sample_weight, class_weight)
   1215             ins = x + y + sample_weights
   1216         self._make_train_function()
-> 1217         outputs = self.train_function(ins)
   1218         return unpack_singleton(outputs)
   1219

/usr/local/lib/python3.6/dist-packages/keras/backend/tensorflow_backend.py in __call__(self, inputs)
   2713                 return self._legacy_call(inputs)
   2714
-> 2715             return self._call(inputs)
   2716         else:
   2717             if py_any(is_tensor(x) for x in inputs):

/usr/local/lib/python3.6/dist-packages/keras/backend/tensorflow_backend.py in _call(self, inputs)
   2673             fetched = self._callable_fn(*array_vals, run_metadata=self.run_metadata)
   2674         else:
-> 2675             fetched = self._callable_fn(*array_vals)
   2676         return fetched[:len(self.outputs)]
   2677

/usr/local/lib/python3.6/dist-packages/tensorflow/python/client/session.py in __call__(self, *args, **kwargs)
   1437           ret = tf_session.TF_SessionRunCallable(
   1438               self._session._session, self._handle, args, status,
-> 1439               run_metadata_ptr)
   1440         if run_metadata:
   1441           proto_data = tf_session.TF_GetBuffer(run_metadata_ptr)

/usr/local/lib/python3.6/dist-packages/tensorflow/python/framework/errors_impl.py in __exit__(self, type_arg, value_arg, traceback_arg)
    526             None, None,
    527             compat.as_text(c_api.TF_Message(self.status.status)),
--> 528             c_api.TF_GetCode(self.status.status))
    529     # Delete the underlying status object from memory otherwise it stays alive
    530     # as there is a reference to status from this from the traceback due to

ResourceExhaustedError: OOM when allocating tensor with shape[3114176,32] and type float on /job:localhost/replica:0/task:0/device:GPU:0 by allocator GPU_0_bfc
	 [[{{node training_3/Adam/gradients/dense_17/MatMul_grad/MatMul_1}}]]
Hint: If you want to see a list of allocated tensors when OOM happens, add report_tensor_allocations_upon_oom to RunOptions for current allocation info.

I should be able to free the GPU memory in order to run my tests, It should be noted that my dataset has 1000 images of 800x1000 shape.
A snippet of the code that causes the problem (.ipynb => .py) :
!pip install gputil
!pip install psutil
!pip install humanize
#Imports ...

def penalty(y_true, y_pred):
    a = tf.placeholder(tf.float64)
    p = 20
    loss = K.switch(tf.less(y_true - y_pred, 0.1), K.square(y_true - y_pred) , p * K.square(y_true - y_pred))
    return K.max(loss)

def cusloss(y_true,y_pred):
    return K.mean(K.equal(K.round(100*y_pred , 100*y_true)),tf.zeros_like(y_pred))

# Global parameters
IMG_SIZE = 800,1000,3
BATCH_SIZEs = [4,8,16,32]
EPOCHSs = [10]
PARAMSs = [{"rotation":20,"scale":0.1,"shear":0.1,"translate":0.1,"scale":0.1}]
OPTIMIZERs = ['adam']
LOSSEs = [penalty]
METRICSs = [[cusloss,penalty,losses.msle,losses.mae,losses.mse,losses.logcosh]]
LRs = [0.01,0.005]
MOMENTUMs = [0.05,0.1]
DECAYs = [0.2]
VAL_SPLITs = [0.2]

def load_data(*args):
    ...
    return Data

class Generator(keras.utils.Sequence):

    def __init__(self, Data, params ,batch_size):
        """Initials an image generator"""
        self.x = col(Data,0,1)
        self.y = np.array(col(Data,1,5))
        self.batch_size = batch_size
        self.params = params
        self.on_epoch_end()

    def __len__(self):
        """Our generator's length"""
        return int(np.ceil(len(self.x) / float(self.batch_size)))

    def __getitem__(self, idx):
        """ __getitem__ gives access to an item of our generator which will be a batch of BATCH_SIZE size. It is called via the brackets []"""
        images_list = self.x
        bboxes = self.y
        batch_size =  self.batch_size
        w,h = IMG_SIZE[:2]
        required_transformations = self.params.keys()

        # Generate indexes of the batch
        indexes = self.indexes[idx*self.batch_size:(idx+1)*self.batch_size]
        if sum(indexes) == 0 :        # check if indexes is empty
          return None

        # extracting BATCH_SIZE images from the dataset
        x_temp = [self.x[i]  for i in indexes]
        y_temp = np.array([self.y[i,] for i in indexes])

        # shuffling our batch's elements
        Ids,y0 = sklearn.utils.shuffle(x_temp,y_temp)

        # Initiate our batchs
        X = np.zeros((batch_size,h,w,1))
        y = np.zeros((batch_size,4))

        for i,image in enumerate(Ids) :
            image = image[0]
            try :
                img = cv2.imread("scans/"+image+".png")
            except :
                print("Unable to read %s"%(image))
                img = None

            # Starting preprocessing
            if not (img is None) :
                img = cv2.resize(img,(w,h))
                bbox = y0[i,]
                try :
                    X[i,:,:,:] = np.expand_dims(rgb2gray(img_),axis=2)
                    y[i,:] = bboxes_

                except Exception as exc:
                    # Prints the error without stoping the process
                    print("Error found at index %d"%(i))
                    print(traceback.format_exc())
                    print(exc)

            else :
                print("%s is None"%(image))
        return X,y

    def on_epoch_end(self):
        'Updates indexes after each epoch'
        self.indexes = np.arange(len(self.x))
        np.random.shuffle(self.indexes)

def fit(model,Hist,Data,validation_split,batch_size,epochs,params):
  """ Fits our input to the output"""
  n = len(Data)
  lenvalidation = int(validation_split*n)
  lentrain =  n - lenvalidation
  train_set = sklearn.utils.shuffle(Data[:lentrain])
  validation_set = sklearn.utils.shuffle(Data[lentrain:])
  train_gen = Generator(train_set,params,batch_size)
  validation_gen = Generator(validation_set,params,batch_size)

  print("starting training...")
  model.fit_generator(train_gen,
                   steps_per_epoch = lentrain // batch_size,
                   epochs=epochs,
                   validation_steps = lenvalidation // batch_size,
                   callbacks=[Hist],
                   validation_data = validation_gen
                   )

  return train_gen,validation_gen,Hist

def create_model():
  # History initialisation
  Hist = History()
  # Defining the architecture of our CNN based NN
  model = Sequential()
  model.add(Conv2D(32, kernel_size=(3, 3), activation='relu', input_shape=(IMG_SIZE[1],IMG_SIZE[0],1)))
  model.add(MaxPooling2D(pool_size=(2, 2),strides=(2,2)))
  model.add(Dropout(0.25))
  model.add(Conv2D(64, kernel_size=(5, 5), activation='relu'))
  model.add(MaxPooling2D(pool_size=(2, 2),strides=(2,2)))
  model.add(Dropout(0.3))
  model.add(Flatten())
  model.add(Dense(32, activation='relu'))
  model.add(Dropout(0.3))
  model.add(Dense(4))
  return Hist,model

def compile_model(model,optimize,loss,metric,lr,momentum,decay):
  # Compiles the model
  run_opts = tf.RunOptions(report_tensor_allocations_upon_oom = True)
  model.compile(optimizer=optimize , loss = loss, metrics = metric, options = run_opts)

  # Define optimizers
  K.set_value(model.optimizer.lr, lr)
  K.set_value(model.optimizer.decay, decay)
  try :
      K.set_value(optimizer.momentum, momentum)
  except :
    pass

def allinone(Hist,model,Data,validation_split,optimizer,loss,metric,lr,momentum,decay,batch_size,epochs,params) :
  compile_model(model,optimizer,loss,metric,lr,momentum,decay)
  train_gen,validation_gen,Hist = fit(model,Hist,Data,VAL_SPLIT,BATCH_SIZE,EPOCHS,PARAMS)
  torch.cuda.empty_cache()
  del model
  gc.collect()
  K.clear_session()

def printmm(y_true=0,y_pred=0):
  GPUs = GPUtil.getGPUs()
  gpu = GPUs[0]
  print(GPUtil.showUtilization())
  return(tf.Variable(gpu.memoryUtil*100))

# The Ultimate test
Data = load_data()
Hist,model = create_model()
for EPOCHS in EPOCHSs:
  for BATCH_SIZE in BATCH_SIZEs:
    for PARAMS in PARAMSs :
      for OPTIMIZER in OPTIMIZERs:
        for LOSS in LOSSEs :
          for METRICS in METRICSs:
            for LR in LRs :
              for MOMENTUM in MOMENTUMs:
                for DECAY in DECAYs:
                  for VAL_SPLIT in VAL_SPLITs :
                    allinone(Hist,model,Data,VAL_SPLIT,OPTIMIZER,LOSS,METRICS,LR,MOMENTUM,DECAY,BATCH_SIZE,EPOCHS,PARAMS)

@YKritet Can you create a colab gist. Current code has some typos resulting some other errors. Thanks!

Closing due to lack of recent activity. Please update the issue when new information becomes available, and we will reopen the issue. Thanks!


Firestore cmake: update GoogleUtilities version to 7.4.0

Fixes build failure.

cc @var-const

The SPM failure is not relevant for the current PR and is being investigated separately. I'll merge the PR on CI green.


Use a higher granular rate limiter for VRG reconciles

The default rate limiter has a 5ms baseDelay and a max
of 1000 seconds.
Reconcilig at such low base delays is highly frequent in
the case of DR actions in VRG where we are waiting for
storage state changes. Further the max delay is very high
causing unwarranted delays.
Changing this to 1 second and a minute as the base and max
delays.
Further removing existing 1 second reconcile frequency for
certain VRG reconciliation requests.
Signed-off-by: Shyamsundar Ranganathan<EMAIL_ADDRESS>

Other issues: While testing, a deployment followed by a relocate ended up in an error on the current cluster, as VRG changed to request a prepare for final sync, and that caused VRG to attempt PV restore again and detect that the existing PVs are conflicting with the same. This needs to be fixed as a separate issue, but noting it here at present.

Interesting. I wonder why that would be.  The status VRGConditionTypeClusterDataReady should be still true and the restore PV operation should be skipped.  This happens in every reconciliation.  What made it different?

Other issues: While testing, a deployment followed by a relocate ended up in an error on the current cluster, as VRG changed to request a prepare for final sync, and that caused VRG to attempt PV restore again and detect that the existing PVs are conflicting with the same. This needs to be fixed as a separate issue, but noting it here at present.

Interesting. I wonder why that would be. The status VRGConditionTypeClusterDataReady should be still true and the restore PV operation should be skipped. This happens in every reconciliation. What made it different?

The VRG generation is different, so it restores again...

@BenamarMk Tested e2e with the changes and with VR setup. VolSync setup is not tested (or code modified) and would need attention.
@raghavendra-talur There are a couple of cases in Sync DR where we request a requeue for no reason (afaict) from processVRAsPrimary and processVRAsSecondary need to check the same and possibly return false from these instances.


Recepient VASP can't send pre approval request to a sender VASP it is not aware of

In the recurring payments scenario recipient VASP (some merchant acquirer) should ask sending VASP (some consumer wallet) for a FundPullPreApprovalCommand (request for consumer consent for a recurring charge by the merchant). After such a request has been submitted the recipient VASP can now use "out-of-band methods" (Some interaction with the wallet user) to approve/reject the pull pre-approval request.
According to my understanding of the process, we may encounter a problem.
Let's say a merchant consumer wants to add Libra as a payment method (i.e to his favorite transportation app who wants to charge him for every trip).
The merchant app will ask it's Libra acquirer service to generate a request for a recurring charge consent. Problem is,
at that point in time nor the merchant or the acquirer can know who is the consumer VASP and who is the specific user (subaddress?) inside the VASP to whom the pre-approval request should be sent to.
Alternative flow might be:

Acquirer provides a QR/link at the checkout page with the scope of the consent request (amount, currency, etc...), the acquirer VASP address, and the merchant user id.
consumer scans the QR / opens the link with his Libra wallet.
The Libra consumer wallet asks for consumer consent (approve/reject).
Consumer wallet opens a channel to the requesting VASP (the merchant acquirer) and creates the FundPullPreApprovalObject with the consumer desition.

Thoughts?

Great question.  The LIP should be updated to make it agnostic to who the creating party is (sender or receiver) and should instead allow either party to create the FundPullPreApprovalObject.  I do think that there are times when both will be applicable - for example, a merchant could simply ask you to enter your bech32 address identifier and then it initiates the pull pre-approval.  Or you could do one payment and then the merchant could initiate this, etc.  But I agree that the LIP shouldn't be indicating that the flow is unidirectional.  I'll update to change that, thanks for the input!

@udirom could you please indicate in issues which LIP you are referring to?


Move team guard check to the actual use case

This pull request adds the ability to add factories in combination with teams. As we're creating a instance with a team attached in our factory, but no one is authenticated at the moment, the saving closure triggers the 'No authenticated user with selected team present.'
This ensures the check is only done when necessary, that case would be when the team actually needs to be fetched from the authenticated user.

Thanks for your PR!


Backgroud Image is Imperfect

The background image does not align with the brand archetype and the thematic concept of a Chinese restaurant.

The Background Image is Updated .
Figma Design is Updated.


PR: Fix sorting of files in profiler by fixing parser

Description of Changes

[ ] Wrote at least one-line docstrings (for any new functions)
[ ] Added unit test(s) covering the changes (if testable)

[x] Included a screenshot or animation (if affecting the UI, see Licecap)

The regex expression in the times parser had the old characters so replacing u by μ and sec by s fixed the issue.

Issue(s) Resolved

Fixes #13363
Affirmation
By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct:
Juanis2112

/binder


Removing the need to maintain lodash fork

This just removes the need for you to maintain the fork and makes lodashes the "source of truth".
Great addon :+1:

I think we've got a better solution on the way now that @jdalton has made a fix to esperanto and I've released a new broccoli/es6-modules.

@jasonmit looks like we're a little ways out to the proper solution. This is still a significant improvement. Thanks!

https://github.com/truenorth/ember-lodash/pull/3 addresses one thing I noticed around how I build up the path


Please make sure key binding and mappings done with autohotkey on Windows are respected.

Is your feature request related to a problem? Please describe.
I use autohotkey scripts to try and make a Windows keyboard feel more like a Mac one.
Describe the solution you'd like
Please make sure Aminal uses the post-auto-hotkey keys.
Describe alternatives you've considered
None.
Additional context
Most stuff on Windows gets the post hotkey-manipulated keys, Powershell and Chrome are two annoying exceptions, so please don't do whatever they do ;-)

Moved to https://github.com/jumptrading/waminal/issues/3


Trying to use length condition doesn't allow less than '<'

When trying to use the length condition as follows:
<when condition="length('${message}') < 10" action="Log"/>

I get an error in my config file.  It doesn't like the less than character because it thinks its a beginning of a new tag and I obviously haven't yet closed my beginning tag from the 'when'.  Changing this to a greater than character works fine.

Please use
https://help.github.com/articles/github-flavored-markdown/#fenced-code-blocks

I'm not sure what you are suggesting.  Below is my code example from my XML config file:

This should be a valid condition.  But Intellisense is compaining with the less than '<'.  It's confusing it with an opening tag.  The following statement works:

Intellisense has no issue with this because I assume it thinks the the greater than symbol is a close tag.

Just use the backticks. I edited your post, but that was difficult from mobile yesterday.
Is Intellisense just buggy, or isn't not working?

It isn't working.  For this example, I'l logging the word 'short'.  If I change the < 10 to  = 5 it works.  Otherwise with the < 10 I get no log file at all.  So I'm assuming the "error" in the config file causes nothing to be logged.

And does > work?

Yes.  Greater than works fine.

Did you checked the internal log file?
This is a weird bug and I don't get it why Intellisense would complain.

Where is the internal log file?

https://github.com/nlog/nlog/wiki/Logging-troubleshooting#internal-logging

I ran it with the following settings:
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     internalLogFile="c:\internal_log_file.txt"      internalLogLevel="Trace"
`      internalLogToConsole="true">
I got no log file and nothing was written to the console.

On trace level, nlog writes a lot to the internal log. So maybe your config is xml invalid or this is a permission problem?

The 'less than' error is causing the log not to be created.  I came in this morning and the ONLY change I made was replacing the less than with the greater than.  I reran my test and got the trace messages in the console as well as the interal_log_file.txt file.  Apparently, the error in the config file (the less than symbol), causes NLog to not do anything.

You need to escape the <  I was under the impression this wasn't needed with attributes, but I was wrong.
http://stackoverflow.com/questions/5709232/how-do-i-include-etc-in-xml-attribute-values

Thank you!  That worked!  Thanks for all your time.

NP!
It would be great if you could improve the wiki docs :)

I added a note on the conditions page.

Thanks!


Enforce in glib_wrapper! that the subclass actually implements the required traits for super classes / interfaces

When using the glib_wrapper! macro for subclasses there is currently no compile-time check for the interfaces/classes that are listed. At runtime it would nonetheless panic in (I hope) all cases when misusing it, but a compile-time check would be possible here and useful.
We'd need something to map from the type name to the corresponding impl trait, i.e. some other trait with an associated type. And then use the static_assertions crate, for example.
@ids1024 What do you think?

At runtime it would nonetheless panic in (I hope) all cases when misusing it,

This is not the case. These checks are disabled in release mode and not all glib functions perform these checks themselves. It is possible to cause segfaults in safe code with an incorrect application of glib::wrapper.

Which checks specifically are disabled in release mode?

https://github.com/gtk-rs/gtk-rs-core/blob/75c847827a349d233f872f22540d6feebc54f240/glib/src/object.rs#L264-L282


Add Query Exporter to exporter list

query-exporter is

Centralized query execution
Target DB group management
Flexible metric definition

Query Exporter
Thanks,
Chan.

Oh! good job! thanks! :)


Navbar collapse bug with dropdown menu

Using: a navbar with dropdown menu's and collapsable

resize window to something smaller then 980px
open the menu by clicking the icon
resize to fullscreen again (more then 980px)
try to open a dropdown, menu is not visible
see: http://www.vve-site.nl/issue_bootstrap_navbar.png

Hope somebody can take a look at this!
Bootstrap rocks!

This issue has been reported and fixed in v2.0.2, which should be released soon (I have not heard any dates though.)

Closing, what @mkchandler said.

Thanks!


Remove installation of apt-transport-https from repository recipe

The installation of apt-transport-https is already taken care of by apt::default, and installing it from yarn::repository too triggers a resource cloning warning:
Cloning resource attributes for apt_package[apt-transport-https] from prior resource
Previous apt_package[apt-transport-https]: /var/chef/cache/cookbooks/apt/recipes/default.rb:96:in `from_file'
Current  apt_package[apt-transport-https]: /var/chef/cache/cookbooks/yarn/recipes/repository.rb:15:in `from_file' at 1 location:
    - /var/chef/cache/cookbooks/yarn/recipes/repository.rb:15:in `from_file'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.

Hello, I'm a little pressed for time right now. Would you please consider submitting a pull request addressing the issue?

Sure, here you are!


Fix access denied windows fail of test on github actions

Description

This PR fix failing test on windows with limit GabrielBB/xvfb-action usage to linux.
Type of change

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

References

How has this been tested?

[ ] example: the test suite for my feature covers cases x, y, and z
[ ] example: all tests pass with my change

Final checklist:

[ ] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If I included new strings, I have used trans. to make them localizable.
For more information see our translations guide.

issue here https://github.com/GabrielBB/xvfb-action/issues/25

actions.exec

maybe this call is somehow buggy on windows?

This what I see is that Current runner version: was changed from '2.286.1' to '2.287.1'.
But also this action contains, in node_modules, frozen version of actions/core and actions/exec from two years ago. And for example core has a release 4 months ago:  https://www.npmjs.com/package/@actions/core
So maybe just updating of actions versions to the latest one may be a solution. It is late here, so feel free to try.

thanks!


export excel which formated as xls don't work, bookType: biff8, help!!!

// XLSX  version 0.16.9   node version 12.16.2

const XLSX = require('xlsx')
const workbook = {
  SheetNames: 'TEST',
  Sheets: {
    'TEST': { A1: 123, B1: '333', '!ref': 'A1:B1'}
  }
}

XLSX.writeFile(workbook, 'a.xls', {
  bookType: 'biff8',
  bookSST: false,
  type: 'binary',
});

this demo code above,  which export a empty excel .

SheetNames should be an array and each key in the sheet object is supposed to be a cell object https://docs.sheetjs.com/#cell-object
The correct way to represent what you want is:
const XLSX = require('xlsx');

const workbook = {
  SheetNames: [
    'TEST'
  ],
  Sheets: {
    'TEST': {
      A1: { t: "n", v: 123 },
      B1: { t: "s", v: '333' },
      '!ref': 'A1:B1'
    }
  }
};

XLSX.writeFile(workbook, 'a.xls', {
  bookType: 'biff8',
  bookSST: false,
  type: 'binary',
});

SheetNames should be an array and each key in the sheet object is supposed to be a cell object https://docs.sheetjs.com/#cell-object
The correct way to represent what you want is:
const XLSX = require('xlsx');

const workbook = {
  SheetNames: [
    'TEST'
  ],
  Sheets: {
    'TEST': {
      A1: { t: "n", v: 123 },
      B1: { t: "s", v: '333' },
      '!ref': 'A1:B1'
    }
  }
};

XLSX.writeFile(workbook, 'a.xls', {
  bookType: 'biff8',
  bookSST: false,
  type: 'binary',
});

thank you very much, I got it !!


No support for trackpad in WMR

Currently we only support a single joystick/trackpad input mapped to the analog input.
On vive this is mapped to the trackpad
On touch, wmr and index this is mapped to the joystick
WMR also has a trackpad, index controllers also have a.. well... little horizontal thingy....
We'll need to add a second analog input that is only mapped for WMR and index and outputs to an extra set of axis.

On a side note, we did implement this in the OpenXR plugin and as Valve is moving to making OpenXR their main API switching over to it might be a good idea.

Since WMR is removed in Windows 11, I guess this can be repurposed just for the index controller? I'm not sure if any other new controllers have multiple analog.


nuttx uptream only has syslog (lowsyslog is gone)

When building with https://github.com/UAVCAN/libuavcan/tree/for_upstream_nuttx_changes_4  and chibios this breaks the travise build of UAVCAN/libuavcan (PX4 is fine)

lowsyslog() is part of the Zubax ChibiOS framework, it has no relation to NuttX (other than it's named similarly). In order to fix the failure, syslog() should be replaced back with lowsyslog() in the demo app.


⚠ Jenkins Plugins Artifactory has degraded performance

In ec4061b, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1274 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 5e24722 after 18 minutes.


Non-deterministic? behavior if a requirements.txt contains a dependency which is also specified to be installed editable

Consider a trivial (empty) package foo with a requirements.txt file containing just file:., i.e. "install this package".
During development, one of course often wants to install the package under development in editable mode, effectively attempting to override the requirement. Note that in pip, that does not work (and I personally generally resort to simply running 2 commands).
More specifically, the following command results in the successive output when using pip:
⊙  rm -rf venv && python3.12 -m venv venv && venv=$PWD/venv/bin/python && echo $venv && $venv -m pip install -r requirements.txt -e . && printf 'Empty:\n' && printf '\n' >foo/__init__.py && $venv -c 'import foo' && printf 'Modifying...\n' && printf 'print("MODIFIED")\n' >foo/__init__.py && $venv -c 'import foo' && cd /tmp && $venv -c 'import foo' && cd -
/Users/julian/Desktop/foo/venv/bin/python
Obtaining file:///Users/julian/Desktop/foo
  Installing build dependencies ... done
  Checking if build backend supports build_editable ... done
  Getting requirements to build editable ... done
  Installing backend dependencies ... done
  Preparing editable metadata (pyproject.toml) ... done
Processing /Users/julian/Desktop/foo
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
ERROR: Cannot install foo 0.1.dev1+g81dbecd (from .) and foo 0.1.dev1+g81dbecd (from /Users/julian/Desktop/foo) because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested foo 0.1.dev1+g81dbecd (from /Users/julian/Desktop/foo)
    The user requested foo 0.1.dev1+g81dbecd (from .)

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

I believe there is an issue somewhere on the pip tracker to loosen this constraint, as of course it is possible to simultaneously satisfy the two requirements, but I haven't gone and found it at the minute.
With uv however, no error is emitted, which made me think this works in uv, but it has subtly non-deterministic behavior (or at least I can't tell what it's doing, and it doesn't appear that the package is installed in editable mode). Specifically here's the behavior I get from running something like the above commands twice, where we're installing simultaneously, modifying the file, then checking to see if Python sees our modifications:
⊙  rm -rf venv && uv venv venv && venv=$PWD/venv/bin/python && echo $venv && uv pip install --verbose --python $venv -r requirements.txt -e . && printf 'Empty:\n' && printf '\n' >foo/__init__.py && $venv -c 'import foo' && printf 'Modifying...\n' && printf 'print("FIRST")\n' >foo/__init__.py && $venv -c 'import foo' && printf 'print("SECOND")\n' >foo/__init__.py && cd /tmp && $venv -c 'import foo' && cd -
Using Python 3.12.3 interpreter at<EMAIL_ADDRESS>Creating virtualenv at: venv
Activate with: source venv/bin/activate
/Users/julian/Desktop/foo/venv/bin/python
DEBUG Checking for Python interpreter at path `venv/bin/python`
DEBUG Using Python 3.12.3 environment at venv/bin/python
DEBUG Acquired lock for `venv`
DEBUG At least one requirement is not satisfied: file:///Users/julian/Desktop/foo
DEBUG Using registry request timeout of 30s
DEBUG Found PEP 621 metadata for /Users/julian/Desktop/foo in `pyproject.toml` (foo)
DEBUG Found PEP 621 metadata for /Users/julian/Desktop/foo in `pyproject.toml` (foo)
DEBUG Acquired lock for `/Users/julian/Library/Caches/uv/built-wheels-v3/editable/865209b8dda329ac`
DEBUG Preparing metadata for: foo @ file:///Users/julian/Desktop/foo
DEBUG No static `PKG-INFO` available for: foo @ file:///Users/julian/Desktop/foo (MissingPkgInfo)
DEBUG No static `pyproject.toml` available for: foo @ file:///Users/julian/Desktop/foo (DynamicPyprojectToml(DynamicField("version")))
DEBUG Solving with target Python version 3.12.3
DEBUG Adding direct dependency: hatchling*
DEBUG Adding direct dependency: hatch-vcs*
DEBUG Found fresh response for: https://pypi.org/simple/hatch-vcs/
DEBUG Found fresh response for: https://pypi.org/simple/hatchling/
DEBUG Searching for a compatible version of hatchling (*)
DEBUG Selecting: hatchling==1.24.2 (hatchling-1.24.2-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/82/0f/6cbd9976160bc334add63bc2e7a58b1433a31b34b7cda6c5de6dd983d9a7/hatch_vcs-0.4.0-py3-none-any.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/5f/20/b890241570ac3ba6508febab3104eeb1acd7ffba1bd3447190f56151f1bc/hatchling-1.24.2-py3-none-any.whl.metadata
DEBUG Adding transitive dependency for hatchling==1.24.2: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.24.2: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.2: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.24.2: trove-classifiers*
DEBUG Searching for a compatible version of hatch-vcs (*)
DEBUG Selecting: hatch-vcs==0.4.0 (hatch_vcs-0.4.0-py3-none-any.whl)
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: hatchling>=1.1.0
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: setuptools-scm>=6.4.0
DEBUG Found fresh response for: https://pypi.org/simple/pluggy/
DEBUG Found fresh response for: https://pypi.org/simple/pathspec/
DEBUG Found fresh response for: https://pypi.org/simple/trove-classifiers/
DEBUG Found fresh response for: https://pypi.org/simple/packaging/
DEBUG Searching for a compatible version of packaging (>=23.2)
DEBUG Selecting: packaging==24.0 (packaging-24.0-py3-none-any.whl)
DEBUG Found fresh response for: https://pypi.org/simple/setuptools-scm/
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/88/5f/e351af9a41f866ac3f1fac4ca0613908d9a41741cfcf2228f4ad853b697d/pluggy-1.5.0-py3-none-any.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/cc/20/ff623b09d963f88bfde16306a54e12ee5ea43e9b597108672ff3a408aad6/pathspec-0.12.1-py3-none-any.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/49/df/1fceb2f8900f8639e278b056416d49134fb8d84c5942ffaa01ad34782422/packaging-24.0-py3-none-any.whl.metadata
DEBUG Searching for a compatible version of pathspec (>=0.10.1)
DEBUG Selecting: pathspec==0.12.1 (pathspec-0.12.1-py3-none-any.whl)
DEBUG Searching for a compatible version of pluggy (>=1.0.0)
DEBUG Selecting: pluggy==1.5.0 (pluggy-1.5.0-py3-none-any.whl)
DEBUG Searching for a compatible version of trove-classifiers (*)
DEBUG Selecting: trove-classifiers==2024.5.22 (trove_classifiers-2024.5.22-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/00/87/c8ccf265dea5f96a1e930e69b97214255bbe284ca78e450aeaba7d021bdb/trove_classifiers-2024.5.22-py3-none-any.whl.metadata
DEBUG Searching for a compatible version of setuptools-scm (>=6.4.0)
DEBUG Selecting: setuptools-scm==8.1.0 (setuptools_scm-8.1.0-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/a0/b9/1906bfeb30f2fc13bb39bf7ddb8749784c05faadbd18a21cf141ba37bff2/setuptools_scm-8.1.0-py3-none-any.whl.metadata
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: packaging>=20
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: setuptools*
DEBUG Found fresh response for: https://pypi.org/simple/setuptools/
DEBUG Searching for a compatible version of setuptools (*)
DEBUG Selecting: setuptools==70.0.0 (setuptools-70.0.0-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/de/88/70c5767a0e43eb4451c2200f07d042a4bcd7639276003a9c54a68cfcc1f8/setuptools-70.0.0-py3-none-any.whl.metadata
DEBUG Tried 9 versions: hatch-vcs 1, hatchling 1, packaging 1, pathspec 1, pluggy 1, root 1, setuptools 1, setuptools-scm 1, trove-classifiers 1
DEBUG Installing in hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22 in /Users/julian/Library/Caches/uv/.tmphH0mHN/.venv
DEBUG Requirement already cached: hatch-vcs==0.4.0
DEBUG Requirement already cached: hatchling==1.24.2
DEBUG Requirement already cached: packaging==24.0
DEBUG Requirement already cached: pathspec==0.12.1
DEBUG Requirement already cached: pluggy==1.5.0
DEBUG Requirement already cached: setuptools==70.0.0
DEBUG Requirement already cached: setuptools-scm==8.1.0
DEBUG Requirement already cached: trove-classifiers==2024.5.22
DEBUG Installing build requirements: hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22
DEBUG Calling `hatchling.build.get_requires_for_build_editable()`
DEBUG Installing extra requirements for build backend
DEBUG Solving with target Python version 3.12.3
DEBUG Adding direct dependency: hatchling*
DEBUG Adding direct dependency: hatch-vcs*
DEBUG Adding direct dependency: editables>=0.3, <1.dev0
DEBUG Searching for a compatible version of hatchling (*)
DEBUG Selecting: hatchling==1.24.2 (hatchling-1.24.2-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.24.2: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.24.2: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.2: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.24.2: trove-classifiers*
DEBUG Searching for a compatible version of hatch-vcs (*)
DEBUG Selecting: hatch-vcs==0.4.0 (hatch_vcs-0.4.0-py3-none-any.whl)
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: hatchling>=1.1.0
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: setuptools-scm>=6.4.0
DEBUG Found stale response for: https://pypi.org/simple/editables/
DEBUG Sending revalidation request for: https://pypi.org/simple/editables/
DEBUG Found not-modified response for: https://pypi.org/simple/editables/
DEBUG Searching for a compatible version of editables (>=0.3, <1.dev0)
DEBUG Selecting: editables==0.5 (editables-0.5-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/6b/be/0f2f4a5e8adc114a02b63d92bf8edbfa24db6fc602fca83c885af2479e0e/editables-0.5-py3-none-any.whl.metadata
DEBUG Searching for a compatible version of packaging (>=23.2)
DEBUG Selecting: packaging==24.0 (packaging-24.0-py3-none-any.whl)
DEBUG Searching for a compatible version of pathspec (>=0.10.1)
DEBUG Selecting: pathspec==0.12.1 (pathspec-0.12.1-py3-none-any.whl)
DEBUG Searching for a compatible version of pluggy (>=1.0.0)
DEBUG Selecting: pluggy==1.5.0 (pluggy-1.5.0-py3-none-any.whl)
DEBUG Searching for a compatible version of trove-classifiers (*)
DEBUG Selecting: trove-classifiers==2024.5.22 (trove_classifiers-2024.5.22-py3-none-any.whl)
DEBUG Searching for a compatible version of setuptools-scm (>=6.4.0)
DEBUG Selecting: setuptools-scm==8.1.0 (setuptools_scm-8.1.0-py3-none-any.whl)
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: packaging>=20
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: setuptools*
DEBUG Searching for a compatible version of setuptools (*)
DEBUG Selecting: setuptools==70.0.0 (setuptools-70.0.0-py3-none-any.whl)
DEBUG Tried 10 versions: editables 1, hatch-vcs 1, hatchling 1, packaging 1, pathspec 1, pluggy 1, root 1, setuptools 1, setuptools-scm 1, trove-classifiers 1
DEBUG Installing in editables==0.5, hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22 in /Users/julian/Library/Caches/uv/.tmphH0mHN/.venv
DEBUG Requirement already cached: editables==0.5
DEBUG Requirement already installed: hatch-vcs==0.4.0
DEBUG Requirement already installed: hatchling==1.24.2
DEBUG Requirement already installed: packaging==24.0
DEBUG Requirement already installed: pathspec==0.12.1
DEBUG Requirement already installed: pluggy==1.5.0
DEBUG Requirement already installed: setuptools==70.0.0
DEBUG Requirement already installed: setuptools-scm==8.1.0
DEBUG Requirement already installed: trove-classifiers==2024.5.22
DEBUG Installing build requirement: editables==0.5
DEBUG Calling `hatchling.build.prepare_metadata_for_build_editable()`
DEBUG Prepared metadata for: foo @ file:///Users/julian/Desktop/foo
DEBUG No workspace root found, using project root
DEBUG Acquired lock for `/Users/julian/Library/Caches/uv/built-wheels-v3/path/865209b8dda329ac`
DEBUG Preparing metadata for: foo @ file:///Users/julian/Desktop/foo
DEBUG No static `PKG-INFO` available for: foo @ file:///Users/julian/Desktop/foo (MissingPkgInfo)
DEBUG No static `pyproject.toml` available for: foo @ file:///Users/julian/Desktop/foo (DynamicPyprojectToml(DynamicField("version")))
DEBUG Solving with target Python version 3.12.3
DEBUG Adding direct dependency: hatchling*
DEBUG Adding direct dependency: hatch-vcs*
DEBUG Searching for a compatible version of hatchling (*)
DEBUG Selecting: hatchling==1.24.2 (hatchling-1.24.2-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.24.2: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.24.2: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.2: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.24.2: trove-classifiers*
DEBUG Searching for a compatible version of hatch-vcs (*)
DEBUG Selecting: hatch-vcs==0.4.0 (hatch_vcs-0.4.0-py3-none-any.whl)
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: hatchling>=1.1.0
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: setuptools-scm>=6.4.0
DEBUG Searching for a compatible version of packaging (>=23.2)
DEBUG Selecting: packaging==24.0 (packaging-24.0-py3-none-any.whl)
DEBUG Searching for a compatible version of pathspec (>=0.10.1)
DEBUG Selecting: pathspec==0.12.1 (pathspec-0.12.1-py3-none-any.whl)
DEBUG Searching for a compatible version of pluggy (>=1.0.0)
DEBUG Selecting: pluggy==1.5.0 (pluggy-1.5.0-py3-none-any.whl)
DEBUG Searching for a compatible version of trove-classifiers (*)
DEBUG Selecting: trove-classifiers==2024.5.22 (trove_classifiers-2024.5.22-py3-none-any.whl)
DEBUG Searching for a compatible version of setuptools-scm (>=6.4.0)
DEBUG Selecting: setuptools-scm==8.1.0 (setuptools_scm-8.1.0-py3-none-any.whl)
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: packaging>=20
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: setuptools*
DEBUG Searching for a compatible version of setuptools (*)
DEBUG Selecting: setuptools==70.0.0 (setuptools-70.0.0-py3-none-any.whl)
DEBUG Tried 9 versions: hatch-vcs 1, hatchling 1, packaging 1, pathspec 1, pluggy 1, root 1, setuptools 1, setuptools-scm 1, trove-classifiers 1
DEBUG Installing in hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22 in /Users/julian/Library/Caches/uv/.tmpyILCIY/.venv
DEBUG Requirement already cached: hatch-vcs==0.4.0
DEBUG Requirement already cached: hatchling==1.24.2
DEBUG Requirement already cached: packaging==24.0
DEBUG Requirement already cached: pathspec==0.12.1
DEBUG Requirement already cached: pluggy==1.5.0
DEBUG Requirement already cached: setuptools==70.0.0
DEBUG Requirement already cached: setuptools-scm==8.1.0
DEBUG Requirement already cached: trove-classifiers==2024.5.22
DEBUG Installing build requirements: hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22
DEBUG Calling `hatchling.build.get_requires_for_build_wheel()`
DEBUG Calling `hatchling.build.prepare_metadata_for_build_wheel()`
DEBUG Prepared metadata for: foo @ file:///Users/julian/Desktop/foo
DEBUG No workspace root found, using project root
DEBUG Solving with target Python version 3.12.3
DEBUG Adding direct dependency: foo*
DEBUG Adding direct dependency: foo*
DEBUG Searching for a compatible version of foo @ file:///Users/julian/Desktop/foo (*)
DEBUG Tried 2 versions: foo 1, root 1
Resolved 1 package in 1.04s
DEBUG Identified uncached requirement: foo @ file:///Users/julian/Desktop/foo
DEBUG Acquired lock for `/Users/julian/Library/Caches/uv/built-wheels-v3/path/865209b8dda329ac`
DEBUG Building: foo @ file:///Users/julian/Desktop/foo
DEBUG Solving with target Python version 3.12.3
DEBUG Adding direct dependency: hatchling*
DEBUG Adding direct dependency: hatch-vcs*
DEBUG Searching for a compatible version of hatchling (*)
DEBUG Selecting: hatchling==1.24.2 (hatchling-1.24.2-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.24.2: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.24.2: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.2: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.24.2: trove-classifiers*
DEBUG Searching for a compatible version of hatch-vcs (*)
DEBUG Selecting: hatch-vcs==0.4.0 (hatch_vcs-0.4.0-py3-none-any.whl)
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: hatchling>=1.1.0
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: setuptools-scm>=6.4.0
DEBUG Searching for a compatible version of packaging (>=23.2)
DEBUG Selecting: packaging==24.0 (packaging-24.0-py3-none-any.whl)
DEBUG Searching for a compatible version of pathspec (>=0.10.1)
DEBUG Selecting: pathspec==0.12.1 (pathspec-0.12.1-py3-none-any.whl)
DEBUG Searching for a compatible version of pluggy (>=1.0.0)
DEBUG Selecting: pluggy==1.5.0 (pluggy-1.5.0-py3-none-any.whl)
DEBUG Searching for a compatible version of trove-classifiers (*)
DEBUG Selecting: trove-classifiers==2024.5.22 (trove_classifiers-2024.5.22-py3-none-any.whl)
DEBUG Searching for a compatible version of setuptools-scm (>=6.4.0)
DEBUG Selecting: setuptools-scm==8.1.0 (setuptools_scm-8.1.0-py3-none-any.whl)
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: packaging>=20
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: setuptools*
DEBUG Searching for a compatible version of setuptools (*)
DEBUG Selecting: setuptools==70.0.0 (setuptools-70.0.0-py3-none-any.whl)
DEBUG Tried 9 versions: hatch-vcs 1, hatchling 1, packaging 1, pathspec 1, pluggy 1, root 1, setuptools 1, setuptools-scm 1, trove-classifiers 1
DEBUG Installing in hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22 in /Users/julian/Library/Caches/uv/.tmptcdfFf/.venv
DEBUG Requirement already cached: hatch-vcs==0.4.0
DEBUG Requirement already cached: hatchling==1.24.2
DEBUG Requirement already cached: packaging==24.0
DEBUG Requirement already cached: pathspec==0.12.1
DEBUG Requirement already cached: pluggy==1.5.0
DEBUG Requirement already cached: setuptools==70.0.0
DEBUG Requirement already cached: setuptools-scm==8.1.0
DEBUG Requirement already cached: trove-classifiers==2024.5.22
DEBUG Installing build requirements: hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22
DEBUG Calling `hatchling.build.get_requires_for_build_wheel()`
DEBUG Calling `hatchling.build.build_wheel("/Users/julian/Library/Caches/uv/built-wheels-v3/path/865209b8dda329ac/ahCsxAvuODcIU4xUw99Pw/.tmpLAhMzR", {}, None)`
DEBUG Finished building: foo @ file:///Users/julian/Desktop/foo
Downloaded 1 package in 352ms
Installed 1 package in 0.70ms
 + foo==0.1.dev1+g81dbecd (from file:///Users/julian/Desktop/foo)
Empty:
Modifying...
FIRST
SECOND
~/Desktop/foo

~/Desktop/foo is a git repository on main
⊙  rm -rf venv && uv venv venv && venv=$PWD/venv/bin/python && echo $venv && uv pip install --verbose --python $venv -r requirements.txt -e . && printf 'Empty:\n' && printf '\n' >foo/__init__.py && $venv -c 'import foo' && printf 'Modifying...\n' && printf 'print("1")\n' >foo/__init__.py && $venv -c 'import foo' && printf 'print("2")\n' >foo/__init__.py && cd /tmp && $venv -c 'import foo' && cd -
Using Python 3.12.3 interpreter at<EMAIL_ADDRESS>Creating virtualenv at: venv
Activate with: source venv/bin/activate
/Users/julian/Desktop/foo/venv/bin/python
DEBUG Checking for Python interpreter at path `venv/bin/python`
DEBUG Using Python 3.12.3 environment at venv/bin/python
DEBUG Acquired lock for `venv`
DEBUG At least one requirement is not satisfied: file:///Users/julian/Desktop/foo
DEBUG Using registry request timeout of 30s
DEBUG Found PEP 621 metadata for /Users/julian/Desktop/foo in `pyproject.toml` (foo)
DEBUG Found PEP 621 metadata for /Users/julian/Desktop/foo in `pyproject.toml` (foo)
DEBUG Acquired lock for `/Users/julian/Library/Caches/uv/built-wheels-v3/editable/865209b8dda329ac`
DEBUG Preparing metadata for: foo @ file:///Users/julian/Desktop/foo
DEBUG No static `PKG-INFO` available for: foo @ file:///Users/julian/Desktop/foo (MissingPkgInfo)
DEBUG No static `pyproject.toml` available for: foo @ file:///Users/julian/Desktop/foo (DynamicPyprojectToml(DynamicField("version")))
DEBUG Solving with target Python version 3.12.3
DEBUG Adding direct dependency: hatchling*
DEBUG Adding direct dependency: hatch-vcs*
DEBUG Found fresh response for: https://pypi.org/simple/hatchling/
DEBUG Found fresh response for: https://pypi.org/simple/hatch-vcs/
DEBUG Searching for a compatible version of hatchling (*)
DEBUG Selecting: hatchling==1.24.2 (hatchling-1.24.2-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/5f/20/b890241570ac3ba6508febab3104eeb1acd7ffba1bd3447190f56151f1bc/hatchling-1.24.2-py3-none-any.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/82/0f/6cbd9976160bc334add63bc2e7a58b1433a31b34b7cda6c5de6dd983d9a7/hatch_vcs-0.4.0-py3-none-any.whl.metadata
DEBUG Adding transitive dependency for hatchling==1.24.2: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.24.2: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.2: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.24.2: trove-classifiers*
DEBUG Searching for a compatible version of hatch-vcs (*)
DEBUG Selecting: hatch-vcs==0.4.0 (hatch_vcs-0.4.0-py3-none-any.whl)
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: hatchling>=1.1.0
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: setuptools-scm>=6.4.0
DEBUG Found fresh response for: https://pypi.org/simple/pluggy/
DEBUG Found fresh response for: https://pypi.org/simple/pathspec/
DEBUG Found fresh response for: https://pypi.org/simple/trove-classifiers/
DEBUG Found fresh response for: https://pypi.org/simple/packaging/
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/88/5f/e351af9a41f866ac3f1fac4ca0613908d9a41741cfcf2228f4ad853b697d/pluggy-1.5.0-py3-none-any.whl.metadata
DEBUG Searching for a compatible version of packaging (>=23.2)
DEBUG Selecting: packaging==24.0 (packaging-24.0-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/cc/20/ff623b09d963f88bfde16306a54e12ee5ea43e9b597108672ff3a408aad6/pathspec-0.12.1-py3-none-any.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/00/87/c8ccf265dea5f96a1e930e69b97214255bbe284ca78e450aeaba7d021bdb/trove_classifiers-2024.5.22-py3-none-any.whl.metadata
DEBUG Found fresh response for: https://pypi.org/simple/setuptools-scm/
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/a0/b9/1906bfeb30f2fc13bb39bf7ddb8749784c05faadbd18a21cf141ba37bff2/setuptools_scm-8.1.0-py3-none-any.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/49/df/1fceb2f8900f8639e278b056416d49134fb8d84c5942ffaa01ad34782422/packaging-24.0-py3-none-any.whl.metadata
DEBUG Searching for a compatible version of pathspec (>=0.10.1)
DEBUG Selecting: pathspec==0.12.1 (pathspec-0.12.1-py3-none-any.whl)
DEBUG Searching for a compatible version of pluggy (>=1.0.0)
DEBUG Selecting: pluggy==1.5.0 (pluggy-1.5.0-py3-none-any.whl)
DEBUG Searching for a compatible version of trove-classifiers (*)
DEBUG Selecting: trove-classifiers==2024.5.22 (trove_classifiers-2024.5.22-py3-none-any.whl)
DEBUG Searching for a compatible version of setuptools-scm (>=6.4.0)
DEBUG Selecting: setuptools-scm==8.1.0 (setuptools_scm-8.1.0-py3-none-any.whl)
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: packaging>=20
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: setuptools*
DEBUG Found fresh response for: https://pypi.org/simple/setuptools/
DEBUG Searching for a compatible version of setuptools (*)
DEBUG Selecting: setuptools==70.0.0 (setuptools-70.0.0-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/de/88/70c5767a0e43eb4451c2200f07d042a4bcd7639276003a9c54a68cfcc1f8/setuptools-70.0.0-py3-none-any.whl.metadata
DEBUG Tried 9 versions: hatch-vcs 1, hatchling 1, packaging 1, pathspec 1, pluggy 1, root 1, setuptools 1, setuptools-scm 1, trove-classifiers 1
DEBUG Installing in hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22 in /Users/julian/Library/Caches/uv/.tmpGuDG1Z/.venv
DEBUG Requirement already cached: hatch-vcs==0.4.0
DEBUG Requirement already cached: hatchling==1.24.2
DEBUG Requirement already cached: packaging==24.0
DEBUG Requirement already cached: pathspec==0.12.1
DEBUG Requirement already cached: pluggy==1.5.0
DEBUG Requirement already cached: setuptools==70.0.0
DEBUG Requirement already cached: setuptools-scm==8.1.0
DEBUG Requirement already cached: trove-classifiers==2024.5.22
DEBUG Installing build requirements: hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22
DEBUG Calling `hatchling.build.get_requires_for_build_editable()`
DEBUG Installing extra requirements for build backend
DEBUG Solving with target Python version 3.12.3
DEBUG Adding direct dependency: hatchling*
DEBUG Adding direct dependency: hatch-vcs*
DEBUG Adding direct dependency: editables>=0.3, <1.dev0
DEBUG Searching for a compatible version of hatchling (*)
DEBUG Selecting: hatchling==1.24.2 (hatchling-1.24.2-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.24.2: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.24.2: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.2: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.24.2: trove-classifiers*
DEBUG Searching for a compatible version of hatch-vcs (*)
DEBUG Selecting: hatch-vcs==0.4.0 (hatch_vcs-0.4.0-py3-none-any.whl)
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: hatchling>=1.1.0
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: setuptools-scm>=6.4.0
DEBUG Found fresh response for: https://pypi.org/simple/editables/
DEBUG Searching for a compatible version of editables (>=0.3, <1.dev0)
DEBUG Selecting: editables==0.5 (editables-0.5-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/6b/be/0f2f4a5e8adc114a02b63d92bf8edbfa24db6fc602fca83c885af2479e0e/editables-0.5-py3-none-any.whl.metadata
DEBUG Searching for a compatible version of packaging (>=23.2)
DEBUG Selecting: packaging==24.0 (packaging-24.0-py3-none-any.whl)
DEBUG Searching for a compatible version of pathspec (>=0.10.1)
DEBUG Selecting: pathspec==0.12.1 (pathspec-0.12.1-py3-none-any.whl)
DEBUG Searching for a compatible version of pluggy (>=1.0.0)
DEBUG Selecting: pluggy==1.5.0 (pluggy-1.5.0-py3-none-any.whl)
DEBUG Searching for a compatible version of trove-classifiers (*)
DEBUG Selecting: trove-classifiers==2024.5.22 (trove_classifiers-2024.5.22-py3-none-any.whl)
DEBUG Searching for a compatible version of setuptools-scm (>=6.4.0)
DEBUG Selecting: setuptools-scm==8.1.0 (setuptools_scm-8.1.0-py3-none-any.whl)
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: packaging>=20
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: setuptools*
DEBUG Searching for a compatible version of setuptools (*)
DEBUG Selecting: setuptools==70.0.0 (setuptools-70.0.0-py3-none-any.whl)
DEBUG Tried 10 versions: editables 1, hatch-vcs 1, hatchling 1, packaging 1, pathspec 1, pluggy 1, root 1, setuptools 1, setuptools-scm 1, trove-classifiers 1
DEBUG Installing in editables==0.5, hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22 in /Users/julian/Library/Caches/uv/.tmpGuDG1Z/.venv
DEBUG Requirement already cached: editables==0.5
DEBUG Requirement already installed: hatch-vcs==0.4.0
DEBUG Requirement already installed: hatchling==1.24.2
DEBUG Requirement already installed: packaging==24.0
DEBUG Requirement already installed: pathspec==0.12.1
DEBUG Requirement already installed: pluggy==1.5.0
DEBUG Requirement already installed: setuptools==70.0.0
DEBUG Requirement already installed: setuptools-scm==8.1.0
DEBUG Requirement already installed: trove-classifiers==2024.5.22
DEBUG Installing build requirement: editables==0.5
DEBUG Calling `hatchling.build.prepare_metadata_for_build_editable()`
DEBUG Prepared metadata for: foo @ file:///Users/julian/Desktop/foo
DEBUG No workspace root found, using project root
DEBUG Acquired lock for `/Users/julian/Library/Caches/uv/built-wheels-v3/path/865209b8dda329ac`
DEBUG Preparing metadata for: foo @ file:///Users/julian/Desktop/foo
DEBUG No static `PKG-INFO` available for: foo @ file:///Users/julian/Desktop/foo (MissingPkgInfo)
DEBUG No static `pyproject.toml` available for: foo @ file:///Users/julian/Desktop/foo (DynamicPyprojectToml(DynamicField("version")))
DEBUG Solving with target Python version 3.12.3
DEBUG Adding direct dependency: hatchling*
DEBUG Adding direct dependency: hatch-vcs*
DEBUG Searching for a compatible version of hatchling (*)
DEBUG Selecting: hatchling==1.24.2 (hatchling-1.24.2-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.24.2: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.24.2: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.2: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.24.2: trove-classifiers*
DEBUG Searching for a compatible version of hatch-vcs (*)
DEBUG Selecting: hatch-vcs==0.4.0 (hatch_vcs-0.4.0-py3-none-any.whl)
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: hatchling>=1.1.0
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: setuptools-scm>=6.4.0
DEBUG Searching for a compatible version of packaging (>=23.2)
DEBUG Selecting: packaging==24.0 (packaging-24.0-py3-none-any.whl)
DEBUG Searching for a compatible version of pathspec (>=0.10.1)
DEBUG Selecting: pathspec==0.12.1 (pathspec-0.12.1-py3-none-any.whl)
DEBUG Searching for a compatible version of pluggy (>=1.0.0)
DEBUG Selecting: pluggy==1.5.0 (pluggy-1.5.0-py3-none-any.whl)
DEBUG Searching for a compatible version of trove-classifiers (*)
DEBUG Selecting: trove-classifiers==2024.5.22 (trove_classifiers-2024.5.22-py3-none-any.whl)
DEBUG Searching for a compatible version of setuptools-scm (>=6.4.0)
DEBUG Selecting: setuptools-scm==8.1.0 (setuptools_scm-8.1.0-py3-none-any.whl)
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: packaging>=20
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: setuptools*
DEBUG Searching for a compatible version of setuptools (*)
DEBUG Selecting: setuptools==70.0.0 (setuptools-70.0.0-py3-none-any.whl)
DEBUG Tried 9 versions: hatch-vcs 1, hatchling 1, packaging 1, pathspec 1, pluggy 1, root 1, setuptools 1, setuptools-scm 1, trove-classifiers 1
DEBUG Installing in hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22 in /Users/julian/Library/Caches/uv/.tmpiDZtHF/.venv
DEBUG Requirement already cached: hatch-vcs==0.4.0
DEBUG Requirement already cached: hatchling==1.24.2
DEBUG Requirement already cached: packaging==24.0
DEBUG Requirement already cached: pathspec==0.12.1
DEBUG Requirement already cached: pluggy==1.5.0
DEBUG Requirement already cached: setuptools==70.0.0
DEBUG Requirement already cached: setuptools-scm==8.1.0
DEBUG Requirement already cached: trove-classifiers==2024.5.22
DEBUG Installing build requirements: hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22
DEBUG Calling `hatchling.build.get_requires_for_build_wheel()`
DEBUG Calling `hatchling.build.prepare_metadata_for_build_wheel()`
DEBUG Prepared metadata for: foo @ file:///Users/julian/Desktop/foo
DEBUG No workspace root found, using project root
DEBUG Solving with target Python version 3.12.3
DEBUG Adding direct dependency: foo*
DEBUG Adding direct dependency: foo*
DEBUG Searching for a compatible version of foo @ file:///Users/julian/Desktop/foo (*)
DEBUG Tried 2 versions: foo 1, root 1
Resolved 1 package in 780ms
DEBUG Identified uncached requirement: foo @ file:///Users/julian/Desktop/foo
DEBUG Acquired lock for `/Users/julian/Library/Caches/uv/built-wheels-v3/path/865209b8dda329ac`
DEBUG Building: foo @ file:///Users/julian/Desktop/foo
DEBUG Solving with target Python version 3.12.3
DEBUG Adding direct dependency: hatchling*
DEBUG Adding direct dependency: hatch-vcs*
DEBUG Searching for a compatible version of hatchling (*)
DEBUG Selecting: hatchling==1.24.2 (hatchling-1.24.2-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.24.2: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.24.2: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.2: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.24.2: trove-classifiers*
DEBUG Searching for a compatible version of hatch-vcs (*)
DEBUG Selecting: hatch-vcs==0.4.0 (hatch_vcs-0.4.0-py3-none-any.whl)
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: hatchling>=1.1.0
DEBUG Adding transitive dependency for hatch-vcs==0.4.0: setuptools-scm>=6.4.0
DEBUG Searching for a compatible version of packaging (>=23.2)
DEBUG Selecting: packaging==24.0 (packaging-24.0-py3-none-any.whl)
DEBUG Searching for a compatible version of pathspec (>=0.10.1)
DEBUG Selecting: pathspec==0.12.1 (pathspec-0.12.1-py3-none-any.whl)
DEBUG Searching for a compatible version of pluggy (>=1.0.0)
DEBUG Selecting: pluggy==1.5.0 (pluggy-1.5.0-py3-none-any.whl)
DEBUG Searching for a compatible version of trove-classifiers (*)
DEBUG Selecting: trove-classifiers==2024.5.22 (trove_classifiers-2024.5.22-py3-none-any.whl)
DEBUG Searching for a compatible version of setuptools-scm (>=6.4.0)
DEBUG Selecting: setuptools-scm==8.1.0 (setuptools_scm-8.1.0-py3-none-any.whl)
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: packaging>=20
DEBUG Adding transitive dependency for setuptools-scm==8.1.0: setuptools*
DEBUG Searching for a compatible version of setuptools (*)
DEBUG Selecting: setuptools==70.0.0 (setuptools-70.0.0-py3-none-any.whl)
DEBUG Tried 9 versions: hatch-vcs 1, hatchling 1, packaging 1, pathspec 1, pluggy 1, root 1, setuptools 1, setuptools-scm 1, trove-classifiers 1
DEBUG Installing in hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22 in /Users/julian/Library/Caches/uv/.tmpdGWv66/.venv
DEBUG Requirement already cached: hatch-vcs==0.4.0
DEBUG Requirement already cached: hatchling==1.24.2
DEBUG Requirement already cached: packaging==24.0
DEBUG Requirement already cached: pathspec==0.12.1
DEBUG Requirement already cached: pluggy==1.5.0
DEBUG Requirement already cached: setuptools==70.0.0
DEBUG Requirement already cached: setuptools-scm==8.1.0
DEBUG Requirement already cached: trove-classifiers==2024.5.22
DEBUG Installing build requirements: hatch-vcs==0.4.0, hatchling==1.24.2, packaging==24.0, pathspec==0.12.1, pluggy==1.5.0, setuptools==70.0.0, setuptools-scm==8.1.0, trove-classifiers==2024.5.22
DEBUG Calling `hatchling.build.get_requires_for_build_wheel()`
DEBUG Calling `hatchling.build.build_wheel("/Users/julian/Library/Caches/uv/built-wheels-v3/path/865209b8dda329ac/FbM6kNSTVxMSFcuMCja34/.tmpuvtH9o", {}, None)`
DEBUG Finished building: foo @ file:///Users/julian/Desktop/foo
Downloaded 1 package in 359ms
Installed 1 package in 0.80ms
 + foo==0.1.dev1+g81dbecd (from file:///Users/julian/Desktop/foo)
Empty:
Modifying...
1
SECOND

Note that the first time around everything seems fine (and the package seems like modifications are being seen), but the second time around, some caching seems to be visible, and our modification isn't seen / Python seems to see an old version of the package. In transparency, I haven't tried to diagnose this, so it's possible this is say, a hatch bug (which happens to be the build system I'm using in the above trivial package). But I thought I'd raise it in case you have thoughts, and also because if I had to wager, it'd seem slightly more likely to be uv than hatch that was in control there.
I'll note also that I don't seem to observe this behavior if I don't install out of a requirements.txt... specifically if in the above commands I use uv pip install 'file:.' -e ., I seem to consistently see the package "properly" installed editable.
(Thanks as usual for a great project!)

I think this is probably is non-deterministic somewhere.

So in my own testing, it does deterministically install as not editable above.

However, when I do install as editable, I sometimes don't see changes reflected, but I think it's due to CPython's bytecode caching.
The command I'm testing with (from ./scripts/packages/black_editable in this repo):
rm -rf venv && uv venv venv && venv=$PWD/venv/bin/python && rm black/__init__.py && touch black/__init__.py && echo $venv && uv pip install --verbose --python $venv -r requirements.txt -e . && printf 'Empty:\n' && printf '\n' >black/__init__.py && $venv -B -I -c 'import black' && printf 'Modifying...\n' && printf 'print("1")\n' >black/__init__.py && $venv -B -I -c 'import black' && printf 'print("2")\n' >black/__init__.py && $venv -B -I -c 'import black'

This consistently gives:
Empty:
Modifying...

If you install as editable in the requirements file, and omits the -B, then you see:
Empty:
Modifying...
1
1

If you include the -B:
Empty:
Modifying...
1
2

I think I'm going to change this to prefer editables though.


false duplication warning

I have a valid build.gradle, and the plugin complains

"repositories" has already been used in this build script.

buildscript {
    repositories {
    }
}
repositories {
}

It is the same for subprojects and they are duplicated in all flutter project.


Changed string ser/des names to avoid confusion.

Status
Type
⚠ Core Change
Issue

Ready
Refactor
Yes
Closes #276

Problem
String serialization and deserialization method names are ambiguous.
Solution
Changed these method names to be more explicit in what they do.

This will require new deploys of all dependent libraries that decode strings. Maybe we should bump to 0.6?

This will require new deploys of all dependent libraries that decode strings. Maybe we should bump to 0.6?

Could work, master already has the Get/Write/BigInt fixes which are kind of a big deal so wouldn't bother me to move faster with this version

Should we change the Bincode methods to have similar semantics as the others?


how can i split this into two activity's

Step 1: Are you in the right place?

For issues or feature requests related to the code in this repository file a Github issue.

If you are filing an issue about FCM in the background make sure to read #4 and #89 first!

For general technical questions, post a question on StackOverflow tagged appropriately.
For general Firebase discussion, use the firebase-talk google group
For help troubleshooting your application that does not fall under one of the above categories, reach out to the personalized Firebase support channel

Step 2: Describe your environment

Android device: _____
Android OS version: _____
Google Play Services version: _____
Firebase/Play Services SDK version: _____

Step 3: Describe the problem:
Steps to reproduce:

Observed Results:

What happened?  This could be a description, logcat output, etc.

Expected Results:

What did you expect to happen?

Relevant Code:
// TODO(you): code here to reproduce the problem

@oneilbogle1 we would need more information to assist with your issue.

@kroikie  using two activities for firebase phone authentication
https://stackoverflow.com/questions/46686891/using-two-activities-for-firebase-phone-authentication?noredirect=1#comment80321174_46686891

@oneilbogle1 could you post the logcat messages you get when the crash occurs?

Process: com.example.bogle.chatdemo2, PID: 32609 java.lang.IllegalArgumentException: Given String is empty or null  at com.google.android.gms.common.internal.zzbo.zzcF(Unknown Source)  at com.google.firebase.auth.PhoneAuthCredential.<init>(Unknown Source)   at com.google.firebase.auth.PhoneAuthProvider.getCredential(Unknown Source)  at com.example.bogle.chatdemo2.PhoneVerAuthActivity.verifyPhoneNumberWithCode(PhoneVerAuthActivity.java:127)  at com.example.bogle.chatdemo2.PhoneVerAuthActivity.onClick(PhoneVerAuthActivity.java:181)  at android.view.View.performClick(View.java:6205)  at android.widget.TextView.performClick(TextView.java:11103)  at android.view.View$PerformClick.run(View.java:23653)  at android.os.Handler.handleCallback(Handler.java:751)  at android.os.Handler.dispatchMessage(Handler.java:95) at android.os.Looper.loop(Looper.java:154) at android.app.ActivityThread.main(ActivityThread.java:6682) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1520) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1410)

@oneilbogle1 looks like your second activity has an empty verificationId since you are not calling verifyPhoneNumber in the second activity verificationId is never set.


audio streams done with VideoStream API don't join-in-progress

From Steven: when using a video stream instance that plays an audio stream (for example a radio feed), users joining the MRE late don't hear the stream
One guess is because join-in-progress on regular video streams seek forward, the seek may be not working on live streams.

It turns out that any live media (online radio, Mixer) will have a defined duration of 0.
The set-media-state rule is responsible for setting the the expirationTime of the media instance. Because it only checks to see if the VideoStream duration is undefined, a duration of 0 means the instance will receive an expirationTime of the current time (basisTime).
Within the activeMediaInstances method in clientSync.ts, the following line of code checks to see if the media instance has expired. It will always be true because the expirationTime is defined and it will always be slightly less than the targetTime.
if (activeMediaInstance.expirationTime !== undefined && targetTime > activeMediaInstance.expirationTime)

The sync payload never gets sent.
Possible fix is to check if the duration is 0 in the set-media-state rule.
if (activeMediaInstance.message.payload.options.looping === true ||
    activeMediaInstance.message.payload.options.paused === true ||
    (asset === undefined || asset.duration === undefined || asset.duration === 0)) {
        // media instance current will last forever
        activeMediaInstance.expirationTime = undefined;
}
else {

Fixed by #569