Backend vincent pr

added comments to everything
changed data structure to have to relating collections (topics and articles)
updated schemas
updated seeding to work with new schemas and relations
added API
hope I didn't forget anything

wrong branch


Add return functions to manually stop/start intervals and cancel timeouts

Currently, the componentInterval and componentTimeout functions perform their cleanup when the component is destroyed. Leaving this here to brainstorm an API for manually performing these actions.

Update: We're going to only add a cancel function to both return values. Looking at it more, there probably isn't a real need for interval to have a start and stop functions. If someone needs to restart an interval, they can just call componentInterval again.

// the following api could be used to start / stop an interval
new Vue({
    created() {
        const interval = componentInterval(this, this.tick, 100);

        interval.cancel();
    }.
});

// the following api could be used to manually cancel a timeout
new Vue({
    created() {
        const timeout = componentTimeout(this, this.whatever, 100);

        timeout.cancel();
    },
});

Closed by 60a13df49c60f0a16fc0288f57496bcb57685167 and 15b4a0f034fd767ffd4487d88469131a16aa5ad7


WL-3881: Managing Library dropdown to Edit Reading List page

Bad merge

Doesn't merge.

Merges now


"Connection reset by peer" on port 8080

Hi, Jochen and Kannan from neuland here!
We tried running aether locally and therefore created a local.yaml with our credentials. When starting the application with docker-compose everything looks fine and we get data on the std out of docker-compose, like so:

aether-1  | {"time":"2024-05-08T09:22:46.523103205Z","level":"INFO","msg":"server started","address":"<IP_ADDRESS>:8080"}
aether-1  | {"time":"2024-05-08T09:22:46.740398767Z","level":"DEBUG","msg":"CPU calculation","energy usage":0.00009117109104346985,"emissions":{"Value":0.034975965657006336,"Unit":"gCO2eq"}}

However, when we try to access the site that is supposed to run on port 8080, we get a "Connection reset by peer" error. We also tried using https, and added a /metrics to the address, but that didn't help either. To our understanding this should be the endpoint for Prometheus, so this would run into the same problem.
Are we missing anything?
Best regards!

Hi Jochen and Kannan!
First off, thank you for giving aether a try, and creating the issue!!
My initial thought is that you may be unable to access localhost since it's running in an docker container.
I think if you try changing the API address in you local config to <IP_ADDRESS>, it should work.
api:
  address: <IP_ADDRESS>

You're correct in the understanding of using the same Prometheus endpoint of /metrics, so it should work with <IP_ADDRESS>:8080/metrics
I think you could also add network_mode: "host" to the docker-compose.yaml file and continue to use localhost.
Hope that works :crossed_fingers:

Hi Gabi!
Changing the address to <IP_ADDRESS> will now yield a 404 (which might be correct behaviour?), but accessing /metrics will now yield us the metrics page, so I believe this did the trick.
Thank you!

Fantastic! Yeah, at the moment that's the correct behavior. I've created an issue to update our docs to be more clear and hopefully help others avoid this in the future!


[WFLY-13839] Undertow https-listerner does not generate required capability

This PR does the following:

adds a capability org.wildfly.undrtow.listener.http-upgrade-registry to Undertow's https-listener to represent the ChannelUpgradeHandler service used by HTTP Upgrade
fixes an issue with a capability reference for the attribute ssl-context in the HttpsListenerResourceDefinition

For more details, see:  https://issues.redhat.com/browse/WFLY-13839

Had a look at te mixed domain test failures - can't see any errors that involve undertow or the capability I added specifically.

retest please


fix: RHTAPBUGS-34 return the error instead of fatal log it

Description
After adding ginkgo flag --output-interceptor-mode=none, another test failed with this error on Apr 06<PHONE_NUMBER>60821248.
From the --output-interceptor-mode=none logs, we can see that it fails on the function sendRequest:
Output from proc 13:
    "level"=0 "msg"="Starting Red Hat App Studio e2e tests...\n"2023/04/06 15:19:08 failed to access Tekton Result Service with status code: 401 and
  body: {"code":16,"message":"permission denied","details":[]}

I think it is the log.Fatal(err) that is causing it
Issue ticket number and link
RHTAPBUGS-34
Type of change

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

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added meaningful description with JIRA/GitHub issue key(if applicable), for example HASSuiteDescribe("STONE-123456789 devfile source")
[ ] I have updated labels (if needed)

/test ?


optgroup compatibility

Hello,
Amazing script! But what about optgroup tag ? Is supported by your script ?
Thanks for answer

No, optgroup tags are currently not supported. Not sure whether there is high demand for this. But I will have a look at it.
Jos

I think this is last missing feature in your script.


[BEAM-6017] [WIP] Support nanosecond precision for DateTime field in Row

Support nanosecond precision for DateTime field in Row.

Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.
 It might require updating the ByteBuddy code.
On Fri, Nov 9, 2018 at 8:28 AM amaliujia<EMAIL_ADDRESS>wrote:

I think the failures of check mostly came from direct access Row's values,
which I didn't expect.
As Row is associated with Schema and Row provides specific type access
method already, seems to me that make generic access method as private will
be a working solution.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/beam/pull/6991#issuecomment-437206360, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AUGE1SN7_e6TZP_uO0ikTW3MMOvM2YTiks5utMwfgaJpZM4YVr4r
.

It would be nice to restart discussions about adding this functionality in Beam 2.x because BigQueryUtils currently drops the microseconds?  In order to maintain backwards compatibility and facilitate DATETIME removal in 3.x, it might be better to create a new type altogether in the interim.


Check if database already exists

Hi,
This is a great plugin, however I wanted to ask if there is a way to check if the database already exists before trying to copy it over?
Thank you

This method doesn't copy  the database, if the database already exists -
window.plugins.sqlDB.copy(dbname, location, success,error);
It goes to error callback with the db exists response and error code, see README.md for more details.


Sample code wouldn't compile missing "

I copy n paste the sample code and it wouldn't compile.
There is a missing " around the URI in the code snippet.
This is such a "sad" update

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

Thank you for your contribution, @KiwiBryn -- we appreciate it! #sign-off


Wrong colors

After applying the theme using the instructions provided on the landing page, I got the following colorscheme. It does not look OK. I am a Neovim newbie so please guide me if anything is missing from my setup.
Screenshots

hey @rajat1saxena can you share your config and the neovim version you are using please?

closing since we don't have an answer. Feel free to reopen


Missing Tooltip while converting vscode.ChatFolloup to internal interface IChatFollowup

VS Code Version: 1.88.0

I was trying to provide some sample questions for a interactive session. and I provided a list of vscode.ChatFollowup like:
{
    prompt: 'write a bubble sort',
    label: 'write a bubble sort',
    participant: 'workspace',
    command: 'fix'
}

I noticed we didn't convert tooltip property here.

but tooltip property is used while rendering.
is there any way to customize this tooltip for sample questions? I don't want to reuse label here.

Good point, but I'm actually not sure we should allow customizing the tooltip in the API. If the label is customized, then I want the tooltip to be able to show the user what exactly will be sent when they click it. If the tooltip is also customized, then this info isn't available anywhere.
What do you want to use it for?

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Removed Preview from some of the SAP alert rules

Learn Build status updates of commit ce51ab7:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/sentinel/sap/sap-solution-security-content.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

#sign-off


Animate problem line

This commit adds an animation on the line when the problem is displayed
https://github.com/boolder-org/boolder-android/assets/8343416/51aab492-dccd-49d3-a5da-ab2f85650cbc
The Android Gradle Plugin version has also been updated to the latest.
Fixes #16

@wang-li Great! 👍
Small request: can you change the animation duration to 400 milliseconds?
And fix the merge conflict, cause I'm afraid I will mess it up 😅
Thank you so much! 🙏

@nmondollot I have updated the duration and rebased the branch over main 😉


Icons +10, Links +23

Description
https://docs.google.com/spreadsheets/d/1AXc9EDXA6udZeGROtB5nuABjM33VluGY_V24tIzHaKc/edit#gid=1923954573⧉
Icons addition information
TODO

Icon update for Student Messenger

Outlined Circle

Icon update for Perfect Ear

It's not centered

Icon update for Turnip Boy Commits Tax Evasion

Icon too small for viewing

Examine all icons' corner radius (I realised I forgot to set it to 6px)

Added
Most of these are randomly selected from the spreadsheet and Play store

[!WARNING]
Might contain unpushed changes

[!CAUTION]
Commit that start with [ICON] does not contains svg file, see [ASSET] instead.

Honeygain ⧉[^1] (linked com.honeygain.make.money/com.honeygain.app.ui.splash.SplashActivity to @drawable/honeygain)
Student Messenger (linked com.thaionline.studentcare/com.thaionline.studentcare.MainActivity to @drawable/student_messenger)
BMTA mTicket (linked com.mbta.mobileapp/io.ionic.starter.MainActivity to @drawable/bmta_mticket)
K PLUS (linked com.kasikorn.retail.mbanking.wap/com.kasikorn.retail.mbanking.kplus.home.activity.SplashScreenActivity to @drawable/kplus)

K PLUS Vietnam (linked com.kasikornbank.kplus.vn/com.kasikornbank.regional.features.onboard.presentation.ui.splash.SplashActivity to @drawable/kplus)
K PLUS Laos (linked com.kasikornbank.kpluslifelaos/com.kbank.laos.emoney.consumer.openapp.activity.SplashScreenActivity to @drawable/kplus)

Bangkok Bank (linked com.bbl.mobilebanking/com.bbl.mobilebanking.ui.PreLoginActivity to @drawable/bangkok_bank)
DataCamp (linked com.datacamp/com.datacamp.MainActivity to @drawable/datacamp)
Turnip Boy Commits Tax Evasion (linked com.pid.turnipboy/com.unity3d.player.UnityPlayerActivity to @drawable/turnip_tax_evasion)
Flat (linked com.tutteo.flat/com.tutteo.flat.presentation.activities.MainActivity to @drawable/flat)
Perfect Ear (linked com.evilduck.musiciciankit/com.evilduck.musiciankit.pearlets.home.HomeActivity to @drawable/perfect_ear)
Geogebra Geometry (linked org.geogebra.android.geometry/org.geogebra.android.privatelibrary.splashscreen.SplashScreenActivity to @drawable/geogebra_geometry)

Linked
Xbox Beta (but I forgor to save the summary)

Camera (linked com.google.android.GoogleCameraLMCR17/com.android.camera.CameraLauncher to @drawable/camera)
Camera (linked com.google.android.GoogleCameraLMCR18/com.android.camera.CameraLauncher to @drawable/camera)
Camera (linked com.google.android.GoogleCameraEngR15/com.android.camera.CameraLauncher to @drawable/camera)
Camera (linked com.android.lmc82r8/com.android.camera.CameraLauncher to @drawable/camera)
Camera (linked com.android.hasil.lmc82r8/com.android.camera.CameraLauncher to @drawable/camera)
Camera (linked com.camera.lmc84r7/com.android.camera.CameraLauncher to @drawable/camera)
Camera (linked com.camera.lmc84lite/com.android.camera.CameraLauncher to @drawable/camera)
Camera (linked com.google.android.GoogleCameraEngR13F2/com.android.camera.CameraLauncher to @drawable/camera)
Camera (linked com.google.android.GoogleCameraEngR14/com.android.camera.CameraLauncher to @drawable/camera)
Camera (linked com.htc.camera3/com.htc.camera3.CameraEntry to @drawable/camera)
Mi Fitness (linked com.mi.health/com.xiaomi.fitness.login.SplashActivity to @drawable/mi_fitness)
Camera (linked com.mediatek.camera/com.android.camera.CameraLauncher to @drawable/camera)
Camera (linked com.iakmds.librecamera/com.iakmds.librecamera.MainActivity to @drawable/camera)
OpenTracks (linked de.dennisguse.opentracks.playstore/de.dennisguse.opentracks.introduction.IntroductionActivity to @drawable/opentracks)
OpenTracks (linked de.dennisguse.opentracks.debug/de.dennisguse.opentracks.introduction.IntroductionActivity to @drawable/opentracks)
OpenTracks (linked de.dennisguse.opentracks.nightly/de.dennisguse.opentracks.introduction.IntroductionActivity to @drawable/opentracks)
Sudoku (linked com.kaajjo.libresudoku/com.kaajjo.libresudoku.MainActivity to @drawable/sudoku)
Sudoku (linked com.easybrain.sudoku.android/com.easybrain.template.SplashActivity to @drawable/sudoku)
Sudoku (linked com.gamovation.sudoku/com.unity3d.player.UnityPlayerActivity to @drawable/sudoku)
Sudoku (linked com.brainium.sudoku.free/com.brainium.brainlib.core_android.BrainlibActivityFree to @drawable/sudoku)
Chess (linked com.google.android.chess/com.google.android.chess.Chess to @drawable/chess)

Updated
Microsoft Office -> Microsoft 365
Contributor's checklist

[x] I have followed the Lawnicons Guidelines
[x] I have ensured that Lawnicons builds correctly
[x] I am willing to make changes to my icons if someone suggests changes

[^1]: APK obtains via downloading from their website

com.microsoft.xboxone.smartglass.beta/com.microsoft.xbox.MainActivity

Added in #1805.


Laravel 10 and the events

Hi,
I would like to give extra powers to some commands with your package, and I read about the events fired during some commands execution, at this point all it's clear, but after reading the Laravel 10 documentation, I see that now the events are working with Event classes, but the event is only text like 'enabling' but I can't see any Event class or derived from it.
My question is so simple, how could I listen the text based events using classes? How can I connect both sides?
Any clue or trick are welcome to advance in my project.
Thanks in advance and congratulations for your job and the package, it is awesome!

I found the solution and it is so simple, just declare an Event listener in EventServiceProvider as the piece of code below:
    public function boot(): void
    {
        $this->app['events']->listen('modules.*.enabling', function($event) {
            dd($event);
        });
    }


paged_search example broken

Hi, I tried the example in - https://metacpan.org/pod/WWW::Google::Places#paged_search(%params), but it returns paged_search(): Parameter failed check constraint. (types) (status: 105) file /home/faraco/perl5/lib/perl5/WWW/Google/Places.pm on line 42 instead.
I found the problem is in parameter 'type value'. I fixed it by using either 'bar' or 'restaurant' instead of 'bar|restaurant'. Is this supposed to happen, and is there workaround?

Hi @faraco
Thanks for raising the issue and above all using my module :-)
The issue you raised is coming from the dependent module Method::ParamValidator.
Luckily I am the author of both the modules, so I take the blame for the disaster.
I now have a patch ready for Method::ParamValidator and will be releasing sometimes tomorrow i.e. Friday 5th May 2017. Once that patch is out of the way then I will have to do minor tweak to the module WWW::Google::Places. The day after i.e. Saturday 6th May 2017, I will push the changes.
As soon as the two patches are in CPAN, please update your local copy and you are good to go. If you still have any issues, please give me shout back. I promise to look into it straight away.
Best Regards,
Mohammad S Anwar

Thank you.

Hi,
Just to update, patched Method::ParamValidator v0.10
Sometimes tomorrow I will push the patch for WWW::Google::Places and that should resolve your issue.
Best Regards,
Mohammad S Anwar

Hi @faraco
FYI, I have pushed the tweak (WWW::Google::Places v0.32).
Please test against your code.
Hopefully this should resolve your issue. If not then please feel free to report back.
If you are satisfied with the fix then please close the issue.
PS: Thanks for giving star on GitHub and MetaCPAN.
Best Regards,
Mohammad S Anwar

Hi again, thank you for the quick response and determination. Is it now fixed and the problem's gone. :+1:


Imlementation of HTTP Template Renderer

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

Test name
Commit
Details
Rerun command

operator-lint
263c0a5267e27aea676957149c3b359ef603b2c7
link
/test operator-lint

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

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

Test name
Commit
Details
Rerun command

operator-lint
263c0a5267e27aea676957149c3b359ef603b2c7
link
/test operator-lint

operator-test
263c0a5267e27aea676957149c3b359ef603b2c7
link
/test operator-test

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

@richardwxn: PR needs rebase.

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

Closing this PR as HTTP template renderer is not needed, file template renderer should handle the installation when install package point to a http url


Autogen interfaces from deployed and verified contracts

[x] better dir management for where to store the interfaces
[x] tests
[x] comment source code for interface generation for easier reference

fixes https://github.com/gakonst/foundry/issues/331

looks good directionally. some comments. I'd focus on cleaning up the abi_to_solidity function with more idiomatic rust, e.g. usage of iter().map(...) instead of for loops, trying to avoid redundant clones, and using format! to create complex strings instead of pushing each element one by one.

That's very pertinent @gakonst . I had a feeling that I am not writing idiomatically. The clones() are used where the "move occurred, doesn't implement copy trait" error was encountered. Perhaps I should change the algo at that part instead of using clone.
For the format, perhaps it would make sense to push every line into the vector and format the line with format!?

Final touch, figure out how to make coc not auto-add ;

If it's possible (in this one or future PR), having it generate interfaces from ABI could also be quite useful

one issue to be aware of - ethabi can produce incompatible ABIs due to solc removing constant in the abi. Currently, ethers.js will fail to parse a foundry outputted ABI.
I opened a PR upstream to try to get this fixed: https://github.com/rust-ethereum/ethabi/pull/256

@odyslam any update on next steps here?

one issue to be aware of - ethabi can produce incompatible ABIs due to solc removing constant in the abi. Currently, ethers.js will fail to parse a foundry outputted ABI.
I opened a PR upstream to try to get this fixed: rust-ethereum/ethabi#256

@brockelmore -- I feel that the issue you describe is orthogonal to the implementation here? What am I missing?

@gakonst The tests seem to fail at an irrelevant test ? I think it's a regression I imported from master

OK this supports ABI Encoder V2 to some extent now. It wont fully parse things like DyDx's solo margin, but it generates most of the structs correctly, for getting started. cc @samczsun


[android] Video is crashing Error: while updating property 'rate' of a view managed by: RCTVideo

Current behavior
it gives me error : Error: while updating property 'rate' of a view managed by: RCTVideo
Reproduction steps
it gives error every time we navigate to screen for playing video
Expected behavior
Video should play on android
Which player are you experiencing the problem on:

Android ExoPlayer

Video sample
I am picking video from local
Video code :
renderVideo() { 		return( 			<Video 				source={('./Measurements.mp4')} 				ref={(ref) => { 					this.player = ref 				}} 				controls = {false} 				fullscreen = {false} 				onLoadStart={() => {console.log("loading started")}} 				onLoad={() => {console.log("loading done")}} 				rate = {this.state.playerRate} 				style = {[styles.video]} 			/> 	 )  }
my package.json
{
"name": "abc",
"version": "0.0.1",
"private": true,
"scripts": {
"start": "node node_modules/react-native/local-cli/cli.js start",
"test": "jest"
},
"dependencies": {
"aws-amplify": "^1.0.11",
"aws-amplify-react": "^2.0.1",
"aws-amplify-react-native": "^2.0.1",
"aws-appsync": "^1.7.0",
"aws-appsync-react": "^1.2.5",
"aws-sdk": "^2.353.0",
"d3-shape": "^1.2.2",
"es6-symbol": "^3.1.1",
"google-libphonenumber": "^3.1.14",
"graphql-tag": "^2.10.0",
"i": "^0.3.6",
"mobx": "^4.8.0",
"mobx-react": "^5.0.0",
"moment": "^2.22.2",
"moment-range": "^4.0.1",
"npm": "^6.4.1",
"prop-types": "^15.6.2",
"react": "16.5.0",
"react-apollo": "^2.2.4",
"react-art": "^16.6.0",
"react-native": "^0.57.4",
"react-native-chart-kit": "^1.1.9",
"react-native-circular-progress": "^1.0.1",
"react-native-elements": "^1.0.0-beta6",
"react-native-i18n": "^2.0.15",
"react-native-keyboard-aware-scroll-view": "^0.7.2",
"react-native-linear-gradient": "^2.4.2",
"react-native-multiple-picker": "0.0.21",
"react-native-parallax-header": "^1.0.6",
"react-native-phone-input": "^0.2.1",
"react-native-popup-dialog": "^0.16.3",
"react-native-progress": "^3.5.0",
"react-native-progress-circle": "^2.0.1",
"react-native-segmented-control-tab": "^3.3.1",
"react-native-simple-dialogs": "^0.4.1",
"react-native-slider": "^0.11.0",
"react-native-svg": "^6.4.1",
"react-native-svg-charts": "^5.2.0",
"react-native-triangle": "0.0.9",
"react-native-vector-icons": "^6.1.0",
"react-native-video": "^4.0.1",
"react-navigation": "^2.14.2",
"rn-viewpager": "^1.2.9"
},
"devDependencies": {
"@babel/plugin-proposal-decorators": "^7.1.2",
"@babel/runtime": "^7.1.2",
"babel-jest": "23.6.0",
"eslint-config-rallycoding": "^3.2.0",
"jest": "23.6.0",
"metro-react-native-babel-preset": "^0.48.3",
"react-test-renderer": "16.5.0"
},
"jest": {
"preset": "react-native"
},
"rnpm": {
"assets": [
"./assets/fonts/"
]
}
}

I have the same issue. With values from 0.1 to 2.0 it works, but gives me error when set to zero.
Is there another way to pause the video?

I have the same issue. With values from 0.1 to 2.0 it works, but gives me error when set to zero.
Is there another way to pause the video?

Now the author has not maintained this problem, what should I do?

@cobarx I'm facing this issue when I set 0 in Android, on iOS it works fine. What to do now?

Now the author has not maintained this problem, what should I do?


UFW Setup

Abstract
We should setup UFW on our nodes to control inbound and outbound traffic.
Implementation
There are several ways to implement this so we should talk about whether roles should control their own UFW rules or whether we should have a ufw role which manages all rules.
Ansible has a ufw module for rule management.
We need to allow SSH, Wireguard and HTTP off the top of my head, there are probably other things here and there as well.

We've decided to centralise the UFW rules within a single UFW role.
We need to be able to support:

Default policy (deny all)
Allow by port
Allow setting comment
Filtering by hosts (not all firewall rules make sense for every host)
Some non-configurable sane defaults (e.g. allowing SSH)


Window Controls

Hello all! This is a PR that is in collaboration between me and BlueDome. Me and him have merged ours extensions together and made a even better one! This extension gives you control over everything we could think of. More blocks will be coming soon!
This is the current roster:

COLLAB EXTENSION REALLL

We should really be specifying this does not work in browser and only in electron applications. I can already imagine the issue statements.

We should really be specifying this does not work in browser and only in electron applications. I can already imagine the issue statements.

@LilyMakesThings I will be making a documentation page specifying this. Also, after vigorous testing, some blocks do still work in browsers/html. Just the ones that don't affect the page state.

put that ones that work in Electron only under a BlockType.LABEL, perhaps

put that ones that work in Electron only under a BlockType.LABEL, perhaps

I could, but basically all of them work in electron only. So it could mess up the entire order. So I'll just define in documentation that most work in electron only.

put that ones that work in Electron only under a BlockType.LABEL, perhaps

@GarboMuffin I could, but basically all of them work in electron only. So it could mess up the entire order. So I'll just define in documentation that most work in electron only.

You need to make a label saying the blocks only work in electron. The kind of people who would be making issues about it not working in browser and the kind of people who don't read the documentation.

put that ones that work in Electron only under a BlockType.LABEL, perhaps

@GarboMuffin I could, but basically all of them work in electron only. So it could mess up the entire order. So I'll just define in documentation that most work in electron only.

You need to make a label saying the blocks only work in electron. The kind of people who would be making issues about it not working in browser are the kind of people who don't read the documentation.

Ahhhh like that one other extension I forgot the name of that had a label stating something important. Alright I will do that tomorrow with some more block additions and documentation and anything else. Then everything should be ready.

Could this then help with #360?

@UndermanReal Yes actually. I haven't added it yet because I'm outside. But I will be adding a block called "match stage size" that will change the window aspect ratio to match the canvas.

@GarboMuffin @LilyMakesThings Wanted to update you guys on something. After further testing, Window Controls works perfectly in Electron AND Pop Up HTML. Only certain ones work in browser/browser HTML.

@GarboMuffin, Window Controls is ready for review/ready to be merged.

I feel like these blocks need a spot, while deprecating the enter and exit fullscreen blocks

I feel like these blocks need a spot, while deprecating the enter and exit fullscreen blocks

@echoless3484, let me explain some things. The set Fullscreen to true/false block doesn't make sense on how the Fullscreen API works. Fullscreen API is a tricky thing to explain, as the API uses different sets to make it function. Fullscreen API functions using the sub window API called "window.document" which has its own set of APIs. To enter Fullscreen, it uses ANOTHER SUB API within "window.document", which is "window.document.documentElement", and to enter Fullscreen, we use "document.documentElement.requestFullscreen()". This is because ".documentElement.requestFullscreen" can be added to any element within the window, not just the window. Now for exiting, that doesn't even use "document.documentElement", but uses just "window.document" for some odd reason. So to exit we run "document.exitFullscreen()". So we don't just set Fullscreen to true or false. So enter/exit cannot be deprecated, nor can "set Fullscreen to true/false" be added. BUT... Based on the reporter named simply "Fullscreen" that most likely returns if the window is in Fullscreen or not IS POSSIBLE. There is an official API that returns true or false in correlation to the window being Fullscreen or not. And I actually did have plans to add a boolean named, "is window fullscreen?", but I had forgotten to add it. But I will be adding this in the next version of Window Controls.
You can find more details about the Fullscreen API in depth here: https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API

Oh wow, amazing. Is there a link or github page for the newest extension file?

Oh wow, amazing. Is there a link or github page for the newest extension file?

Go to the top and click on "Window Controls" in the "Window Controls > Master" boxes

Now what's left is to be able to fullscreen, get the width and height of the display/screen, and to minimize, maximize, and change the ability of a window to be resizeable.
Also imagine what we could do if we could open apps using scratch, like export 2 exe projects, and run the exe/open the project using scratch code.

Now what's left is to be able to fullscreen, get the width and height of the display/screen, and to minimize, maximize, and change the ability of a window to be resizeable.
Also imagine what we could do if we could open apps using scratch, like export 2 exe projects, and run the exe/open the project using scratch code.

this extension already has fullscreen supports

Now what's left is to be able to fullscreen, get the width and height of the display/screen, and to minimize, maximize, and change the ability of a window to be resizeable.
Also imagine what we could do if we could open apps using scratch, like export 2 exe projects, and run the exe/open the project using scratch code.

@creepersaur This extension can already enter and exit fullscreen. It can also already get the width and height of the screen, hence the screen x/y reporters. I'm not exactly sure what you mean by setting the ability of a window to be resizeable. And finally, I already have plans to add blocks that can minimize and maximize the window, but they won't be added among a ton others once I fully have a list of which BrowserWindow apis I want GarboMuffin to add.

Now what's left is to be able to fullscreen, get the width and height of the display/screen, and to minimize, maximize, and change the ability of a window to be resizeable.
Also imagine what we could do if we could open apps using scratch, like export 2 exe projects, and run the exe/open the project using scratch code.

@creepersaur This extension can already enter and exit fullscreen. It can also already get the width and height of the screen, hence the screen x/y reporters. I'm not exactly sure what you mean by setting the ability of a window to be resizeable. And finally, I already have plans to add blocks that can minimize and maximize the window, but they won't be added among a ton others once I fully have a list of which BrowserWindow apis I want GarboMuffin to add.

Ohh. I wasn't using the latest extension file. Now I see the screen w,h and the fullscreen, etc. This is very cool. The window resizeability means that currently, the user can drag on the corners of the application to change the size (w,h) of the window. Which you may not want in all cases. So the ability to stop the user from doing that could help. And also I don't know if this is possible, but removing the window border (including the edges of the application window and the top bar) so you could just have a plain window application, and then add your own border and things if you want.

Now what's left is to be able to fullscreen, get the width and height of the display/screen, and to minimize, maximize, and change the ability of a window to be resizeable.
Also imagine what we could do if we could open apps using scratch, like export 2 exe projects, and run the exe/open the project using scratch code.

@creepersaur This extension can already enter and exit fullscreen. It can also already get the width and height of the screen, hence the screen x/y reporters. I'm not exactly sure what you mean by setting the ability of a window to be resizeable. And finally, I already have plans to add blocks that can minimize and maximize the window, but they won't be added among a ton others once I fully have a list of which BrowserWindow apis I want GarboMuffin to add.

Ohh. I wasn't using the latest extension file. Now I see the screen w,h and the fullscreen, etc. This is very cool. The window resizeability means that currently, the user can drag on the corners of the application to change the size (w,h) of the window. Which you may not want in all cases. So the ability to stop the user from doing that could help. And also I don't know if this is possible, but removing the window border (including the edges of the application window and the top bar) so you could just have a plain window application, and then add your own border and things if you want.

@creepersaur Ahhh I see. I will try to add a block that counters window size change, but you can currently use a method where if the program detects the window size changes, then you can set the size back to the dimensions you want. And about window border, I'm not sure if it's possible, I thought of it, but from what I'm seeing, it may be only for .appx apps.

Now what's left is to be able to fullscreen, get the width and height of the display/screen, and to minimize, maximize, and change the ability of a window to be resizeable.
Also imagine what we could do if we could open apps using scratch, like export 2 exe projects, and run the exe/open the project using scratch code.

@creepersaur This extension can already enter and exit fullscreen. It can also already get the width and height of the screen, hence the screen x/y reporters. I'm not exactly sure what you mean by setting the ability of a window to be resizeable. And finally, I already have plans to add blocks that can minimize and maximize the window, but they won't be added among a ton others once I fully have a list of which BrowserWindow apis I want GarboMuffin to add.

Ohh. I wasn't using the latest extension file. Now I see the screen w,h and the fullscreen, etc. This is very cool. The window resizeability means that currently, the user can drag on the corners of the application to change the size (w,h) of the window. Which you may not want in all cases. So the ability to stop the user from doing that could help. And also I don't know if this is possible, but removing the window border (including the edges of the application window and the top bar) so you could just have a plain window application, and then add your own border and things if you want.

@creepersaur Ahhh I see. I will try to add a block that counters window size change, but you can currently use a method where if the program detects the window size changes, then you can set the size back to the dimensions you want. And about window border, I'm not sure if it's possible, I thought of it, but from what I'm seeing, it may be only for .appx apps.

Maybe this could help?

Now what's left is to be able to fullscreen, get the width and height of the display/screen, and to minimize, maximize, and change the ability of a window to be resizeable.
Also imagine what we could do if we could open apps using scratch, like export 2 exe projects, and run the exe/open the project using scratch code.

@creepersaur This extension can already enter and exit fullscreen. It can also already get the width and height of the screen, hence the screen x/y reporters. I'm not exactly sure what you mean by setting the ability of a window to be resizeable. And finally, I already have plans to add blocks that can minimize and maximize the window, but they won't be added among a ton others once I fully have a list of which BrowserWindow apis I want GarboMuffin to add.

Ohh. I wasn't using the latest extension file. Now I see the screen w,h and the fullscreen, etc. This is very cool. The window resizeability means that currently, the user can drag on the corners of the application to change the size (w,h) of the window. Which you may not want in all cases. So the ability to stop the user from doing that could help. And also I don't know if this is possible, but removing the window border (including the edges of the application window and the top bar) so you could just have a plain window application, and then add your own border and things if you want.

@creepersaur Ahhh I see. I will try to add a block that counters window size change, but you can currently use a method where if the program detects the window size changes, then you can set the size back to the dimensions you want. And about window border, I'm not sure if it's possible, I thought of it, but from what I'm seeing, it may be only for .appx apps.

Maybe this could help?

@BlueDome77 I already know of this, and I have it planned to add, but again, like I said a few comments ago, I'm still talking to GarboMuffin of which BrowserWindow APIs I want him to add. Once he does, I can add tons of new blocks, like min/max the window, and tons more.

My bad for not reading the previous comments

My bad for not reading the previous comments

It's fine

Ok, NOW Window Controls is fully ready for review.

Why'd you shoot down #778 and then add a block from it into your extension without any credit? I feel like it would be fine as it's own extension to be honest, it feels too different to this one.

Why'd you shoot down #778 and then add a block from it into your extension without any credit? I feel like it would be fine as it's own extension to be honest, it feels too different to this one.

It isn't necessary to have an extension that has a couple of blocks that are already implemented better in another extension.

Why'd you shoot down #778 and then add a block from it into your extension without any credit? I feel like it would be fine as it's own extension to be honest, it feels too different to this one.

It isn't necessary to have an extension that has a couple of blocks that are already implemented better in another extension.

They weren't implemented better though, given that OP had to add a crucial block from the other one. It was implemented, just not implemented well. That's not to say the other one is infinitely better, however telling someone to remove their PR because they already had those features, only to add those features later, is rather rude.

Why'd you shoot down #778 and then add a block from it into your extension without any credit? I feel like it would be fine as it's own extension to be honest, it feels too different to this one.

@NexusKitten, I had already had the boolean that checks for fullscreen status for a while now, I never added it in case this PR was going to be merged. Since it hasn't yet, I added the new boolean, and I did NOT take anything from the other PR, if you read the above comments about me explaining about fullscreen api, I had mentioned I had a an api ready to check fullscreen. Do not make such claims of me taking ones code.

Why'd you shoot down #778 and then add a block from it into your extension without any credit? I feel like it would be fine as it's own extension to be honest, it feels too different to this one.

It isn't necessary to have an extension that has a couple of blocks that are already implemented better in another extension.

They weren't implemented better though, given that OP had to add a crucial block from the other one. It was implemented, just not implemented well. That's not to say the other one is infinitely better, however telling someone to remove their PR because they already had those features, only to add those features later, is rather rude.

@NexusKitten, another thing, the blocks are made better by adding failsafe methods that don't give off errors, and allow for the blocks to run better.

Why'd you shoot down #778 and then add a block from it into your extension without any credit? I feel like it would be fine as it's own extension to be honest, it feels too different to this one.

@NexusKitten, I had already had the boolean that checks for fullscreen status for a while now, I never added it in case this PR was going to be merged. Since it hasn't yet, I added the new boolean, and I did NOT take anything from the other PR, if you read the above comments about me explaining about fullscreen api, I had mentioned I had a an api ready to check fullscreen. I've always been prepared to add the new block. Do not make such claims of me taking ones code.

I never once claimed you stole code, all I'm saying is that it's a little rude to shoot down someone else's PR (that already had a thumbnail and all, other than bug fixing, is completely ready to merge) just to add blocks from that PR into your extension without even a comment. It still feels like it either belongs in it's own extension, or (with credit to the extension creator and you) Browser Utilities, as fullscreen has nothing to do with "Window Controls."

Why'd you shoot down #778 and then add a block from it into your extension without any credit? I feel like it would be fine as it's own extension to be honest, it feels too different to this one.

@NexusKitten, I had already had the boolean that checks for fullscreen status for a while now, I never added it in case this PR was going to be merged. Since it hasn't yet, I added the new boolean, and I did NOT take anything from the other PR, if you read the above comments about me explaining about fullscreen api, I had mentioned I had a an api ready to check fullscreen. I've always been prepared to add the new block. Do not make such claims of me taking ones code.

I never once claimed you stole code, all I'm saying is that it's a little rude to shoot down someone else's PR (that already had a thumbnail and all, other than bug fixing, is completely ready to merge) just to add blocks from that PR into your extension without even a comment. It still feels like it either belongs in it's own extension, or (with credit to the extension creator and you) Browser Utilities, as fullscreen has nothing to do with "Window Controls."

@NexusKitten, didn't I just say the blocks we're already present in my extension, and have no relation to the other extension at all. I added fullscreen because, like the other blocks, modifies the state of the Window. Fullscreen blocks were one of the first blocks added to this extension, you may even check the commit history.

Again, recheck everything in this PR before making assumptions with what happened.

Again, recheck everything in this PR before making assumptions with what happened.

I'm not making any assumptions. I know you mentioned making a boolean a while ago. Still feels wrong that you shut down the other pull request even though it fits better there. They can fix the bug that shows an error with like 4 lines of code, and I feel like the blocks would belong better there or browser utilities. I mean, it's browser fullscreen; most features in the extension work mostly for electron.

Again, recheck everything in this PR before making assumptions with what happened.

I'm not making any assumptions. I know you mentioned making a boolean a while ago. Still feels wrong that you shut down the other pull request even though it fits better there. They can fix the bug that shows an error with like 4 lines of code, and I feel like the blocks would belong better there or browser utilities. I mean, it's browser fullscreen; most features in the extension work mostly for electron.

@NexusKitten, if you've been attentive in the Discord Server, or looked at the code for the HTML Documentation, you'll see that every single one of these blocks work outside of Electron, as this extension uses HTML based window api, meaning it works EVERYWHERE. Most blocks don't work in normal browser tabs due to browser security. But after vigorous testing, Window Controls works in Electron, HTML Pop Up tabs, Web Apps, and more.

put that ones that work in Electron only under a BlockType.LABEL, perhaps

@GarboMuffin I could, but basically all of them work in electron only. So it could mess up the entire order. So I'll just define in documentation that most work in electron only.

You need to make a label saying the blocks only work in electron. The kind of people who would be making issues about it not working in browser are the kind of people who don't read the documentation.

@LilyMakesThings Ahhhh like that one other extension I forgot the name of that had a label stating something important. Alright I will do that tomorrow with some more block additions and documentation and anything else. Then everything should be ready.

Where is that label?

put that ones that work in Electron only under a BlockType.LABEL, perhaps

@GarboMuffin I could, but basically all of them work in electron only. So it could mess up the entire order. So I'll just define in documentation that most work in electron only.

this you

Also you can't close the window while its moving and the move window to the [position] block seems to do nothing

put that ones that work in Electron only under a BlockType.LABEL, perhaps

@GarboMuffin I could, but basically all of them work in electron only. So it could mess up the entire order. So I'll just define in documentation that most work in electron only.

this you

This is prior to testing vigorously, if you want, I can send a video right now of everything working.

put that ones that work in Electron only under a BlockType.LABEL, perhaps

@GarboMuffin I could, but basically all of them work in electron only. So it could mess up the entire order. So I'll just define in documentation that most work in electron only.

You need to make a label saying the blocks only work in electron. The kind of people who would be making issues about it not working in browser are the kind of people who don't read the documentation.

@LilyMakesThings Ahhhh like that one other extension I forgot the name of that had a label stating something important. Alright I will do that tomorrow with some more block additions and documentation and anything else. Then everything should be ready.

Where is that label?

It's no longer needed.

put that ones that work in Electron only under a BlockType.LABEL, perhaps

@GarboMuffin I could, but basically all of them work in electron only. So it could mess up the entire order. So I'll just define in documentation that most work in electron only.

You need to make a label saying the blocks only work in electron. The kind of people who would be making issues about it not working in browser are the kind of people who don't read the documentation.

@LilyMakesThings Ahhhh like that one other extension I forgot the name of that had a label stating something important. Alright I will do that tomorrow with some more block additions and documentation and anything else. Then everything should be ready.

Where is that label?

It's no longer needed.

why?

put that ones that work in Electron only under a BlockType.LABEL, perhaps

@GarboMuffin I could, but basically all of them work in electron only. So it could mess up the entire order. So I'll just define in documentation that most work in electron only.

You need to make a label saying the blocks only work in electron. The kind of people who would be making issues about it not working in browser are the kind of people who don't read the documentation.

@LilyMakesThings Ahhhh like that one other extension I forgot the name of that had a label stating something important. Alright I will do that tomorrow with some more block additions and documentation and anything else. Then everything should be ready.

Where is that label?

It's no longer needed.

If I click a block and it does nothing, I'd put up an issue on the github. We don't want that to happen.

put that ones that work in Electron only under a BlockType.LABEL, perhaps

@GarboMuffin I could, but basically all of them work in electron only. So it could mess up the entire order. So I'll just define in documentation that most work in electron only.

You need to make a label saying the blocks only work in electron. The kind of people who would be making issues about it not working in browser are the kind of people who don't read the documentation.

@LilyMakesThings Ahhhh like that one other extension I forgot the name of that had a label stating something important. Alright I will do that tomorrow with some more block additions and documentation and anything else. Then everything should be ready.

Where is that label?

It's no longer needed.

why?

Because I added documentation specifying the support, and it was supposed to specify it's electron only, but after testing, no need to add it since it works anywhere.

Also you can't close the window while its moving and the move window to the [position] block seems to do nothing

What are you using the preset block on?

put that ones that work in Electron only under a BlockType.LABEL, perhaps

@GarboMuffin I could, but basically all of them work in electron only. So it could mess up the entire order. So I'll just define in documentation that most work in electron only.

You need to make a label saying the blocks only work in electron. The kind of people who would be making issues about it not working in browser are the kind of people who don't read the documentation.

@LilyMakesThings Ahhhh like that one other extension I forgot the name of that had a label stating something important. Alright I will do that tomorrow with some more block additions and documentation and anything else. Then everything should be ready.

Where is that label?

It's no longer needed.

why?

Because I added documentation specifying the support, and it was supposed to specify it's electron only, but after testing, no need to add it since it works anywhere.

You should probably fix some of the issues with the blocks
the move window block bricks turbowarp desktop!
Also the move to preset block doesn't seem to work.

put that ones that work in Electron only under a BlockType.LABEL, perhaps

@GarboMuffin I could, but basically all of them work in electron only. So it could mess up the entire order. So I'll just define in documentation that most work in electron only.

You need to make a label saying the blocks only work in electron. The kind of people who would be making issues about it not working in browser are the kind of people who don't read the documentation.

@LilyMakesThings Ahhhh like that one other extension I forgot the name of that had a label stating something important. Alright I will do that tomorrow with some more block additions and documentation and anything else. Then everything should be ready.

Where is that label?

It's no longer needed.

why?

Because I added documentation specifying the support, and it was supposed to specify it's electron only, but after testing, no need to add it since it works anywhere.

You should probably fix some of the issues with the blocks the move window block bricks turbowarp desktop!
Also the move to preset block doesn't seem to work.

what issues? I've tested everything, in all platforms, everything is perfect.
If your desktop app is bricked, it's because you made a script using Window Controls that makes the app have high ram usage, which slows the app and computer down, nothing you can do about that.
the preset block works, tell me how you're using it.

Here is the script I don't know how this would use all 64Gigs of ram

How extensive of testing have you done?

It's because the blocks work instantly, since you're using it in a forever loop, it moves the window at a speed you can't even comprehend, which can make the window unusable, in order to counter it, at the end of the loop, like under change window, add "wait 0 seconds".

How extensive of testing have you done?

Hours upon hours of testing, so I know my extension inside out, and tried everything.

It's because the blocks work instantly, since you're using it in a forever loop, it moves the window at a speed you can't even comprehend, which can make the window unusable, in order to counter it, at the end of the loop, like under change window, add "wait 0 seconds".

I prefer using wait 0.01 seconds for a better effect, but 0 seconds is the base recommendation.

Let's move this conversation to Discord.

It's because the blocks work instantly, since you're using it in a forever loop, it moves the window at a speed you can't even comprehend, which can make the window unusable, in order to counter it, at the end of the loop, like under change window, add "wait 0 seconds".

Issue. The forever loop when screen is refreshed waits a frame.

It's because the blocks work instantly, since you're using it in a forever loop, it moves the window at a speed you can't even comprehend, which can make the window unusable, in order to counter it, at the end of the loop, like under change window, add "wait 0 seconds".

Issue. The forever loop when screen is refreshed waits a frame.

This is something I can't fix, this is just how the API works.

It's because the blocks work instantly, since you're using it in a forever loop, it moves the window at a speed you can't even comprehend, which can make the window unusable, in order to counter it, at the end of the loop, like under change window, add "wait 0 seconds".

Issue. The forever loop when screen is refreshed waits a frame.

This is something I can't fix, this is just how the API works.

Nonetheless, it feels like it's an issue that needs to be addressed. You could:

Remove the "change by" blocks to discourage the blocks being used in a loop.
Automatically limit the rate the API can fire in the code
Ask the user's permission before moving the screen, to avoid random bricking of windows.
If it were up to me, I'd like all 3 to be in place, but ultimately, anything working against bricking the user's window with 6 blocks of code is a step in the right direction.

It's because the blocks work instantly, since you're using it in a forever loop, it moves the window at a speed you can't even comprehend, which can make the window unusable, in order to counter it, at the end of the loop, like under change window, add "wait 0 seconds".

Issue. The forever loop when screen is refreshed waits a frame.

This is something I can't fix, this is just how the API works.

You could make the blocks request a screen redraw.

It's because the blocks work instantly, since you're using it in a forever loop, it moves the window at a speed you can't even comprehend, which can make the window unusable, in order to counter it, at the end of the loop, like under change window, add "wait 0 seconds".

Issue. The forever loop when screen is refreshed waits a frame.

This is something I can't fix, this is just how the API works.

You could make the blocks request a screen redraw.

Can you tell me how? I will experiment it.

can you tell me how? I will experiment it.

Scratch.vm.runtime.requestRedraw()

Ok, now Window Controls is TRULY done. It is ready to be merged.

I give up having to comstantly remove .vscode, which is force adding itself to my repo for some reason.

Ok, Window Controls is ready to be merged, for real this time.

Regarding https://github.com/TurboWarp/extensions/pull/778#issuecomment-1663121242

What do you mean by "unnecessary"? All blocks in Window Controls are necessary, without any of the ones in the current palette, there's no reason for Window Controls to exist.

When @LilyMakesThings said your blocks were unnecessary, what she meant is that the beginning of the block pallet is bloated. Due to lack of dropdowns, the first two sections have 8 and 11 blocks each, when realistically it could function with 3 each. While blocks such as "change window _ by ()" are useful, having them as their own separate blocks bloat the pallet quite a bit, and makes it so you have to scroll quite a bit to get to the other functions of the extension.

It would be perfect to say that Window Controls will soon be an extension with the most blocks in the entirety of all the extensions available when I'm done with it.

No offense in saying this, but this phrasing makes the extension feel like a Utilities extension. I and most others had assumed the extension's main purpose was to manipulate window position and size, however there's now several other blocks (some of which are already in other extensions) that do not pertain to that theme. I saw where you said that the theme that ties your extension together is window.document, however I believe this theme to be far too vague. It's like justifying an extension because it has blocks, it's technically true, but is far too vague to actually gauge the extension's contents by looking at it.

All in all I feel as if the best course of action would be to remove the "window title," "window focused," and "window fullscreen" blocks from the extension. All of these blocks are already in other PRs (#614 and #778 respectively), and feel off-topic to the extension's primary function. With it's new patches, the window manipulation blocks work really well, however I feel like the extension should stick to that rather than expand to all things window related.

Following from what @NexusKitten said, the best TurboWarp extensions have the smallest palettes. It's a terrible mindset to aim for quantity over quality, as is very much implied in "Window Controls will soon be an extension with the most blocks of all extensions available".
This palette can produce the exact same functionality of the current extension, but isn't unnecessarily large. Consider limiting the palette.

Regarding #778 (comment)

What do you mean by "unnecessary"? All blocks in Window Controls are necessary, without any of the ones in the current palette, there's no reason for Window Controls to exist.

When @LilyMakesThings said your blocks were unnecessary, what she meant is that the beginning of the block pallet is bloated. Due to lack of dropdowns, the first two sections have 8 and 11 blocks each, when realistically it could function with 3 each. While blocks such as "change window _ by ()" are useful, having them as their own separate blocks bloat the pallet quite a bit, and makes it so you have to scroll quite a bit to get to the other functions of the extension.

It would be perfect to say that Window Controls will soon be an extension with the most blocks in the entirety of all the extensions available when I'm done with it.

No offense in saying this, but this phrasing makes the extension feel like a Utilities extension. I and most others had assumed the extension's main purpose was to manipulate window position and size, however there's now several other blocks (some of which are already in other extensions) that do not pertain to that theme. I saw where you said that the theme that ties your extension together is window.document, however I believe this theme to be far too vague. It's like justifying an extension because it has blocks, it's technically true, but is far too vague to actually gauge the extension's contents by looking at it.

@NexusKitten, I don't have much time to explain everything, as it's late night for me, but I specifically state this extension gives you control over every aspect of the Window. This wasn't an extension to just move and resize the window only. Everything you can do to a window is what I want to have in Window Controls. It's my choice because it just makes sense, and I understand about me being able to compress it all, but it still just feels natural not compressing it. Window Controls end goal is to be the go to extension for anything related to the window, as it wants to give you full control over the window in any way. This is my choice Nexus, I hope you can respect that. Again, so much more I want to say, but little time...

If you want to keep this extension to precisely your (as well as BlueDome's) vision, there's obviously nothing wrong with that. It is your extension (as well as BlueDome's). But so long as you do that, you can't stop others from making an equivalent extension that's more aligned with what they need if you can't adjust it with criticism, and it's for that reason shouldn't be going onto other PRs and claiming them to be redundant by the existence of this extension.

Ok Window Controls is ready, like actually ready.

Also, I hate to bring this up again, but are you sure you're giving enough credit to everyone involved in making this extension? I don't know what BlueDome and you discussed, however from the looks of it he made most of the extension, including the move window blocks, resize window blocks, and window title blocks. Actually, in accordance with @LilyMakesThings's and I's advice, I'd consider the original to be superior to this version. However, the only credit I see for BlueDome is right at the bottom of the documentation and feels a little biased (if you read it with a blank slate, it basically says "Mostly by Cubester, and BlueDome did a few things too."
Again, I don't know what you guys have discussed regarding this extension, and if BlueDome has agreed to this, it's fine, however it feels rather rude considering you took the base of their first extension and put your name on it as the main creator.

How to load html?

How to load html?

huh

How to load html?

Can you elaborate what you want to say please?

How to load html?

Can you elaborate what you want to say please?

So the ext is in html and it does not want to load

How to load html?

Can you elaborate what you want to say please?

So the ext is in html and it does not want to load

You're probably trying to load the docs page instead of the actual .js file.

How to load html?

Can you elaborate what you want to say please?

So the ext is in html and it does not want to load

You're probably trying to load the docs page as an extension instead of the actual .js file.

Where can I find the js ext?

Where can I find the js ext?

https://raw.githubusercontent.com/TurboWarp/extensions/95dd29343e26e705a37d59a7e3528848665b1558/extensions/CubesterYT/WindowControls.js

Where can I find the js ext?

https://raw.githubusercontent.com/CubesterYT/Turbowarp-Extensions/WindowControls/extensions/CubesterYT/WindowControls.js (just note that this will not be loaded unsandboxed as it is not on extensions.turbowarp.org)

I found it thanks anyways for this extension!

Updated the PR to latest changes of this repo because of the migration to Markdown Docs, but I don't have the time right now to convert them to Markdown, so I updated for now future proof the migration.

There is one more update I need to do, I'll do that tommorrow.

Why did you move TurboHook so far up?

Still a couple more things to do, but I gotta wait till I get home.

The wonders of Meta Games begins here.

Welp, Window Controls V.1.0.0 is officially, truly, done. Even though it already was, the new TW updates allowed me to make it better. Now Window Controls is ready for merging.

In some regards I question how necessary some of these blocks are but okay, that''s fine, don't need to change
Last thing is making sure that people are aware that like half of these blocks won't work in the online editor, only desktop app and packaged projects as Electron

In some regards I question how necessary some of these blocks are but okay, that''s fine, don't need to change
Last thing is making sure that people are aware that like half of these blocks won't work in the online editor, only desktop app and packaged projects as Electron

I thought of that, in the documentation at the top, I state the places it mainly works in.

I'm going to change something later in this updated code, I'll explain why later.

Then I think I have an idea, I'll have to test it though.

Ok finished making the changes. Prettier is my new enemy, at least eslint let you keep your own style.

Wait, let me add an example Project

Nevermind, I'll do example project later, so it's ready for now.


feat: fill in proof of Array.erase_data

I also added some lemmas in List.Lemmas that were necessary.
I'm not sure about the naming of some of the lemmas I added, so I would appreciate feedback!

awaiting-review

Oops 🤦  Linter errors should be fixed now

Otherwise looks good.

I thought it was a bit ugly that this PR had to unfold morally private definitions from core like eraseIdxAux so I made a PR which would allow us to simply unfold feraseIdx instead: leanprover/lean4#3676. If that PR gets merged it will break the proofs here.

as I said on the other PR @timotree3: In the case that your PR gets merged (and std4's lean-toolchain gets bumped) I have a commit lying around that fixes the proof https://github.com/Seppel3210/std4/commit/109c3ce97e182813a166c9b55418d9a599a01bb6

I think it makes sense to wait for the lean4 version to get bumped since the lean4 PR was merged. Or should I PR it to the bump branch instead? (@semorrison you probably know this)

Yes, if you'd like to PR to bump/v4.8.0 that's fine. It's also fine to wait: hopefully the release will be out next Tuesday.

Sorry, the release was much delayed, but now should be out in the next few days again!

Not really sure who to ping for this issue :sweat_smile: @semorrison

Let's summon @nomeata.

I think the problem isn’t with feraseIdx.induct per se, but rather with rw [eraseIdx], because
diff --git a/Std/Data/Array/Lemmas.lean b/Std/Data/Array/Lemmas.lean
index 31d9a385..a56c8c5e 100644
--- a/Std/Data/Array/Lemmas.lean
+++ b/Std/Data/Array/Lemmas.lean
@@ -843,16 +843,24 @@ theorem eraseIdx_swap_data {l : Array α} (i : Nat) (lt : i + 1 < size l) :
       simp [swap_def, List.set_succ, getElem_eq_data_get]
     simp [this, ih]

+theorem feraseIdx_eq (a : Array α) (i : Fin a.size) :
+  a.feraseIdx i =
+    if h : ↑i + 1 < a.size then
+      let a' := a.swap ⟨↑i + 1, h⟩ i;
+      let i' : Fin a'.size := ⟨i.val + 1, by simp [a', h]⟩
+      a'.feraseIdx i'
+    else a.pop := by rw [feraseIdx]
+
 theorem feraseIdx_data {l : Array α} {i : Fin l.size} :
     (l.feraseIdx i).data = l.data.eraseIdx i := by
   induction l, i using feraseIdx.induct with
   | @case1 a i lt a' i' _ ih =>
-    rw [feraseIdx]
+    rw [feraseIdx_eq]
     simp [lt, ih, a', eraseIdx_swap_data i lt]
   | case2 a i lt =>
     have : i + 1 ≥ a.size := Nat.ge_of_not_lt lt
     have last : i + 1 = a.size := Nat.le_antisymm i.is_lt this
-    simp [feraseIdx, lt, List.dropLast_eq_eraseIdx last]
+    simp [feraseIdx_eq, lt, List.dropLast_eq_eraseIdx last]

 @[simp] theorem erase_data [BEq α] {l : Array α} {a : α} : (l.erase a).data = l.data.erase a := by
   let ⟨xs⟩ := l

moves the error there.
The problem is that eraseIdx.eq_1 has these unnecessary have on the right-hand side.
The proper fix that I’d advocate for is to move everything that’s only needed for the termination argument into decerasing_by, this way you get the proper equational lemma.
If you don't want to wait with this PR until that lands, just mark the proof as nolint until this is fixed (import Std.Tactic.Lint.Misc, @[nolint unusedHavesSuffices] -- explanation).

should be good now @semorrison

awaiting-review

awaiting-review

not sure why this is waiting on me again… I intended to push the TODO in another PR since this one is already pretty big, but I can also do it in this one I guess.

awaiting-review

awaiting-review

thanks for taking a look!

awaiting-review


Process chapter names as well

Chapter names are used for rendering the sidebar table of contents. When it contains latex markup, then it's rendered correctly in the chapter contents, but the sidebar has the unrendered latex source code.
The processing is a matter of adding chapter.name to the rendering queue in preprocess::KatexProcessor::run and then popping it back. Preferable it would also pass a flag to get_render_tasks so that every ToC entry doesn't have its own reference to the stylesheet header.
This issue is blocked on https://github.com/rust-lang/mdBook/issues/2179, because otherwise the result is even worse than having raw latex in the sidebar.

Hi @VojtechStep. Given that you want this feature, I suggest that you implement it to your liking and I will help merge your PR.

I will submit a PR once the mentioned mdbook issue is solved 👍


LoadOrCompute should document intended per-key behavior

I was wondering if xsync.MapOf holds fine grained locks (per key) on LoadOrCompute(). The documentation doesn't say much about how the function is expected to behave. e.g. would LoadOrCompute('keyA', slowInitializer(a)) block out LoadOrCompute('keyB', slowinitializer(b))?
Wrote a quick test for it:
package main

import (
	"github.com/puzpuzpuz/xsync/v3"
	"sync"
	"time"
)

func main() {
	testM := xsync.NewMapOf[string, int]()
	wg := sync.WaitGroup{}
	wg.Add(3)
	go func() {
		value, loaded := testM.LoadOrCompute("key-one", func() int {
			println("INNER 1 ran")
			time.Sleep(1 * time.Second)
			return 1
		})
		println("FIRST LOADED", loaded, value)
		wg.Done()
	}()
	go func() {
		time.Sleep(500 * time.Millisecond)
		value, loaded := testM.LoadOrCompute("key-one", func() int {
			println("INNER 2 ran")
			time.Sleep(1 * time.Second)
			return 2
		})
		println("SECOND LOADED", loaded, value)
		wg.Done()
	}()

	go func() {
		time.Sleep(100 * time.Millisecond)
		value, loaded := testM.LoadOrCompute("key-two", func() int {
			println("INNER 3 ran")
			time.Sleep(1 * time.Second)
			return 3
		})
		println("THIRD LOADED", loaded, value)
		wg.Done()
	}()

	wg.Wait()

}

Output is:
INNER 1 ran
INNER 3 ran
FIRST LOADED false 1
SECOND LOADED true 1
THIRD LOADED false 3

I expected the third go routine (operating on key-two) not to get blocked by the initializers for the other keys. Reading the code, I guess it makes sense that it does get blocked.

Is there a better way to achieve what I want to achieve ? I was hoping I'd avoid making my own map of sync.Once's

Would be helpful to clarify this behavior in the docs

Error in my code, sorry!

Glad that you found the solution.

The documentation doesn't say much about how the function is expected to behave. e.g. would LoadOrCompute('keyA', slowInitializer(a)) block out LoadOrCompute('keyB', slowinitializer(b))?

When Compute path of the LoadOrCompute method kicks in, it locks the hash table bucket holding keyA. So, if keyB's hash code has the same lower bits as keyA's one, they will be stored in the same bucket and LoadOrCompute('keyB', slowinitializer(b)) would have to wait until Compute on keyA finishes.
On the other hand, the number of buckets starts with 32 on an empty map and grows as the power of 2. In practice it means that a map has quite many buckets which lowers the chance of bucket collisions for Compute calls.

Thanks for the information. Yeah I'm using the map as a "room" table for a chat like server (with a blocking initializer). The behavior of the locked-if-same-bucket is unreliable for these types of cases, I think the function should probably be clarified that it behaves that way (and that its dependent on the hash/bucket palcement). I would have probably been bitten by this if I hadn't dug in deeper.
I ended up writing a OnceMap type thing that uses singleflight to guard the initializer:
package utils

import (
	"github.com/puzpuzpuz/xsync/v3"
	"golang.org/x/sync/singleflight"
)

type OnceMap[T any] struct {
	dat   *xsync.MapOf[string, T]
	group singleflight.Group
}

func (o *OnceMap[T]) LoadOrCompute(key string, fn func() (T, error)) (T, error) {
	// Check cache
	value, found := o.dat.Load(key)
	if found {
		return value, nil
	}
	_, err, _ := o.group.Do(key, func() (interface{}, error) {
		// try again
		if _, found := o.dat.Load(key); found {
			return nil, nil
		}
		// compute
		data, innerErr := fn()
		if innerErr == nil {
			o.dat.Store(key, data)
		}
		return nil, innerErr
	})
	value, _ = o.dat.Load(key)
	return value, err
}

func NewOnceMap[T any]() *OnceMap[T] {
	return &OnceMap[T]{
		dat:   xsync.NewMapOf[string, T](),
		group: singleflight.Group{},
	}
}

That's a good input. I'll update the godoc, so that the locking behavior is clear.


🐛 [firebase_messaging] subscribeToTopic hanging on error

Bug report
Describe the bug
While setting up firebase messaging I noticed that when subscribeToTopic errors it sometimes hangs instead of throwing. The reason I think it is erroring is because I am getting a firebase log "Error when communicating with the Firebase Installations server API" when calling subscribeToTopic. And then the future never completes. But it seems like it does complete with an error in other invalid states, like when I subscribe to a topic with a "/" in it (ex: "topic/1"). I have only seen the hanging behavior when I get a "Error when communicating with the Firebase Installations server API. HTTP response: [403 Forbidden:" log
Steps to reproduce
Steps to reproduce the behavior:

Setup invalid google-serivces.json (Still figuring out what is wrong with mine)
Initialize Firebase normally and subscribe to a topic

Expected behavior
I expect the future to complete with an error if the subscribeToTopic fails. The hanging behavior makes error handling extremely difficult/impossible.
I will be putting together a sample project soon but I thought I would at least throw this out here in the meantime

I am seeing this issue across many different futures now so I think it is a problem elsewhere and not with flutter fire


[feat] Statistics view showing all statistics of all devices in single view

Is your feature request related to a problem? Please describe.
I have 90 or so devices. I find the statistics to be very useful but very hard to take advantage of as to find what devices are having issues I have to open the statistics for each device. Two clicks per device plus the scrolling means nearly 200 mouse operations to view all devices.
Describe the solution you'd like
A single view in a tabular format with each column showing device statistics would make it super quick to identify what devices are having issues. It would be nice for the view to also provide information such as when the statistics shown started (I assume last restart of zwavejs2mqtt but I don't know when that was with good accuracy without further hunting). Tool tip, or other, explaining a bit more what each tooltip means, and some way to raise awareness of what is bad would be nice. High message numbers may be bad if collected in a short period of time as they may represent excessive traffic, but may be OK if the collection time is extended. Showing what devices cause the majority of traffic would be great (percentage of total related messages)
Describe alternatives you've considered
Export to CSV file
Additional context
I have always had issues with excessive traffic on my mesh network. Issues were usually related to very chatty devices but I never had proof on which ones specifically or good ways to see the effects of my changes when trying to tone them down.

Hi @alexruffell ! Thanks for your issue. Looks interesting and super useful. I think that a general indication about how the device is performing could be implemented on zwavejs side too. Something that reports the general status of a node depending on how stats change over the time.
@AlCalzone ideas?

AFAIK z2m already has access to all the information necessary to generate such a view. Surely zwave-js could be extended give some hints, but the raw data is there as a first step.

Yep I already have all the information needed for it, just wondering if it could make sense to add to statistics updated event something that tells us an health status of that node based on them instead of implementing that logic on my side

I have a couple of plans in this regard, will take some time though.


new release version / git tag

Hey, its quite some time... its not really an "issue", but I would like to ask if you could consider to make a new release version.
The current git HEAD feels kind of stable and the last release is really long ago :smile:
thank you very much for this very useful tool and all the hard work that went into it :+1:

Merry Christmas!


migrate from semaphore to jenkins

 Issue by bcwaldon
Thursday Aug 06, 2015 at 22:25 GMT
Originally opened as https://github.com/coreos-inc/auth/issues/359

@bcwaldon out of curiosity, why switch from semaphore to jenkins?

@heckj Hi, Joe!
We have had a lot of issues with all hosted CI systems, not just semaphore, when it comes to automating docker builds. We haven't found something that provides a good experience around the multi-step build/test/publish process, where multiple calls to a docker daemon are required.
Semaphore, for example, doesn't actually have a public docker environment. One of our developers has been blessed with some special power to create projects with a "beta" docker environment. We're also still stuck writing a bash script, which is what I'm used to with Jenkins, but now I have no idea what I can trust to be on the build slave and I have no real power to debug and fix it when I run into issues (docker running hosts out of space, for example).
We are more than capable of running Jenkins, we just haven't had the time to get it properly configured. We have it running dex functional tests in our private instance, but ideally this is visible to the public.

Here here. I've resorted to the same with my projects of which build dockers in composition (+ release triggers).

@bcwaldon Hey Brian! Thanks - makes sense.
I still haven't shifted to building docker (or other container) images for anything I'm building directly yet. Are the relevant scripts in this repo? I'm kind of curious to see what you're doing and how you're doing it, just to keep up a bit. Or can you point me at a sample GIST or somethat that has the rough script?

@heckj :This is the Jenkins build script gist - all sub-scripts mentioned are in the root level of the repo:
https://gist.github.com/bobbyrullo/84cd5f0f24f68b1f3175

we're using travis for the foreseeable future.


npm package build fails

Environment

Dev OS: macOS 13.5.2
@rnmapbox/maps version: 10.1.1
React Native version: 0.72.4

Steps to reproduce

npm install @rnmapbox/maps
npm run android

Error:
e: file:///Users/xxx/work/mobile/mobile_app/node_modules/@rnmapbox/maps/android/src/main/java/com/rnmapbox/rnmbx/components/AbstractEventEmitter.kt:53:5 'addEventEmitters' overrides nothing

It's interesting as according to https://github.com/facebook/react-native/blame/746ad378c7efe3ee2f4926ab30e5401407f8b3ba/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/uimanager/ViewManager.java#L242
superclass of AbstractEventEmitter - ViewManager in react-native had the
  protected void addEventEmitters(@NonNull ThemedReactContext reactContext, @NonNull T view) {}

Unchanged for for years.
So not sure why the compiler error.

Yes, this is strange.
I tried the same with "vanilla" project and it compiles ok.
So my project has something which causes the compilation error. Just hard to figure out what it is.

My 2 tips, is either your react-native version.  - check content of ViewManager.java. Or your kotlin settings in your Gradle files?

I'm closing this as this sound project specific then.

I ran into the exact same issue on my project.
Environment:

React Native: 0.72.4
@rnmapbox/maps: 10.1.15
kotlinVersion: 1.9.0
Gradle: 8.0.1

Downgrading Kotlin version to 1.8.0 helped resolve this:
buildscript {
    ext {
       ...
        kotlinVersion = '1.8.0'
    }
    ...
    dependencies {
       ...
        classpath('org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.0')
     }
}

Hope this helps :)

I got this working after upgraded react-native to version 0.73.1
They also switched to Kotlin.

Proposed a PR fix that worked for me, should be an easy patch if anyone else needs to implement it ASAP. Got the inspiration from https://github.com/invertase/react-native-google-mobile-ads/issues/511

Any progress there? The fix is easy to apply, but would be good to have working lib release without applying additional patch.

Like I mentioned earlier, the problem disappeared with the latest React native version.

I just encountered a similar issue, Android build fails after mapbox upgrade:
"react-native": "0.72.14",
"@rnmapbox/maps": "^10.1.21",
> Task :rnmapbox_maps:compileReleaseKotlin e: Incompatible classes were found in dependencies. Remove them from the classpath or use '-Xskip-metadata-version-check' to suppress errors e: /Users/runner/.gradle/caches/transforms-3/49101a29b9e4fb48ee2b093f44617f88/transformed/jetified-kotlinx-coroutines-android-1.8.0.jar!/META-INF/kotlinx-coroutines-android.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.6.0. e: /Users/runner/.gradle/caches/transforms-3/7fc092dbf0c43219afef390baa06b7b3/transformed/jetified-kotlin-stdlib-1.9.21.jar!/META-INF/kotlin-stdlib-jdk7.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.6.0. e: /Users/runner/.gradle/caches/transforms-3/7fc092dbf0c43219afef390baa06b7b3/transformed/jetified-kotlin-stdlib-1.9.21.jar!/META-INF/kotlin-stdlib-jdk8.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.6.0. e: /Users/runner/.gradle/caches/transforms-3/7fc092dbf0c43219afef390baa06b7b3/transformed/jetified-kotlin-stdlib-1.9.21.jar!/META-INF/kotlin-stdlib.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.6.0. e: /Users/runner/.gradle/caches/transforms-3/9134c1c30b1a5b9ad37dd095f699d011/transformed/jetified-kotlinx-coroutines-core-jvm-1.8.0.jar!/META-INF/kotlinx-coroutines-core.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.6.0.

@andreirat That is a bit different issue. See https://github.com/rnmapbox/maps/pull/3465/files
You might be able to work around that using
kotlinxCoroutinesCoreVersion = 1.6.4
kotlinxCoroutinesAndroidVersion = 1.6.4

Add this to your andorid/build.gradle file after  kotlinVersion = 1.6... in buildscript { ext {

@andreirat That is a bit different issue. See https://github.com/rnmapbox/maps/pull/3465/files
You might be able to work around that using
kotlinxCoroutinesCoreVersion = 1.6.4
kotlinxCoroutinesAndroidVersion = 1.6.4

Add this to your andorid/build.gradle file after kotlinVersion = 1.6... in buildscript { ext {

@mfazekas already did that, but it would break other packages we are using. It worked with RN version 0.72.4.

@mfazekas

datadog
react-native-screens
mapbox still throws this

The class is loaded from /Users/andreirat/.gradle/caches/transforms-3/5d727cf8e0ce4b87b50c99126e24b794/transformed/jetified-kotlin-stdlib-1.9.21.jar!/kotlin/Unit.class
e<EMAIL_ADDRESS>(16, 10): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.6.0.
The class is loaded from /Users/andreirat/.gradle/caches/transforms-3/5d727cf8e0ce4b87b50c99126e24b794/transformed/jetified-kotlin-stdlib-1.9.21.jar!/kotlin/Unit.class
e<EMAIL_ADDRESS>(20, 5): Unresolved reference:

@mfazekas downgraded to "@rnmapbox/maps": "10.1.17", and the build works. I wonder if this version covers all the Apple Privacy warnings?

I had the same issue that @andreirat,  Environment:

React Native: 0.72.6
@rnmapbox/maps: 10.1.21
kotlinVersion: 1.9.0

and downgraded to @rnmapbox/maps: 10.1.17, and it works


Azure App Service SSL Configuration Question

Hello everyone,
This isn't an issue as much of a question since I believe django-axes is behaving properly.
I have this particular Django app deployed to Azure App Services which uses SSL.  I have also read through the other posts/documentation that resolved this by adding the following to the settings.py file:
AXES_META_PRECEDENCE_ORDER = [
'HTTP_X_FORWARDED_FOR',
'REMOTE_ADDR',
]
I have added middleware to print out HTTP_X_FORWARDED_FOR and REMOTE_ADDR just to make sure the headers are valid.  I can see that X_FORWARDED_FOR has the user's IP address and port in it.  However, only the REMOTE_ADDR is getting logged to the database.  Which is always the same - <IP_ADDRESS> for every user as it is the internal address of the App Service instance.
I don't know if I am missing something simple here or not.  I'm also not sure if this would even work properly with django-ipware with the way App Services works on azure.  It is a dockerized instance with private IP addressing that App Service then relays https to.  At least, that is what I believe is happening.
I'm just looking for some advice on where to go next.
Thanks.

This was a configuration issue on my part.
I read through ipware documentation and this is working now with the following precedence order:
AXES_META_PRECEDENCE_ORDER = [
'HTTP_X_FORWARDED_FOR', 'X_FORWARDED_FOR',  # , ,
'REMOTE_ADDR',
]