Error adding sheets using VS Code

I'm creating an Excel file and adding empty sheets to it using Visual Studio Code.  I get the following error when I call Add-Worksheet:
Add-Worksheet: Cannot process argument transformation on parameter 'ExcelPackage'. Cannot convert value "OfficeOpenXml.ExcelP
the "OfficeOpenXml.ExcelPackage" value of type "Deserialized.OfficeOpenXml.ExcelPackage" to type "OfficeOpenXml.ExcelPackage"
I do not get this error when using PowerShell ISE.
OS is Server 2012 R2, PowerShell version is 5.1.14409.1029, ImportExcel version is 7.1.0.

Need a script that repos this, plus the version of ImportExcel and the version of PowerShell in VS Code

Hopefully I can get you a script soon.  My company has to approve it.
Thanks.
On Mon, Jan 23, 2023 at 12:44 PM Doug Finke @.***>
wrote:

Need a script that repos this, plus the version of ImportExcel and the
version of PowerShell in VS Code
—
Reply to this email directly, view it on GitHub
https://github.com/dfinke/ImportExcel/issues/1384#issuecomment-1400811832,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVGUKG64YS2MRSFRANHTH6TWT3GRNANCNFSM6AAAAAAUEDB6VA
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Larry Singer
@.***

Best is if you can send a sample sample of the script + data of what you are trying to do. I won't be able to go through a large script and figure things out

FYI: Scope is Script level by default
This works for me on my test machines.  Share the error you are seeing.
$path = 'c:\temp\test.xlsx'
Remove-Item -Path $path -ErrorAction SilentlyContinue

$sheets = @('Dashboard','Page1','Page2')

$excel = Export-Excel -Path $path -WorksheetName 'Introduction' -PassThru

$sheets | foreach {
    $null = Add-Worksheet -ExcelPackage $excel -WorksheetName $PSItem
}

Close-ExcelPackage $excel -Show

Here is the error I'm getting:
Add-Worksheet: Cannot process argument transformation on parameter
'ExcelPackage'. Cannot convert value "OfficeOpenXml.ExcelPackage" to type
"OfficeOpenXml.ExcelPackage". Error: "Cannot convert the
"OfficeOpenXml.ExcelPackage" value of type
"Deserialized.OfficeOpenXml.ExcelPackage" to type
"OfficeOpenXml.ExcelPackage"."
I'm only getting this error on our Server 2012 R2 system.  It works fine on
Win 11 and Server 2019.
On Thu, Jan 26, 2023 at 2:50 PM Wes Stahler @.***>
wrote:

FYI: Scope is Script level by default
This works for me on my test machines. Share the error you are seeing.
$path = 'c:\temp\test.xlsx'Remove-Item -Path $path -ErrorAction SilentlyContinue
$sheets = @('Dashboard','Page1','Page2')
$excel = Export-Excel -Path $path -WorksheetName 'Introduction' -PassThru
$sheets | foreach {
$null = Add-Worksheet -ExcelPackage $excel -WorksheetName $PSItem
}
Close-ExcelPackage $excel -Show
—
Reply to this email directly, view it on GitHub
https://github.com/dfinke/ImportExcel/issues/1384#issuecomment-1405632891,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVGUKG2ULQZY4JZFQSWVMY3WULPQHANCNFSM6AAAAAAUEDB6VA
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Larry Singer
@.***

Sanity checks:

Is ImportExcel installed correctly?
Is the xlsx on a shared file system for 2012 R2?

Question 1) I have not seen any indication that the module is NOT installed
correctly, i.e., no errors were generated when I installed it.  HOWEVER, I
have seen another strange anomaly when adding sheets to an Excel file.
When I run this script with the builtin PowerShell IDE, I don't get the
error message I have shared, but I do get an extra sheet added that I have
not requested.  When I run this script on other computers, I don't see this
problem.  At first, I thought this was a bug in the module, but now I don't
think it is.
Question 2) The resulting xlsx file is on the system D: drive.  That drive
is not part of the shared file system.
On Fri, Jan 27, 2023 at 1:10 PM Doug Finke @.***> wrote:

Sanity checks:

Is ImportExcel installed correctly?
Is the xlsx on a shared file system for 2012 R2?

—
Reply to this email directly, view it on GitHub
https://github.com/dfinke/ImportExcel/issues/1384#issuecomment-1406960193,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVGUKGYY34NX5HZMTNI6QUTWUQMS7ANCNFSM6AAAAAAUEDB6VA
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Larry Singer
@.***


Notes present if no entry

Notes on authors are present even if no author present this note.
Issue in the before-body.tex
\Yinyang $if(author-notes.equal-contributor)$$author-notes.equal-contributor$$else$These authors contributed equally to this work.$endif$

% Additional Equal Contribution Note
% Also use this double-dagger symbol for special authorship notes, such as senior authorship.
%\ddag These authors also contributed equally to this work.

% Current address notes
\textcurrency Current Address: Dept/Program/Center, Institution Name, City, State, Country % change symbol to "\textcurrency a" if more than one current address note
% \textcurrency b Insert second current address
% \textcurrency c Insert third current address

% Deceased author note
\dag $if(author-notes.deceased)$$author-notes.deceased$$else$Deceased$endif$

This should only be included if there is a note, right ? DId I miss something?
IN the pdf:
PLOS templateName1 Surname1,2, Name2 Surname2, Name3 Surname2,3, Name4 Surname2, Name5Surname2†, Name6 Surname2, Name7 Surname1,2,3*, with the Lorem IpsumConsortium¶1Affiliation Dept, Institution Name, City, State, Country,2Affiliation Center, Institution Name, City, State, Country,3Affiliation Program, Institution Name, City, State, Country,YThese authors contributed equally to this work.¤Current Address: Dept/Program/Center, Institution Name, City, State, Country†Deceased

Oh thanks ! I understand !
So when a note is not used, it is not removed. I see.
We need to see how to modify the template to know about this. Hopefully our authors normalization will allow us to get the info in templates.


x/clock - permissionless

like feepay, allow a dev to put some funds in to pay for execution fees
Free execution up to 100k gas, then a reduced ujuno fee compare to globalfee (ex: 0.075ujuno is current. for this maybe charge 0.00075ujuno*gas each block. something reasonable)
if a contract execute fails enough (ex: no sudo message) "jail" the contract. small fee to unjail

Discussed with @Reecepbcups, we will not be implementing fees for clock contracts. So, that being said, contracts will not need to be funded nor will they be allowed to exceed 100k gas consumed.


fix: remove unused schema

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


trace CcdCallFnAfter() causality

Original author: Jim Phillips (@jcphill)
Original issue: https://charm.cs.illinois.edu/redmine/issues/1436

NAMD uses CcdCallFnAfter() to poll for GPU completion, which breaks the causality chain.  It should be possible to trace a chain of CcdCallFnAfter() calls back to the entry method that called the first one.

Original date: 2017-10-11 20:14:59

Ronak or Karthik, please get whatever further details are necessary, and decide if this should be addressed in the next release timeframe.

Original date: 2019-04-04 19:15:14

I think this is doable, but the detail of functions coming from a CcdCallFnAfter may be a bit suspect (since it just calls a function directly, so it's hard for the RTS to know what's executing) and the ordering causality chain may include extraneous calls due to differing levels of delays for different invocations of  CcdCallFnAfter. Regardless, getting causation to the right place may be a bit tricky without adding significantly more disambiguation code to adding stuff to the CcdCallFnAfter call. I've started toying with an implementation to see if I can get it to work correctly or not.


Can't access params from conf capabilities

Hello,
I'd like to pass a param from the command line and use it to set up my conf capabilities chrome language, like so:
Command line:
    protractor conf.js --params.language.lang='es-419'

I'd love to be able to set it like this and have it use my command:
Conf.js
exports.config = {
...
    capabilities: {
        browserName: 'chrome',
        chromeOptions: {
            args: ['lang=' + params.language.lang]
        }
    },
    params: {
        language: {
            lang: 'en-US'
        }
    },
...
};

Currently this says 'params not defined' and errors out before it begins.
Similarly, this.params.laguage.lang returns the error 'cannot read property language of undefined'.
As I understand, I can't access the params until the onPrepare section, so I think I am going about it wrong trying to access it in the setup. Is there a way to access the chromeOptions after the setup, or a way to get the params available beforehand?

Can't you write
protractor conf.js --capabilites.chromeOptions.args.0="'lang'=es-419"

?

@eolognt This seems to have no effect as far as I can tell =\

You can set  properties of the config object via the command line, though I don't think you can sub-properties like that.  I'll look into it.

Hey, @eolognt was basically right, but misspelled capabilities and had the syntax slightly off.  Try:
protractor conf.js --capabilities.chromeOptions.args.0 "'lang'=es-419"


Fix broken and flaky tests

the package removal tests are flaky because soon after the test package is installed, the startup script tries to access package manager database but it is locked by some other process.
I only saw this happening frequently with debian hosts

/gocheck


[Hub Generated] Publish private branch 'AddNewApiVersion'

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
ARM (Control Plane) API Specification Update Pull Request
PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

Purpose of this PR
What's the purpose of this PR? Check all that apply. This is mandatory!

[ ] New API version. (Such PR should have been generated with OpenAPI Hub, per this wiki doc.)
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[ ] Update existing version to fix swagger quality issues in S360.
[ ] Other, please clarify:

edit this with your clarification

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[ ] I have reviewed the general guidance on the spec PR review process: https://aka.ms/specprreview.
[ ] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data-plane related specifications.
[ ] I commit to follow the Breaking Change Policy.
[ ] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can request review from an ARM API Review board.

ARM API changes review

If you want for the ARM team to review this PR, you must add the ARMReview label.
The automation may automatically add the ARMReview label, if appropriate.
If this happens, proceed according to guidance given in GitHub comments also added by the automation.

Breaking change review
If you have any breaking changes as defined in the Breaking Change Policy,
follow the process outlined in the High-level Breaking Change Process doc.
Getting help

For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
For additional help, see https://aka.ms/azsdk/support/spectools.

The PR is created based on the updates in the private branch. The updates in the PR has already been reviewed and approved with this PR Azure/azure-rest-api-specs-pr/13385

Hi team, gentle reminder if you approved https://github.com/Azure/azure-rest-api-specs/pull/24940 then you can skip this PR.
They are the same, one is created by myself manually, this one is created via Hub. Both PRs are based the merged private pr https://github.com/Azure/azure-rest-api-specs-pr/pull/13385

Hi team, gentle reminder if you approved #24940 then you can skip this PR. They are the same, one is created by myself manually, this one is created via Hub. Both PRs are based the merged private pr Azure/azure-rest-api-specs-pr#13385

Thank you for adding this comment. We have already reviewed the other PR, so I believe this needs to be closed/drafted.

Hi team, I closed this one due to https://github.com/Azure/azure-rest-api-specs/pull/24940 is ARM signed off.


Add support for cleanup_efficiency

This PR adds support for calling diff_cleanupEfficiency from Python code.

Merged (with some changes)! Thanks!


autocomplete search bug

When I type "g." in the search page on http://brca-website.cloudapp.net/ it does nothing. (Well actually, a frustrating little "?" pops up next to the search box, but when I go over there to click on it is disappears.)
However, on http://brca-website.cloudapp.net/variants?search=g.&hide[]=Source_URL, when I type the same thing, i.e. "g.", it displays above the search box
"
12364 matching variants of which 32 matched on synonyms"
This is much more helpful than doing nothing. (Although the frustating little "?" still pops up, but here I can ignore it because I have the info I want)

At this point, both search boxes do the same thing in response to "g.": they return the hit to 12K matching variants with 32 pseudonym matches.  There is no auto-complete on g.  This  may be related to our wait for the Invitae library.

The issue is that we do not have anything in the pseudonyms column that lists the genomic HGVS string, with the formal "g." prefix.  We could fix this by adding pseudonyms that list the genomic coordinates in HGVS format.

Melissa to add the pseudonyms with the g.* prefix to the pseudonym column.


Monorepo setup and scaffolding

We will have various things in here probably so let's do the monorepo setup.
Acceptance

[x] Monorepo setup with flowershow package in it at packages/flowershow 🚧2022-10-25 ❓ think we could rename CLI to be named flowershow consistent with npm naming ✅ 2022-10-31 olayway: from what I see in how nx handles creating new packages/apps by their generators in monorepos, how they do this in their docs but also how community does it, it's best to have all our packages published under flowershow organization, and publish them as scoped packages, i.e. they will be available under prefix @flowershow. Cool thing about it is that we can name our packages whatever we want and we don't have to worry about name clashes with some other public packages, so we can have our CLI package named just cli, and it will be published under @flowershow/cli
[x] Moved templates/default into packages e.g. at packages/template (we can drop default for now!)
[x] Linting and prettier in right place
[ ] changeset setup documented for monorepos (in e.g. flowershow.app/docs/developers

Tasks (old)
Preliminaries

[x] Compare briefly monorepo tools e.g. nx, lerna, turborepo and make a choice

[ ] Brief summary of each
[x] Choice ✅2022-07-01 Let's go with nx

[x] Create packages/ directory ✅2022-08-?? done
[x] Setup nx 🚧2022-10-25 ❓ is this relevant anymore?
[ ] Briefly document for other devs about anything they need to do in e.g. base README.md

Doing the work

[x] Monorepo setup with flowershow package in it at packages/flowershow 🚧2022-10-25 ❓ think we could rename CLI to be named flowershow consistent with npm naming
[x] Moved templates/default into packages e.g. at packages/template (we can drop default for now!)
[x] Linting and prettier in right place
[ ] changeset setup documented for monorepos (in e.g. flowershow.app/docs/developers

https://github.com/flowershow/flowershow/issues/187#issuecomment-1262358821

@olayway i think we want to move templates default into packages with a name like template-default or even app-default (though app is overused), or even, app-template-default

@rufuspollock I'd recommend we also include all our remark plugins in our monorepo (maybe next sprint)


Merge master <IP_ADDRESS> back into develop

EDIT: it looks like Gitlab CI fails on test/lint/commit-script-check.sh with some weird error and I can't figure out why (and there are no scripted-diff commits here). Travis is green https://travis-ci.com/github/UdjinM6/dash/builds/189855974 (but test/lint/commit-script-check.sh is skipped there because it's just another branch, not a PR).

Build fails

Added e537c3c which should fix the build.  Not sure if it's ok to keep it this way, Gitlab suggests using lower values (e.g. 10, default is 50) to speed things up https://docs.gitlab.com/ee/ci/large_repositories/#shallow-cloning. We do not have huge files though, so maybe 150 is ok-ish to keep. If you think it's not, pls ACK eeadfe4 instead and I'll drop e537c3c.

@UdjinM6 want to make a Merge master <IP_ADDRESS> back into develop here or should this be seperated?
Btw, im good with trying e537c3c and see if it causes any problems/slowdowns... We will anyway run into the same again if we don't add it? But me feeling says it should be fine.. 3x default doesn't sound that bad also with a max of 20x default haha..
Nit: Maybe remove the # temporary fix then if we go with it?

want to make a Merge master <IP_ADDRESS> back into develop here or should this be separated?

This set contains quite a few changes to images and it's a pita to resolve merge conflicts for binary files, so I would really like to avoid doing that again :)

We will anyway run into the same again if we don't add it?

My understanding is that this will only happen for PRs with 50+ commits which we should avoid. If we all agree that a patch like e537c3c is still a nice/useful/harmless thing to have I would suggest to drop it here anyway and submit it as a separate PR to avoid bringing this change in a "merge back" pack.

My understanding is that this will only happen for PRs with 50+ commits (and we should avoid producing such monsters normally).

Yeah i meant, after the next big release if we again end up with the a merge master back PR

If we all agree that a patch like e537c3c is still a nice/useful/harmless thing to have I would suggest to drop it here anyway and submit it as a separate PR to avoid bringing this change in a "merge back" pack.

Alright, im in, lets see what @PastaPastaPasta has to say

Dropped e537c3c


feat: support local model path

Description
Supports configuration of the local model path to omit downloading.
Motivation
close #128.
Sometimes there is already a local model, or a network problem connecting to HuggingFace, so we want to use local model instead.
Now we can achieve this by configuring backend_config.pretrained_model_name_or_path, it both supports transformers and vllm backends, for example:
{
    "model": "facebook/opt-1.3b",
    "backend": "transformers",
    "num_gpus": 1,
    "auto_scaling_config": {
        "metric": "concurrency",
        "target": 1,
        "min_instances": 0,
        "max_instances": 10
    },
    "backend_config": {
        "pretrained_model_name_or_path": "/root/users/dblate/facebook/opt-1.3b",
        "device_map": "auto",
        "torch_dtype": "float16"
    }
}

Since the pull request contains many file changes, I'd like to state my points:

In config, model and pretrained_model_name_or_path should be two independent fields

model used to be an identifier, like as internal keys for routers or serverless format file path
pretrained_model_name_or_path used to get the model, it can be a HuggingFace model name, or local path

They can be the same sometimes, but not always

Feel free to modify my code or reject it if necessary.
Type of Change

[ ] Bug fix
[x] New feature
[ ] Breaking change
[x] Documentation update

Checklist

[x] I have read the CONTRIBUTION guide.
[x] I have updated the tests (if applicable).
[x] I have updated the documentation (if applicable).

I see there are some unit tests failed because of my modification, I will fix it.
By the way, what command should I run locally to verify these tests?

I see there are some unit tests failed because of my modification, I will fix it. By the way, what command should I run locally to verify these tests?

You can run these tests locally via pytest tests/backend_test. It seems because the unit test haven't been updated (i.e., when init the backend, current test only pass in the config but didn't pass in the model name added in this PR).

Hi, is this branch ready to merge? Have you passed all tests?

Hi, is this branch ready to merge? Have you passed all tests?

I think this branch is ready to merge. Currently all tests are passed.


Contribution: Pixel Fireplace?

Hi, I recently created a Pixel Fireplace! If you think it's appropriate for your project let me know:
Live preview:
https://js-pixel-fireplace.sourceforge.io/fireplace.html
Source code:
https://github.com/lexterror/8-bit-pixel-fireplace-android-linux
Thank you!

Hi @lexterror I think it's totally appropriate! If you'd like it to be a part of the project, you could open a PR over at before-dawn-screensavers. Thank you!

Hi @muffinista
I just finished tweaking the fireplace, there's so many possibilities as to what you can add/build with any coding language. Umm.. I really don't have anyone to give me feedback (How does the fireplace look to you from what you saw last time) Only if you have time. I understand you may be busy. I adjusted and added many things but you'd have to have attention to detail as they say. And maybe even take 2 minutes to observe the differences. I wanted something fancier that's all. I'm trying read the README you have posted in the contribution section. Give me some time. I would like to include it if you think it's good enough or whatever. Thank you

@muffinista
Hi, I've made some major improvements to the Pixel Fireplace and Im feeling confident.
I'm attaching my template. Please get back to me. If you need further information, etc, let me know.
Thank you!
template.zip

Sorry for the delay, I just opened a PR to add the screensaver at https://github.com/muffinista/before-dawn-screensavers/pull/21 -- @lexterror please let me know if you're cool with that. Thanks!


Documentation: remove all migrated READMEs

Summary
Documentation: remove all migrated READMEs
I'm keeping this as DRAFT and waiting for community feedback in https://github.com/apache/nuttx/issues/11058
Impact

Documentation in one place.
Easier to maintain.
Separation doc from code

Testing

@raiden00pl I think this is the right thing to do! Having the documentation spread in many places is difficult to follow. Thank you for doing taking ownership of it!

@xiaoxiang781216 @pkarashchenko @btashton @masayuki2009 @patacongo @jerpelea everybody agree to remove the README.txt files from inside NuttX diretories? Everything already moved to Documentation/

Yes, it's important to avoid the same information come from the different source.


Nesreb/feature/sitemap trailing slash for extensionless urls

Mayank Arora added a nice feature to optionally exclude ".html" extensions from urls in sitemap.xml.  This adds a complementary option for including or excluding trailing slashes in those extensionless urls in sitemap.xml.  Thanks, Nes.

I'm going to merge this but need to set up the test infrastructure first since this class is not yet tested.

Thanks!

Thanks @justinedelson!


ci: skip alpha-goerli integration tests

This PR skips 3 tests that hit the alpha testnet. Based on Henri's request in the Telegram group, I figured it's better to skip them completely rather then just ignore failures in the CI process.

🙏


Release v176

https://github.com/heroku/heroku-buildpack-python/compare/v175...7c4f55bc324d0280a4c0b91c4daf8b4d649d37e6
Closes<EMAIL_ADDRESS>

Published to buildpack registry:
$ bash etc/publish.sh
Deploy as version: v176 [y/n]? y

Tagging commit 84ac34b1d4e56df1ffed9f7f408a3e9f5d92b71b with v176...
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/heroku/heroku-buildpack-python
 * [new tag]         v176 -> v176
Two-factor code: ********************************************
Publishing buildpack heroku/python... done
Publishing buildpack was successful
Done.

$ h buildpacks:versions heroku/python | head -n4
Version  Released At               Status
───────  ────────────────────────  ─────────
176      2020-08-12T16:52:36.651Z  published
175      2020-08-05T08:22:22.514Z  published


Update publish-jekyll.md

Updated instructions to run Jekyll build, instructions were a little confusing so cleared up. It wasn't clear that you should after the "uses" block add lines and the code sample results in an invalid YAML file, so also made this correct with what needs to be added.

@martyncoup : Thanks for your contribution! The author(s) have been notified to review your proposed change.

thanks, @martyncoup!
#sign-off


feat increase codecoverage

enabled codecov

What is the purpose of this pull request?:
What issue does this pull request address?: Fixes #
Notes for reviewers to consider:
Specific reviewers for pull request:

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@d187c83). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #122   +/-   ##
=========================================
  Coverage          ?   55.46%
=========================================
  Files             ?       26
  Lines             ?      896
  Branches          ?        0
=========================================
  Hits              ?      497
  Misses            ?      399
  Partials          ?        0

Continue to review full report at Codecov.

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


Return DeleteResource back to codebase

post #295

This feels like a duplicate of #261. I'm not sure we need a new ticket.

@aaron-collier cool? This is coming from a point in your PR being reviewed now

I'm OK with closing this as the point of "LATER:" was that there was an outstanding PR that shouldn't block my PR but will need to be rebased once #295 is merged, so I agree that we don't actually need this ticket.

you didn't write "LATER" on that PR, so needed to confirm what work was where.


Error when import tree

Python 3.10.2 (main, Jan 15 2022, 19:56:27) [GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tree
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.10/site-packages/tree/__init__.py", line 23, in <module>
    from .sequence import _is_attrs
  File "/usr/lib/python3.10/site-packages/tree/sequence.py", line 19, in <module>
    from tree import _tree
ImportError: /usr/lib/python3.10/site-packages/tree/_tree.cpython-310-x86_64-linux-gnu.so: undefined symbol: _ZN4absl12lts_2021032420raw_logging_internal6RawLogENS0_11LogSeverityEPKciS4_z

How did you get / build this dm-tree tho?

Built from source, at git head:
python setup.py build
python setup.py install --optimize=1

I'm sorry which line do I change?

Let me first test it. I am building this for conda-forge: https://github.com/conda-forge/dm-tree-feedstock/pull/28

I'm sorry which line do I change?

--- a/tree/tree/CMakeLists.txt
+++ b/tree/tree/CMakeLists.txt
@@ -54,1 +54,1 @@ set(PYBIND_VER
-set(PYBIND_VER v2.6.2)
+set(PYBIND_VER v2.9.2)
@@ -71,1 +71,1 @@ set(ABSEIL_VER
-set(ABSEIL_VER 20210324.2)
+set(ABSEIL_VER 20211102.0)

We're seeing the same failure on NixOS with

python 3.9.12 & 3.10.4
pybind 2.9.1 & 2.9.2
absl-cpp 20210324.2 & 20211102.0

I bisected this issue to our gcc bump from 10 to 11.

As of today, this is still an issue when building from source.
Tried different version of abseil without luck.
@ngam Can you point me to the exact requirements that were used to build v0.1.7 ? (As using https://github.com/deepmind/tree/blob/2cb667a2cd5cd57beacb1e4f3296fa71e282bbea/tree/CMakeLists.txt#L71 does not work correctly.)

Please see my comment https://github.com/deepmind/tree/issues/103#issuecomment-1618283988 . With this patch, I was able to compile dm-tree 0.1.8.

I also have this error.
$ pip install dm-tree
Requirement already satisfied: dm-tree in ./venv/lib/python3.9/site-packages (0.1.8)

[notice] A new release of pip available: 22.3.1 -> 24.0
[notice] To update, run: pip install --upgrade pip
(venv) -----------------------------------------------------------------------
$python
Python 3.9.6 (default, Feb  3 2024, 15:58:27)
[Clang 15.0.0 (clang-15<IP_ADDRESS>)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import tree
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'tree'


Clean Python bindings

Fixes writing of chunktable in the PyVLRCompressor
Adds LazVLR bindings
Fixes a few leaks due to undeleted vectors
Adds a class to fake a read-only stream to avoir copying (potentially huge) uncompressed points data from a numpy array to a std::vector in the Compressors classes
Splits cpp declarations in a .pxd file, and Cython code in .pyx
Adds docstrings

This is awesome. I’ll merge once I get back to my desk.

On Mar 3, 2018, at 11:03 AM, Jälv<EMAIL_ADDRESS>wrote:
Fixes writing of chunktable in the PyVLRCompressor
Adds LazVLR bindings
Fixes a few leaks due to undeleted vectors
Adds a class to fake a read-only stream to avoir copying (potentially huge) uncompressed points data from a numpy array to a std::vector in the Compressors classes
Splits cpp declarations in a .pxd file, and Cython code in .pyx
Adds docstrings
You can view, comment on, or merge this pull request online at:
https://github.com/hobu/laz-perf/pull/46
Commit Summary
Fix writing of chunk table
VlrCompressor, the out vector is owned by the cpp side
Add LazVLR to python bindings
VLRCompressor computes the num of pts to compress
PyDecompressor construc its own output buffer
Fix leaks
Add test to check if exception is raised
Add class to wrap buffer and avoid copying data
Move cpp declarations in a .pxd file
File Changes
M python/lazperf/PyLazperf.cpp (11)
M python/lazperf/PyLazperf.hpp (75)
M python/lazperf/PyVlrCompressor.cpp (15)
M python/lazperf/init.py (1)
A python/lazperf/lazperf.pxd (76)
M python/lazperf/pylazperfapi.pyx (396)
M python/setup.py (3)
M python/test/test_lazperf.py (10)
M python/test/test_lazperf_vlr.py     (63)
Patch Links:
https://github.com/hobu/laz-perf/pull/46.patch
https://github.com/hobu/laz-perf/pull/46.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

There was another critical fix to the GPSTime compression, and I think we should do a proper release of the library soon. If you have any other python issues you want to tackle before that happens, please let me know.

I think that things are good for now.
One cosmetic change that I'd like to make is to allow passing python byte strings, byte arrays and not just numpy arrays as arguments but from what I undestand we'll need to wait for the next cython release for that to happen


Does publishing work?

https://github.com/nicfv/npm/blob/1f7e6f6fda99d87c4e778eae0fcab58bfa1e1ff0/.github/workflows/run#L17
I recently made this change to the workflow script file, but I'm not convinced it will actually work as intended. I want it to run through each workspace and attempt an npm publish --provenance and continue running through each workspace even if one of the packages is already published. If it received an exit code 1 for any workspace, will output the error message but still not fail.
I should probably test this with viridis or something that depends on smath or t6.

Confirmed broken in #137, fixed in #138


Sampled values not transformed back?

In the PyMC4 Made Simple notebook I wrote, I found that the sig parameter was not transformed back from unbounded space to positive support space in the trace. Instead, I had to access model/__log_sig. I think we need to implement an auto back-transform so that ArviZ plots the posterior distribution of model/sig rather than model__log_sig.

Yah, #180 fixes it. I want to kick the tires a little more on it before merging.

This is a duplicate from #169


fix: defaulting values to 'none' #695

Which problem does the PR fix?
#695
What's in this PR?
Defaulting zeebe-gateway to 'none' to meet standards
Checklist
Before opening the PR:

[x ] There is no other open pull request for the same update/change.
[ x] The commits follow our Commit Guidelines.

After opening the PR:

[ ] Did you sign our CLA (Contributor License Agreement)? It will show once you open the PR.
[ ] Did all checks/tests pass in the PR?

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.German M. Yebenes seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Changing API keys does not go well

Impacts later versions of the code.
If one changes API key then it is an almost certainty that everything Solcast will turn to custard. It turned to custard in spectacular fashion for me whilst testing this rare happening.
The logs were quite breathtaking, if I'm honest. I won't share, despite their cruel beauty.
The fix is to remove all solcast JSON cache files from the config directory, scorched-earth-reset style, and then re-load.
Please don't try an API key change for shits and giggles to replicate this. Unless you backed up the instant prior, have sadistic tendancies and want to watch the show...
The fix is being worked on.
(Further, if the API key is changed then re-load happens, and if the integration just happens to hit a '429 go away we're busy' then it will blindly load the previous sites as if they belonged to the new API key and bad stuff will not immediately happen. Rather, this will result in tears and an exploded log some time later.)

Ok, I am intrigued. Different API key, but same resource IDs? Or both change?

If an API key changes, then the site IDs will change. Yep. Deffo.
But the crux to the custard is an API change.
I am making headway. (Apologies for bumping your usage while I switch between that and the Sydney Opera House, violating Solcast's terms and conditions just a weeny little bit for the time being... Their DOS detection has slowed me down somewhat, giving me 429s for a whole half hour! Unmetered my arse...)

Apologies for bumping your usage while I switch between that and the Sydney Opera House

No worries - it is there for the common good.

Righto.
API key change is golden. No logs hysterically spammed (awww! it was awesome!!!). There are now not enough 'O's in smooth to describe the experience.
What is not yet golden is that when the API key gets changed when one is using just one API key, as is Solcast's desire and want and T's&C's blah, blah, the API usage does not get reset to zero. It should be really, because you've got a new API key.
This is doing my head in somewhat, currently seeking a coding epiphany, but I will hurdle that... Maybe today. Maybe tomorrow.

It is officially bed time... I got a limit exceeded from Solcast for a supposedly unmetered site... The Sydney Opera House. Gah! Then bad things.
2024-10-14 23:51:04.187 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Configuration directory is /config
2024-10-14 23:51:04.205 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Sites cache exists
2024-10-14 23:51:04.205 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Connecting to https://api.solcast.com.au/rooftop_sites?format=json&api_key=******sxdNS5
2024-10-14 23:51:04.343 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] HTTP session returned status 200/Success in __sites_data()
2024-10-14 23:51:04.343 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Writing sites cache
2024-10-14 23:51:04.355 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Sites data: {'sites': [{'name': 'Sydney Opera House', 'resource_id': '69d4-4611-63a4-5baa', 'capacity': 13.2, 'capacity_dc': 12, 'longitude': **.******, 'latitude': **.******, 'azimuth': 90, 'tilt': 30, 'install_date': '2024-10-13T13:00:00.0000000Z', 'loss_factor': 0.9, 'tags': [], 'location': 'Sydney, NSW Australia', 'api_key': '******sxdNS5'}], 'page_count': 1, 'current_page': 1, 'total_records': 1}
2024-10-14 23:51:04.356 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Usage cache exists for ******sxdNS5
2024-10-14 23:51:04.365 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Usage cache for ******sxdNS5 last reset 2024-10-14 11:00:00
2024-10-14 23:51:04.366 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] API counter for ******sxdNS5 is 17/48
2024-10-14 23:51:04.366 DEBUG (MainThread) [custom_components.solcast_solar] Successful init
2024-10-14 23:51:04.366 INFO (MainThread) [custom_components.solcast_solar] Solcast integration version: 4.2.0
2024-10-14 23:51:04.384 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Using legacy hourly dampening
2024-10-14 23:51:04.432 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Data cache /config/solcast.json exists, file type is <class 'dict'>
2024-10-14 23:51:04.450 INFO (MainThread) [custom_components.solcast_solar.solcastapi] New site(s) have been added, so getting forecast data for them
2024-10-14 23:51:04.450 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Polling API for site 69d4-4611-63a4-5baa lastday 2024-10-21 numhours 169
2024-10-14 23:51:04.450 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetch data url: https://api.solcast.com.au/rooftop_sites/69d4-4611-63a4-5baa/estimated_actuals
2024-10-14 23:51:04.451 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetching forecast
2024-10-14 23:51:04.857 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetch successful
2024-10-14 23:51:04.858 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] API returned data, API counter incremented from 17 to 18
2024-10-14 23:51:04.858 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Writing API usage cache file: /config/solcast-usage.json
2024-10-14 23:51:04.867 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] HTTP session returned data type <class 'dict'>
2024-10-14 23:51:04.867 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] HTTP session status 200/Success
2024-10-14 23:51:04.989 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetch data url: https://api.solcast.com.au/rooftop_sites/69d4-4611-63a4-5baa/forecasts
2024-10-14 23:51:04.989 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetching forecast
2024-10-14 23:51:05.042 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Writing API usage cache file: /config/solcast-usage.json
2024-10-14 23:51:05.058 ERROR (MainThread) [custom_components.solcast_solar.solcastapi] API allowed polling limit has been exceeded, API counter set to 48/48
2024-10-14 23:51:05.059 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] Site resource id a546-98c5-53c5-d101 is no longer configured, removing saved data from cached files /config/solcast.json, /config/solcast-undampened.json
2024-10-14 23:51:05.068 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Saved forecast cache /config/solcast.json
2024-10-14 23:51:05.100 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Saved forecast cache /config/solcast-undampened.json
2024-10-14 23:51:05.100 INFO (MainThread) [custom_components.solcast_solar.solcastapi] Migrating undampened history to /config/solcast-undampened.json for 69d4-4611-63a4-5baa
2024-10-14 23:51:05.131 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Saved forecast cache /config/solcast-undampened.json
2024-10-14 23:51:05.132 INFO (MainThread) [custom_components.solcast_solar.solcastapi] Dampening forecasts for today onwards for site 69d4-4611-63a4-5baa
2024-10-14 23:51:05.140 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Saved forecast cache /config/solcast.json
2024-10-14 23:51:05.146 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Data cache /config/solcast-undampened.json exists, file type is <class 'dict'>
2024-10-14 23:51:05.156 ERROR (MainThread) [custom_components.solcast_solar.solcastapi] Exception in get_forecast_update(): Traceback (most recent call last):
  File "/config/custom_components/solcast_solar/solcastapi.py", line 2501, in build_forecast_data
    await self.__check_data_records()
  File "/config/custom_components/solcast_solar/solcastapi.py", line 2538, in __check_data_records
    st_i, end_i = self.__get_forecast_list_slice(self._data_forecasts, start_utc, end_utc)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/solcast_solar/solcastapi.py", line 1671, in __get_forecast_list_slice
    _forecasts_start_idx = self.__calc_forecast_start_index(_data)
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/solcast_solar/solcastapi.py", line 2530, in __calc_forecast_start_index
    return idx
           ^^^
UnboundLocalError: cannot access local variable 'idx' where it is not associated with a value

Turns out...

Please note that Unmetered Locations are not available for the Legacy products including Weather Sites, Utility Scale Sites, Rooftop Sites and World API.

The hobbyist rooftop sites is legacy, so I can't even rely on the opera house. No free lunch, so fixing this will be significantly slowed down to the rate of ten API calls per day.

+20 of mine (and if you go over, I don't care)

This issue is resolved.
The fix will be included in v4.2.1 when that gets released. Leaving this issue open until that happens.


Forcing a toggle to be false in the middle of the EnabledFor

Hi,
I have the necessity to force a toggle to false in the middle of the EnabledFor for a particular  filter.
For example
My feature flags
"FeatureManagement": {
    "FeatureA": {
      "EnabledFor": [
        {
          "Name": "QueryString",
        },
       {
          "Name": "AppSettings",
        }
      ]
    }
  }

In my Appsettings file the feature is enable but i need force disable feature by query string(https://www.microsoft.com/?FeatureA=false).
Proposed Snippet
on IFeatureFilter.cs Line 18
Task<bool?> EvaluateAsync(FeatureFilterEvaluationContext context);

on FeatureManager.cs Line 108
if (filter is IFeatureFilter featureFilter)
 {
    var result = await featureFilter.EvaluateAsync(context).ConfigureAwait(false);
    if(result.hasValue){
          enabled = result.Value;
           break;
    }
 }

Or you think it's better throw a exception from the filter?
What do you think about this?

The feature manager will always evaluate all feature filters until one turns the feature on. There is no way for a filter to stop the evaluation and return false.
To achieve the behavior you want you would have to create a single filter that combines the querystring and appsettings approaches. The filters are an extensibility point for custom logic which it sounds like you need since query string can disable a feature.


Project Details Page

Subtasks

[x] UI Wireframe #685
[x] Project Details Endpoint
[x] New Route for project #684
[x] List of Builds on Project Details page #683
[x] Link the commit shas to their github page #708
[x] Relative Pipe for the latest build Date #666
[x] Status icon colors 🌈
[ ] Clickable Rows, Rows link to Build Details Page
[ ] Style Tweakzz
[x] Loading spinner while loading data #668
[ ] Show project details
[ ] Add Settings dialog
[ ] Add Rebuild option on hover
[ ] Get Branch and duration info
[x] Switch to defined Status Icons

Mock

Was thinking that we need some sort of notification that the build was triggered while we're waiting for a response on the rebuild. Maybe also add a notification if the build has already been triggered to rebuild, as to throttle the question and/or prevent accidental duplicate rebuilds?
@chemichelle WDYT?


#946: Implement SSE-KMS and SSE-C for AWS S3

Implements #946

[] I added CHANGELOG entry for this change.
[] Change is not relevant to the end user.

Changes
Added support for parsing and passing along AWS S3 SSE-KMS and SSE-C mode configuration details. Seemed pretty easy.
Adds the following config vars:

sse_s3 - essentially the new encrypt_sse, enables SSE-S3 mode.
sse_kms_id - enables SSE-KMS mode when set.
sse_kms_context - optional map of string keys and values for the KMS Context.
sse_c_key - enables SSE-C mode when set. expects a filepath.

encrypt_sse is kept as an alias for sse_s3, as that's what encrypt_sse currently does, and it seems silly to break valid configuration files from prior to this change for little reason.
Note that KMS and C mode both supersede and override SSE-S3 mode currently. This allows for syntax like:
encrypt_sse: true
sse_c_key: "/path/to/my/key"

to work as expected.
KMS and C mode are mutually exclusive, and trying to enable both currently throws an error.
E.G.
# this is invalid and will throw an error during validation
sse_c_key: "/path/to/my/key"
sse_kms_id: "myid"

Verification
Haven't yet really... would like some help from @jujugrrr to validate the code does what I think it does before going any further really.

It seems like this feature should work but probably not in my environment. During attempts to upload the new block into AWS S3 store or to read meta.json file of already uploaded block with help by AWS CLI, I only get 403 http-error. Unfortunately I have no access to AWS Console to touch the knobs but from the other side I've tried to put files to and get files from this bucket with SSE-KMS with help by peace of code which uses the same version of the minio-go labrary (6.0.49). What's a miserable week (


Integration not working anymore

Hi,
my integration works well the last months. But after some days the status not changed. today i rebooted my home assistant. If if take a look under integration, i see that the entity will not be provided by pioneer_async anymore.
Home assistant is the actual version 2023.8.4.
i configured it manually through config file like this.
`media_player:

platform: pioneer_async
name: Pioneer AVR
host: <IP_ADDRESS>
port: 8102
scan_interval: 60
timeout: 5.0
sources: { TV: '05', SAT: '06', GAME: '49' }`

Try increasing the timeout, although looking at this you should be able to configure this from inside HA under "devices & services" without the need to use the configuration file.
Are there any errors in the logs?

sorry, it seems that the problem is the av receiver self. It is actually not reachable from the network.

can be closed

can be closed


Implement OS::get_locale_language() helper method

This method extracts the 2 or 3-letter language code from OS::get_locale(),
making it easier for users to identify the "main" language code for users
that might have different OS locales due to different OS or region, but
should be matched to the same translation (e.g. "generic" Spanish).
Fixes #40703.

Notes:

I added it to OS and not just to core_bind::OS as I figured it could be useful for engine code or GDExtensions too. But strictly speaking it could be included only in core_bind::OS for the binding if we want.
There's similar language code extraction logic in TranslationServer, but it's actually more complex as it has to handle user-provided locale strings, while here we know that we'll get something reliable from OS::get_locale().

Test on my system (Linux with en_DK locale):
print(OS.get_locale())  # en_DK
print(OS.get_locale_language())  # en

Note to self: Before cherry-picking this for 3.x, #40708 should be cherry-picked too, otherwise OS::get_locale() can't be expected to be reliable cross-platform.


APIResponseError: invalid request URL

Nice tool! thank you so much! I am having an API Response Error: invalid request URL. I have attached a screenshot. Thanks in advance!

Hi @BeckyYhui, thanks for the kind words. 🙂
This error usually occurs when there's something amiss with the database ID entered in the Notero preferences. Can you double check that the database ID follows the format described in the Configure Notion section of the readme? It should be 32 characters consisting of only numbers and letters.
See #193 for an example of someone who had a similar issue.
Let me know if that helps!

Thank you very much. It's solved, sorry to bother you with this silly problem.


Get elapsed time after the text has finished reading

How to get elapsed time after the text has finished reading, if in web we can used event onend.
Does says.js have an onend event?
thank you

You can store the time when you call the speech method, then compare the time in the callback with the original value.
const start = Date.now()
say.speak("What's up, dog?", 'Good News', 1.0, (err) => {
  const duration = Date.now() - start
  if (err) {
    return console.error(err)
  }

  console.log(`Text tool ${duration}ms to be spoken`)
});

Cool, thanks
I look get a time including code executing


extracting headerRight to a separate function doesn't work.

I have a Stacknavigator as below
const Nav = createStackNavigator({
  Make: {screen: MakeScreen},
  ModelScreen: {screen: ModelScreen, navigationOptions: ({navigation}) => ({headerRight: renderHome(navigation)})},
  YearScreen: {screen: YearScreen, navigationOptions: ({navigation}) => ({headerRight: renderHome(navigation)})}
});

and a function to render headerRight as below
renderHome = ({navigation}) => {
  return <TouchableOpacity style={{marginRight: 10}}
                           onPress={() => navigation.dispatch(StackActions.reset({
                             index: 0,
                             key: null,
                             actions: [NavigationActions.navigate({routeName: 'Make'})]
                           }))}>
    <Icon name='home' size={25}
          color='#121212'
          style={{height: 25, width: 25}}/>
  </TouchableOpacity>
};

But i get an error Cannot read property 'dispatch' of undefined. However, if i don't use the function and put the code in the navigator, it works. please check below what I mean.
ModelScreen: {
    screen: ModelScreen,
    navigationOptions: ({navigation}) => ({
      headerRight: <TouchableOpacity style={{marginRight: 10}}
                                     onPress={() => navigation.dispatch(StackActions.reset({
                                       index: 0,
                                       key: null,
                                       actions: [NavigationActions.navigate({routeName: 'Make'})]
                                     }))}>
        <Icon name='home' size={25}
              color='#121212'
              style={{height: 25, width: 25}}/>
      </TouchableOpacity>
    })
  },

hi there! this is a question which is better suited for stackoverflow or discord. see https://reactnavigation.org/help.html for more information on how to get help.


[Desktop] TextField has too generous selection area

Steps to Reproduce

Execute flutter run on the code sample
Drag mouse cursor above the decoration label and helper texts

Expected results:
No text selection when dragging outside TextField's border.
Actual results:
Text selection works outside TextField's visual bounds.

Code sample

import 'package:flutter/material.dart';

void main() {
  runApp(
    MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: const Text('TextField')),
        body: Padding(
          padding: const EdgeInsets.all(48.0),
          child: TextField(
            controller: TextEditingController(text: 'text field text field'),
            decoration: const InputDecoration(
              border: OutlineInputBorder(),
              labelText: 'label label label label label label label label',
              helperText: 'helper helper helper helper helper helper helper',
            ),
          ),
        ),
      ),
    ),
  );
}

Logs

[✓] Flutter (Channel stable, 2.10.2, on Ubuntu Jammy Jellyfish (development branch) 5.15.0-18-generic, locale en_US.UTF-8)
    • Flutter version 2.10.2 at /home/jpnurmi/.fvm/versions/stable
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 097d3313d8 (10 days ago), 2022-02-18 19:33:08 -0600
    • Engine revision a83ed0e5e3
    • Dart version 2.16.1
    • DevTools version 2.9.2

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /home/jpnurmi/Android/Sdk
    • Platform android-31, build-tools 31.0.0
    • ANDROID_SDK_ROOT = /home/jpnurmi/Android/Sdk
    • Java binary at: /home/jpnurmi/Android/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[✓] Linux toolchain - develop for Linux desktop
    • Ubuntu clang version 13.0.0-9
    • cmake version 3.22.1
    • ninja version 1.10.1
    • pkg-config version 0.29.2

[✓] Android Studio (version 2020.3)
    • Android Studio at /home/jpnurmi/Android/android-studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[✓] VS Code
    • VS Code at /snap/code/current
    • Flutter extension version 3.34.0

[✓] Connected device (1 available)
    • Linux (desktop) • linux • linux-x64 • Ubuntu Jammy Jellyfish (development branch) 5.15.0-18-generic

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

https://user-images.githubusercontent.com/140617/156029103-bd813661-c834-4524-a3d6-3680081bcd22.mp4

CC @justinmc @chunhtai

This looks like something we can solve by applying global selection to textfield, but that would require a big refactor to textfield though

+1 to applying global selection to TextField.  In the long run at least.  In the meantime I feel like I can quickly patch this, I'll take a look.

@justinmc  FYI, This is the logic to transform the mouse offset to normalize it  if developer happen to move outside of the rect, and it works quite well.
/// Adjust the dragging offset based on target rect.
  ///
  /// This method moves the offsets to be within the target rect in case they are
  /// outside the rect.

  ///
  /// For points in Area 1:
  ///   move them to top-left of the widget if text direction is ltr, or bottom-right if rtl.
  ///
  /// For points in Area 2:
  ///   move them to bottom-right of the widget if text direction is ltr, or top-left if rtl.
  static Offset adjustDragOffset(Rect targetRect, Offset point, TextDirection direction) {
    if (targetRect.contains(point)) {
      return point;
    }
    if (point.dy <= targetRect.top ||
        point.dy <= targetRect.bottom && point.dx <= targetRect.left) {
      // Area 1
      return direction == TextDirection.ltr ? targetRect.topLeft : targetRect.bottomRight;
    } else {
      // Area 2
      return direction == TextDirection.ltr ? targetRect.bottomRight : targetRect.topLeft;
    }
  }

we can reuse this if it happen to solve the issue

Thank you!

I was hoping I could do this by just wrapping the correct widget with the GestureDetector, but unfortunately that won't be possible because the _RenderDecoration lays out all of this stuff in a custom RenderBox.

In the image, the red is where we currently listen to gestures.  The green is where we could listen if we wrapped the EditableText with the GestureDetector, but that's too small.  We need the red box down to the underline, so it seems we'll probably have to do something custom like what @chunhtai suggested above.
Another thing to note is how the Material spec shows that this should work.  In that interactive example, if you add helper text, you can see that it's actually selectable itself.  Tapping on it causes the field to lose focus as well.


[Build failure] Building failing in older versions

Build is failing in older versions. We need to check and fix the build failures.
Sample build failures:
https://github.com/opensearch-project/performance-analyzer-rca/actions/runs/9904383072/job/27361670580
https://github.com/opensearch-project/performance-analyzer-rca/actions/runs/8084625353/job/22090306040

[Catch All Triage - 1, 2, 3]


Msal removeAccount shouldn't invoke broker's removeAccount

MSAL's removeAccount was invoking broker's removeAccount (the one that's supposed to be called by broker hosting app).
It doesn't actually remove broker account (the operation will fail). Still, it means that MSAL's removeAccount is now botched.

We should have tests here.


merge 'dev' into 'master'

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


Invalid multihash format in db address, how to read manifest ?

The GUIDE says that the second part of the db address is composed of a multihash that we can read using:
ipfs dag get <multihash>
In fact, in the example we have a valid multihash format.
But the addresses I get is like: /orbitdb/zdpuAuZ7jiofffFnQgGknfRseqi2zbmHYER75viguePqHUeGD/database-name
zdpuAuZ7jiofffFnQgGknfRseqi2zbmHYER75viguePqHUeGD is not a valid multihash and I cannot read from IPFS node.

in reality, while it doesn't work with ipfs cat <multihash>, it works with ipfs dag get <multihash>
Fixed!

I think ipfs cat is for ipfs files and we use ipld DAG objects encoded with CBOR.


Adding html_link to the GitHub plugin

This fixes #351

Alright, I was already in there writing some examples - so I will merge this and add some examples to the plugin


Support various language

Hi, itsprathi!
Many languages are defined in the constant.py file, but only three languages are actually translated.
By modifying the upload_image.html file, it will be able to support more languages. Can I change it?

star my repository


swagger-maven-plugin complains about missing junit dependency

When I've tried to build the project locally, the process fails during runtime module execution of swagger:generate.
iPaaS API Java :: Project .......................... SUCCESS [  1.058 s]
iPaaS API Java :: API .............................. SUCCESS [  8.288 s]
iPaaS API Java :: Swagger UI Customizations ........ SUCCESS [  0.063 s]
iPaaS API Java :: Runtime .......................... FAILURE [  0.755 s]
------------------------------------------------------------------------
BUILD FAILURE
------------------------------------------------------------------------
Total time: 10.466 s
Finished at: 2017-01-16T13:41:04+01:00
Final Memory: 58M/490M
------------------------------------------------------------------------
Failed to execute goal com.github.kongchen:swagger-maven-plugin:3.1.4:generate (default) on
project runtime: Execution default of goal com.github.kongchen:swagger-maven-
plugin:3.1.4:generate failed: Plugin com.github.kongchen:swagger-maven-plugin:3.1.4 or one of its
dependencies could not be resolved: Failure to find junit:junit:jar:4.8.2-redhat-1 in http://origin-
repository.jboss.org/nexus/content/groups/ea/ was cached in the local repository, resolution will
not be reattempted until the update interval of fuse-origin-ea-repository has elapsed or updates are forced -> [Help 1]

@jimmidyson closing this one. I've found out that my maven settings.xml caused the issue, for some reason Central repo was skipped in favor of RH ones.


Storybook has to be refreshed to show Date Picker

I want to say thank you for your great work on phx_live_storybook!
We have one issue when using Date Picker in the Storybook. The date picker is not shown, unless storybook page is refreshed once.
We are using https://flowbite.com/docs/plugins/datepicker which is basically a Tailwind CSS date picker.
Is it because of the components are rendered during compile time and refreshing the page re-renders the component and activating the hook?
Thank you.

Hey Hendri 👋
I assume you are using 0.3.0
Lots of things have changed since, and 0.4.0 should be ready in a couple of weeks.
Can you try using the main branch and tell me if you are still experiencing the issue?
Instructions to use main branch: https://github.com/phenixdigital/phx_live_storybook/issues/48#issuecomment-1237880396

Thank you for the prompt response.
I have tried the latest main branch, and updated the router.ex.
It seems the datepicker works properly in the Stories tab, without refreshing the page 👍🏽
However, in the Playground tab it seems still need a refresh to make it works.
Thanks.

I have no clue, maybe move your JS init code (in your Hook) from the mount() callback to the update() callback?
You can also send me component, story, and hook files if you want me to investigate a bit further

Hey, is this still an issue?

Hi @cblavier,
@hendri-tobing is my colleague and yes this is still an issue. Not just hooks though, but any imported JS from the app.
For example in our app.js, we have:
import "flowbite";
import "flowbite/dist/datepicker";

This has scripts related to interactive components such as accordion, dropdown, datepicker, etc... When we open those stories we need to refresh again just to make the JS work. This is in v0.3.0
We tried the latest main branch, just 2 days ago, but now imported JS totally does not work. Not sure now which breaks it 🤔

Sorry for the delay but I put this issue on hold until some really big refactoring tickets are finished.
0.4.0 is now around the corner, but a lot of breaking changes have been recently introduced, which really won't help us at investigating your issue.
I'll ping you here pre 0.4.0 release to figure out what's happening.

Most of the pre 0.4.0 refactoring has been done now.
You should update to the latest main version (which involves a lot of changes, including switching to LiveView 0.18.0) and try to reproduce the issue.

👋 Did you have a change to test your app against storybook 0.4.1?

A lot of moving parts these days!
Just went through the migration myself ;-)

@cblavier thanks for waiting for our response. I think I found the answer now. I tried to look inside flowbite's source code and it is just initializing accordions on document's ready state like this:
if (document.readyState !== 'loading') {
	// DOMContentLoaded event were already fired. Perform explicit initialization now
	initAccordion()
} else {
	// DOMContentLoaded event not yet fired, attach initialization process to it
	document.addEventListener('DOMContentLoaded', initAccordion)
}

The page needs to be refreshed for it to call this again. We need to find a way to hook this code to accordion's mounted lifecycle via phx-hook. The same case with datepicker.
cc: @hendri-tobing

Yes you should call initAccordion in your hook mount callback
It doesn't seem to be related to the storybook, may I close the ticket?

Yup probably not related to storybook. Sure, please close


SpeedDial - sometimes double click is required to show more buttons

It is easier to show than describe, see movie here
Basically, if you click any action, action buttons are hidden (which is correct), but then if you try to scroll down and click main button, you need to click twice to show action buttons again.
Putting aside this bug, I think it would be great to add prop like disableHoverEvent, so we could show/hide action buttons only onClick, so behaviour would be more predictable.

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior
1 click in above situation should be enough.
Current Behavior
You need to click twice in situation described above.
Steps to Reproduce (for bugs)

Hover over main button.
Click any action button.
Scroll down to main button.
Click main button once, you need to click 2nd time to make it work.

Your Environment

Tech
Version

Material-UI
1.0.0-beta.45

React
used in official docs

browser
latest Chrome

Regarfing show on hover, that just depends on how you wire your implementation.

I cannot reproduce this anymore in 1.4.3 Mui version, so unless you have some planned for this issue, we could close it.

@klis87 Thanks for circling back.

This happens but is not there consistently.


Recognize option for custom jsonp callback

Not all servers respond to "callback". This patch adds support for a
custom callbackName option when using jsonp.

This works, but the pull request needs to be rebased.

Rebased.


Safari, Safari & Chrome on iOS fail to load video

Related: #56
I suspect the stream handling with MediaStream constructor is of issue here (unsupported in Safari/Safari on iOS)
Will need people with iPhones/iPads to test, I have none ;(

I can test and wirk with you on implementing

This still valid?

Wirks on my iPhone


Refactor Construct Pipeline Block to Segregate ec2 logic

This is an attempt to break #180 into smaller PRs
This just separates out ec2 logic from create_pipeline and construct_pipeline_block. This makes it easier to then refactor so that the separate classes for s3 and lambda can be removed. Makes the calls more generic

Thanks for the changes. I think this looks good for merging after the conflicts have been resolved. You might want to resolve some style linting issues if you get the chance.


Expenses should be subtracted from income

It seems that 'out; is now added to 'in':

Fixed with: https://github.com/quintel/etmoses/commit/57990fa45ec0d21da581555a700e3ad9ae1f6758


The name of the project is now not in sync with npm?

On npm, the package is called chaos-monkey but there are npm installs in the README.md of this repo referencing node-chaos-monkey?

Closing as doesn't seem to be an interest from repo owner to get a fix.


merge changes on inference methods from learning branch

I disable IntersectionBasedInference in the python interface, seemed to be a problem with vigra.
need to be investigated


[Testing] Set up testing configuration and create a 1st test #14

Adding react native testing library to project to enable unit and integration testing using jest and testing library.
Implementation follow expo testing guide
File structure chosen for is to keep test close to implementation by adding sub folders __tests__ in each directory.
src
  components
    button.js
    __tests__
      button.test.js

did all the tests pass?

Hi @Vcky4
The simple tests of I wrote for Wallet pass, but I've not figured out Register yet

So I can remove the Register test for this PR and we would have a working framework with passing tests for Wallet

resolve the conflict and update the PR please

also move this pr to a new branch please

also move this pr to a new branch please

Not sure what you mean @Vcky4, the PR is already from jasonsrogers:setup-testing to JiggyDevs:master

please resolve the conflict in you code editor by pulling from master

Rebased but need to update the test (will do it when I get some spare time)

Alright
let me know if you like me to merge
Thanks and well done

@Vcky4 should be all good now
Followup task would be to run again PRs with a github action (but you need the rights to see the workflow)

This branch is not available in JiggyDevs/twikkl-app
it appears to be a pull request from a forked repo which makes me unable to fix the merge conflict, please fix the conflict and push again.

Will do
I see that package-lock.json has been replaced by yarn-lock.json so it's probably the reason


Compositor pointer grab for the focused view (fix #613)

Feedback on the approach is appreciated.
Tests:

Test drag and drop still works.
Test #613 is fixed.
Click on the window and drag outside and make sure the view you clicked on is getting all those motion events outside the surface still.

When you release the button, make sure the pointer leaves the surface
When you press additional buttons outside the surface, make sure that surface is getting the buttons.

Test xwayland decorations work correctly (cursors were broken before)

Compare the behavior to Weston and X11 (because the behaviors are different and Weston still has bugs related to this, but X11 works pretty well).
Open question:
Should we deny popups while the view has a pointer grab?
TODO:

[ ] style cleanups
[ ] handle the grabbed view closing during the grab
[ ] handle management of cursor->grabbed_view a bit better

fixes #613

Here's a different approach that seems to work ok.

I'll just say it once because nobody else did it, but an issue that says "fix 613" is pretty hard to follow unless (even if?) you're close to the project, and a commit message that says "fix 613" or "fix bugs" is petty much useless to anyone taking a look at the git log later on.
However good the code is, the wrapping does matter, a bit.
On a more positive note, I'll have a look at the code now I looked up that this is about "keep track of what buttons are pressed"

Thanks for keeping me honest, @martinetd . The truth is I had no idea what I was going to do to fix this when I opened the PR. I come from the computer science school of "try random stuff until it works".

@acrisci Whats the status on this PR?

I've been on a break from my sway work, but at the time this was written, I thought this was the best approach to fix this bug. If it's still an issue, I should probably come back and complete this.

I thought this was the best approach to fix this bug

I agree

I should probably come back and complete this.

Feel free not to do it if you're not interested in this anymore :)
If you are, you'll be welcome of course.


org-mode delete other windows

org-mode offers you the option of closing other windows by pressing o while showing the agenda:
https://orgmode.org/manual/Agenda-commands.html
In doom-emacs, doing so will close the agenda instead.
I also tried prefacing it with \ (switch to emacs state), resulting in the same behaviour.
The same thing can be observed if you try the following custom function:
(defun start-agenda ()
  (interactive)
  (org-agenda-list)
  (delete-other-windows))

I have always found this option very convenient, especially for viewing monthly agendas, but sadly this does not seem possible in doom yet.

As of 5e25cfd this should be fixed. Please update and let me know if that isn't the case!

Updated, 5325cfd fixed the issue! Thanks. :)


ENH: reimplement plotting module

This pull request fully reimplements the fastf1.plotting submodule with the following aims:

increase compatibility to all drivers/teams/session from 2018 to the current season
reduce maintenance effort

Summary of the changes:

Team colours and short team names are hard-coded per season to support abbreviated team names and higher contrast colour maps that aren't available from the APIs
Driver names, driver abbreviations and the driver-to-team mapping is loaded from the F1 livetiming API for each session. This way, driver changes, test drivers, ... are automatically supported.
The existing lists/dictionaries of driver colours/team colours/driver abbreviations/... are deprecated and replaced with new API consisting of .get_<something>() functions. This serves two purposes. First, it decouples the internal implementation for providing the data from the public API. Second, it should make for more concise and readable code in almost all use-cases.
Driver-specific colours are deprecated. The driver colour will now identically match the team colour for all drivers of a team. To differentiate drivers in graphics, other stylistic options should be used. A new .get_driver_style() function can be used to largely automate this.
The old API is fully supported during the deprecation period.

Deprecations:

functions driver_color, lapnumber_axis, team_color
attributes COMPOUND_COLORS, DRIVER_TRANSLATE, DRIVER_COLORS,  TEAM_COLORS,  TEAM_TRANSLATE, COLOR_PALETTE
argument misc_mpl_mods of function .setup_mpl() is deprecated and will be removed without replacement.

Upcoming behaviour changes:

Argument color_scheme of function .setup_mpl() will default to None instead of 'fastf1' in the future, meaning that FastF1's default colour scheme needs to be enabled explicitly.

I appreciate reviews/comments/testing of these changes, even if comments/testing is just limited to parts of this (fairly large) change 😄 (maybe @Casper-Guo, @pesaventofilippo, @harningle ?)
To facilitate this, here is a link to a prebuilt version of the documentation: https://theoehrly.github.io/Fast-F1-Pre-Release-Documentation/plotting.html
For easy testing with your existing scripts, a pre-release is available through PyPI and can be installed with pip install fastf1==3.4.0a1
To-Do

[x] add exact_match parameter to all functions that use fuzzy matching
[x] evaluate option to automatically support future seasons in a limtied way (no 'default' colormap, no short team names) deferred, TODO: create issue, make this a future problem
[x] fix formatting of code example for get_driver_style in documentation
[x] refactor fuzzy matching, fix lookup warnings (problems see https://github.com/theOehrly/Fast-F1/pull/585#issuecomment-2107627133)
[x] setting default color map and names of color maps as suggested in https://github.com/theOehrly/Fast-F1/pull/585#issuecomment-2107627133
[x] option for overriding constants, probably use implementation similar to suggestion in https://github.com/theOehrly/Fast-F1/pull/585#issuecomment-2111085481
[x] try to generate official color map dynamically from API

Amazing work! 🙏🏻
I've read the new documentation and it feels very solid and well-organized, especially the driver style functions.
I tested it quickly and it works very well, but I plan on testing (almost) all changes more in depth ASAP.
Any specific reason why the misc_mpl_mods argument will be removed? They seem quite "fixed" changes to mpl, in the sense that they shouldn't need to be maintained or modified over time. If (and only if) that is the case, then maybe a good idea would be to keep that functionality, maybe by moving it in a separate function like .enable_misc_mpl_mods()?
On a side note (and very low priority), a tricky question comes to mind about 'Official' team colors. From the documentation:

Colors are constant over the course of a season.

If I recall correctly, at the start of 2024 F1 used pink as Alpine's color, and after a while the official color changed to blue-ish, which is the current color inside of the Constants file.
Let's say a new season starts, teams' colors get published and so the initial colors are picked as the Official palette. If later in the season F1 changes color for a team, what takes precedence, using the latest official color or keeping them constant over a season?
If I were to choose I'd stay with the first color (also to avoid having to update the constants mid-season), but then the 'Official' palette and the team color returned by the API would differ, so for clarity it should be specified in the docs 👀

After using it a bit more, I have some feedback, but they all are nice-to-have suggestions, so I'm open to discussions and maybe input from others!
1. Lookup warnings when getting team names from session.laps
If you need to get the short team name or color from a Lap, you would get the lap.Team, and then use that as the identifier for plotting.get_team_name. The problem is, lap.Team contains the full name of each team, while FastF1 uses the short names, so every time you lookup a team like "Haas F1 Team", "Kick Sauber" or "Red Bull Racing", fuzzy matching is used and a warning is generated, which can be annoying.
Code example:
import fastf1
from fastf1 import plotting

session = fastf1.get_session(2024, "Miami", "Q")
session.load()

for teamName, laps in session.laps.groupby('Team'):
    shortName = plotting.get_team_name(teamName, session, short=True)
    print(f"{shortName} has {len(laps)} laps")

Output:
...
_base       WARNING 	Correcting invalid user input 'haas f1 team' to 'haas'.
_base       WARNING 	Correcting invalid user input 'kick sauber' to 'sauber'.
_base       WARNING 	Correcting invalid user input 'red bull racing' to 'red bull'.

The warnings are useful when passing the team name as a string, so if a user types "red ball" it gets correctly flagged. But I think an exception needs to be made for the names returned by the API.
2. Setting the default colormap used for all plotting functions
In every functions that accepts the colormap parameter, the two values are 'default' and 'official'. In general, when one wants to change the colormap, that choice is made for every function call, e.g. it's very uncommon to use a color palette for a plot and then a different palette for another plot; but as of now you would need to update every call to use the new palette (which could also be a problem for the next suggestion).
Here's a quick general idea on how I would change it, although as I said some feedback would be appreciated:

Rename the 'default' colormap to 'fastf1', so the two colormaps are 'fastf1' and 'official'
Keep the 'default' option so that, by default, using colormap='default' is the same as using colormap='fastf1'
Create a new function plotting.set_default_colormap(colormap: str) that changes the value which gets used for the 'default' colormap.

For example:
plotting.get_driver_color(identifier, session) # no colormap specified, using 'default', gets evaluated to 'fastf1'
plotting.set_default_colormap('official')
plotting.get_driver_color(identifier, session) # no colormap specified, using 'default', gets now evaluated to 'official'

This way, you would use the 'default' argument as always, but now you also have the option to change the default behaviour. If needed, you can always choose a specific colormap by specifying 'fastf1' or 'official'.
3. Support for changing constants (colors, names)
The general idea would be to be able to specify an override for some values. For example, I like the 'official' colormap for most colors, but I would like to manually change the Alpine color to pink (the color used by the default colormap).
Another example would be to modify the short name for a team, for example "RB" gets confused with Red Bull, so I'd replace the RB ShortName with VCARB.
Now, I have no idea if there's a good way to implement this without having to a new custom value for each property that is now in the Constants file. Ideally the code would work like this:
# Create a new 'constant' by specifying a name and a "base" colormap, from which all values that don't get overridden are picked. The fields of the newly created `Constants` object can be overridden.
plotting.create_constants(name='custom', base='default')

# Override a team color
plotting.constants['custom'].Teams['alpine'].TeamColor = "#ff87bc"

# Override another property
plotting.constants['custom'].Teams['rb'].ShortName = "VCARB"

I realize this is not very intuitive and it would need at least a partial rewrite of how the constants work. If someone has a better idea of how this could work or be implemented it would be nice, otherwise this is not important.

@pesaventofilippo  I don't have my computer so I cannot review all the code but I'm assuming the fuzzy match logic is the same as before.
If that's the case, then these warnings were added in #574 and the logic is a simpler version of what's implemented in #579. In the latter case, no warning is generated if there is an unambiguous full partial match which would cover all the false positives here.
There is also some code duplication with fuzzy matching in the plotting module. A clean solution would be to implement the more complex logic as a helper function and reuse it. I cannot work on that any time soon so feel free to call dibs.
@theOehrly I am doing some traveling so I cannot dive in until June. Then I can start a new branch and try all the new interfaces in my own use cases.
Since this is a big change, we should add a todo to rewrite examples as needed and maybe prepare a short transition guide outlining the idiomatic usages in the old vs new versions.

1. Lookup warnings when getting team names from session.laps

That needs to be fixed, true. There really shouldn't be warnings in those cases.
@Casper-Guo the fuzzy matching logic is similar but not exactly the same as for events. I'll look into refactoring your improved logic out and use it in all places. I think that should be doable.

2. Setting the default colormap used for all plotting functions

I think that's a reasonable suggestion, including the renaming of the colormaps. And it shouldn't be too difficult to do.

Since this is a big change, we should add a todo to rewrite examples as needed and maybe prepare a short transition guide outlining the idiomatic usages in the old vs new versions.

The examples are updated in this PR as well. Do you think a transition guide is necessary? The old API still works, but users will get FutureWarnings when using it.

That looks very good. I especially love the way how we can combine (partial) custom colouring styles with the default style in examples/plot_driver_styling.py.
This is related to "3. Support for changing constants (colors, names)" above. Can we pass a dictionary to setup_mpl, so that if we specify some colours for some teams, we use it; otherwise, use the default colours. But I'm not sure what's the best practice to combine this with how constants work.
fastf1.plotting.setup_mpl(color_scheme='fastf1',
                          custom_scheme={
    'team': {
        'alpine': '#000000'
    },
    'driver': {
        'ver': '#123456',
        'pez': '#ABCDEF'
    }
})

I've tried to address all your great feedback now. The new pre-release is published (pip install fastf1==3.4.0a1) and the pre-release documentation that is linked in the opening comment has been updated.
The following suggestions have been addressed:
1. Official team colours may change during the seasons
One example for this is Alpine this season, where the colour changed from pink to blue. Now, the team constants have a "base" colour for the official colour. This colour value is updated from the API on a per-session basis now. Only if there were no team colours available somehow, the base colour would be kept.
2. Lookup warnings when getting team names from session.laps
The fuzzy matching code has been refactored and unified throughout FastF1. This problem should be fixed now.
3. Naming of the colour maps and setting the default colour map
As suggested, the colour maps are now named "fastf1" and "official". The "default" keyword now refers to the default colour map, which is "fastf1". The default colour map can be changed by calling fastf1.plotting.set_default_colormap. This way, it is not necessary to specify the colour map in every function call. But it is still possible to set it per function call.
4. Support for changing constants
It is now possible to override the team's short names and the colours in each colour map. Use the function fastf1.plotting.override_team_constants for this. The overrides are per session and do not persist.
I do not want to expose the internal constants API because this is currently a semi-mess. It works right now, but there are some not so great things about it and I can't gurantee that it might not require some major breaking changes at some point. As long as this is an internal API, that's fine and the current implementation is "good enough" even though I'm not very happy with it. If I were to expose this as public API, I basically commit to keeping this as is. This might really make things much more complicated down the road. Alternatively, I'd need to give this much more thought and implement it more cleanly and future proof, delaying this long overdue change even further. Therefore, I have decided to keep this internal API. One could argue that the new function simply hides the internal mess from the user but I consider this the lesser evil here.
@harningle, overriding colours on a per-driver basis will not be added for two reasons. First, this would be a fairly large change or a very hacky implementation, because driver colours do no longer exist in the new implementation. Everything is team colours and I'd need to change that just to enable these overrides. Second, the reason why driver colours are deprecated is that they end up being a huge mess requiring shades of almost the same colour for various drivers. And in the end, you can barely tell them apart. People should use other means to differentiate drivers of the same team in a visualization.
I hope I have addressed all suggestions properly and not forgotten anything. Looking forward to your comments :)

One more question, I had switched Red Bull over to a yellow team colour some time ago, because there are too many teams with a blueish colour. Therefore, I decided that it is much better for readability if Red Bull gets a different colour and yellow is one of their (minor) accents colours after all. I have a feeling that this change wasn't popular at all. If everybody ends up overwriting this colour back to a blue colour, I might as well just change it back. What's your opinion?

Well, what can I say, massive work! This feels much more polished and customizable now, which is a very good thing for a "plotting update". As for the internal mess, I think it was inevitable, because some data comes from the API and some is hardcoded (and customizable). I don't think you should worry too much about it, at least for the end user's perspective. Maybe it's difficult to maintain or add stuff to it, but as you said this can always change silently in the background in the future.
Regarding the Red Bull color change, here's my opinion: I think part of the reason many (at least, I) don't use it is because Red Bull is a top team, so many people are interested to see them and people are used to look for "the blue color at the front". If there's a graph which represents Ferrari vs. RB, or Mercedes vs. RB etc, the blue color is immediately obvious (because most of the time you aren't comparing a top team to Alpine or Williams for example), while the yellow color isn't immediately obvious without reading the legend (at least the first time, but habits die hard 😂).
IF that's true, then maybe this same idea could work better by changing other teams. An example would be using pink for Alpine, which also was their official color at some point (as opposed to yellow for Red Bull). I'd say also using white for Williams could work, because they had white in their logo and in the past their car was white. But this wouldn't work with a white background graph, so maybe it's a bit of a stretch.

I will start migrating my code to the new API soon. I only interact with the plotting module in a few places so hopefully it will be a smooth transition.

The team colour overriding looks very good to me! I used to hardcode driver colours, but now being able to change the team's colour should be enough for almost all my use cases. I will try the new plotting module later. Thank you so much!

@pesaventofilippo thanks for the feedback on the yellow Red Bull colour. I think your arguments are very valid. I might have looked at this too much from a general data visualization standpoint and not enough from a fan point of view. Your arguments and the general lack of adoption of this change have convinced me 😅
Alpine currently already has pink as the team colour in the 'fastf1' colour map. As you say, white for Williams is difficult because of the default white background of Matplotlib. But maybe a future enhancement could be to add specific colour maps for dark and light backgrounds as an addition to the current compromise colour map.

Hi,
I have been trying the new plotting module. I have not found any errors and have tried to migrate my code to this new module. I use different functions to generate graphs; one of them is the minisector that indicates which driver is the fastest in each part of the track. It is made by concatenating segments, and the color of the segment indicates who was the fastest in that area of the track.
The problem arises when I plot two drivers from the same team. I tried changing the linestyle, linewidth, and transparency, but I cannot find an appropriate solution. Do you have a solution, or should I use colors not correlated with team colors?
Another question, when do you plan to launch the update?

@formulatimer looking at the following graphic from your Twitter account, it is just as difficult to tell HAM and RUS apart as in the examples you gave above.

I don't intend to hate on your work and graphics here. But this precisely underlines the point why I have decided to deprecate driver specific colours. They are annoying to maintain, make things quite a bit more complicated, and in the end they are not a good tool to differentiate between drivers of the same team. (To my knowledge) I am not colour-blind and the monitor that I am currently viewing this on has decent colour accuracy. Yet, I am barely able to tell the colours apart here.
One good solution is to use alternate colours similar to here:

Or a different suggestion from me is to do something like this:

(This is not actually a mini sector comparison because I had not code for that ready. It's just the track segmented by gear shifts.)

Another question, when do you plan to launch the update?

I was considering this week. But I am still waiting on some additional feedback from someone who hasn't commented here. And a few people here wanted to test with their scripts. We'd be getting very close to the race weekend then, and I don't want to release this on a friday during a race weekend.
I'd say next week seems reasonable for a release if there are no unexpected things.

@theOehrly how did you get that white line with a blue edge? Could you the style configuration
my_styles = [
# style for each first driver
{'color': 'auto', 'linestyle': 'solid', 'linewidth': 10, 'alpha': 1},
# styles for each second driver with two different lines
{'color': 'white', 'linestyle': 'solid', 'linewidth': 10, 'alpha': 1, 'markeredgecolor':'yellow'}
]

@formulatimer this is the minimal example for this type of visualization
import matplotlib.pyplot as plt
import matplotlib.patheffects as pe

import fastf1
from fastf1.plotting import add_sorted_driver_legend, get_driver_style

session = fastf1.get_session(2024, 'Spain', 'R')

my_styles = [
    {'color': 'auto', 'lineedgecolor': 'slategrey', 'linewidth': 4},
    {'color': 'white', 'lineedgecolor': 'auto', 'linewidth': 4},
]

fig, ax = plt.subplots()

for i, drv in enumerate(('HAM', 'RUS', 'VER')):
    style = get_driver_style(drv, my_styles, session,
                             additional_color_kws=['lineedgecolor'])
    le_color = style.pop('lineedgecolor')

    ax.plot(
        [i, i + 1], [i, i + 1], label=drv, **style,
        path_effects=[pe.Stroke(linewidth=6, foreground=le_color), pe.Normal()]
    )

add_sorted_driver_legend(ax, session)

plt.show()

It'll give you this output

Remember that you can add anything to the style dictionary, and that the new API allows you to define any key in the dictionary as a color-like key. Yes, you need to pop the the line edge color from the driver style because of how the matplotlib API works here. But I still think that this is a pretty clean solution overall.

@theOehrly The minimal example is not equal to your suggestion because if you concatenate segments for the same driver, you will see that the line is split into segments

Using red to highlight the segements

Sorry I forgot to update you. I had few points of access to the plotting module so it was fairly painless.
I was using:

setup_mpl with misc_mpl_mods=False so straightforward here
team_color with easy migration to get_team_color
DRIVER_TRANSLATE and DRIVER_COLORS. On that front I need to figure out how to differentiate drivers from the same team using linestyles etc. but that's outside of the scope of this PR

So nothing unexpected

@Casper-Guo great, thanks for the feedback


[ENH] image gradient consistency checking

Builds upon #26 by adding a check that gradient encoding patterns found in the b-values correspond to those found in signal intensity variance across 4d volumes of the dwi image.
Disclaimer: this is experimental (sklearn's MeanShift is magic), but potentially invaluable. I still need to create a test or two, but figured I'd proceed to at least open the PR. So far, this function verifiably works on all different kinds of images that I've tried it with-- including multishell, dki, etc.
If the check fails for any reason, a simple userwarning is raised (i.e. rather than crashing the whole workflow) so as to minimally alert the user to look at their images and ensure bval correspondence. This tool is also valuable for any changes made to the image volumes (e.g. removal of high-motion or FD ones), where an accompanying update to the gradient table becomes necessary. This check could be re-run after any such update to ensure consistency is maintained (it runs in ~1-2 seconds provided that the dwi image dataobject is already loaded into memory)...
@dPys

Hello @dPys, Thank you for updating!

In the file dmriprep/utils/vectors.py:

Line 422:100: E501 line too long (114 > 99 characters)
Line 429:70: E226 missing whitespace around arithmetic operator
Line 429:72: E226 missing whitespace around arithmetic operator
Line 432:47: E712 comparison to True should be 'if cond is True:' or 'if cond:'
Line 433:100: E501 line too long (109 > 99 characters)
Line 452:35: E226 missing whitespace around arithmetic operator
Line 458:100: E501 line too long (110 > 99 characters)
Line 462:100: E501 line too long (106 > 99 characters)

To test for issues locally, pip install flake8 and then run flake8 dmriprep.

@oesteban  - rebased to latest master merges, test added. Boolean to activate for CheckGradientTable interface.

Can we close this one?

This one we might actually want to keep open since it adds an experimental feature unrelated to emc and not quite ready for primetime integration into the vectors interface. Could be useful, but would need tests. Can discuss whether we consider it a valuable target tomorrow when we meet?

This PR should be fully covered elsewhere. Closing. @dPys I haven't copied your branch to upstream, so please do not remove it until the other PRs are all merged. Thanks for this!


Missing currencies

I've added support for the currencies that are in the official list (http://www.iso.org/iso/home/standards/currency_codes.htm) that were missing from this library.
Fixes #84

@spookylukey Is there a reason this isn't getting merged? If there's a problem with the code, please let me know.

I haven't checked everything, but generally looks good.
The only thing is this changes the version number, which is normally done in separate commit, and is down to @limist to decide I think (I just help out here).

@limist any update on this?

If you can just remove the version change from this PR I will merge it.

In the end I did the change myself - I just removed that one commit. Thanks!

This has been merged (with the exception of one commit)


Bump<EMAIL_ADDRESS>

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

Comparison is base (2fc0b25) 87.61% compared to head (65f1536) 87.61%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #228   +/-   ##
=======================================
  Coverage   87.61%   87.61%
=======================================
  Files          68       68
  Lines        5126     5126
=======================================
  Hits         4491     4491
  Misses        635      635

Flag
Coverage Δ

unittests
87.61% <ø> (ø)

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

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


Improvement of the 'Video Conference Mute'

Description of the new feature / enhancement
Can you make a new button in Video Conference Mute>Toolbar>Show toolbar called 1st Monitor, 2nd Monitor, 3rd Monitor or more, and All Monitors? This only should show when they have multiple monitors.
Scenario when this would be used?
This can ask you which monitor you want to show the toolbar on.
Supporting information
No response

@skanda890 Video conference mute is in maintenance mode, we will not actively apply any additional features.  If a community member does a PR, we will accept it but we are not doing any future work


False positive warning about calling useRoute within middleware

Environment
n/a
Reproduction
https://stackblitz.com/edit/github-vmpomt?file=pages%2Findex.vue
Describe the bug
When middleware contains navigateTo('<url>') to a page, which has a $fetch call using an interceptor, which in turn has a useRoute within it, a false positive warning is shown.

Additional context
No response
Logs
No response

After some attempts, it seems the error occurs on line 89 of the code below:
https://github.com/nuxt/nuxt/blob/386be0b866382caddf31eba9965a0fd5cef94d7f/packages/nuxt/src/app/composables/router.ts#L82-L92
However, the cause of the error is the useRoute inside onRequestError. It appears we cannot use useRoute in this place.

This warning occurs even if the middleware is removed. It seems the error originates from the useRoute inside onRequestError. It appears we cannot use useRoute in this context.

@danielroe
Should we change the setting on line 89 to false? This is because, at that time, there was no nuxtApp.runWithContext due to the context. If we cannot obtain nuxtApp now, does that mean it's also unlikely to be within the middleware?
https://github.com/nuxt/nuxt/blob/386be0b866382caddf31eba9965a0fd5cef94d7f/packages/nuxt/src/app/composables/router.ts#L82-L92


feature: 增加 GSE2.0 的依赖 (#2036)

PR
CheckList（PR Assigners）
确认已完成以下操作：

[ ] 已将分支与当前合入分支同步
[ ] 已在关联 Issue 中补充「功能自测」部分内容
[ ] 已更新关联 Issue 的状态 backlog -> todo -> for test -> tested（需通过测试同学测试） -> done
[ ] 将 PR 添加上 pr/reviewable

CheckList（PR Reviewers）
确认已完成以下操作：

[ ] 检查关联 Issue 「功能自测」部分内容
[ ] 必要时打回 pr/reviewable，要求重新修改
[ ] 及时 Approve

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

Comparison is base (e7c110b) 74.70% compared to head (aa4361c) 74.69%.

Additional details and impacted files
@@              Coverage Diff               @@
##           v2.4.4-dev    #2038      +/-   ##
==============================================
- Coverage       74.70%   74.69%   -0.02%
==============================================
  Files             404      404
  Lines           28230    28230
==============================================
- Hits            21089    21086       -3
- Misses           7141     7144       +3

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