High CPU Usage

On Nvidia Orin Nano, ldlidar node uses 100% of one core. This seems high for me since it's just parsing out serial input and publishing. Comparatively, nav2 uses less. Is there any way to reduce it? Lower publish rate or something? Maybe we should try to use static memory or maybe some external library like CUDA or something to speed it up?

OS: Ubuntu 22.04
ROS2 version: humble (nvidia docker image)
Jetson Orin Nano

I'm just using the stock launch file and parameters.

I am running same on RPI4, and I measured the cpu usage to be 10-12%. I also compared it with a previous driver, and found that it is about the same. So this must be a problem with your jetson or the docker image way of passing the serial data.


Show Gestational Age when hovering over pre-term measurements

We have had a clinician point out that it would be helpful to see the 'gestational age' when hovering over a point on the chart for a pre-term baby (< 37 weeks).
For example, DOB=10/01/23, Measurement Date = 10/01/23. Gestation = 36 weeks 0 day. The chart shows the 'adjusted' plot point as a cross and when you hover it says 'Corrected Age: undefined'. This was confusing to the clinician as they thought it was showing a 'corrected age'. Adding another measurement for same DOB and Measurement Date 28/02/23 does show 'Corrected Age: 3 weeks' which makes sense.
We have tested this in your Demo Chart site and it does the same, but unsure if this is by design.

Thanks for posting this. This relates to the chart component so moving this issue to that repository

this has been fixed in https://github.com/rcpch/digital-growth-charts-react-component-library/commit/2508fc0618defbdab0335ec466d359c138cf72a4 and a new patch published to rpm


Fix errors in deleting routes and route rules

During the reapply of nmstate templates, the mismatch in routes and route rules will result in deletion of some routes and route rules. The deletion of some of the routes conflicts with the addition of new entries. In order to avoid the conflict, when there is a difference between the existing route/route rules and the desired ones, the existing routes and route rules were flushed and the new entries were made.

recheck

recheck

recheck

recheck


Check shell return code in addition to output

When the rufo command does not exist, or outputs something with a non-success exit code, the current failure check considers the run as successful, replacing the original buffer with the error message.
By checking the command return code (v:shell_error), it correctly displays the message in the error buffer and keeps the original buffer intact.

@13k Nice, thank you! :+1:
I can confirm the behaviour described:
Before

After

@lucerion I suspect that the commit 60241f8 broke it. WDYT?

@splattael I've updated the PR, it was incorrectly assuming non-zero is an error, but rufo would exit with code 3 for "formatting would change the input". So I'm checking for status !=0 && status != 3.
Something still bugs me, though, that is the "first output line contains the word Error" check. If I'm formatting code that has Error in the first line, it will detect the output as an error, despite the status codes. I think it should only rely on the status codes, not the output.

Example:

@13k it's a hack that can be completely deleted and we can use exit codes only. When I've added it (#5) there is no exit codes in rufo (https://github.com/ruby-formatter/rufo/commit/068bf0b417f4b8a82c5b14f7d5858f5cdf42a713).

@lucerion @splattael Updated the PR. It now checks only the exit code.
Thanks for your feedback!

@13k LGTM :+1: but @lucerion should approve as well :green_heart:

@13k good job! Thank you!


shiftTime Helper (+raise gas limit)

a simple helper + test to shift time on an ETO to right before the next state transition.
NOTE:
I think, for this to be effective the gas limit has to be raised on our parity-clone as well, see PR
Neufund/parity-instant-seal-byzantium-enabled#25
While the current limit is at 10 million (https://ethgasstation.info/blog/ethereum-block-size/)
I chose to only raise to 8, so that we will be conscious of any changes to increase our contract size

please do not merge yet, I am seeing if i can refactor it to define that variable in one place only and then use it everywhere.
(but historically, this has been difficult to do in truffle.js, somehow)


Test runner refactorings: adapt to changes in psycopg2

Extract PostgreSQL connection logic into PgProtocol
This patch aims to:

* Unify connection & querying logic of ZenithPagerserver and Postgres.
* Mitigate changes to transaction machinery introduced in `psycopg2 >= 2.9`.

Now it's possible to acquire db connection using the corresponding
method:

```python
pg = postgres.create_start('main')
conn = pg.connect()
...
conn.close()
```

This pattern can be further improved with the help of `closing`:

```python
from contextlib import closing

pg = postgres.create_start('main')

with closing(pg.connect()) as conn:
    ...
```

All connections produced by this method will have autocommit
enabled by default.

I don't really understand what with closing does.

Basically, it means that a connection object will be closed after its with block has ended. Further reading.

Should we add a section to test_runner/README.md explaining what this does, and when to use it?

Will do.


Added Modali

Added modali modal-dialog component to the list of overlay components.

Checked in Safari and there's a noticeable content shift on modal open.

Hi @jcrowson can you please handle comment from @z-ax before integration?

@bluepeter @z-ax I've released a new version of Modali: v1.2.0.
It fixes the content shift bug, among other things. Thanks for picking up on this issue, and being so diligent. It goes to show you clearly care about the quality of the libraries in your list. 👍
I'd very much appreciate a re-review. Thanks for the support!

Nice work!


[8.x] New flag --requests -R to make:controller and make:model Commands

This PR adds a new flag to php artisan make:controller command, which creates FormRequest class and uses it immediately in the generated controller.
Problem
How I personally use Resourceful Controllers with Form Requests:

php artisan make:controller UserController --resource
php artisan make:request StoreUserRequest
php artisan make:request UpdateUserRequest
Go to the UserController and manually replace Illuminate\Http\Request with those new FormRequest classes

Why couldn't we generate it all at once?
This problem resonated with my Twitter audience, with 180+ likes on this Tweet.

My Proposed Solution (updated October 7)
Now, when you run php artisan make:controller UserController --resource --model=User --requests, it will generate two FormRequest classes: StoreUserRequest and UpdateUserRequest, and will replace them in the Controller.
A short version of --requests flag is -R, not to mix with -r for resources.
It is done by reusing the make:request command and calling it with appropriate class name.
This functionality works only together with --model flag, otherwise it would be impossible/hard to guess the name for the FormRequest classes.
Also, it works one "layer" above in the Model: php artisan make:model Project -mcrR would generate StoreProjectRequest and UpdateProjectRequest

Breaking changes
It shouldn't break any existing functionality, it's just a new flag. If that flag isn't used, it all falls back to the old default values.

Any other suggestions for improvement are welcome.

@PovilasKorop I personally only think you should include the requests version and not the single request. I typically would never create a single request to handle both create and update.

Yup, agreed, me too. Removed the singular --request.
Also, pushed the changes for make:model --requests flag like @tontonsb suggested, and for accepting -R as a short version.
@TomHAnderson will submit a PR to the docs then this PR is fully merged, then I will know which flag to put where in the docs.

Just to add two more ideas:

An interactive mode (-i), especially for beginners and devs that don't know yet what they want.
A wizard mode (-w) that determines the choices based on which items already exist and which namespaces the project already uses.

Slightly related, I tweeted about a proof of concept for artisan make:migration --interactive a while back:
https://user-images.githubusercontent.com/7202674/136399862-71bf8c85-678f-41a5-b05e-0b3073e14c94.mp4
I think a similar interactive mode for make:model would definitely improve the developer experience.

I have mainly been hesitating because this is somewhat related to and close to functionality I was considering building in a laravel/concepts package that was a generator building out an entire "concept"'s files in your application. Typically, related to a model.
So, php artisan make:concept Invoice generates controllers, requests, tests, events, and so on for that concept, and it also generated store and update requests like this PR does.
I've been debating if I want to pursue that package or not so that has caused the hesitation here.

I have mainly been hesitating because this is somewhat related to and close to functionality I was considering building in a laravel/concepts package that was a generator building out an entire "concept"'s files in your application. Typically, related to a model.
So, php artisan make:concept Invoice generates controllers, requests, tests, events, and so on for that concept, and it also generated store and update requests like this PR does.
I've been debating if I want to pursue that package or not so that has caused the hesitation here.

I vote for this solution so I can stop maintaining Larawiz.

@PovilasKorop Thanks for this PR!
Would you consider a follow-up release to create the Request files in the correct subfolder? Saves time to move 2 files and edit 3 of them. Or is that blocked by default Laravel behavior?
Simple example
php artisan make:model "Accounting\CustomerAddress" -crmfR
This will create a new model under App\Models\Accounting
The Controller is created under App\Http\Controllers
The Requests are created under App\Http\Requests

@dragonfly4 I thought about it but had a doubt if everyone would want to create subfolders for the requests exactly as for models.
Also, it would require quite a lot of work to make it properly, for now I moved on to other work and don't have that much time, sorry


randomise loading messages

supersede https://github.com/silverstripe/deploynaut/pull/857/

could you also do this for "Requesting abort" on the abort button? :)

I tried adding it to the abort button, but it makes less sense since it's a "momentary" button that then goes back to the 'Abort' state. I also don't want to joke around with abort, since the user is probably a bit stressed at that point.


remove share buttons in posts

Hi,
Thanks for the great template!
Wondering how to remove the share buttons within posts?
Thanks!

problem solved:
remove
<div class="share-buttons">
        {% include share.html %}
      </div>

under
in post.html in _layouts


Search News

Hi,
Can you give an example on how to search just news using this wrapper?
Thanks

You can't, except if you modify the QUERY_URL. See the Azure datamarket page for examples of how to modify the URL. The base is https://api.datamarket.azure.com/Bing/Search/v1/News and a simple query for 'Angela Merkel' looks like this: https://api.datamarket.azure.com/Bing/Search/v1/News?Query=%27angela%20merkel%27.

Old thread, I know. But the new version will handle images, videos, as well as news (specifically via 8e3ed75b02418403385c2be3441ce4b0d8ce94bc) @parangsaraf


[문서 번역] migrating from 4 or 5

@iChenLei merge please :)

Vercel auto deploy failed, I will retry later. And all translation work finished ? What a awesome work ! Thanks you @kimyoungjae96  and all korean documentation translatation volunteers !

Vercel auto deploy failed, I will retry later. And all translation work finished ? What a awesome work ! Thanks you @kimyoungjae96 and all korean documentation translatation volunteers !

Thanks to you, I was able to finish the translation. Thank you so much for trusting me and helping me a lot. If there are any modifications or changes in the future, I will apply them. :)

This is the meaning of the open source, regardless of nationality or race. Thank you again ! The final PR  was successfully deployed to ko.mobx.js.org 🎉

@kimyoungjae96 Thanks for awesome contribution, I invite you become a outside collaborator for mobxjs/ko.mobx.js.org. It means you have the write permission, you can merge PR by yourself. ❤


Add an int() stdlib function to KCL

We currently have no way in KCL to go from a floating point to an integer type, but it should be pretty trivial to create a standard library function to coerce a passed in number.

For more context this is useful for functions which require an integer parameter

What happens if the floating point number is -1.5? There are many options for what to do, including error out because it's not representable as an integer. In Rust, for example, you first have to make sure it doesn't have a fractional part by calling one of these. My impression is that KCL is a little more fast and loose. But please at least consider the consequences first 🙇

-1 is a valid integer though? And functions which can't take negatives would error?

Yes, there are many ways to round. There isn't a right answer, which is why all languages expose many ways to do it.

Yeah I have no preference on how we go about it. I'd be perfectly happy with using floor or ceil functions exclusively and foregoing an int function entirely (and closing this issue) if I could pass the output of all of those functions into a function that requires an integer parameter like patternTransform does for its iteration counts.

I originally missed the Slack thread about this. I think the consensus was that floor, ceil, and family are float -> float. Only this new function is float -> int, i.e. returns an integer.


Add St John the Baptist day for Catalonian calendar

Adds missing public holiday for Catalonian calendar, see here for reference: https://www.timeanddate.com/holidays/spain/sant-joan

[x] Tests with a significant number of years to be tested for your calendar.
[x] Changelog amended with a mention describing your changes. Note Please do NOT change the version number here. It's the project maintainers' duty.

Another source, the Barcelona City Council site showing that June 24th is a public holiday in Catalonia region: https://ajuntament.barcelona.cat/calendarifestius/en/

Planning to merge this and make a bugfix release today. Stay tuned!

version 15.2.0 was released and publish on PyPI, happy upgrading!

https://pypi.org/project/workalendar/15.2.0/
https://github.com/peopledoc/workalendar/releases/tag/15.2.0


Sweep: Flutter build error: flutterVersionCode property not found

Flutter version code not set in Gradle build file

Sweep: fix gradle file in app/build.gradle

Cache cleared & fixed Gradle error in main branch


accept existing iframe by id

At AJ English we usually already have the iframe in the page, all we need is to augment it with pym.js. This change allows you to skip the container element and the iframe creation when the supplied id points to an iframe element.
Example:

//override iframe's @src
var pymParent2 = new pym.Parent('f2', 'frame.html?foo=bar', {});

//use iframe's @src
var pymParent3 = new pym.Parent('f3', null, {});

Note that the framed content requires pym.Child(), this is not a solution for https://github.com/nprapps/pym.js/issues/32

FWIW, I'm a big fan of being able to Pym-enhance an existing iframe. It's actually how I expected it to work originally.


Update Meta “authors”

Automatically generated by Netlify CMS

👷 Deploy Preview for badinfluencecoder processing.

Name
Link

🔨 Latest commit
f276a404157fc73019b804e3f6252a356b21d2b3

🔍 Latest deploy log
https://app.netlify.com/sites/badinfluencecoder/deploys/63a2c7325190be0009fe47ba


Breaks out the vsphere cpi build into release branch builds

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve

/lgtm
/approve


Refactor ConfigModel Construction in StandardActivity

This will have a refactoring of StandardActivity to provide proper scoping of ConfigModel construction along with providing advice and analysis about parameters.
We will try to solve all of these in this PR:

[ ] #1808
[ ] #1609
[ ] #1187
[x] #1182
[ ] #1003
[ ] #451
[ ] #117
[ ] #21

--advisor=validate or --parameter-model will be used to show activity, template, and model parameters use.


[1.20.1] Weird bug with Dragon armor

When trying to do creative flight with dragon armor. it does this weird FOV bug and it doesnt let me fly up but slowly make me descend.
I even tried to go into a Single player world and same issue exists.
Using latest version of Gobber on latest Forge 1.20.1
Update: This happens only in certain dimensions? I think only in Vanilla dimensions so far.
https://github.com/user-attachments/assets/32eec025-2bc4-47c6-9740-f5a527fe4a14

hmm, yeah it looks like some other mod is trying to fight the flight mechanism.
please post a log so I can see what else you are running and if there are any errors

This is the Warn i get everytime i try to fly

is this on a server?

No, its this is on my client and on the server it doesn't log anything. It logs only that on the client side. So it's probably not a server issue.

Sorry hit the close button by mistake

Can you post a full log of when you are flying?

debug.log
latest.log
I uploaded both logs for you. I dont know what exactly to look for in the logs since it's not caused by gobber mod itself.

Can you include a log that shows your startup and the mods you are loading?

debug.log
latest.log
I uploaded them again. I launched Minecraft and didnt go to any worlds or didnt click anything. It should be just loading.

You might try without Embeddium or any other performance enhancing mods.  They tend to skip player ticks to improve performance.

I have been testing around and it is for sure performance enhancing mod. Idk which one yet. Do you think rubidium would do the same?

I tried removing all of them, on the server as well. Didn't seem to fix it sadly. I dont know what's causing it. Its really weird.

  Maybe I can try playing around with it.

  So I don't think this is strictly a dragon armor issue.  The armor simply enables vanilla creative flight, so I tried playing in create and using flight, it does the same stutter on take off and drops out.   I still don't know what would cause this, but I believe something in the pack is interfering with vanilla creative flight, which in turn affects the dragon armor.

Okie Dokie.  Good luck.

So, I removed even more performance enhancing mods. I forgot to remove AttributeFix mod and that seems to have fixed the issue. As for right now. I am not 100% sure.

Did you uncover anything else about possible causes?

Sadly I have not. But my big assumption is that a mod can be causing it, especially if its a "tick improving" or along those words.

I'm having the same issue with a custom modpack I'm putting together.  Anything I can send along to compare?

Having the same issue. For some reason it also disables the water breathing effect on the helmet. Weird stuff.

Having same issue on Windows 10, Java17/Java21, Minecraft 1.20.1, Forge 47.2.18/47.3.5

What issue are you experiencing?  Several were mentioned in this issue.

@chuigda can you post your list of mods?
I tried adding GeckoLib 4.4.7 for Forge and no issues.

@chuigda Also, check to make sure armor water breathing is set to true in the config.

What issue are you experiencing? Several were mentioned in this issue.

After trying to take off by pressing space key twice, it doesn't let me fly up but slowly make me descend and the screen jitters.
Sometimes for the first several attempts after entering the game I'll successfully take off, but then the issue comes. Pressing space key twice again during descending sometimes resolve the problem.

Can you post your list of mods?

AppleSkin 2.5.1 (known irrelevant)
ArmorPoints++ 1.20-3.1.1 (known irrelevant)
AttributeFix 21.0.4
Butcher 2.5.1
Caelus API 3.2.0
Catalogue 1.8.0
Configured 2.2.3
CosmeticArmorReworked 1.20.1-v1a
Curious API 5.9.1
Durability Tooltip 1.1.5
Elytra Slot 6.4.3+1.20.1
Embeddium 0.3.30+mc1.20.1
Farmer's Delight 1.20.1-1.2.4
GeckoLib 4 4.4.7
Just Enough Items <IP_ADDRESS>
Journeymap 5.10.1
LesRaisinsAddon 0.2.2
YDM's Mob Health Bar 2.3.0
SuperMartijn642's Config Library 1.1.8
Times & Classics Guns: Zero 1.0.2
Vampirism 1.10.9

I tried adding GeckoLib 4.4.7 for Forge and no issues.

Sorry my badness. I did not test very throughly. I'll take more experiments.

Having this same problem rn but for me it only breaks in my server, singleplayer works normally.
Looking at the mod list of the last post, the only mods we have in common would be:
• Caelus API/Elytra Slot
• Cosmetic Armor Reworked
• Curios
• Gecko Lib
• JEI
• Vampirism
• SuperMartijn642's Config Library
• Embeddium

I had this issue and solved it!
Trouble Shooting
So, I grinded away and finally made the armour to also be met with that weird stuttering. I compared similar mods to what I had installed for a multiplayer server I'm on and got to testing. Went into single player, tested - had the stuttering issue even in creative if i equipped the armour. I turned all the mods that I had that others here had off to begin with and could fly in my single player world, clearly onto something. One by one flipped them on. Narrowed it down to a couple, kept flipping them on until... All of them were on and I could still fly. I, very confused, hopped on my multiplayer server and? It didnt work. But now my single player was always letting me fly with it. I could no longer test and have no idea what I did that made it so I could fly in singleplayer.
My Solution
Had some similar issues with other mods in our pack on our multiplayer server so tried out a fix we did for a different mod of rolling back the version. I rolled back by one (now on 1.20.1-2.8.7, as opposed to -2.8.9) and hopped on the server. Despite the server running -2.8.9, it let me join still and finally I could fly. Hopefully this helps someone.

I had this issue and solved it!
Trouble Shooting
So, I grinded away and finally made the armour to also be met with that weird stuttering. I compared similar mods to what I had installed for a multiplayer server I'm on and got to testing. Went into single player, tested - had the stuttering issue even in creative if i equipped the armour. I turned all the mods that I had that others here had off to begin with and could fly in my single player world, clearly onto something. One by one flipped them on. Narrowed it down to a couple, kept flipping them on until... All of them were on and I could still fly. I, very confused, hopped on my multiplayer server and? It didnt work. But now my single player was always letting me fly with it. I could no longer test and have no idea what I did that made it so I could fly in singleplayer.
My Solution
Had some similar issues with other mods in our pack on our multiplayer server so tried out a fix we did for a different mod of rolling back the version. I rolled back by one (now on 1.20.1-2.8.7, as opposed to -2.8.9) and hopped on the server. Despite the server running -2.8.9, it let me join still and finally I could fly. Hopefully this helps someone.

Ty my friend, going back to 2.8.7 worked perfectly for me.
I feel kinda dumb for not thinking of doing that before LMAO.


Support for transformers Trainer

Is there a way to use this directly on a transformers Trainer? Are there any plans to include it?

Both approaches are different: the Trainer already does everything accelerate has to offer, but you can't customize your training loop as easily.


fix: add codeowners file

Ok. I think since I do not have access to the repository I cannot be made owner. Please ignore then

FYI @machi1990 I will be making this new team to simplify reviews that have OpenAPI files. Once team is created I will be looking to create codeowners in kas-fleetshard as well

Ah.. it is write access then.. Ok. Bad idea. CLosing

@wtrocki it looks like individuals need read access, but teams need write. I'm not sure why the difference. I think it's still achievable with the team members listed out.

It is still failing but I have write access. I would leave that for now considering that we might get new community for project sooner than later.


Xamarin.Firebase.iOS.Analytics - framework not found GoogleAppMeasurement when building on Windows

Hi,
when adding Xamarin.Firebase.iOS.Analytics and building on Windows with a paired Mac I receive the following error:

Severity	Code	Description	Project	File	Line	Suppression State
Error		linker command failed with exit code 1 (use -v to see invocation)	MyProject.iOS
Error		framework not found GoogleAppMeasurement	MyProject.iOS
Error		Native linking failed. Please review the build log and the user flags provided to gcc: -ObjC -lc++ -lsqlite3 -lz -ObjC -lc++ -lsqlite3 -lz	MyProject.iOS
Error		warning: directory not found for option '-FC:/Users/chris/AppData/Local/XamarinBuildDownloadCache/GAppM-6.4.1/Frameworks'	MyProject.iOS

Microsoft Visual Studio Enterprise 2019 Version 16.6.0 (Windows)
Visual Studio for Mac Enterprise Version 8.6 (build 4520) (Mac)
Xamarin.Forms <IP_ADDRESS>0
Xamarin.Firebase.iOS.Analytics 6.4.1

When building directly on the Mac it works though.

C:\Users\chris\AppData\Local\XamarinBuildDownloadCache\ contained GAppM-6.4.1.tgz. Manually extracting did the trick.

Hello,
I do have the same issue but on macOS.
When creating new project - everything is okay and running just fine. But after adding Firebase.iOS packages - I get this error of missing GoogleAppMeasurement framework. The Cache folder is empty.
Xamarin.Forms version - 5

Hello,
I do have the same issue but on macOS.
When creating new project - everything is okay and running just fine. But after adding Firebase.iOS packages - I get this error of missing GoogleAppMeasurement framework. The Cache folder is empty.
Xamarin.Forms version - 5

C:\Users\chris\AppData\Local\XamarinBuildDownloadCache\ contained GAppM-6.4.1.tgz. Manually extracting did the trick.

Thanks @Dresel
This saved me a lot of research :)

C:\Users\chris\AppData\Local\XamarinBuildDownloadCache\ contained GAppM-6.4.1.tgz. Manually extracting did the trick.

This saved me, many thanks


Growl notification on new event (tweet)?

Is it possible to notify new event (any new tweet or from a particular follower) with Growl notification? (terminal notifier on mac)

+1


Prune +1

Currently
GlaiveÐ - Today 04:36: one
GlaiveÐ - Today 04:36: two
GlaiveÐ - Today 04:36: tree !!!
GlaiveÐ - Today 04:36: .prune 3

After:
GlaiveÐ - Today 04:36: one

Can you add one more to Nadeko for it removes all the desired elements ? :#

no sorry, its not backwards compatible, people will screw up :) always add 1 to the number you want to delete


Scroll to focused element

Is there a way to make it scroll to currently focused element?

This is issue #1 which I haven't found a solution for yet. I need to ask in the Elm UI Slack room, I guess.


bugfix: fix diskquota test case

Ⅰ. Describe what this PR did
fix TestRunWithDiskQuotaForLog test case, remove add group and user.
Ⅱ. Does this pull request fix one issue?

NONE
Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗？)
It just fix test case bug.
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews
Signed-off-by: Rudy Zhang<EMAIL_ADDRESS>

lgtm


Remove the UI Progress Updates example

Bug Report
The Game of Life example shows how to do continuous updates. There is no need to have it shown in two examples. Some things to consider:

The Game of Life doesn't do cancellation. Consider adding it.
Mention in the example Readme that the Game of Life example shows how to do UI progress updates.

AB#2594787

Let's also remove sample_streaming_measurement. It was added to support automated tests, but now the tests have a fork of this code.


Malformed version number: 3.0b1

I got a linker error (Xcode 7 beta4) that this version number was not in a.b.c.d format after pod updating my project last night. I had to pin to the previous commit on this branch.

I'm unable to reproduce this issue. Is it a CocoaPods only issue?


Binaries with inserted commands do not round-trip

Attempting to insert a load command into a binary produced by ktool after previously inserting a load command does not work.
To reproduce, run the following:
$ ktool insert --lc load --payload libFirst.dylib --out FirstOutput Target
$ ktool insert --lc load --payload libSecond.dylib --out SecondOutput FirstOutput

This results in the following error:
Traceback (most recent call last):
  File "/opt/homebrew/bin/ktool", line 866, in <module>
    main()
  File "/opt/homebrew/bin/ktool", line 356, in main
    args.func(args)
  File "/opt/homebrew/bin/ktool", line 567, in insert
    image = process_patches(image)
  File "/opt/homebrew/bin/ktool", line 407, in process_patches
    return ktool.reload_image(image)
  File "/opt/homebrew/lib/python3.9/site-packages/ktool/ktool.py", line 55, in reload_image
    return load_image(image.slice)
  File "/opt/homebrew/lib/python3.9/site-packages/ktool/ktool.py", line 84, in load_image
    return Dyld.load(macho_slice, load_symtab=load_symtab, load_imports=load_imports, load_exports=load_exports)
  File "/opt/homebrew/lib/python3.9/site-packages/ktool/dyld.py", line 289, in load
    image = Image(macho_slice)
  File "/opt/homebrew/lib/python3.9/site-packages/ktool/dyld.py", line 138, in __init__
    self.macho_header: ImageHeader = ImageHeader.from_image(macho_slice=macho_slice)
  File "/opt/homebrew/lib/python3.9/site-packages/ktool/dyld.py", line 77, in from_image
    raise ex
  File "/opt/homebrew/lib/python3.9/site-packages/ktool/dyld.py", line 73, in from_image
    load_cmd = Struct.create_with_bytes(LOAD_COMMAND_MAP[LOAD_COMMAND(cmd)], cmd_raw)
  File<EMAIL_ADDRESS>line 384, in __call__
    return cls.__new__(cls, value)
  File<EMAIL_ADDRESS>line 702, in __new__
    raise ve_exc
ValueError: 791555631 is not a valid LOAD_COMMAND

Some testing on my end reveals this doesn't seem to depend on the binaries themselves.

Fixed in 963e41c

Fix published in 1.3.0


Coordinator can release a csv file to be processed into the CEN2 database

At that point the Coordinator does any final validations and when satisfied indicates to CEN2 that the csv file can be processed into the database.

Writing an overview document to describe how it works.

The incorporation process is documented
https://drive.google.com/file/d/12uuSmqTHwVwU2i-OvvhaIrLkL17CvWPZ/view?usp=sharing

Tested and worksd OK.
Documentation included in October version 1.2 of Handbook
Geoff


Swift 3.1 support

Please change M_PI to Double.pi to remove compiler warnings!

This was fixed in commit d96a23d


Blockquote attribution / citation

> denotes a <blockquote> in Markdown/Djot

The blockquote element represents a section that is quoted from another source.
Content inside a blockquote must be quoted from another source, whose address, if it has one, may be cited in the cite attribute.

— W3C HTML spec, https://html.spec.whatwg.org/multipage/grouping-content.html#the-blockquote-element
As a user, I want syntax explicitly support attributing and citing blockquotes. This not only matches the HTML spec closer, but it's good to cite your sources! With explicit syntax it would be much easier to support styling that author information instead of it being in some generic <p> that can't reasonable be selected (made up CSS selector: blockquote + p:has(:where(text-begins-with("—"), text-begins-with("--"))) or the last paragraph inside if nested.  The point being having a consistent pattern will make it easier to group together with the blockquote and handle the blockquote accordingly instead of using ad-hoc conventions.

Prior art: Asciidoctor
.AsciiDoc Block syntax
[quote,Monty Python and the Holy Grail]
____
Dennis: Come and see the violence inherent in the system. Help! Help! I'm being repressed!

King Arthur: Bloody peasant!

 Did you hear that? Did you hear that, eh? That's what I'm on about! Did you see him repressing me? You saw him, Didn't you?
____

.AsciiDoc Markdown-style
> I hold it that a little rebellion now and then is a good thing,
> and as necessary in the political world as storms in the physical.
> -- Thomas Jefferson, Papers of Thomas Jefferson: Volume 11

That said, — (em dash) seems to be the preferred symbol for quotation attribution and Djot uses triple hyphen, ---, for that symbol (and base AsciiDoc uses --).
For rendering, it still seems a bit unclear if attribution should live inside or outside of the <blockquote>, wrapped in a <div> or in a <figure> with <figcation> to cite (and there's the <cite> tag itself).

This may also tangentially relate to https://github.com/jgm/djot/issues/28#issuecomment-1535554065 if captions were generalized:
> I hold it that a little rebellion now and then is a good thing,
> and as necessary in the political world as storms in the physical.
^ Thomas Jefferson, _Papers of Thomas Jefferson_. Volume 11

I opted for that option, with a modified version of the Djot reader, in my Djot for SILE renderer (then styling such quotes as "epigraphs") -- but this is admittedly a workaround to fit my typesetting needs, until some consensus is reached).

FWIW I started implementing something similar in my own markdownish language using a tilde:
> Something intelligent said about markup languages
~ Not me

The text after the tilde can contain other syntax elements like citations etc. (so you could have something like ~ [+@foo, p. 33] as per #32).


Issue using Python 3.13

Describe the bug
A clear and concise description of what the bug is.
Error Stacks
../../../.cache/pypoetry/virtualenvs/rp-python-sdk-V_ZVmfOb-py3.13/lib/python3.13/site-packages/authlib/jose/__init__.py:14: in <module>
    from .rfc7517 import Key, KeySet, JsonWebKey
../../../.cache/pypoetry/virtualenvs/rp-python-sdk-V_ZVmfOb-py3.13/lib/python3.13/site-packages/authlib/jose/rfc7517/__init__.py:10: in <module>
    from ._cryptography_key import load_pem_key
../../../.cache/pypoetry/virtualenvs/rp-python-sdk-V_ZVmfOb-py3.13/lib/python3.13/site-packages/authlib/jose/rfc7517/_cryptography_key.py:1: in <module>
    from cryptography.x509 import load_pem_x509_certificate
../../../.cache/pypoetry/virtualenvs/rp-python-sdk-V_ZVmfOb-py3.13/lib/python3.13/site-packages/cryptography/x509/__init__.py:7: in <module>
    from cryptography.x509 import certificate_transparency, verification
../../../.cache/pypoetry/virtualenvs/rp-python-sdk-V_ZVmfOb-py3.13/lib/python3.13/site-packages/cryptography/x509/certificate_transparency.py:11: in <module>
    from cryptography.hazmat.bindings._rust import x509 as rust_x509
E   pyo3_runtime.PanicException: Python API call failed

To Reproduce
The only thing I'm doing is importing a library:
from authlib.jose import JsonWebSignature

Expected behavior
It shouldn't fail (this code works in 3.12)
Environment:

OS: Ubuntu
Python Version: 3.13
Authlib Version: 1.3.2

According to your error stack, it seems cryptography's issue. Can you upgrade cryptography?
Also, if you want to use the jose module, I suggest that you using https://jose.authlib.org/en/migrations/authlib/

Hi @lepture , the only dependencies in my project I have are these:
[tool.poetry.dependencies]
python = "^3.12"
requests = "^2.32.3"
authlib = "^1.3.2"

I've now added cryptography version 43.0.1, but I'm still getting a similar error:
../../../.cache/pypoetry/virtualenvs/rp-python-sdk-V_ZVmfOb-py3.13/lib/python3.13/site-packages/authlib/jose/__init__.py:14: in <module>
    from .rfc7517 import Key, KeySet, JsonWebKey
../../../.cache/pypoetry/virtualenvs/rp-python-sdk-V_ZVmfOb-py3.13/lib/python3.13/site-packages/authlib/jose/rfc7517/__init__.py:10: in <module>
    from ._cryptography_key import load_pem_key
../../../.cache/pypoetry/virtualenvs/rp-python-sdk-V_ZVmfOb-py3.13/lib/python3.13/site-packages/authlib/jose/rfc7517/_cryptography_key.py:1: in <module>
    from cryptography.x509 import load_pem_x509_certificate
../../../.cache/pypoetry/virtualenvs/rp-python-sdk-V_ZVmfOb-py3.13/lib/python3.13/site-packages/cryptography/x509/__init__.py:7: in <module>
    from cryptography.x509 import certificate_transparency, verification
../../../.cache/pypoetry/virtualenvs/rp-python-sdk-V_ZVmfOb-py3.13/lib/python3.13/site-packages/cryptography/x509/certificate_transparency.py:11: in <module>
    from cryptography.hazmat.bindings._rust import x509 as rust_x509
E   ImportError: /home/runner/.cache/pypoetry/virtualenvs/rp-python-sdk-V_ZVmfOb-py3.13/lib/python3.13/site-packages/_cffi_backend.cpython-313-x86_64-linux-gnu.so: undefined symbol: **_PyErr_WriteUnraisableMsg**

I saw the jose module, but after reading the documentation, it wasn't clear to me why I'd use that, why it exists, how it's different. I can give it a go though.

I've migrated the code now to jose, and that gave some issues. It seems the OctKey doesn't like it when my key looks like this:
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhki.........4XiTRA=
-----END PRIVATE KEY-----

This wasn't an issue with the old code. Another issue I ran into, which I'm not sure how to fix, is how to use PS256?
My current code looks like this:
    cleaned_key = config.signing_key.replace("-----BEGIN PRIVATE KEY-----", "").replace("-----END PRIVATE KEY-----", "").strip()
    key = OctKey.import_key(cleaned_key)
    header = {'alg': 'PS256', 'kid': config.signing_kid}
    client_assertion_jwt = jws.serialize_compact(header, json.dumps(client_assertion_payload), key)

And it's throwing an error:
Algorithm of "PS256" is not allowed

Okay, after reading this: https://jose.authlib.org/en/guide/algorithms/, I've given it another shot:
Now with using RSA Key instead of OctKey:
    cleaned_key = config.signing_key.replace("-----BEGIN PRIVATE KEY-----", "").replace("-----END PRIVATE KEY-----", "").strip()
    key = RSAKey.import_key(cleaned_key)
    header = {'alg': 'PS256', 'kid': config.signing_kid}
    client_assertion_jwt = jws.serialize_compact(header, json.dumps(client_assertion_payload), key)

Here, I'm getting:
Could not deserialize key data. The data may be in an incorrect format, it may be encrypted with an unsupported algorithm, or it may be an unsupported key type (e.g. EC curves with explicit parameters). Details: ASN.1 parsing error: unexpected tag (got Tag { value: 13, constructed: false, class: Application }

If I remove that cleaning part, I'm getting this:

key = RSAKey.import_key(config.signing_key)
header = {'alg': 'PS256', 'kid': config.signing_kid}
client_assertion_jwt = jws.serialize_compact(header, json.dumps(client_assertion_payload), key)

I'm getting:

Algorithm of "PS256" is not allowed

Any suggestion would be appreciated.

Ah, this seems to be caused by user error: I was using the default registry, and I've updated to a new registry, which made things pass:
    # See https://jose.authlib.org/en/guide/registry/
    registry = JWSRegistry(algorithms=["PS256"])

    # cleaned_key = config.signing_key.replace("-----BEGIN PRIVATE KEY-----", "").replace("-----END PRIVATE KEY-----", "").strip()
    key = RSAKey.import_key(config.signing_key)
    header = {'alg': 'PS256', 'kid': config.signing_kid}
    client_assertion_jwt = jws.serialize_compact(header, json.dumps(client_assertion_payload), key, registry = registry)

Unfortunately, the code still doesn't work with Python 3.13.
I have this as my dependencies:
[tool.poetry.dependencies]
python = "^3.12"
requests = "^2.32.3"
authlib = "^1.3.2"
cryptography = "^43.0.1"
joserfc = "^1.0.0"

And with the above code, I'm getting this error:
undefined symbol: _PyErr_WriteUnraisableMsg

Turns out, this is caused by an older version of CFFI. I was using 1.16.0, when I explicitly use CFFI 1.17.1, this fixes the issue. See https://github.com/python-cffi/cffi/issues/23.
I can confirm our code now works on 3.12 and 3.13.


[Refactor] Add use-override in clang-tidy

What type of PR is this：

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

starrocks_be_unittest succeeded.


Alacritty v0.4.0 crashes on macOS when maximized with no decorations in alacritty.yml

This works fine in v0.3.3.
System
OS: macOS
Version: alacritty 0.4.0 (b115b90)
I just installed via the DMG on the releases page.
Logs
The output from /Applications/Alacritty.app/Contents/MacOS/alacritty -vv
Created log file at "/var/folders/4l/52prl3_54bxfpsqpnllff_ch0000gp/T/Alacritty-14660.log"
[2019-12-18 13:09] [INFO] Welcome to Alacritty
[2019-12-18 13:09] [INFO] Configuration loaded from "/Users/gabe/.config/alacritty/alacritty.yml"
[2019-12-18 13:09] [DEBUG] Estimated DPR: 2
[2019-12-18 13:09] [DEBUG] Estimated Cell Size: 13 x 26
[2019-12-18 13:09] [DEBUG] Estimated Dimensions: None
zsh: illegal hardware instruction  /Applications/Alacritty.app/Contents/MacOS/alacritty -vv

I reduced the issue to the following ~/.config/alacritty/alacritty.yml file:
window:
  startup_mode: Maximized
  decorations: none

If I change either setting (e.g. if I set startup_mode to Fullscreen, or if I change decorations to buttonless), it works fine.

duplicate of #2877

Yep, you're right. Closing. Thanks @kchibisov!


Fix formating

Hi @sadortun
Your PR has been merged. Changes from PR will be synced to the public repository in a few days. Thank you.

PR has already been merged into master.
Thank you!


"Search Help" - Bad selection color

https://github.com/godotengine/godot/commit/9f8e2d5c5bb0ab56630768530025e9e36c4bd445

If someone works in a bright environment the selection color(black) is almost not visible on the greyish background. (thinking maybe I should look for a basement to solve this issue thinking )

I found that replacing all instances of "selection_color" with another color in editor/editor_help.cpp worked (lines 1784, 1866, 1932, 1951).

It points to a specific path "text_editor/theme/selection_color".
I don't think using a different name is a good idea.
The setting in the editor is missing too so I added it.
I am not sure if this is right but it works.
https://github.com/godotengine/godot/blob/master/editor/editor_settings.cpp#L360
_initial_set("text_editor/theme/selection_color", Color::html("006400"));
Replacing all 4 lines from @ComradeSparklePony
https://github.com/godotengine/godot/blob/master/editor/editor_help.cpp#L1784
class_desc->add_color_override("selection_color", EditorSettings::get_singleton()->get("text_editor/theme/selection_color"));
What would be a good color default color?

What would be a good default color?

You could try a semi-transparent grey color such as Color::html("40808080"), this way, it works on both dark and light backgrounds. However, it will become less visible in low-contrast themes (as the background color becomes closer to gray).


github workspace setting not working

This is not a bug for Thanos itself. But maybe related to the settings we have here https://github.com/thanos-io/thanos/tree/main/.devcontainer.
Can be reproduced by creating a new code space on main.

Creation log:

=================================================================================
2023-10-19 21:46:59.771Z: Configuration starting...
2023-10-19 21:46:59.827Z: Cloning...
2023-10-19 21:46:59.872Z: $ git -C "/var/lib/docker/codespacemount/workspace" clone --branch "main" --depth 1 https://github.com/thanos-io/thanos "/var/lib/docker/codespacemount/workspace/thanos"
2023-10-19 21:46:59.973Z: Cloning into '/var/lib/docker/codespacemount/workspace/thanos'...
2023-10-19 21:47:03.207Z: git process exited with exit code 0
2023-10-19 21:47:03.249Z: $ git -C "/var/lib/docker/codespacemount/workspace/thanos" config --local remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
2023-10-19 21:47:03.266Z: git process exited with exit code 0

=================================================================================
2023-10-19 21:47:04.072Z: Creating container...
2023-10-19 21:47:04.110Z: $ devcontainer up --id-label Type=codespaces --workspace-folder /var/lib/docker/codespacemount/workspace/thanos --mount type=bind,source=/.codespaces/agent/mount/cache,target=/vscode --user-data-folder /var/lib/docker/codespacemount/.persistedshare --container-data-folder .vscode-remote/data/Machine --container-system-data-folder /var/vscode-remote --log-level trace --log-format json --update-remote-user-uid-default never --mount-workspace-git-root false --omit-config-remote-env-from-metadata --skip-non-blocking-commands --skip-post-create --config "/var/lib/docker/codespacemount/workspace/thanos/.devcontainer/devcontainer.json" --override-config /root/.codespaces/shared/merged_devcontainer.json --default-user-env-probe loginInteractiveShell --container-session-data-folder /workspaces/.codespaces/.persistedshare/devcontainers-cli/cache --secrets-file /root/.codespaces/shared/user-secrets-envs.json
2023-10-19 21:47:04.341Z: @devcontainers/cli 0.52.1. Node.js v18.17.1. linux 6.2.0-1014-azure x64.
2023-10-19 21:47:04.791Z: {"outcome":"error","message":"Command failed: docker inspect --type image mcr.microsoft.com/devcontainers/go:0-1.21","description":"An error occurred setting up the container."}
2023-10-19 21:47:04.796Z: Error: Command failed: docker inspect --type image mcr.microsoft.com/devcontainers/go:0-1.21
2023-10-19 21:47:04.799Z:     at EAA (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:462:1260)
2023-10-19 21:47:04.802Z:     at kK (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:462:1002)
2023-10-19 21:47:04.807Z:     at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
2023-10-19 21:47:04.810Z:     at async NAA (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:479:3660)
2023-10-19 21:47:04.822Z:     at async vC (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:479:4775)
2023-10-19 21:47:04.827Z:     at async etA (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:613:10941)
2023-10-19 21:47:04.833Z:     at async AtA (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:613:10682)
2023-10-19 21:47:04.840Z: devcontainer process exited with exit code 1

====================================== ERROR ====================================
2023-10-19 21:47:04.845Z: Failed to create container.
=================================================================================
2023-10-19 21:47:04.848Z: Error: Command failed: docker inspect --type image mcr.microsoft.com/devcontainers/go:0-1.21
2023-10-19 21:47:04.860Z: Error code: 1302 (UnifiedContainersErrorFatalCreatingContainer)

====================================== ERROR ====================================
2023-10-19 21:47:04.872Z: Container creation failed.
=================================================================================

Looks like this is the issue https://github.com/thanos-io/thanos/pull/6615/files#diff-13bd9d7a30bf46656bc81f1ad5b908a627f9247be3f7d76df862b0578b534fc6R2
The image tag for 1.21 seems wrong. Available image for 1.21 is listed here https://github.com/devcontainers/images/tree/main/src/go

Indeed, it looks like rather than 0-1.21 it should be 1.21


Does uniswap extension support Uniswap v2 contract?

I'm not sure that does it support v2 or not.
https://github.com/thirdweb-example/thirdweb-uniswap
Just found the official thirdweb example but it's v3 implementation.
Thanks ;)

Hey @iamcryptofennec, the Uniswap extension currently only supports v3


1.9.1 device not supported

When I updated to 1.9.1, it says my device is no longer supported

My magic home device*

Hi there,
Please download your log, ensure it has no sensitive information, and upload it here so I can further assist you.
Additionally, give me a purchase link to your device.

Same here
Log
08/12/2020, 20:35:38] [homebridge-magichome-dynamic-platform] 1 -Registering existing accessory...
Display Name: 'Simple RGB'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'xxxxxxxxx'
IP-Address: 'Xxxxxxx
Hardware Version: '51'
Firmware Version: '6'
[08/12/2020, 20:35:38] [homebridge-magichome-dynamic-platform] platform.ts discoverDevices() accessory creation has thrown the following error: TypeError: accessoryType[existingAccessory.context.device.lightParameters.controllerLogicType] is not a constructor
at HomebridgeMagichomeDynamicPlatform.registerExistingAccessory (/usr/local/lib/node_modules/homebridge-magichome-dynamic-platform/src/platform.ts:404:28)
at HomebridgeMagichomeDynamicPlatform.discoverDevices (/usr/local/lib/node_modules/homebridge-magichome-dynamic-platform/src/platform.ts:159:20)
at processTicksAndRejections (internal/process/task_queues.js:93:5) {
[stack]: 'TypeError: accessoryType[existingAccessory.context.device.lightParameters.controllerLogicType] is not a constructor\n' +
'    at HomebridgeMagichomeDynamicPlatform.registerExistingAccessory (/usr/local/lib/node_modules/homebridge-magichome-dynamic-platform/src/platform.ts:404:28)\n' +
'    at HomebridgeMagichomeDynamicPlatform.discoverDevices (/usr/local/lib/node_modules/homebridge-magichome-dynamic-platform/src/platform.ts:159:20)\n' +
'    at processTicksAndRejections (internal/process/task_queues.js:93:5)',
[message]: 'accessoryType[existingAccessory.context.device.lightParameters.controllerLogicType] is not a constructor'
}
[08/12/2020, 20:35:38] [homebridge-magichome-dynamic-platform]
Registered 0 Magichome device(s).
New devices: 0
Cached devices that were seen this restart: 0
Cached devices that were not seen this restart: 0

Same exception and hardware. Found this commit and reverted to 1.8.4. Led strip works fine now. Mine controller is RGB, without W pin.

09/12/2020, 08:17:37] [homebridge-magichome-dynamic-platform]
Discovered 1 devices.
[09/12/2020, 08:17:37] [homebridge-magichome-dynamic-platform] 1 -Registering existing accessory...
Display Name: undefined
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ2101'
Unique ID:
IP-Address: xx
Hardware Version: '51'
Firmware Version: '8'
[09/12/2020, 08:17:37] [homebridge-magichome-dynamic-platform] platform.ts discoverDevices() accessory creation has thrown the following error: TypeError: accessoryType[existingAccessory.context.device.lightParameters.controllerLogicType] is not a constructor
at HomebridgeMagichomeDynamicPlatform.registerExistingAccessory (/usr/lib/node_modules/homebridge-magichome-dynamic-platform/src/platform.ts:404:28)
at HomebridgeMagichomeDynamicPlatform.discoverDevices (/usr/lib/node_modules/homebridge-magichome-dynamic-platform/src/platform.ts:159:20)
at processTicksAndRejections (internal/process/task_queues.js:93:5) {
[stack]: 'TypeError: accessoryType[existingAccessory.context.device.lightParameters.controllerLogicType] is not a constructor\n' +
'    at HomebridgeMagichomeDynamicPlatform.registerExistingAccessory (/usr/lib/node_modules/homebridge-magichome-dynamic-platform/src/platform.ts:404:28)\n' +
'    at HomebridgeMagichomeDynamicPlatform.discoverDevices (/usr/lib/node_modules/homebridge-magichome-dynamic-platform/src/platform.ts:159:20)\n' +
'    at processTicksAndRejections (internal/process/task_queues.js:93:5)',
[message]: 'accessoryType[existingAccessory.context.device.lightParameters.controllerLogicType] is not a constructor'
}
[09/12/2020, 08:17:37] [homebridge-magichome-dynamic-platform]
Registered 0 Magichome device(s).
New devices: 0
Cached devices that were seen this restart: 0
Cached devices that were not seen this restart: 0

I have the same. I downgraded 1.8.5 and all is good for now but I would be nice to know that the issue is solved.

I am having the same issue as above. I updated to homebridge-magichome-dynamic-platform v1.9.2-alpha6
and here is my logs.  Hope it gives some info to help.
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform]
Discovered 3 devices.
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform] 1 -Registering existing accessory...
Display Name: 'LivingRoom LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228A18XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '51'
Firmware Version: '6'
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform] [3] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform] device object:  {
UUID: 'f64ea12b-5a32-4f5b-ba01-f253c41a39XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'LivingRoom LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228A18XX',
modelNumber: 'AK001-ZJ2XX',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform] 2 -Registering existing accessory...
Display Name: 'Kitchen LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228B9EXX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '51'
Firmware Version: '6'
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform] [3] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform] device object:  {
UUID: '5c5d77a0-93fd-4309-a1c5-db06ad1144XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Kitchen LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228B9EXX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform] 3 -Registering existing accessory...
Display Name: 'Bed  LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: '600194B950XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '51'
Firmware Version: '6'
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform] [3] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform] device object:  {
UUID: '34975ffe-f13e-4748-be10-5520631e0cXX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Bed  LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 82, green: 42, blue: 213 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: '600194B950XX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform]
Registered 0 Magichome device(s).
New devices: 0
Cached devices that were seen this restart: 0
Cached devices that were not seen this restart: 0
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform] All devices have been updated to latest data model. Disabling periodic device discovery.
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform] Online and New: []
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform] Online and known: [ 'DC4F228A18XX', 'DC4F228B9EXX', '600194B950XX' ]
[12/9/2020, 10:07:06 AM] [homebridge-magichome-dynamic-platform] Offline and known: []

Same it's stopped working not a very good update unitstable

Hello and thank you for the logs. It has been very helpful. There are two bugs here that we have tracked down.
The first is a bug was a copy error that changed grb devices to become grbw which does not exist. That has been solved.
As for this error: TypeError: accessoryType[existingAccessory.context.device.lightParameters.controllerLogicType] is not a constructor
We are finalizing a fix but want to make absolutely sure it won't break anything before releasing it. 1.9.0 was an attempt to fix many issues but it wasn't tested thoroughly enough. If you aren't having the GRBW issue and wish to use 1.9.1., you can purge your MagicHome accessories, losing automations, names, rooms, and scenes, but it will work properly.
Please note that any alpha / beta versions WILL break your current Homebridge Magichome build. So use them with caution and not as a fix. If you are interested in trying out alphas giving feedback, we'd love your help. Let us know in the MagicHome Discord Server and we'll get you fixed up with a Beta Tester role.
Thank you everyone for your continued patience with this update and with this plugin as a whole. I will keep you informed.

If you'd like, the beta3 is looking very stable from initial tests. Use with caution however as we have made many changes with very little testing time.

Upgraded to beta 3. Here is the logs. Hope the logs help..  Let me know if I need to purge and try again
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] 1 - Registering existing accessory...
Display Name: 'Bed  LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: '600194B950XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object:  {
UUID: '34975ffe-f13e-4748-be10-5520631e0cXX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Bed  LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 82, green: 42, blue: 213 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: '600194B950XX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] 2 - Registering existing accessory...
Display Name: 'LivingRoom LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228A18XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object:  {
UUID: 'f64ea12b-5a32-4f5b-ba01-f253c41a39XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'LivingRoom LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228A18XX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] 3 - Registering existing accessory...
Display Name: 'Kitchen LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228B9EXX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object:  {
UUID: '5c5d77a0-93fd-4309-a1c5-db06ad1144XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Kitchen LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228B9EXX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] 1 - Registering existing accessory...
Display Name: 'Bed  LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: '600194B950XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object:  {
UUID: '34975ffe-f13e-4748-be10-5520631e0cXX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Bed  LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 82, green: 42, blue: 213 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: '600194B950XX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] 2 - Registering existing accessory...
Display Name: 'Kitchen LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228B9EXX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object:  {
UUID: '5c5d77a0-93fd-4309-a1c5-db06ad1144XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Kitchen LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228B9EXX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] 3 - Registering existing accessory...
Display Name: 'LivingRoom LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228A18XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object:  {
UUID: 'f64ea12b-5a32-4f5b-ba01-f253c41a39XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'LivingRoom LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228A18XX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] 1 - Registering existing accessory...
Display Name: 'Kitchen LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228B9EXX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object:  {
UUID: '5c5d77a0-93fd-4309-a1c5-db06ad1144XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Kitchen LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228B9EXX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] 2 - Registering existing accessory...
Display Name: 'Bed  LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: '600194B950XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object:  {
UUID: '34975ffe-f13e-4748-be10-5520631e0cXX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Bed  LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 82, green: 42, blue: 213 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: '600194B950XX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] 3 - Registering existing accessory...
Display Name: 'LivingRoom LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228A18XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object:  {
UUID: 'f64ea12b-5a32-4f5b-ba01-f253c41a39XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'LivingRoom LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228A18XX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}

Okay yes this helps tremendously. The program isn’t looking for that specific error... I’ll add that to the next beta so look out for it. We’re planning on a non beta release Friday morning EST.

On Dec 9, 2020, at 6:55 PM, CAuguston<EMAIL_ADDRESS>wrote:

Upgraded to beta 3. Here is the logs. Hope the logs help.. Let me know if I need to purge and try again
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] 1 - Registering existing accessory...
Display Name: 'Bed LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: '600194B950XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object: {
UUID: '34975ffe-f13e-4748-be10-5520631e0cXX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Bed LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 82, green: 42, blue: 213 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: '600194B950XX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] 2 - Registering existing accessory...
Display Name: 'LivingRoom LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228A18XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object: {
UUID: 'f64ea12b-5a32-4f5b-ba01-f253c41a39XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'LivingRoom LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228A18XX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] 3 - Registering existing accessory...
Display Name: 'Kitchen LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228B9EXX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:47:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object: {
UUID: '5c5d77a0-93fd-4309-a1c5-db06ad1144XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Kitchen LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228B9EXX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] 1 - Registering existing accessory...
Display Name: 'Bed LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: '600194B950XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object: {
UUID: '34975ffe-f13e-4748-be10-5520631e0cXX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Bed LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 82, green: 42, blue: 213 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: '600194B950XX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] 2 - Registering existing accessory...
Display Name: 'Kitchen LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228B9EXX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object: {
UUID: '5c5d77a0-93fd-4309-a1c5-db06ad1144XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Kitchen LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228B9EXX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] 3 - Registering existing accessory...
Display Name: 'LivingRoom LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228A18XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:47:41 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object: {
UUID: 'f64ea12b-5a32-4f5b-ba01-f253c41a39XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'LivingRoom LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228A18XX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] 1 - Registering existing accessory...
Display Name: 'Kitchen LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228B9EXX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object: {
UUID: '5c5d77a0-93fd-4309-a1c5-db06ad1144XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Kitchen LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228B9EXX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] 2 - Registering existing accessory...
Display Name: 'Bed LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: '600194B950XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object: {
UUID: '34975ffe-f13e-4748-be10-5520631e0cXX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'Bed LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 82, green: 42, blue: 213 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: '600194B950XX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] 3 - Registering existing accessory...
Display Name: 'LivingRoom LED'
Controller Logic Type: 'GRBWStrip'
Model: 'AK001-ZJ210'
Unique ID: 'DC4F228A18XX'
IP-Address: '<IP_ADDRESS>XX'
Hardware Version: '33'
Firmware Version: '6'
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] The controllerLogicType does not exist in accessoryType list. controllerLogicType= GRBWStrip
[12/9/2020, 6:48:11 PM] [homebridge-magichome-dynamic-platform] [registerExistingAccessory] device object: {
UUID: 'f64ea12b-5a32-4f5b-ba01-f253c41a39XX',
cachedIPAddress: '<IP_ADDRESS>XX',
restartsSinceSeen: 0,
displayName: 'LivingRoom LED',
lastKnownState: {
debugBuffer: { type: 'Buffer', data: [Array] },
controllerHardwareVersion: 51,
isOn: false,
RGB: { red: 123, green: 121, blue: 134 },
whiteValues: { warmWhite: 0, coldWhite: 0 },
controllerFirmwareVersion: 6
},
ipAddress: '<IP_ADDRESS>XX',
uniqueId: 'DC4F228A18XX',
modelNumber: 'AK001-ZJ210',
lightParameters: {
controllerLogicType: 'GRBWStrip',
convenientName: 'GRBW Strip',
simultaneousCCT: true,
hasColor: true,
hasBrightness: true
},
controllerHardwareVersion: 51,
controllerFirmwareVersion: 6
}
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

@CAuguston would you say your 'LivingRoom LED' has white?  In other words,  I wonder if it's an RGB or RGBW.

The release 1.9.2-alpha8 now available in npm (and upcoming 1.9.2-beta4 and 1.9.2 latest) fixes this issue.
The root cause is that we renamed GRBWStrip to GRBStrip better reflect the nature of the device. But that renaming broke the cached data.  In our latest code, every start-up we validate that cached data and update it as needed.

@CAuguston @techo91
@mik9 @djweinhagen
Reopening to ensure that the problem has been solved.

The release 1.9.2-alpha8 now available in npm (and upcoming 1.9.2-beta4 and 1.9.2 latest) fixes this issue.
The root cause is that we renamed GRBWStrip to GRBStrip better reflect the nature of the device. But that renaming broke the cached data. In our latest code, every start-up we validate that cached data and update it as needed.

While this is partially true. The root cause of the error was created when GRBStrip was renamed to GRBWStrip. This was a copy error that occurred in v1.9.1. We reverted the name in 1.9.2 beta, however our repair function was unable to catch this difference which resulted in nothing being repaired. @isramos has since added in a great check for this in beta4 so please let me know if that works out for you. Thank you.

Installed 1.9.2-alpha8, my strip was detected and working fine.

I am having problems with the latest update this work as well as the last I figured out that the name had to be what it said on the app on the last update that fix some of the problem and it was working perfectly why change something when it was doesn’t need to change
Sent from my iPhone

On 10 Dec 2020, at 03:21, Igor Ramos<EMAIL_ADDRESS>wrote:

The release 1.9.2-alpha8 now available in npm (and upcoming 1.9.2-beta4 and 1.9.2 latest) fixes this issue.
The root cause is that we renamed GRBWStrip to GRBStrip better reflect the nature of the device. But that renaming broke the cached data. In our latest code, every start-up we validate that cached data and update it as needed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

v1.9.2-beta4  has solved the issue for me. Thank you. My LED strips are now functional without having to purge them out.
Thanks as always for your help. Very happy with the programmers and community

Happy to be of service. We plan on officially releasing this version in ~ 12 hours. So keep an eye out.
With our new beta team we're able to test these updates a few days first. Making things a lot smoother.

Closing this issue as it was reported solved. Thank you.


treewide (darwin): fix or enable darwin build for many packages (4)

Motivation for this change
See #114976 for details.
Things done

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

[ ] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 115756 run on x86_64-linux 1

3 packages built:

analog
midicsv
p910nd

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:

analog:

warning: unclear-gpl
gpl2 is a deprecated license, check if project uses gpl2Plus or gpl2Only and change meta.license accordingly.
Near pkgs/tools/admin/analog/default.nix:33:5:
   |
33 |     license = lib.licenses.gpl2;
   |     ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/unclear-gpl.md

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 115756 run on x86_64-darwin 1

21 packages built:

analog
coan
lambda-mod-zsh-theme
makefile2graph
midicsv
mnemonicode
p910nd
postsrsd
python38Packages.tinyobjloader-py
python39Packages.tinyobjloader-py
r2mod_cli
restya-board
rocm-cmake
routinator
swarm
tidyp
tinyobjloader
tllist
udpt
utf8cpp
vcg

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:

analog:

warning: unclear-gpl
gpl2 is a deprecated license, check if project uses gpl2Plus or gpl2Only and change meta.license accordingly.
Near pkgs/tools/admin/analog/default.nix:33:5:
   |
33 |     license = lib.licenses.gpl2;
   |     ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/unclear-gpl.md

Needs another rebase, but all builds for me on macos 10.14 - nice work.

Rebased.

@SuperSandro2000 ping


aiohttp gets 403, message='Forbidden'

For some months already I am not able to run the integration because of the authentication issues.
As far as I can read around the new versions should have fixed this authentication issue but for some reason I am still affected.
The last time I tried was a couple of minutes ago, tested version v1.0.19.
I am installing it manually on a containerized homeassistant, where in the past was able to run correctly.
Now when I install the integration from the HA UI I get the error: Failed to set up: check the logs
while from the logs I see:
2024-09-11 22:37:23.602 ERROR (MainThread) [custom_components.electrolux_status] Could not log in to ElectroluxStatus, 403, message='Forbidden', url=URL('https://accounts.eu1.gigya.com/accounts.login')
2024-09-11 22:37:23.602 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry<EMAIL_ADDRESS>for electrolux_status
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 586, in async_setup
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/electrolux_status/__init__.py", line 46, in async_setup_entry
    if not await coordinator.async_login():
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/electrolux_status/coordinator.py", line 39, in async_login
    raise ex
  File "/config/custom_components/electrolux_status/coordinator.py", line 32, in async_login
    token = await self.api.get_user_token()
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/pyelectroluxocp/oneAppApi.py", line 126, in get_user_token
    id_token = await gigya_client.login_user(self._username, self._password)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/pyelectroluxocp/gigyaClient.py", line 289, in login_user
    session = await self.login_session(username, password, gmid, ucid)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/pyelectroluxocp/gigyaClient.py", line 240, in login_session
    response.raise_for_status()
  File "/usr/local/lib/python3.12/site-packages/aiohttp/client_reqrep.py", line 1070, in raise_for_status
    raise ClientResponseError(
aiohttp.client_exceptions.ClientResponseError: 403, message='Forbidden', url=URL('https://accounts.eu1.gigya.com/accounts.login')

I am using a working password that has been reset to be absolutely sure it was correct.
Am I doing anything wrong?

I have the same issue, the same log message. Mine is a brand new AEG washer and a brand new AEG account created with the new AEG app. The AEG Care app is not working, it says it is obsolete and I have to use the new AEG app

I successfully migrated from the old app to the new one and I can successfully manage my AEG washing machine from the new app.
But I can't get the integration to pass the authentication step because of the issue above

@JJanssen123 that was a great catch. After I accessed the aeg site (in my case aeg.it ) the password was accepted on the integration login. The log is now gone and I am getting all the sensors as expected.
@albaintor I think this step should be mentioned in the documentation.

I tried to login in aeg.nl for the first time, with the account and password I made in the (new) app. But website said the password was wrong. I changed it using "forgot password" into the password I created in the app. Now the integration is able to connect!
Maybe changing the password through the aeg-website into your app-password can help you as well?

Thanks, I have added this workaround in the readme https://github.com/albaintor/homeassistant_electrolux_status/blob/main/README.md


Disable automatic phone number formatting

<meta name="format-detection" content="telephone=no">

We actually already have this in the page.html <head>, so I'm not sure why we saw this on mobile.


hotspot stransform style error on chrome version 116

After upgrade chrome browser to version 116. Hotspot error when hover on div hotspot
Example: https://simplevirtualtour.it/app/viewer/POIs-error-on-chrome
I found some update in chrome version 116: https://developer.chrome.com/blog/chrome-116-beta/
How to fix this error?

Care to elaborate? What kind of error? What do you mean by "div hotspot"?

Care to elaborate? What kind of error? What do you mean by "div hotspot"?

I am using the pannellumjs library to build a virtual store for displaying products. After upgrading the Chrome browser from version 115 to version 116, I encountered the following issue:
When hovering over hotspots containing images, the images experience noticeable shaking or jittering. My hypothesis is that this behavior is related to Chrome's update of the CSS transform property and potential changes in the mouseenter and mouseleave events. I found some information about this in the documentation at https://developer.chrome.com/blog/chrome-116-beta/. I suspect that these changes might be affecting the events within the pannellumjs library. I would appreciate it if you could investigate this matter.
Below is an video illustrating the issue:
https://github.com/mpetroff/pannellum/assets/9640740/20b30a72-3344-450d-b978-703810044a6e
And link my website: https://my.vrmall.io/viewer/index.php?code=6c524f9d5d7027454a783c841250ba71

The hot spots you're having issues with are something you added yourself, by modifying Pannellum. Best I can tell, the issues are not related to Pannellum itself but only with your additions; I can't reproduce the issue with the default hot spots with either the current master branch or with v2.5.6.
The issue is not directly related to anything mentioned in the Chrome 116 developer notes. The mouse event changes are not relevant (you get the same shaking at your link if you move the view with the arrow keys), and the CSS motion path feature should not directly cause any issues either. However, it's entirely possible that the Chromium developers broke something when implementing the CSS motion path feature, which caused the regression you see.
Are you absolutely sure you upgraded from v115 and not v114? I found an issue on the Chromium issue tracker that looks like it could be related to the issues you're seeing, but it was reported for v115, not v116; of course, it could also be entirely unrelated.
Why should I help you debug an issue with a feature you've added yourself but haven't opened a pull request for and contributed back? You're well within your rights to take my work, extend it, and sell it as you've done, but I'm also under no obligation to help you for free if you do. Regardless of whether or not I should help you, I don't have the code for your added features, making it difficult to see how they work or to debug them.

First of all, I apologize for my poor English.
I don't intend to ask you for help debugging. I will close this issue.
Again, thank you for your support and providing a great library.

First of all, I apologize for my poor English.

Your English is fine.

Again, thank you for your support and providing a great library.

Thanks!
I'd recommend trying to produce a minimal reproducible example. I think the issue is likely due to a browser bug, so a minimal example would allow you to report it to the Chromium developers.


UI Changes and Runtime Improvements (Part 1)

Description
As the title name suggest, this PR introduces some UI changes into the launcher and some minor runtime improvements.
What's New?
New OOBE UI
The OOBE (Out of the Box Experience) now has a new UI. Keep it in mind that the implementation is still in early stage and might be changed over time. Let me know if you have any concerns or advice regarding to this change.
1.OobenewAV1.webm
Image Cropper for Custom Background Image
You can now select a specific area of your backgroud
2.BackgroundimagecropperAV1.webm
New Loading Indicator UI
Also the new UI is now shared to the entire app as it's now a part of MainWindow's element

Changing old CommunityToolkit's DataTable to the new one
Due to some issues with the repo not being maintained, we are deciding to move into the new CommunityToolkit. You might notice that the UI is slightly changed.

Old
New

"Game Type" Aware Mascot for Empty News Display
The news panel will now show the mascot representing each game instead of always showing Paimon as the default mascot.

Genshin Impact
Honkai Impact 3rd

Honkai: Star Rail
Zenless Zone Zero

Other Changes
TBA
What's Fixed?
TBA

UI itself looks great, going to be reviewing the code when I have a bit more time. Is there a way to refresh the latency for the CDNs? Right now it seems to be hardlocked at whatever the initial test said, but would be great if the user could see which one is the best by also manually refreshing the page or just that single UI component.

Is there a way to refresh the latency for the CDNs?
I will be planning to add this feature later.

UI itself looks great, going to be reviewing the code when I have a bit more time. Is there a way to refresh the latency for the CDNs? Right now it seems to be hardlocked at whatever the initial test said, but would be great if the user could see which one is the best by also manually refreshing the page or just that single UI component.
@neon-nyan @bagusnl

Preview
2024-02-18 17-31-05.webm

changing the accept button to go to the "3rd parties notice" first, and only on this page allowing to actually accept it.

That sounds good.
Also the "next" button for each pages does not align to a same direction.

changing the accept button to go to the "3rd parties notice" first, and only on this page allowing to actually accept it.

That sounds good.
Also the "next" button for each pages does not align to a same direction.

The style has been adjusted in the latest commit. Let me know if something related with the style need to be changed again.

As a reply regarding to @gablm comment:
Agreement page

Additionally, I think it would be nice if scrolling down or up after reaching the limit of the agreement content would change to the other page.
As per now, I still can't figured out why the chained scroll down doesn't work on mouse scroll wheel while using touch input like touch bar seems to scroll just fine as expected where the next agreement is shown if the current one has reached its end offset.

The arrow to change between the "pages" is not that noticeable.

The arrow style has been changed as per below:
2024-02-23 00-59-50.webm
Data folder choice page

The TextBox should be a little bit bigger.

The size has been adjusted on small size window mode.

It would be useful to have a "Back" button here as sometimes people only remember to change a specific setting after actually closing the "first time settings selection" page.
Also, shouldn't the "Enter Launcher" button follow the same design of the other new buttons? Or is it still highlighted as it is the last button before exiting setup?

The Back button has been re-added to the Game Selection page and the button style has been adjusted to match the other buttons as well.
2024-02-23 01-09-53.webm

Good work @neon-nyan <3
Is there anything left to do for the scope of this PR?
Dont mind the Qodana report, I'll handle it on next codeQA wave

Good work @neon-nyan <3
Is there anything left to do for the scope of this PR? Dont mind the Qodana report, I'll handle it on next codeQA wave

I'll be working on Honkai Impact 3rd's 7.3 Repair adjustment regarding to the changes on the backend stuffs. Once that's finished, we can continue to merge this PR

Good work @neon-nyan <3
Is there anything left to do for the scope of this PR? Dont mind the Qodana report, I'll handle it on next codeQA wave

I'll be working on Honkai Impact 3rd's 7.3 Repair adjustment regarding to the changes on the backend stuffs. Once that's finished, we can continue to merge this PR

Can we merge this PR first ? I dont want this to be 'small-changes part. 2' :derp:

Can we merge this PR first ? I dont want this to be 'small-changes part. 2' :derp:

Welp, yeah. We can merge this first then since the 7.3 changes are unrelated with this PR
:klee_derp:

As per internal discussion, I will be merging this PR now.
Thank you guys for the feedback and your help on this!


[5.2] added compileUrl() and compileAsset() functions

Blade directives: @url and @asset

Going to hold off on this for now actually. Sorry.