Create 2505-foreach-style.md

Hi there. Thank you for your interest in improving Rust!
Unfortunately, this idea does not seem fully formed per our RFC template so I'm going to go ahead and close this. If you would like to brainstorm your ideas or need help with formulating your proposal, you can do that more effectively at our internals forum.
With respect to your ideas, it seems to me like it is already possible to do this.
For example, we may write (playground):
fn main() {
    let list = vec!["hello", "world.", "Nice", "to", "meet", "you!"];

    for x in list {
        println!("word: {}", x);
    }
}

If you also need the index, you can write this with (playground):
fn main() {
    let list = vec!["hello", "world.", "Nice", "to", "meet", "you!"];

    for (i, x) in list.iter().enumerate() {
        println!("word #{}: {}", i, x);
    }
}

As for iterating over a HashMap, you can write (see HashMap::iter):
use std::collections::HashMap;

let mut map = HashMap::new();
map.insert("a", 1);
map.insert("b", 2);
map.insert("c", 3);

for (key, val) in map.iter() {
    println!("key: {} val: {}", key, val);
}

Sorry it's my first RFC.
Best regards ccgauche.


[Backend] Save Cookie Types on Privacy Declaration and Surface with Notices

Closes #3477
Blocked by https://github.com/ethyca/fideslang/issues/114
Code Changes

[ ] list your code changes here

Steps to Confirm

[ ] list any manual steps for reviewers to confirm the changes

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
Documentation:

[ ] documentation complete, PR opened in fidesdocs
[ ] documentation issue created in fidesdocs

[ ] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[ ] Update CHANGELOG.md
[ ] For API changes, the Postman collection has been updated

Description Of Changes
Add a PrivacyDeclaration.cookies field, as well as a PrivacyNotice.cookies property that dynamically queries to see which cookies are applicable based on data use. These are automatically surfaced when Privacy Experiences are queried, as part of the embedded notices in the response.

Closing - cookies also need to be saved separately from privacy declarations in case a privacy declaration is deleted -


Weight init with non-default tokenizer bug fix

Changes
Currently, training with a tokenizer with different vocab size from google-bert/bert-base-uncased gives an initial loss that is 10X bigger than expected. This comes from the embedding resizing in the class PreTrainedModel, which the FlexBert classes inherits from, for which the _init_weights() is called with the embeddings module as the argument. Following #84, _init_weights() in FlexBert classes overrides the corresponding function with a different signature than in BertPreTrainedModel, and consequently function calls to _init_weights() in FlexBert classes from PreTrainedModel gives incorrect behavior. This PR enables embedding resizing with correct init, and in case of other calls to _init_weights() from the transformers library we get an implementation error, instead of a silent issue.
The other call to _init_weights I have identified in the transformers library that can reach the flexbert classes is the lm_head resizing, which happens for training with a tokenizer with different vocab size from google-bert/bert-base-uncased when weights are not tied. Custom init of this module is not as straight forward as there are several potential nn.Linear modules, and these do not have the same module type in the src.bert_layers.initialization.init_weights function. The FlexBertPretrainedModel does not keep track of the true vocal size (only the vocab size before resizing), making it harder to identify a lm head. An ugly solution, assuming that any nn.Linear module with hidden_size as input size and a output size bigger than 16k is a lm head, could be added in FlexBertPreTrainedModel._init_module_weights at row 793:
elif isinstance(module, nn.Linear):
            input_dim, output_dim = module.weight.shape
            # UGLY way to make sure that module is a lm head
            assert input_dim == self.config.hidden_size and output_dim > 16E3, "nn.Linear module must be a lm head"
            init_weights(self.config, module, self.config.hidden_size, ModuleType.final_out)

Let me know if you have any other suggestions. Else I think we can leave the PR as is now, as we at least don't get a silent error for this corner case which I don't see as very likely at the moment.
Tests
Have run all tests and verified that we get a reasonable loss curve with a different tokenizer than bert-base-uncased using the flex-belt-base.yaml config. I also have verified that training with bert-base-uncased tokenizer and flex-belt-base.yaml config gives identical training metrics with this branch and main.

Currently, training with a tokenizer with different vocab size from google-bert/bert-base-uncased gives an initial loss that is 10X bigger than expected. This comes from the embedding resizing in the class PreTrainedModel, which the FlexBert classes inherits from, for which the _init_weights() is called with the embeddings module as the argument

Manually setting the tokenizer vocab size results in correct embedding initialization and expected initial loss, which is why I haven't noticed this issue. Maybe it would be easier to resize the vocab in the config from the len(tokenizer.vocab) before creating the model?

Maybe it would be easier to resize the vocab in the config from the len(tokenizer.vocab) before creating the model?
This would work fine in most cases, but if someone would like to extend the tokenizer post pretaining (add new tokens, support for new languages and whatever) this solution would prevent this. Ofc one could ask if this really is something that will happen in practice (and if they in these cases maybe instead would try to to some more advanced init of the new token embeddings), but we could leave that imagination to the community instead of us setting the limits. Dunno if anyone else has an opinion on this? @bclavie @NohTow

But we can add the len(tokenizer) value to the config and this way identify an lm head, to make sure that resizing also works with untied weights

If I understand correctly, @ohallstrom's solution is a bit more complex but can handle adding new tokens for a pre-trained model (loading weights will break if the layer is already resized). Besides not being able to add tokens for downstream tasks, this prevents starting from a pre-trained model with smaller vocals.
So I would go with Oskar's solution

@ohallstrom I trained a quick test model with this PR and I believe it broke the initialization. The top orange line is this PR with megatron init and the bottom purple line is manually setting the tokenizer vocab size from main with megatron init.

As a sanity check, I trained another test model from main, which results in a near identical loss curve.

I would not expect embedding resizing vs manually setting vocab size to have identical loss curves, as initializing with resizing means that you first init the embedding matrix with default_vocab_size. When the resizing occurs, you init a new embedding matrix with the full vocab size, but then overwrite the first default_vocab_size look-up values of this new embedding matrix with the values from the original matrix. In other words, I believe it can be viewed as they are initialized with different seeds. Will verify that this holds later
I run Megatron init without resizing using different seeds for a few 100M tokens, and indeed the same init but with different seed can give quite different loss curves. I will verify later that the seed change only impact weight init (judging from the plots data ordering seems unaffected at least).

As these two runs have different seeds for all weights (not only embedding), I can do some tests later where I only init the embedding matrix with different seeds to se what an acceptable diff is.

Hey, chiming in:

I think this is potentially the more proper way of doing things, but in practice I'm leaning towards the fact that the current way of doing things is the better way to go forward.
The loss curves do appear noticeably different, especially with all else being equal. While they're trending towards the same, it's either an obscure knock-on effect (from the added complexity due to doing things in a more proper way), or damaging initialisation in a way we'd need to spend time evaluating to ensure it heals reasonably fast, which I'm not sure we want to.

This would work fine in most cases, but if someone would like to extend the tokenizer post pretaining (add new tokens, support for new languages and whatever) this solution would prevent this. Ofc one could ask if this really is something that will happen in practice (and if they in these cases maybe instead would try to to some more advanced init of the new token embeddings), but we could leave that imagination to the community instead of us setting the limits. Dunno if anyone else has an opinion on this? @bclavie @NohTow

I think this is a good point, but I'm not sure if it's really going to have an impact? Someone wanting to make such sizeable changes to the tokenizer will (I assume) know what they're doing enough to modify what needs modified, and any other changes will be largely covered by having ~120 unused tokens, which IIRC covers pretty much all the current usecases of token extension.
Overall I think this might be a case of over-optimising with potential side-effects while it's unlikely to be a problem in practice. Would it be fine with you if we kept going with the current way @ohallstrom ?

I have tested this in numerous settings again, and just as before opening the PR I did not see a noticeable diff between this branch and main when not using resizing. I then tried using the same model config as @warner-benjamin, and it turns out there is a difference because main has been updated with new attention features which Warner used that were not on my branch. When this branch is rebased I get no diff:

And here is the long run (obviously they did not have the exact same values at all times as for the highlighted step)

When it comes to resizing, that is another question. I misunderstood Warners first comment, thinking the diff came from resizing. Resizing is no prioritization for me, and I am fine with not using it. But I'd be inclined to at least have something that raises an error when the init_weights function is called with its parental signature (in other words when it is inited with a call from the PreTrainedModel with a module as argument) to not have any unpleasant surprises if we would update to a new version of transformers.

I tried resizing with Megatron innit, and it does seem to work as expected similar to my initial tests with default innit. Essentially it is hard to verify resizing as like I said previously, it won't give the same innit as not resizing (but instead passing the vocab size with the config) with the same seed. This is due to the fact that with resizing, the embedding is first initialized with a smaller size before the resizing, and this will affect the resizing of all other modules that are initialized afterwards (see toy example below).

So essentially, resizing is expected to have as similar performance to setting the vocab_size manually, as a run when setting the vocab_size manually with a different seed.
And indeed it seems like the loss is within a reasonable margin

Then I think it's good to be merged.


KAFKA-10017: disable flaky EosBetaUpgradeIntegrationTest to stabilize build

More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Thanks for doing this. This test has been incredibly unstable.


#640 FIX: Regress JIRA Settings - Convert Selectors to TEXT Input Fields (for now)

JIRA Settings

[x] Convert Selectors to TEXT Fields
[x] Add Error Handling for Missing Type Mappings before calling [].split

Description
This PR reverts selectors on the JIRA settings page to TEXT Inputs for ITER3 or until after BE implements data endpoints to drive the selectors.
Does this close any open issues?
#640, #606
Screenshots

@kevin-kline @joncodo This one is ready for verification and merge to main. Thanks!


Unable to use torch.Generator on CUDA

Minimal reproduction:
    var generator = new torch.Generator(42, torch.device("cuda"));
    Console.WriteLine(generator.device);
    Console.WriteLine(generator.get_state());
    var distribution = torch.tensor(new float[] {0.1f, 0.2f, 0.3f, 0.4f}, device: torch.device("cuda"));
    var output = torch.multinomial(distribution, num_samples: 1, generator: generator);
    Console.WriteLine(output.ToString(true));

Output:
cuda
[5056], type = Byte, device = cpu
Unhandled exception. System.Runtime.InteropServices.ExternalException (0x80004005): Expected a 'cuda' device type for generator but found 'cpu'
Exception raised from check_generator at /opt/conda/conda-bld/pytorch_1695392067780/work/aten/src/ATen/core/Generator.h:156 (most recent call first):
...(call stack omitted)

This also won't work:
    var generator = new torch.Generator(42, torch.device("cuda"));
    generator.manual_seed(42);
    Console.WriteLine(generator.device);
    Console.WriteLine(generator.get_state());
    generator.set_state(generator.get_state().cuda());

Output:
cuda
[5056], type = Byte, device = cpu
terminate called after throwing an instance of 'c10::TypeError'
  what():  RNG state must be a torch.ByteTensor
Exception raised from check_rng_state at /opt/conda/conda-bld/pytorch_1695392067780/work/aten/src/ATen/core/Generator.h:181 (most recent call first):
...(call stack omitted)

TorchSharp: 0.101.4
libtorch loaded from conda: pytorch 2.1.0 py3.10_cuda12.1_cudnn8.9.2_0

Update:
This issue may be more complicated. The equivalent code works in python/pytorch, and the device of state tensor is exactly cpu with shape [16]. A rolling offset is also used in pytorch.

Okay, thank you for the issue! I'll be taking the rest of the year off after today, and there's no chance of getting a fix into a release before January. A temporary workaround may be to generate random values on CPU and then move the resulting tensor to the CUDA device.

The bug is pretty obvious -- this was a TODO in the C++ code. I still haven't found a way to create anything but the default GPU generator, but the API can at least return that one until I can discover exactly how to do it. The C++ docs for libtorch don't cover it.


Redundant bullet point in CoE Prerequisites

fixes #866

Thank you! We have noticed this also, and made the same change in our branch that we're just preparing for publishing - I will close this PR and push the change with our branch in the coming days.


Upgrade to v3.43.0 of the AWS Terraform Provider

Fixes: #1513
Fixes: #1515

@mikhailshilkov this is an expected "breaking" change to the data source. The data source originally had an input for logs when it should only have been an output


[Service Bus] "SupportOrdering" property in QueueDescription

"SupportOrdering" attribute is present in the "topic" related interfaces, but not the queue.
Same is the case with the .NET SDK.
However, the swagger defines it for queue and Java, python SDKs should be having this in the QueueProps/QueueDescription.
TODO: Verify the attribute is supported by the service for queues and update the interfaces/logic behind serialization/deserialization.
/cc @JoshLove-msft

Indicates if messages are sequenced or received in the same order they are sent. If partitioned entity, defaults to false and setting it to true has no effect. For non-partitioned entities, it is always true for a queue. Setting it to false has no effect. For non-partitioned topics, setting it to false will improve perf, but messages may not received in the order they are sent

The above is from the Service Bus team. Since setting this for queues has no affect, I dont see the point of having it in the APIs

If it has no affect, swagger needs to be updated and the JAVA/Python SDKs need to followup on this.

PR to update the spec: https://github.com/Azure/azure-rest-api-specs/pull/17145


[Snyk] Upgrade com.fasterxml.jackson.core:jackson-annotations from 2.14.0 to 2.14.1

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade com.fasterxml.jackson.core:jackson-annotations from 2.14.0 to 2.14.1.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released 23 days ago, on 2022-11-21.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

 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.You have signed the CLA already but the status is still pending? Let us recheck it.


Add personal repository vision format to the wiki

Add personal repository vision format to the wiki

Added quick vision to https://github.com/calestar/computer-manager/wiki/Vision


Bring back CoAP adapter

CoAP adapter was removed as it was in experimental state. There is a decision to bring that adapter back in the Mainflux, with the note for the users that it is not ready for production use.

Related to https://github.com/mainflux/mainflux/issues/371
Check OCF implementation: https://github.com/go-ocf/go-coap


Add terragrunt-parallelism to documentation

It looks like this option is not included in our reference docs, so I added it in.
NOTE: will be merging this in directly given content.

LGTM, thx for adding!


Help: Is there a way of changing MainMenuState, FreeplayState, StoryModeState?

What do you need help for ?
Please note that the documentation is still under construction.
title says it :/

mods/your mod/ui/MainMenuState.hx
mods/your mod/ui/FreeplayState.hx
mods/your mod/ui/StoryMenuState.hx


Fix noop class in _macros.html

Coverage remained the same at 82.404% when pulling 3d2c940ea6e8dbfcd9b017947fd020e9a6d62326 on raphink:noop_class into f4d61c8d1365c5cd51f721e21718570e68b6662a on voxpupuli:master.


Refactoring of the grid handling to possibly support more complex data structures

A first tests of GridInspector() class and some gridtype based operation as discussed in #32
Target is still far but the idea is in place.

🚀 🚀 🚀

After all this machinery, everything is now working as it was originally, meaning that the Gridtype introduction allow for backward compatibility, at least with the current testing strategy
A lot of things must be still improved:

[ ] Rationalize the regrid2d and regrid3d in order
[ ] Read the vertical_dim from the weight when initialize the Gridtype through weights
[ ] Cleaner GridInspector dealing with Dataset or DataArray. Overarching question, is this class really needed?
[ ] cdo_weights_generator can receive as an argument Gridtype and store some of it into the weights file to be later reused. This is fundamental for the future support for multiple grids
[ ] Verify if the vertical_dim should be a possible argument of the Regrid class to guarantee flexibility
[ ] Agree on naming for vertical_dim or ‘vertical_coord’: is a dimension or a coordinate?
[ ] Extend tests to make it compatible with AQUA cases. There are cases within AQUA with complex cdo_extra arguments which are not covered here
[ ] Review docstrings
[ ] Documentation: a first draft is available and set up on read the docs
[ ] Compatibility test with AQUA: need to run AQUA with a specific installation of smmregrid

Long terms ideas

Move some the grid handling from AQUA to smmregrid
Have a GenerateWeights class which support for cdo but also for other regridding tools

@jhardenberg @mnurisso this can be considered ready to me. I will move the remaining issues (e.g. the creation of a class for generation of weights) to new issues and possibly develop this in the future.
It will be interesting to see which of the features of AQUA should be moved here for a cleaner operativity. For example, now all the dimensions guessing is done inside smmregrid so it should be completely redundant what is done in AQUA. Also, given the properties of the tool, also the grid are generator can be moved here as a specific class (or a twin object of the generation of weights).

I spotted a couple of cases that slipped through the tests, most importantly the one when the time dimension has been dropped. We could make a bit of discussion on the implementation of the GridType class in order to see if there are better possible definitions.

I created a new class CdoGenerate() which has two exposed method, one is weights() and the other is areas() so that it can produce both weights and areas and easily port them to python.
I tried to divide the many options available in order that the ones CDO-related all fill into the class while the other goes into the method. Feel free to suggest improvements. I still need to write some tests to check everything works as expected, but it is quite straightforward since I am using direct cdo calls.

Added supplementary testing, everything seems in place. Consolidation might be required but it would be great if this is done upon review (taggin @jhardenberg for this)

It would be nice to have a method of gridType which prints a detailed user-readable info about a grid (or a method of Regridder which does this for all grids ....) Similar to cdo gridinfo

I did some tests with this:
import xarray as xr
from smmregrid import Regridder
data = xr.open_mfdataset("tests/data/tas-ecearth.nc")
sgrid = data.tas.isel(time=0)
regridder = Regridder(source_grid=sgrid, target_grid="r180x90", method="ycon", loglevel="debug")

If I do
regridder.grids[0].horizontal_dims
I get a list ['lat', 'lon']
If I do
regridder.grids[0].other_dims
I get an empty set  set() : should it not be an empty list for consistency ?
Instead
regridder.grids[0].time_dims
is None ...  (which is ok..but why ... is there no time?)
BTW this time will be the same for all grids, no?

In line 141 of regrid.py I would also log the value of other_dims

If I do regridder.grids[0].other_dims I get an empty set set() : should it not be an empty list or None for consistency ?

this ia good point, we should homogeneize

Instead regridder.grids[0].time_dims is None ... (which is ok..but why ... is there no time?) BTW this time will be the same for all grids, no?

well, above you selected time=0, so there is no time dimension

BTW plev is a vertical dim to add to the defaults

Ah, I see now that this is not good, because then 3D atmospheric variables would be treated like 3D arrays and weights computed separately on all levels. Actually this should be an option, no? There should be a way to tell that in this case the array does not need 3D weights ....

cdogenerate() fails in this case (or maybe I do something wrong)
import xarray as xr
from smmregrid import Regridder
data = xr.open_mfdataset("tests/data/temp3d-fesom.nc")
sgrid = data.temp.isel(time=0)
regridder = Regridder(source_grid=sgrid, target_grid="r180x90", method="con", loglevel="debug")

In the case of tas-healpix2.nc. it does not identify the bounds

If you can wrap up the comments it would be great so that we can think about

addressing what is urgent to get this new release done
identify possible updates to be done in a later stage
most importantly, following your inspection write new tests that covers the different cases!

yes, I will...for the moment these were sort of notes as I was finding things

I am collecting suggested changes in #35 (which is a PR to this branch) but I will keep comments here so that we do not disperse them in two separate threads.

In #35 I introduced a new dataset with two variables, one atmospheric and one oceanic on different grids (and reduced to only 3 levels each).
For some reason this locks up when processing the second variable (in method _prepare_grid()):
import xarray as xr
from smmregrid import Regridder
data = xr.open_mfdataset("tests/data/ua-so_mix_ecearth.nc")
regridder = Regridder(source_grid=data, target_grid="r180x90", method="bil", loglevel="debug")

See comment in #35

I am marking above issues which now work with the latest version using thumbs up and a rocket

BTW plev is a vertical dim to add to the defaults

Ah, I see now that this is not good, because then 3D atmospheric variables would be treated like 3D arrays and weights computed separately on all levels. Actually this should be an option, no? There should be a way to tell that in this case the array does not need 3D weights ....

Should we add an optional flag 'treat_as_2d" or similar so that a 3D array will certainly be regridded like a 2d one (no 3D weights) ?

Ok, remaining issues from above are just:

the one about a possible option to always force considering the grid 2D
the robustness  of doing  nvert = sgrid[vertical_dim].values.size. This could also be  nvert = len(sgrid[vertical_dim])no? But I do not know ifsgrid[vertical_dim]` is robust

the one about a possible option to always force considering the grid 2D

this is a bit complex. I wondering if instead of specific flag wouldn't be better to let the user define the dimensions that he want to use. so potentially a flag (e.g. override_dims=True) that modify the behaviour of extra_dims and replace entirely the DEFAULT_DIMS.
If we store DEFAULT_DIMS into an attribute of the GridType, this can be later modified by GridInspector call.

the robustness  of doing  nvert = sgrid[vertical_dim].values.size. This could also be  nvert = len(sgrid[vertical_dim]) no? But I do not know if sgrid[vertical_dim] is robust

this should have solved with last commit

Why do I get 0from regridder.grids[0].masked if GridType initializes self.maskedto None?

is this a valid issue?

I can't find the right place to put the raise when we try to use multiple gridtypes and we init from weights...this because the regrid is working with map on DataArray, so that we cannot have in the same moment information about multiple grids inside the call.

this is a bit complex. I wondering if instead of specific flag wouldn't be better to let the user define the dimensions that he want to use. so potentially a flag (e.g. override_dims=True) that modify the behaviour of extra_dims and replace entirely the DEFAULT_DIMS.
If we store DEFAULT_DIMS into an attribute of the GridType, this can be later modified by GridInspector call.

Yes, something like this: default_dims becomes an attibute of GridType. Then actually there could be extra_dims  to extend the list and maybe simply dims if instead one wants to substitute ?

Why do I get 0from regridder.grids[0].masked if GridType initializes self.maskedto None?

is this a valid issue? how can I reproduce it?

Not really an issue...more the fact that I did not understand the masked attribute

I can't find the right place to put the raise when we try to use multiple gridtypes and we init from weights...this because the regrid is working with map on DataArray, so that we cannot have in the same moment information about multiple grids inside the call.

Hmm.. yes but the map() is in regrid(). The facts that we initialize with weights and that there are multiple grids are known already when instantiating the Regridder class, so could the raise not be there?

Hmm.. yes but the map() is in regrid(). The facts that we initialize with weights and that there are multiple grids are known already when instantiating the Regridder class, so could the raise not be there?

The problem is that so far the gridtype inspect is done at regrid_array level so that we do not know when calling regrid the properties of dataset we are planning to regrid. We could do it twice, or I can check if it could make sense to move it to a higher level.

Yes, something like this: default_dims becomes an attibute of GridType. Then actually there could be keywords extra_dims to extend the list and maybe simply dims if instead one wants to substitute ? (so no extra flag but rather an extra argument maybe)

I was wondering, but in the very end do we need the extra_dims or simply we want to feed the GridType detection with a new set of dims? it would probably easily meet the user need having a new set of dims, probably there is no need to add them.
I checked the code and extra_dims it is a feature we build inside the regrid and then passe to GridInspect, while in the end what is exposed via the regrid init are horizontal_dims and vertical_dim. So I would probably need a flag to decide if I want to send them to extra_dims or to do default_dims. ...


[Feature Request] Guide for integration with Gatsby

What is your enhancement?
If you can provide a few steps on how I can get started with adding the dashboard to an existing gatsby app or using individual components in the basic gatsby-hello-world-starter, I would be happy to write the guide for you once I get it setup myself.

I tried to do it myself but I am getting an error even setting it up. I tried to post the issue here, but maybe some automation kept deleting it so I am mentioning it here as well:

System Details
OS:  Pop_OS 19.10
Browser: Firefox 80.0
App version: 1.1.0
Device: ASUS ROG STRIX II
Problem
I am trying to get started with using the bundle by following the instruction in the documentation
When I run npm run install:clean, I get the following error:
The app does launch. This message is shown in the browser window
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined
    at validateString (internal/validators.js:125:11)
    at Object.join (path.js:1147:7)
    at noopServiceWorkerMiddleware (/home/razor/main/Requestly/requestly-work/landingPpage/argon-dashboard-react-master/node_modules/react-dev-utils/noopServiceWorkerMiddleware.js:14:26)
    at Layer.handle [as handle_request] (/home/razor/main/Requestly/requestly-work/landingPpage/argon-dashboard-react-master/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/home/razor/main/Requestly/requestly-work/landingPpage/argon-dashboard-react-master/node_modules/express/lib/router/index.js:317:13)
    at /home/razor/main/Requestly/requestly-work/landingPpage/argon-dashboard-react-master/node_modules/express/lib/router/index.js:284:7
    at Function.process_params (/home/razor/main/Requestly/requestly-work/landingPpage/argon-dashboard-react-master/node_modules/express/lib/router/index.js:335:12)
    at next (/home/razor/main/Requestly/requestly-work/landingPpage/argon-dashboard-react-master/node_modules/express/lib/router/index.js:275:10)
    at launchEditorMiddleware (/home/razor/main/Requestly/requestly-work/landingPpage/argon-dashboard-react-master/node_modules/react-dev-utils/errorOverlayMiddleware.js:20:7)
    at Layer.handle [as handle_request] (/home/razor/main/Requestly/requestly-work/landingPpage/argon-dashboard-react-master/node_modules/express/lib/router/layer.js:95:5)

Please let it stay easy to raise issues, whether you attend to them or not is a different thing

Hello there, @nsr-py ,
Thank you for your interest in working with our products.
At the moment we haven't worked with GatsbyJS, so we can't give you any guidance on this issue.
I'll leave this issue open for about 30 days, if no one will be able to help you, I am going to close it.
Best,
Manu

Can you give me guidance regarding my other comment

Yes, sorry, I thought it was the from Gatsby, didn't read thoroughly, sorry my bad.
You need to change react-scripts form inside package.json to 3.4.0. That will solve the issue.

Thank you


feat: toast

Just a problem with the animation out for data-state=end, if anyone have an idea ? (After the swipe)
https://user-images.githubusercontent.com/16818589/215194211-dab2802b-2ab7-4ee1-ab2b-459390b33dc2.mov

If you want I can't remove CVA. I was thinking about a design similar to the Callout in the docs ? Is it better for the toast ?

I think I can improve toast with a placement props on the viewport, remove CVA for the toast and improve for swiping animation to add up and down. Will do all of that tomorrow to improve the component

Everything seems good, the only problem is the tailwind animate exit keyframe that can't take a slide-out-from-x to set the  from translate x to var(--radix-toast-swipe-move-x)

By moving position in toast component, now it need computation to display multiple toasts. I can create a useToaster hook to manage toasts this way but otherwise it's better to set the position in the viewport I think

@Ventinc This is looking incredible! 🤯
I like the react-hot-toast direction. This is what I was planning to implement as well.
If it's OK, I'd like to push some style updates to this PR.

Yes update the style ! I'm not very good at styling things 😅

Do you prefer the position in the Viewport or in the Toast props ? For me it's seems okay to put it in the Viewport and it's simpler than to add a ToastWrapper to compute the height and the position in the useToaster hook. But I can implement this way too

Do you prefer the position in the Viewport or in the Toast props ? For me it's seems okay to put it in the Viewport and it's simpler than to add a ToastWrapper to compute the height and the position in the useToaster hook. But I can implement this way too

No you're right! The position should be in <ToastViewport />.
I tried moving it to toast() but from a UX perspective, it makes sense to keep it viewport since toasts should always be from one position.

@Ventinc Let's simplify this.
We will support one position and one swipe direction in the component. We can cover customization in documentation.
Anyone consuming this component in their app should go with one position and one swipe direction anyway.
So it's ok if we're opinionated here.
I'll push some updates.

@Ventinc I pushed the updates. I updated the use-toast hook to be the default (This is excellent work. Thank you 👍)

Rename use-toaster to use-toast.
Updated the examples to use the hook.
Simplified the position and swipe animation.
Updated the styles for the toast.
Updated docs.

WIP

Animation when adding new toast (let me know if you know how to fix this)
Add a "descructive" variant for toast

@Ventinc I pushed the updates. I updated the use-toast hook to be the default (This is excellent work. Thank you 👍)

Rename use-toaster to use-toast.
Updated the examples to use the hook.
Simplified the position and swipe animation.
Updated the styles for the toast.
Updated docs.

WIP

Animation when adding new toast (let me know if you know how to fix this)
Add a "descructive" variant for toast
Fix dark mode styles.

For me the animation when you add a new toast seems good (slide from bottom to top).
Ok so the UI is opinionated and if the developers want he can update for his design that's it ?
I can fix dark mode and add destructive variant if you want but what is the destructive variant ?

@Ventinc Can we make it red background with white text?

Note: this might require some fixes for the action.

Also what do you think about using outline for the button type?
From Radix UI docs:

An action that is safe to ignore to ensure users are not expected to complete tasks with unexpected side effects as a result of a time limit.

This should probably not be a primary button. What do you think?

Yes I think outline is better for the button. Becaues it's not a primary action, it's here "just in case".
For the action button because default light mode should not be compatible with destructive light mode. You think a props is pass to the action or I add a data-status on the toast and force to be white in destructive mode ?

I think Button variant oultine should be updated because right now it use dark:hover:bg-slate-700 the same background as the notification in dark mode. I think it should use dark:hover:bg-white/X (X to define) and same for light mode colors. Then when destructive status is define I could override theme on the Toast component with data-theme="lignt"

I've add destructive toast, outline for action.
Now we need to find solutions for:

outline in dark mode
How to design action in destructive mode (Props or group-data-[status=x])

@Ventinc

I implement a custom button for the toast. This works for default and destructive.
I'm using group destructive then group-[.destructive]:bg-... to style the button.
I've also update the docs and a few style fixes.

Ready for QA.

Seems good for me ! I had not see that you changed useToast, it's way better with title, description and action as Props than just content. I had done it because I thought it was not opinionated at first.

@Ventinc Yeah I added title, description and action since they are supported by the <Toast /> primitive.
If everything is looking good here, I'll go ahead and merge this.


Error: Vitest failed to access its internal state.

Describe the bug
Running my nextjs application with yarn run dev launches this Vitest error.
error - Error: Vitest failed to access its internal state.
One of the following is possible:
- "vitest" is imported directly without running "vitest" command
- "vitest" is imported inside "globalSetup" (to fix this, use "setupFiles" instead, because "globalSetup" runs in a different context)
- Otherwise, it might be a Vitest bug. Please report it to https://github.com/vitest-dev/vitest/issues
Reproduction

System Info
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
Used Package Manager
yarn
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

vitest.config.ts

import { defineConfig, configDefaults } from "vitest/config";
import { resolve } from "node:path";

export default defineConfig({
  test: {
    include: ["**/*.test.ts", "**/*.test.tsx"],
    exclude: [...configDefaults.exclude, "./pages/_app.tsx"],
    environment: "jsdom",
    reporters: "verbose",
    // outputFile: "./testResults.ts",
  },
  resolve: {
    alias: [{ find: "@", replacement: resolve(__dirname, "./") }],
  },
});


read-only filesystem

Maybe I'm doing something wrong but I'm not able to copy files to the boot disk any more because it's read-only?
mkdir: cannot create directory ‘/media/thijs/AFF1-72C7/config/files’: Read-only file system
mkdir: cannot create directory ‘/media/thijs/AFF1-72C7/config/files’: Read-only file system
'debian/installer-config.txt' -> '/media/thijs/AFF1-72C7/installer-config.txt'
cp: cannot create regular file '/media/thijs/AFF1-72C7/installer-config.txt': Read-only file system

This was not happening with a checkout from a few days ago.

Sorry my mistake. Please mark as invalid.

No problem.


getParam in onCreated returns null

Doesn't feel right that FlowRouter.getParam returns something different then FlowRouter.current().params
// url: /t/abc123
// route '/t/:token?'

Template.myContent.onCreated(function() {
  var token1 = FlowRouter.getParam('token'); // returns null
  var token2 = FlowRouter.current().params.token; // returns abc123
});

+1 - I have exactly the same situation.

+1 - Same thing here

I believe this is caused here when the action is called before registering the reactive values for params and query params.
So, what happens is:

in line 301 the action is called
in the action FlowLayout.render() is called
the render triggers your Template.onCreated() function
then FlowRouter.getParam() returns null
the action returns
in line 305 self._registerParams() is called which sets the reactive params

@arunoda What do you think? Should lines 305 and 306 go before line 301's Tracker.nonreactive() call?

I get your point and that's the reason for this issue.
But if we implement that, old route's template will get re-rendered another time with the new routes data. That might be okay for some template which stays forever. It cause trouble for templates which is going to destroy. I didn't check this. (May be this won't be an issue since they'll get removed anyway)
If we can do a test and see it don't make any issue, we are good to go.

Great point. It would trigger Trackers in current Templates and there's bound to be some about to be destroyed. When I looked earlier I saw line 308 self._currentTracker.changed(); and was thinking they wouldn't be notified yet. Woops. Different tracker.
FlowLayout Option
When using both FlowRouter and FlowLayout a solution would somehow split FlowLayout's render into two phases: 1. destroying the templates which aren't needed anymore, and, 2. creating the new templates. With FlowRouter somehow knowing phase 1 has been done so it can set the new ReactiveDict values before phase 2 runs. Both FlowRouter and FlowLayout are your packages. Would you be interested in FlowRouter listening for FlowLayout's render phases? Or at least for phase 1. It's essentially adding a listener which calls the self._register* functions when FlowLayout finishes its destroy phase. If they haven't been called after the action has been called then FlowRouter can call them like it does now.
This would also only solve this problem for those using FlowLayout and having trouble with Template.onCreated. Other action types could encounter similar trouble.
New Function: FlowRouter#ensureReactive()
What about adding a function to tell FlowRouter to ensure it has updated the reactive values for the current route? Like FlowRouter.ensureReactive() which tells FlowRouter to update its reactive values for the current route if it hasn't done so? It wouldn't break the current API and it would allow the above example to do this:
// url: /t/abc123
// route '/t/:token?'
Template.myContent.onCreated(function() {
  FlowRouter.ensureReactive();
  var token1 = FlowRouter.getParam('token'); // returns abc123
  var token2 = FlowRouter.current().params.token; // returns abc123
});

This requires dev's encountering this issue to tell FlowRouter to ensure the update has been done for the current route. We'd have to track whether the update for the current route was done so we don't do it a second time after the action is called or when the Tracker computation is rerun.
Passing a boolean
Or, add a boolean as a second param to the current API functions which tells FlowRouter to ensure the reactive values are updated: FlowRouter.getParam('token', true);
Only the first option would handle it automatically without developers doing something in their code.
Thoughts anyone?

I believe we can solve this and the other reactive issues, if we dive into the problem a bit.
I still we could deal with this without the intervention of the user.

What great timing! I hope you get this resolved, this would be a bummer.
I was just this out in this MeteorPad. The staticToken is not printing.

Yes it is. This is my top priority for flow router. Let's see.
On 2015 මැයි 16, සෙන at ප.ව. 8.13 Richard Lai<EMAIL_ADDRESS>wrote:

What great timing! I hope you get this resolved, this would be a bummer.
I was just this out in this MeteorPad
http://meteorpad.com/pad/smy3ano7Tk9nsBhu4/FlowLayout + FlowRouter and Blaze Components.
The staticToken is not printing.
—
Reply to this email directly or view it on GitHub
https://github.com/meteorhacks/flow-router/issues/95#issuecomment-102633204
.

But if we implement that, old route's template will get re-rendered another time with the new routes data. That might be okay for some template which stays forever. It cause trouble for templates which is going to destroy. I didn't check this. (May be this won't be an issue since they'll get removed anyway)

@arunoda @elidoran can you guys post code snippet that produce this side effect?
I tried below code:
Template.myContent.helpers({
  token: function() {
    console.log('getting token');
    return FlowRouter.getParam('token');
  }
});

on template {{token}}.
If we render different layout (ofc using flow-layout) token helper doesn't rerun. If we render same layout with different template token helper rerun just before destroy it's template.
But this issue doesn't depend on #107 PR, token helper rerun anyway.

I started working on this on fix-reactive-bugs branch. It have a fix for #103 but not for this.
My idea is to isolate the reactiveData for each route definition. Then we can deal with this issue.
We may have some side effects because of that, but anyway let's give it a try.

Guys, can you now check the fix-reactive-bugs branch. I've a proper fix on that.

This issue seems fixed by fix-reactive-bugs branch.

Nice to hear that.
On 2015 මැයි 19, අඟහ at පෙ.ව. 5.49 Eli Doran<EMAIL_ADDRESS>wrote:

This issue seems fixed by fix-reactive-bugs branch.
—
Reply to this email directly or view it on GitHub
https://github.com/meteorhacks/flow-router/issues/95#issuecomment-103279671
.

Released version 1.8.0 with fixes for this bug.

I think this is still an issue. Let me see if I can reproduce.

Sorry to bother you, @arunoda but I still have exactly this problem with v1.10.0.
FlowRouter.route('/genre/:genre', {
  name: 'appMarketGenre',
  action: function(params, queryParams) {
    FlowLayout.render('MasterLayout', {mainSection: 'Genre'});
  }
});

Template.Genre.onCreated(function() {
  console.log(FlowRouter.getParam('genre'), FlowRouter.current().params.genre);
});

yields:
undefined "publishing"

when you navigate to /genre/publishing and so on.

Okay

@richsilv I tried with as your code but it works well for me.
repo: https://github.com/arunoda/flow-oncreated-issue
video: http://recordit.co/Hi9B75Xh8b
Can you play with this app? or try to send me a the usecase you've

Profuse apologies - I was running this on a dev branch that was still using v1.7.1...

okay. closing then.


Add rule key to summary output of miner

I often use the miner to find what I can repair in a project, and it's always somewhat annoying to try to figure out which rule key corresponds to which rule. The summary output is just CheckName=<num_violations>, and to find the key I either have to go into the stats file or browse through the repair command's help section.
It'd be much nicer if the output was on the form CheckName[<rule_key>]=<num_violations>, or something like that, as you then wouldn't have to go hunting for the key.

@khaes-kth Do you want to do this?

@slarse
Yes, I do.

Fixed in #505


Remove button synthesis from event converter

Description
This PR removes a workaround, which was added because some events used to have buttons: 0 incorrectly (https://github.com/flutter/flutter/issues/30454). Related tests are fixed or removed.
Related Issues

https://github.com/flutter/flutter/pull/55789
#30454

Tests
No tests are added. Some tests are removed because framework no longer provides button synthesis.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I signed the CLA.
[ ] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[ ] I read the Tree Hygiene wiki page, which explains my responsibilities.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] All existing and new tests are passing.
[ ] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[ ] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.

[x] Yes, this is a breaking change. If not, delete the remainder of this section.

[ ] I wrote a design doc: https://flutter.dev/go/template Replace this with a link to your design doc's short link
[ ] I got input from the developer relations team, specifically from: Replace with the names of who gave advice
[ ] I wrote a migration guide: Replace with a link to your migration guide

(PR triage): This PR is getting pretty old. Are there still plans to do anything with this?

Close for now until the removal is verified appropriate.


Update plot dimensions

This PR addresses some QC report things identified in #469 we'd like to fix.

Use theme(aspect.ratio = 1) instead of coord_fixed() for UMAPs
Bigger width for diagnostic cell type plots
Ensure heatmaps are at least 4" tall (related to #541)
Bonus, fix a bug introduced in https://github.com/AlexsLemonade/scpca-nf/pull/574/files

We moved some text into an as_is chunk with glue::glue(), so need to use {} for variables, not `r stuff`

This all looks good to me. I don't know if you had any plans for further modifications?
Oh, one minor one: if we add + xlim(0,1) to the CellAssign plot, I think it should get the densities to extend to the full range of the plot, would look nice.

This all looks good to me. I don't know if you had any plans for further modifications?

No further plans now, just later as part of #541. I'll go ahead and mark this ready for review, and add xlim()

Full range!

After this goes in, I'll regenerate the reports, and move to zipping up example data.


Apple ID get's locked every 1-3 days and ic3 often fails at startup even when account is not locked

I'm reporting these together as I suspect they are related. I have several apple devices linked to my apple ID but I think that ic3 is the only non-apple thing that directly uses my apple credentials. I have 5 trackers setup in ic3, myself and 4 family members all shared via Family Sharing.  For about the last month, my Apple ID has been getting locked every 1-3 days.
I'll notice that icloud3 isn't updating and notice in the ic3 logs that there are errors. I'll then open icloud.com (not in Safari) and after logging in get notified my account is locked. I'll follow the steps to unlock my account and then get an email from Apple confirming that my account is now unlocked.
Once unlocked, I'll then go to ic3 and select Restart icloud3. Sometimes it restarts fine and all 5 trackers come up. However ~50% of the time only my tracker comes up and the rest show yellow triangles. The debug log for starting up where it only finds my device is here:
icloud3-0_bad_init.log
Additionally, since this frequent Apple ID locking has started, when I restart ic3, it is about 50/50 whether it will startup correctly or only have my tracker working with the rest having yellow triangles. This happens when my account isn't currently locked and that I haven't had to unlock it in the last several hours to days.
Any thoughts on this? Both the frequent Applid ID locking and the ic3 failed startup?

I've encountered a similar situation. Unfortunately, I haven't been able to get IC3 to accept the new AppleID credentials.

@garyak
If iCloud3 won’t save a username/password change, on the Configure Settings > Apple Acct screen, try selecting the ‘log out’ option and submit  then save and submit to clear them from the configuration.  Then go back and enter the new ones, log in and submit, then save and submit.

@Snuffy2
When iCloud3 first logs into the Apple Account, Apple returns the devices in the Family Share list. That is used to build the internal tables and t tie everything together. Sometimes it doesn’t return all of them. iCloud3 checks for this and requests for them again. Most of the time it gets them. Sometimes there is an issue with a watch not being returned when it has been charging on the counter overnight or has not been worn for several days Anna Apple seems to loose track of it. Check the FindMe app and see it the device that doesn’t load shows as available before you restart. An older version of iCloud3 has a problem with the retry where it thought it was asking for a data refresh but it really wasn’t and was just looking as the same data 10-times before failing.
You have Log level debug.  You really want ’rawdata’ . Rawdata dumps the data request and what was returned from Apple to the log file. It shows the devices that are returned when iCloud3 starts and all the raw Location data when it is running. Turn it on in Configure Settings > Page 2 > Format Parameters screen so it stays on overnight. Selecting it from the Event Log > Actions > xx will turn it off at midnight. Then let’s see what Apple is returning. There is a ‘locked: True’ field in the data that might show what was going on when it was set.
3-days of log files are kept and they e at midnight. -0 is today, -1 is yesterday and-2 is the day before. If it takes several days to show to, you might need to rename them each day so they are not lost. If this seems to happen more on one device, put that device name in the filter field on the Configure Settings > Page 2 > Format Parameters screen. That will limit the raw data to only that device and I don’t have to go through a lot of hay to find the needle.

@gcobb321 I reloaded fresh code as I was getting new waze errors. All errors are now gone from the event log, but still not connected to icloud after updating credentials. Logs in OK, but doesn't appear to save as I go back to enter the verification code. Request new verification from the Event Log pull-down isn't working for me now. Also, the configure button on the Event Log just circles back instead of initiating the config routine.

@garyak Can you go to configure via Settings > Devices Anna Services > iCloud3 > Configure?
Check the iCloud3 configuration file in .storage/icloud3/configuration and see if it is trashed. It does keep a backup of itself in case of errors. Look at the username and password fields. Clear them to remove the old credentials. That’s what the log out does.

Yes. Can access the configuration screens from devices and services. Configuration file at .storage/icloud3 shows null values for user credentials.

It sounds like HA may have created duplicate sensor entities with the _2 suffix. And maybe the dev trkr entities too. It did that to me last night with my iPad. The mobile app has 4 of them. You may have to go to the devices and settings and rename the entities or go into the iCloud3 Configure Settings >  and select them again.

It sounds like HA may have created duplicate sensor entities with the _2 suffix. And maybe the dev trkr entities too. It did that to me last night with my iPad. The mobile app has 4 of them. You may have to go to the devices and settings and rename the entities or go into the iCloud3 Configure Settings > and select them again.

@gcobb321 after I got prompted to re-authenticate tonight I noticed few hours later after I did re-authentificated and reloaded the integration all sensors created by the Icloud V3 integration got duplicated and got the _2 suffix.

The problem now is I can not rename them by remove the _2 suffix because those entity names still exist, if I try to delete them trying to use th clokwheel within the entity window I can not because it show me that the entity have no unique ID.

You have any suggestion how I can remove these "unavailable" entities?

You can disable unwanted entities.

You can disable unwanted entities.

@garyak No I can not because I can not enter the entity because it not have a unique-id, and every reload I do creates a duplicate of the sensors with a next in line number suffix

@smarthomefamilyverrips  I haven't run into your problem before. If available, you could restore a recent backup. I usually have gotten duplicate entries with numeric (-2) additions when I reinstall over the top of a previous installation. I now delete the previous integration and restart HA before installing a new instance of IC3. The difficult option is to stop HA core and edit the core.entity_registry file to remove, I reccomend you backup the original file before you edit.

@smarthomefamilyverrips This problem should really be in its own issue since it does not relate to the title of the problem even though it is similar to the one GaryK was having.
To remove the unavailable entities, click the check box to select all entities and then select remove..HA will only remove the ones that are unstable and leave the rest. Then restart HA and rename the ones wits the _2 to their correct name without the _2

@smarthomefamilyverrips This problem should really be in its own issue since it does not relate to the title of the problem even though it is similar to the one GaryK was having.
To remove the unavailable entities, click the check box to select all entities and then select remove..HA will only remove the ones that are unstable and leave the rest. Then restart HA and rename the ones wits the _2 to their correct name without the _2

@gcobb321 what checkbox you mean?

@smarthomefamilyverrips settings >devices and services >settings >entities. Then click the  icon to the right of the filters icon  on the top row display the check boxes next to the entities. Check the one on the top row to select everything

@smarthomefamilyverrips You may have to disable iCloud3 and restart HA 2 times. Then try again to clean out everything. Then reenable iCloud3 and restart HA again. I would do a backup first in case of problems

@smarthomefamilyverrips You may have to disable iCloud3 and restart HA 2 times. Then try again to clean out everything. Then reenable iCloud3 and restart HA again. I would do a backup first in case of problems

@gcobb321 I will try this then and let you know if worked

@gcobb321 instead of disable the integration I did power cycle my HA Blue and that did remove all duplicate entities, Only now I am unable to create a new battery sensor, If i select it within sensor section by checking the checkbox and click submit it gives me message "unknow error occured"and the blow is in the HA logs
Logger: aiohttp.server
Source: /usr/local/lib/python3.12/site-packages/aiohttp/web_protocol.py:421
First occurred: 17:25:57 (1 occurrences)
Last logged: 17:25:57
Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/aiohttp/web_protocol.py", line 452, in _handle_request
resp = await request_handler(request)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/aiohttp/web_app.py", line 543, in _handle
resp = await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/aiohttp/web_middlewares.py", line 114, in impl
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 92, in security_filter_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 83, in forwarded_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 26, in request_context_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 85, in ban_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 242, in auth_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 32, in headers_middleware
response = await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/http.py", line 73, in handle
result = await handler(request, **request.match_info)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/decorators.py", line 81, in with_admin
return await func(self, request, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 285, in post
return await super().post(request, flow_id)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 74, in wrapper
return await method(view, request, data, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 122, in post
result = await self._flow_mgr.async_configure(flow_id, data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 368, in async_configure
result = await self._async_configure(flow_id, user_input)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 415, in _async_configure
result = await self._async_handle_step(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 518, in _async_handle_step
result: _FlowResultT = await getattr(flow, method)(user_input)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/icloud3/config_flow.py", line 1542, in async_step_sensors
if self.common_form_handler(user_input, action_item, errors):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/icloud3/config_flow.py", line 1184, in common_form_handler
self._remove_and_create_sensors(user_input)
File "/config/custom_components/icloud3/config_flow.py", line 3618, in _remove_and_create_sensors
self._create_sensor_entity(devicename, conf_device, new_sensors_list)
File "/config/custom_components/icloud3/config_flow.py", line 3866, in _create_sensor_entity
ic3_sensor._setup_recorder_exclude_sensor_filter(NewSensors)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: module 'custom_components.icloud3.sensor' has no attribute '_setup_recorder_exclude_sensor_filter'

@smarthomefamilyverrips That is an iCloud3 bug. That code should have been removed in v<IP_ADDRESS> that fixed the HA recorder issue that I missed. I'm working on that module for another issue and will post it here when it is ready.

@smarthomefamilyverrips That is an iCloud3 bug. That code should have been removed in v<IP_ADDRESS> that fixed the HA recorder issue that I missed. I'm working on that module for another issue and will post it here when it is ready.

@gcobb321 Ok I understand, but how I am able to add battery sensors now then as it not let me from the sensor configuration?

@smarthomefamilyverrips It may have been added. The last thing that was being done was generating the error msg after it had been created. Check to see if it exists. If not, you will have to wait for the update.

@smarthomefamilyverrips It may have been added. The last thing that was being done was generating the error msg after it had been created. Check to see if it exists. If not, you will have to wait for the update.

@gcobb321 If I select the battery sensor by checking the checkbox and click submit indeed the battery sensors get created even while I just stay on the sensor configuration window instead of going back to previous window after clcking submit and still get the error message..... only the battery checkbox afterwards still is blank if I check and when I restart HA it makes the battery sensors become unavailable..... so I geuss I need to wait for update as you suggested, ant ETA on this, I alsocan try a beta if it helps you to see if solves this sensor select issue.

@gcobb321 if I use that I get "failed to setup, import error" and integration not starts
following in logs
Logger: homeassistant.config_entries
Source: config_entries.py:555
First occurred: 19:45:08 (1 occurrences)
Last logged: 19:45:08
Error importing platform config_flow from integration icloud3 to set up icloud3 configuration entry: cannot import name 'get_file_list' from 'custom_components.icloud3.helpers.common' (/config/custom_components/icloud3/helpers/common.py)
AND
Logger: homeassistant.util.loop
Source: util/loop.py:77
First occurred: 19:45:08 (1 occurrences)
Last logged: 19:45:08
Detected blocking call to import_module with args ('custom_components.icloud3.config_flow',) in /usr/src/homeassistant/homeassistant/loader.py, line 1296: return importlib.import_module(f"{self.pkg_path}.{platform_name}") inside the event loop; This is causing stability issues. Please create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue For developers, please see https://developers.home-assistant.io/docs/asyncio_blocking_operations/#import_module Traceback (most recent call last): File "", line 198, in _run_module_as_main File "", line 88, in _run_code File "/usr/src/homeassistant/homeassistant/main.py", line 223, in  sys.exit(main()) File "/usr/src/homeassistant/homeassistant/main.py", line 209, in main exit_code = runner.run(runtime_conf) File "/usr/src/homeassistant/homeassistant/runner.py", line 190, in run return loop.run_until_complete(setup_and_run_hass(runtime_config)) File "/usr/local/lib/python3.12/asyncio/base_events.py", line 674, in run_until_complete self.run_forever() File "/usr/local/lib/python3.12/asyncio/base_events.py", line 641, in run_forever self._run_once() File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1990, in _run_once handle._run() File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run self._context.run(self._callback, *self._args) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 734, in async_setup_locked await self.async_setup(hass, integration=integration) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 553, in async_setup await integration.async_get_platform("config_flow") File "/usr/src/homeassistant/homeassistant/loader.py", line 1100, in async_get_platform platforms = await self.async_get_platforms((platform_name,)) File "/usr/src/homeassistant/homeassistant/loader.py", line 1165, in async_get_platforms platforms.update(self._load_platforms(platform_names)) File "/usr/src/homeassistant/homeassistant/loader.py", line 1090, in _load_platforms platform_name: self._load_platform(platform_name) File "/usr/src/homeassistant/homeassistant/loader.py", line 1264, in _load_platform cache[full_name] = self._import_platform(platform_name) File "/usr/src/homeassistant/homeassistant/loader.py", line 1296, in _import_platform return importlib.import_module(f"{self.pkg_path}.{platform_name}")

@gcobb321 if I replace the configuration file in .storage/icloud3 with a configuration file of a back-up made this morning before I did uncheck the battery sensor in the sensor configuration it will not check again the battery sensor and not make it unavailable anymore when I restart HA?
This is my configuration file now:
{
"profile": {
"version": 1,
"ic3_version": "<IP_ADDRESS>",
"version_install_date": "2024-07-19 14:25:47",
"config_update_date": "2024-07-22 16:53:50",
"event_log_card_directory": "www/custom_cards",
"event_log_card_program": "icloud3-event-log-card.js",
"event_log_btnconfig_url": "",
"event_log_version": "3.0.17",
"event_log_version_running": "",
"picture_www_dirs": [
"www",
"www/xplora_watch",
"www/xplora_watch/emojis",
"www/community",
"www/community/weather-chart-card",
"www/community/lovelace-mushroom",
"www/community/lovelace-fan-xiaomi",
"www/community/lovelace-hourly-weather",
"www/community/button-card",
"www/community/clock-weather-card",
"www/community/platinum-weather-card",
"www/community/simple-thermostat",
"www/community/alarmo-card",
"www/community/lovelace-digital-clock",
"www/community/mini-media-player",
"www/community/simple-clock-card",
"www/community/mini-graph-card",
"www/voice",
"www/custom_cards",
"www/image",
"www/video",
"www/video/thumb"
]
},
"data": {
"tracking": {
"username"<EMAIL_ADDRESS>"password": "*******************",
"encode_password": true,
"icloud_server_endpoint_suffix": "",
"setup_icloud_session_early": true,
"data_source": "famshr,mobapp",
"devices": [
{
"ic3_devicename": "lory_iphone_new",
"fname": "Lory Iphone New",
"picture": "www/custom_cards/loredana.jpg",
"evlog_display_order": 0,
"unique_id": "",
"device_type": "iphone",
"inzone_interval": 5.0,
"tracking_mode": "track",
"famshr_devicename": "iPhone Lory",
"famshr_device_id": "AXmZIYMW1z2oyH/o/xAquqcJEAfUY+9R8TFkpcneZ8FU4Di1MAiOAobdLL2IaZNRb21XEC7oUP+Ukw==",
"raw_model": "iPhone15,2",
"model": "iPhone",
"model_display_name": "iPhone 14 Pro",
"fmf_email": "None",
"fmf_device_id": "",
"track_from_base_zone": "home",
"track_from_zones": [
"home"
],
"old_devicename": "lory_iphone_new",
"log_zones": [
"none"
],
"fixed_interval": 0.0,
"mobile_app_device": "iphone_lory"
}
]
},
"general": {
"log_level": "info",
"unit_of_measurement": "km",
"time_format": "24-hour",
"display_zone_format": "fname",
"max_interval": 240.0,
"offline_interval": 20,
"exit_zone_interval": 0.5,
"old_location_threshold": 3.0,
"old_location_adjustment": 0,
"gps_accuracy_threshold": 40.0,
"display_gps_lat_long": true,
"travel_time_factor": 0.66,
"tfz_tracking_max_distance": 8,
"passthru_zone_time": 0,
"track_from_base_zone": "home",
"track_from_home_zone": false,
"center_in_zone": false,
"discard_poor_gps_inzone": false,
"distance_between_devices": true,
"inzone_intervals": {
"iphone": 5.0,
"ipad": 120.0,
"watch": 15.0,
"airpods": 15.0,
"other": 120.0,
"no_mobapp": 15.0
},
"waze_used": true,
"waze_region": "row",
"waze_min_distance": 1.0,
"waze_max_distance": 1000,
"waze_realtime": true,
"waze_history_database_used": true,
"waze_history_max_distance": 20,
"waze_history_track_direction": "north_south",
"stat_zone_fname": "StatZon#",
"stat_zone_still_time": 0,
"stat_zone_inzone_interval": 30.0,
"stat_zone_base_latitude": 1,
"stat_zone_base_longitude": 0,
"display_text_as": [
"#1",
"#2",
"#3",
"#4",
"#5",
"#6",
"#7",
"#8",
"#9",
"#10"
],
"device_tracker_state_source": "ic3_fname",
"track_from_base_zone_used": false,
"away_time_zone_1_offset": 0,
"away_time_zone_1_devices": [
"none"
],
"away_time_zone_2_offset": 0,
"away_time_zone_2_devices": [
"none"
],
"mobapp_alive_interval": 30.0,
"log_level_devices": [
"all"
]
},
"sensors": {
"monitored_devices": [],
"device": [],
"tracking_update": [
"last_located",
"last_update",
"next_update"
],
"tracking_time": [
"travel_time",
"arrival_time"
],
"tracking_distance": [
"home_distance"
],
"track_from_zones": [
"tfz_zone_info",
"tfz_travel_time",
"tfz_arrival_time"
],
"tracking_other": [
"trigger"
],
"zone": [],
"other": [],
"excluded_sensors": [
"None"
]
}
}
}
And this is my Backed-Up configuration file
{
"profile": {
"version": 1,
"ic3_version": "<IP_ADDRESS>",
"version_install_date": "2024-07-19 14:25:47",
"config_update_date": "2024-07-19 14:25:47",
"event_log_card_directory": "www/custom_cards",
"event_log_card_program": "icloud3-event-log-card.js",
"event_log_btnconfig_url": "",
"event_log_version": "3.0.17",
"event_log_version_running": "",
"picture_www_dirs": [
"www",
"www/xplora_watch",
"www/xplora_watch/emojis",
"www/community",
"www/community/weather-chart-card",
"www/community/lovelace-mushroom",
"www/community/lovelace-fan-xiaomi",
"www/community/lovelace-hourly-weather",
"www/community/button-card",
"www/community/clock-weather-card",
"www/community/platinum-weather-card",
"www/community/simple-thermostat",
"www/community/alarmo-card",
"www/community/lovelace-digital-clock",
"www/community/mini-media-player",
"www/community/simple-clock-card",
"www/community/mini-graph-card",
"www/voice",
"www/custom_cards",
"www/image",
"www/video",
"www/video/thumb"
]
},
"data": {
"tracking": {
"username"<EMAIL_ADDRESS>"password": "*******************",
"encode_password": true,
"icloud_server_endpoint_suffix": "",
"setup_icloud_session_early": true,
"data_source": "famshr,mobapp",
"devices": [
{
"ic3_devicename": "lory_iphone_new",
"fname": "Lory Iphone New",
"picture": "www/custom_cards/loredana.jpg",
"evlog_display_order": 0,
"unique_id": "",
"device_type": "iphone",
"inzone_interval": 5.0,
"tracking_mode": "track",
"famshr_devicename": "iPhone Lory",
"famshr_device_id": "AXmZIYMW1z2oyH/o/xAquqcJEAfUY+9R8TFkpcneZ8FU4Di1MAiOAobdLL2IaZNRb21XEC7oUP+Ukw==",
"raw_model": "iPhone15,2",
"model": "iPhone",
"model_display_name": "iPhone 14 Pro",
"fmf_email": "None",
"fmf_device_id": "",
"track_from_base_zone": "home",
"track_from_zones": [
"home"
],
"old_devicename": "lory_iphone_new",
"log_zones": [
"none"
],
"fixed_interval": 0.0,
"mobile_app_device": "iphone_lory"
}
]
},
"general": {
"log_level": "info",
"unit_of_measurement": "km",
"time_format": "24-hour",
"display_zone_format": "fname",
"max_interval": 240.0,
"offline_interval": 20,
"exit_zone_interval": 0.5,
"old_location_threshold": 3.0,
"old_location_adjustment": 0,
"gps_accuracy_threshold": 40.0,
"display_gps_lat_long": true,
"travel_time_factor": 0.66,
"tfz_tracking_max_distance": 8,
"passthru_zone_time": 0,
"track_from_base_zone": "home",
"track_from_home_zone": false,
"center_in_zone": false,
"discard_poor_gps_inzone": false,
"distance_between_devices": true,
"inzone_intervals": {
"iphone": 5.0,
"ipad": 120.0,
"watch": 15.0,
"airpods": 15.0,
"other": 120.0,
"no_mobapp": 15.0
},
"waze_used": true,
"waze_region": "row",
"waze_min_distance": 1.0,
"waze_max_distance": 1000,
"waze_realtime": true,
"waze_history_database_used": true,
"waze_history_max_distance": 20,
"waze_history_track_direction": "north_south",
"stat_zone_fname": "StatZon#",
"stat_zone_still_time": 0,
"stat_zone_inzone_interval": 30.0,
"stat_zone_base_latitude": 1,
"stat_zone_base_longitude": 0,
"display_text_as": [
"#1",
"#2",
"#3",
"#4",
"#5",
"#6",
"#7",
"#8",
"#9",
"#10"
],
"device_tracker_state_source": "ic3_fname",
"track_from_base_zone_used": false,
"away_time_zone_1_offset": 0,
"away_time_zone_1_devices": [
"none"
],
"away_time_zone_2_offset": 0,
"away_time_zone_2_devices": [
"none"
],
"mobapp_alive_interval": 30.0,
"log_level_devices": [
"all"
]
},
"sensors": {
"monitored_devices": [],
"device": [
"battery"
],
"tracking_update": [
"last_located",
"last_update",
"next_update"
],
"tracking_time": [
"travel_time",
"arrival_time"
],
"tracking_distance": [
"home_distance"
],
"track_from_zones": [
"tfz_zone_info",
"tfz_travel_time",
"tfz_arrival_time"
],
"tracking_other": [
"trigger"
],
"zone": [],
"other": [],
"excluded_sensors": [
"None"
]
}
}
}

my iCloud v3 also stopped working and I can't get it to log in again or anything..

my iCloud v3 also stopped working and I can't get it to log in again or anything..

This is pretty vague.

Was it working previously?
If yes, what changed?  (Did you update iC3, did you update HA?)
What version are you on?
What do the logs show?  (HA and iC3)

I was just able to make it work again, turns out my icloud account got locked (I don't know why) and I could unlock it by going on https://www.icloud.com/

This issue now happens again to me.
One suggetion, if login failed ones it should not hammer login so often to avoid account block.

The difficulty is figuring out what is causing this is it has never have happened to me and I have never seen any Log records that show the Apple account events from before it was locked to when it was locked.
I would appreciate it if someone whose account locked several times would do this:

Go to the Configure Settings > Page 2 > Format Parameters screen and set log level to ‘rawdata‘. Also select the Apple account’s owner in the Filter . This will limit the data being dumped to the log file to only the owners device instead of dumping the records for all devices being tracked.
Let it run this way until the account is locked.
When it happens, send the iCloud3 log files (icloud3-0.log, icloud3-1.log and icloud3-2.log) to<EMAIL_ADDRESS>The files will be big so you might want to zip them. If you zip them, you might have to change the file extension to something else (icloud3-logs.zip.data) to get around gmails filters.


[Event Hubs] Refactor client tests to use producer & consumer clients

This PR refactors the tests in client.spec.ts file to use EventHubProducerClient and EventHubConsumerClient classes instead of the internal EventHubClient class.
In order to do this, the each test case appears twice, once for the producer client, and another time for the consumer client.
This is part of a multiple series of code changes required to

have tests depend on public api surface where possible
reduce internal dependency on EventHubClient so that it can be eventually removed altogether

/azp run js - eventhubs-client - tests

/azp run js - eventhubs-client - tests

/check-enforcer evaluate

/azp run js - eventhubs-client - tests

/check-enforcer evaluate

/azp run js - eventhubs-client - tests


Add base_config() accessor function for NdJsonExec

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
I am trying to produce visual query plans in Ballista and this exec does not allow me to access the file scan config. The other file scan execs do.
Describe the solution you'd like
Add this method - see ParquetExec for example
Describe alternatives you've considered
Additional context

Not sure if this is helpful: https://github.com/apache/arrow-datafusion/blob/81b57948778cfa485d8b3f2c1fe4485f3966e8e4/datafusion/expr/src/logical_plan/plan.rs#L604-L633
https://docs.rs/datafusion/12.0.0/datafusion/logical_plan/enum.LogicalPlan.html#method.display_graphviz


add w3a-modal-sui-react

I found there's no example to connect to Sui chain.
So I implemented an exmaple to show how to work with sui in react.
Thanks for looking into my code, and hope it would help other people.
Please let me know if there's any imporper here.

Hi @yashovardhan , could you help to review these changes?

Currently we're looking for a different approach for Sui blockchain support. That being said, thanks a lot for this PR, this helps us understand the integration between Sui and Web3Auth.
Closing this for now, in favour of the new solution we're working towards.


Fix iOS Push notification crashes

Summary
Fix various sources of crashes when receiving push notifications on iOS
Ticket Link
https://mattermost.atlassian.net/browse/MM-51580
https://mattermost.atlassian.net/browse/MM-51579
Release Note
NONE

Cherry pick is scheduled.

Cherry pick is scheduled.

Error trying doing the automated Cherry picking. Please do this manually
+++ Updating remotes...
Fetching upstream
Failed to add the RSA host key for IP address '<IP_ADDRESS>' to the list of known hosts (/app/.ssh/known_hosts).
Fetching origin
Failed to add the RSA host key for IP address '<IP_ADDRESS>' to the list of known hosts (/app/.ssh/known_hosts).
+++ Updating remotes done...
+++ Creating local branch automated-cherry-pick-of-mattermost-mobile-#7237-upstream-release-2.3-1680182583
Switched to a new branch 'automated-cherry-pick-of-mattermost-mobile-#7237-upstream-release-2.3-1680182583'
Branch 'automated-cherry-pick-of-mattermost-mobile-#7237-upstream-release-2.3-1680182583' set up to track remote branch 'release-2.3' from 'upstream'.

+++ About to attempt cherry pick of PR #7237 with merge commit 05469207d73819c7604223009ef73236e89c29b8.

*** Please tell me who you are.

Run

  git config --global user.email<EMAIL_ADDRESS>  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'mattermod@mattermod-6595fd9b49-wqnql.(none)')
!!! git cherry-pick failed

+++ Aborting in-progress git cherry-pick.

+++ Returning you to the master branch and cleaning up.


Seaborn Star

Hello!  Thank you for the course to work through!  I wanted to send this code snippet for the author to take a look at.  I am using Python 3.9.5.  I believe it is an Anaconda build with math optimizations.
def seaborn_star(test = [-5, 5]):
    """This shape should maintain a symmetrical appearance
    test 1: xlim = [-5,5]
    test 2: xlim = [-50, 50]
    test 2: xlim = [-500, 500]
    """
    style.use('seaborn-poster')
    x,a = sym.symbols('x,a')
    expr = a/x
    p = symplot(expr.subs(a,1), (x, 5,-5), show=False)
    p2 = symplot(expr.subs(a,-1), (x, 5,-5), show=False)
    p3 = symplot(expr.subs(a,0), (x, 5,-5), show=False)
    pb = symplot(expr.subs(a,2), (x, 5,-5), show=False)
    pb2 = symplot(expr.subs(a,-2), (x, 5,-5), show=False)
    p.append(p2[0])
    p.append(p3[0])
    p.append(pb[0])
    p.append(pb2[0])
    p.ylim= test
    p[0].line_color = 'purple'
    p[1].line_color = 'darkblue'
    p[2].line_color = 'crimson'
    p[3].line_color = 'darkblue'
    p[4].line_color = 'purple'
    p[0].label = f'$y={sym.latex(expr.subs(a,1))}$'
    p[1].label = f'$y={sym.latex(expr.subs(a,-1))}$'
    p[2].label = f'$y={sym.latex(expr.subs(a,0))}$'
    p[3].label = f'$y={sym.latex(expr.subs(a,2))}$'
    p[4].label = f'$y={sym.latex(expr.subs(a,-2))}$'
    p.legend = True
    p.show()

Very nice function! Thanks for sharing.

Thank you.
On Mon, Dec 13, 2021 at 3:47 PM Mike X Cohen @.***>
wrote:

Very nice function! Thanks for sharing.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/PacktPublishing/Master-Math-by-Coding-in-Python/issues/1#issuecomment-992892238,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIW2UY3DKBE22FFG2FHCVLUQZLX5ANCNFSM5I4K6QDA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

--
Jesse Bacon


StaticSite V3 - Add the ability to disable the CloudFront auto generated URL

If the custom domain option is set to 'mydomain.com' than the autogenerated CloudFront URL should be disabled by default.
For SEO and potential other reasons, it would see like it should either be the default or at least provide another property to disable the CloudFront URL so that the hosted site does not have two separate URLs with identical content appearing to the search engines which can damage the ranking of the main domain.
I've done the same in Serverless Framework before migrating over to SST, so this would make a really great addition.
PROPOSED OPTION 1:
When I set a custom domain, then the CloudFront URL should not be accessible
PROPOSED OPTION 2:
When I set a custom domain, then there should be an attribute available to disable the autogenerated CloudFront URL

That's a good point. We'll take a look.

Releasing v3.3.33 with the feature - https://github.com/sst/sst/commit/a8be47cdaaf9532a255464bfd78cd6f0b4576287
If custom domain is set, the viewer request CloudFront function will return 403 for requests coming from the cloudfront domain.

You guys rock! Thank you


Refactor AdaptiveExpressions method GetStandardFunctions()

Fixes #4208
Description
Refactor AdaptiveExpressions method GetStandardFunctions()  to make the builtin functions be well organized
Specific Changes

Remove each function into the separate class to shrink the code lines
Use inheritance to easily create some specific evaluators(Stringtransform , number transform . etc.)
Provide optional construction parameters to create aliases for expression evaluator

Structure
GetStandardFunctions() method
private static IDictionary<string, ExpressionEvaluator> GetStandardFunctions()
{
            var functions = new List<ExpressionEvaluator>
            {
                new BuiltinFunctions.Accessor(),
                new BuiltinFunctions.Add(),
                new BuiltinFunctions.AddDays(),
                new BuiltinFunctions.AddHours(),
                new BuiltinFunctions.AddMinutes(),
                ...
                 new BuiltinFunctions.XPath(),
                new BuiltinFunctions.Year(),
            };

            var lookup = new Dictionary<string, ExpressionEvaluator>();
            foreach (var function in functions)
            {
                lookup.Add(function.Type, function);
            }
}

Functions screenshot

It would be nice if you can should a screenshot of the new structure, so that it's straightforward to understand

This one looks good to me now, @chrimc62  @cleemullins can you help take a look?

Looks good to me except missing documentation which I marked in comments.

In reply to: 653971640 [](ancestors = 653971640)

@cleemullins  @tomlm do you want to check again, or i can just take this once ChrisMc's comments is resolved. This new structure is very straightforward, each function is in it's own .cs file, and the registration part is about 100 lines of code.


Using JWT Decode without External Package

Current Behavior

Our gotrue package uses external JWT package

New Behavior

Uses our own minimalist JWT decode file

Why? Is there any performance improvements?

Actuallu there is no performance improvement, only reducing dependency

@anggoran Thanks for writing up this PR in an attempt to reduce dependency. Personally, I am not so confident if we should make this move as it creates more code for us to maintain.
With that note, I am going to close this particular PR, but please feel free to open PR/issues to discuss potential improvements of the library!


Collaboration: Unsloth + llm-course

Hey @mlabonne! Actually found this repo via Linkedin! :) Happy New Year!
Had a look through your notebooks - they look sick! Interestingly I was trying myself to run axolotl via Google Colab to no avail.
Anyways I'm the maintainer of Unsloth, which makes QLoRA 2.2x faster and use 62% less memory! It would be awesome if we could somehow collaborate :)
I have a few examples:

Mistral 7b + Alpaca: https://colab.research.google.com/drive/1Dyauq4kTZoLewQ1cApceUQVNcnnNTzg_?usp=sharing
DPO Zephyr replication: https://colab.research.google.com/drive/15vttTpzzVXv_tJwEk-hIcQ0S9FcEWvwP?usp=sharing
TinyLlama automatic RoPE Scaling from 2048 to 4096 tokens + full Alpaca dataset in 80 minutes. https://colab.research.google.com/drive/1AZghoNBQaMDgWJpi4RbffGM1h6raLUj9?usp=sharing (still running since TinyLlama was just released!)

Anyways great work again!

Hi @danielhanchen, cool I know Unsloth from r/LocalLlama. Do you have something particular in mind? We can continue the conversation on Twitter @maximelabonne if you don't mind.

thankiu I have same question

@mlabonne I'll bring the chat over to Twitter!

Unsloth has been added!


Error "No firebase admin specified"

I setup the node and added the Firebase Admin  SDK JSON to the config node. When I deploy the project, I receive the following errors:

/12/2020, 9:00:44 PMnode: Admin JSON
msg : error
"Error: Firebase app named "iot-alarm-system" already exists. This means you called initializeApp() more than once with the same app name as the second argument. Make sure you provide a unique name every time you call initializeApp()."
4/12/2020, 9:00:44 PMnode: Firebae Admin
msg : string[27]
"No firebase admin specified"

I do have a firebase admin specified and I believe it's setup correctly.   Here is a snapshot of my admin settings (deprecated some information).

This seems to be an issue when you have other Google Core IoT nodes and Firebase nodes installed that have the same Admin SDK Json authentication method.  Closing for now.

Hi @thanksmister !
Yes, if you use another node wih a Firebase admin node, you'll have some conflicts.
We're currently working on using a shared node between Firebase nodes. Which one are you using?
Thank you

I was using https://github.com/cyberflohr/node-red-contrib-google-iot-core/

Do you have any idea why this would call an initialization of Firebase? I looked a bit and it's not even dependent of firebase-admin

They both seem to use the new Admin SDK with JSON for authentication?


Firebase Emulator

Moves unit tests from using the production database to an emulator.
This PR sets up the framework for unit tests to test various firebase functions as well as use emulators for internal testing.
A big feature that this implements is the ability for the app to be able to connect to an emulator. This means that once the app is live, we will no longer have the need to use the production database for
To use the emulator, various environment variables must be set in .env. These define various places where the app/testing environment will connect. The only lines that need to be added are the emulators that are being connected to. For example, you can use the production auth service (recommended) while still using the firestore emulator service:
FIREBASE_EMULATOR_ADDRESS     = <IP_ADDRESS> # Change this to a real host address
FIREBASE_AUTH_PORT            = 9099 # Recommended to omit this line if using the app.
FIREBASE_FIRESTORE_PORT       = 8080
FIREBASE_CLOUD_FUNCTIONS_PORT = 5001
FIREBASE_STORAGE_PORT         = 9199

Note: campus wifi does not allow hosting, so in order to use the emulator on campus, the user must come up with a method to connect to the emulator via LAN or other methods.
The testing framework also mocks firebase/auth as the current implementation contains require cycles which mess with jest. Hopefully this changes in the future, but for now auth does not have full functionality in testing.

LOL THE CI TEST FAILED.
That's funny. Probably some setup failure.


Unable to modify Parameter in Authorization Request

Currently, I am encountering an issue when attempting to modify the redirect_uri parameter to redirect_url using configureTokenExchange within the getAccessToken() function of the CodeAuthFlow class. It seems that the parameters modification is not being applied correctly when making the authorization endpoint call.
I have been able to modify the headers successfully.
val flow = authFlowFactory.createAuthFlow(client)
flow.getAccessToken(
    configureTokenExchange = {
        this.url {
            parameters.remove("redirect_uri")
            parameters.append("redirect_url", "newParameter")
        }
    }
)

Despite this configuration, the redirect_url parameter does not appear to be correctly included in the request sent to the authorization endpoint. This discrepancy prevents the successful exchange of authorization code for an access token.
I appreciate any guidance or suggestions to resolve this issue effectively. Thank you.

Hi,
this is a POST request using form parameters.
If you want to alter the form parameters, i guess you have to set the whole body yourself using
setBody(FormDataContent(formParameters))
You may cast the existing body to FormDataContent, get all existing parameters from there and set a new body.
But the easiest way would propably be to use the correct redirect url in the first place :)
You can also just alter the redirectUri in the config used by the OpenIdConnectClient right before you cann getAccessToken.


Pinned icon now shows, even if authorLabel in nil

okay about the local variable. Since it doesn't change for the lifetime of the app, it really should be a static variable instead of a computed one. That way each cell doesn't have to take the hit to allocate one.
:+1:


Programmatic navigation: router.push and router.go in nuxtjs ?

Hi,
What is the right way to do router.push or router.go inside a function in Nuxt ?
thank you !

For example:
this.$router.push({
    path: '/auth/login'
})

Wow, that was fast.
Thank you !


CFG file with iso-8859-1 encoding or extend to other formats

Hello,
The Cfg class accept only simple ASCII or utf-8.

ASCII is default value.
utf-8 is detected automatically.

It should be great if one could choose the encoding format, other than these two.
By example, by passing endoding=''xxx in Comtrade constructor or in load method ?

Hi @vicnet,
Yes, I totally agree that it's great to have this option available. So I kept the current behavior as you listed and added the encoding parameter for all load methods we have as you suggested.
Try with the new version 0.0.9 changing `comtrade_obj.load('your_cfg_file.cfg', encoding='iso-8859-1') and let me know if it solves the issues you're having.
If you have available, and if it's possible, it would be nice to have an anonymous copy of the cfg file with the encoding you're currently having problems. I implemented a basic unit test for this case but I think it could be improved.
Thanks and let me know if I can close this.

Hello,
Thanks, for you patch.
It's working perfectly.
Regards,
Vicnet


Add height parameter to walletnotify message

Use %i in the command to include the height of the block containing the transaction.
I found myself wanting this when trying to perform an action on an incoming transaction while awaiting n block confirmations. Otherwise I have to perform multiple RPC calls to get this information.

looks good to me

I think the existing mechanism already has the chain tip fork problem, so if we're going to solve that problem, we should solve it for block/wallet notification mechanisms in general.
I'll add the appropriate -help text.

Oh, I see what you mean. In that case we have a couple of options:

add an additional parameter to disambiguate new from updated
skip the height on updated transactions
use a flag value (-1? 0?) for updated transactions

I tend to prefer unambiguous data, so my slight preference is the first option. All of these are easy enough to code and explain.

Something more like this you think?
int64_t nHeight = wtxIn.hashUnset() ? 0 : mapBlockIndex[wtxIn.hashBlock]->nHeight;
No extra parameter, no extra formatting token, present only when the user has asked for the height as a parameter, unambiguous and static flag value that I can document when I update -help?

Squashed and rebased.


Add code tour, see how it works

This is a pretty cool vs code extension, might be a nice helper for getting into the details of how Tina works. Really easy to use. I don't think we should actually use this example, but if we like this it'd be worth putting some time into.

I think would be really beneficial for folks forking the starter.
It's one thing to jump between reading docs/guides and getting familiar with a new code base.


feat: add color converter tool

Fixes #8
This PR adds a new component called "ColorConverter" which provides users with the ability to convert colors between different formats. The component provides a simple interface where the user can input a color in any format and the component will automatically convert it to other formats RGB, HSL, HSV, CMYK, HEX, and HTML.

Awesome! Thanks for the contribution!