Improve Group

Subject
At now Group has 2 difference ways to create itself.

new Group($prefix, callable $callback, $container)
Group::create($prefix, array $routes, $container)

I suggest to combine this 2 methods to one: Group::create($prefix, array|callable $routes, $container)
Why?

Uniform code is more simpler and cleaner.
Developer no need to remebmer all ways to create the same object.

Why static factory method instead of the new operator?
Because Route has no way to create itself with the new operator.

Sounds good to me.

I sent a PR related to this issue :)


[Feature]: Payment customization - Add/override text/styles payment option

What area(s) will this request affect?
Function
What type of change do you want to see?
Substantial change to existing feature
Overview
We need to add content for some payment options and highlight payment option that we are focusing so
Can we provide an override text/styles(css) for payment options?

Motivation
At the moment we don't  know how to add/override content for payment option and override style for payment option. Please help provide a solution. Thank you very much

Hi! Thanks for the suggestion. I'm closing since this is not related to the CLI, but let me share it internally.
@nickwesselman could you please take care of this feature request?


Remove missing key so role doesn't fail with 404 error

Minimal fix, just removed the file that no longer exists on VMware's site

Thanks!


New cmdlet: Stop-PnPFlowRun

Type

[ ] Bug Fix
[x] New Feature
[ ] Sample

Related Issues?
Fixes #1836
What is in this Pull Request ?
New cmdlet to stop/cancel a specific Power Automate flow run.
Stop-PnPFlowRun -Environment Default-00000000-0000-0000-0000-000000000000 -Flow fba63225-baf9-4d76-86a1-1b42c917a182 -Identity<PHONE_NUMBER>2024670884771461819CU230

Thanks @milanholemans , have merged the PR !
Awesome stuff and great work :)


HHH-10422

Pull request to fix IDENTITY IDs when using Oracle12cDialect for Hibernate 5.0.
It adds a new method to Dialect (Dialect#getIdentityColumnSupport) which returns a IdentityColumnSupportImpl. IdentityColumnSupportImpl simply delegates back to Dialect methods (now deprecated) to determine what is needed for the dialect to support identities.
If an existing custom dialect implements the deprecated methods, it will still work because the implementations of IdentityColumnSupport will delegate to the custom Dialect methods.

Overall I am ok with this approach as long as we make some additional changes.  Specifically I do not like the fact that in most cases the direct Dialect methods are the "truth" whereas getting the Dialect's IdentityColumnSupport delegate is the "truth" for handling GetGeneratedKeysDelegate.  I personally find that confusing, and I doubt users will find it any less confusing.
One aspect I really like is that since we are now deprecating all the direct Dialect methods related to IDENTITY support, we can now remove those on master (5.1)

I think @gbadner used this approach to avoid custom dialects break

Applied as is upstream.  Because of this, we will also remove the deprecated Dialect methods on master (5.1) since they are now deprecated as of 5.0.


Break out Edit/Add config into multiple sections like current Manager

Making a note here for this form, inline label while updating form:


Loop doesn't work with two images in gallery

When loop is enabled and the gallery contains only two images, the loop doesn't work.

http://fotorama.io/customize/loop/

Requires three or more images.

Hello,
Thanks for replying.
May I ask why loop with 2 images is not possible?
Is it because how the animation works?
Thanks,
Refael
On Mon, Jun 20, 2016 at 1:52 PM, Берд Киви<EMAIL_ADDRESS>wrote:

http://fotorama.io/customize/loop/
Requires three or more images.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/artpolikarpov/fotorama/issues/480#issuecomment-227110773,
or mute the thread
https://github.com/notifications/unsubscribe/ACUbYuaUZOCzEhf0tdfH-z5cHOzKCkIvks5qNnD-gaJpZM4I0CCO
.

Artem too busy/lazy to realize it :)

Got it, I can try and take a look, I'm a front-end developer myself, but I
can't find the non-minified code.
Anyway, great script. Thanks
Refael
On Mon, Jun 20, 2016 at 2:15 PM, Берд Киви<EMAIL_ADDRESS>wrote:

Artem too busy/lazy to realize it :)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/artpolikarpov/fotorama/issues/480#issuecomment-227115009,
or mute the thread
https://github.com/notifications/unsubscribe/ACUbYqafcd_OQgtUzF6Eu0PGMMNA8W0Fks5qNnZagaJpZM4I0CCO
.

birdkiwi напишите пожалуйста на мою почту<EMAIL_ADDRESS>

@TapakaHoB  Зачем? Я не разработчик.

@birdkiwi  по поводу вашей программы-поздравлялки Вконтакте).

@rellect All transparent. The idea of loop with two images same as without him. You always see first and second image. And it not depends turn it on or not.
@TapakaHoB @birdkiwi  удалите пожалуйста сообщения не по теме.
Спасибо

find e.transition,Md=e.loop&&(zd>2||Sd&&(!Wd||"slide"!==Wd))  and replace zd>2 to zd>1

I am not found this string " e.transition,Md=e.loop&&(zd>2||Sd&&(!Wd||"slide"!==Wd))"(magento 2.2)


Report missing source or target root entry

reason: explain if an empty result is caused by a broken dn config

I actually don't know if the DN is broken or no results are returned because of something else.
But etd now errors out if no source or target records are found.


CFG_LOAD issues

Hi Tuan,
I have updated to your latest version with the makefile that clears out the configuration fields but I still have the issue with configuration not working correct. When I commented out the whole CFG load from memory I've got the things going. Is there any specific reason to write configuration in binary form since you have it anyway in your program?
See the code bellow:
void ICACHE_FLASH_ATTR CFG_Load()
{

	INFO("\r\nload ...\r\n");
/*	spi_flash_read((CFG_LOCATION + 3) * SPI_FLASH_SEC_SIZE,
				   (uint32 *)&saveFlag, sizeof(SAVE_FLAG));
	if (saveFlag.flag == 0) {
		spi_flash_read((CFG_LOCATION + 0) * SPI_FLASH_SEC_SIZE,
					   (uint32 *)&sysCfg, sizeof(SYSCFG));
	} else {
		spi_flash_read((CFG_LOCATION + 1) * SPI_FLASH_SEC_SIZE,
					   (uint32 *)&sysCfg, sizeof(SYSCFG));
	}
	if(sysCfg.cfg_holder != CFG_HOLDER){/**/
		os_memset(&sysCfg, 0x00, sizeof sysCfg);

		sysCfg.cfg_holder = CFG_HOLDER;

		os_sprintf(sysCfg.sta_ssid, "%s", STA_SSID);
		os_sprintf(sysCfg.sta_pwd, "%s", STA_PASS);
		sysCfg.sta_type = STA_TYPE;

		os_sprintf(sysCfg.device_id, MQTT_CLIENT_ID, system_get_chip_id());
		os_sprintf(sysCfg.mqtt_host, "%s", MQTT_HOST);
		sysCfg.mqtt_port = MQTT_PORT;
		os_sprintf(sysCfg.mqtt_user, "%s", MQTT_USER);
		os_sprintf(sysCfg.mqtt_pass, "%s", MQTT_PASS);

		sysCfg.security = DEFAULT_SECURITY;	/* default non ssl */

		sysCfg.mqtt_keepalive = MQTT_KEEPALIVE;

		INFO(" default configurations\r\n");

		CFG_Save();
//	}
	INFO("device_ID:%s\r\n",sysCfg.device_id);
	INFO("MQTTHOST:%s\r\n",sysCfg.mqtt_host);
}

Best regards,
K.

if you do like this, everytime boot, esp8266 will erase and rewrite default configurations, it would not be good for your memory with limit write count. if you want to change default configurations, please change CFG_HOLDER value

Hi,
Question is what if I take out cfg_save completely? Where else is this used
aside from initial boot?
On Saturday, January 31, 2015, Tuan PM<EMAIL_ADDRESS>wrote:

if you do like this, everytime boot, esp8266 will erase and rewrite
default configurations, it would not be good for your memory with limit
write count. if you want to change default configurations, please change
CFG_HOLDER value
—
Reply to this email directly or view it on GitHub
https://github.com/tuanpmt/esp_mqtt/issues/30#issuecomment-72306336.

it will load the default configuration every time boot and do not touch the flash memory

OK. I'll try to elaborate.
If we get rid of CFG_SAVE it will always put the values from user_config.h
into the memory and what we have in user_config.h will be loaded on every
reboot.
What is the reason to use CFG_LOAD in this case? Is it for having the
functionality of loading different configurations stored in different parts
of the memory?
Thanks.
On Sat, Jan 31, 2015 at 8:26 AM, Tuan PM<EMAIL_ADDRESS>wrote:

it will load the default configuration every time boot and do not touch
the flash memory
—
Reply to this email directly or view it on GitHub
https://github.com/tuanpmt/esp_mqtt/issues/30#issuecomment-72306809.

it is used to load the configuration from Flash to RAM, if your application can change the configuration at runtime, whenever changes and call CFG_SAVE, then boot it will take this configuration

Understood. Thank you. Makes a lot of sense if you change configurations
runtime indeed.
On Sat, Jan 31, 2015 at 8:34 AM, Tuan PM<EMAIL_ADDRESS>wrote:

it is used to load the configuration from Flash to RAM, if your
application can change the configuration at runtime, whenever changes and
call CFG_SAVE, then boot it will take this configuration
—
Reply to this email directly or view it on GitHub
https://github.com/tuanpmt/esp_mqtt/issues/30#issuecomment-72307048.


[dv/build_seed] Fix build seed errors

1). Fix regression error that should use otp-seed instead of seed
when generate OTP image.
2). Because the keyword seed and build_seed are both used in run
phase: seed for SV rand seed, and build_seed for build time random
script input. So we need to create a variable for build_seed,
otherwise the build_seed will be override by seed.
3). This is a temp solution, will need further support. If build_seed
mode is not enabled, we should not pass the --otp-seed args. But
current structure does not have a good way to handle this. In this PR,
I manually added the default seed number to generate OTP image.
Further support should be able to not pass the otp-seed args when it
is not under build_seed mode.
Signed-off-by: Cindy Chen<EMAIL_ADDRESS>

Not sure what was broken here to begin with - seed used in build phase is controled by --build-seed and the one used in run phase is controled by the runtime seed. They are of course different, but use the sane hjson variable 'seed'.

Hi Sri,
Michael mentioned the gen-otp-img script from run time also need the same build_seed as the gen-otp-mmap script in build phase.
By sharing the same name - I think somehow the runtime seed was override by SV seed instead of using the actual build_seed. So when generate otp image, we ended up getting a different parameters.

Having to enforce the same build seed also to be used during runtime is a bad idea - they need to be independent controlled. This breaks the --run-only mechanism.
I used the same hjson variable name 'seed' but intentionally, a different value get set during build stage and the run stage.

I will suggest reverting this pr and moving the otp mem map generation which is a pre run step as a pre build step instead.

If we move it to pre build step, then each build we will only use one rand values to generate OTP image. I think that was the only concern. If you think it is fine, totally down to move it to pre build.

I do agree with the --run-only mechanism! It will definitely create some issue there..

If we move it to pre build step, then each build we will generate one OTP image, while currently we are generating a slightly different OTP image for each run. I think that was the only concern. If you think it is fine, totally down to move it to pre build.

You are effectively doing the same in this PR, by using build seed in pre run cmd. Build seed is fixed for all tests. I find the changes to dvsim a bit concerning.

Yeah but the gen-otp-img script also has --otp-img {seed} that can randomize the rand values, which is different in every run phase.
I think maybe we can try changing the gen-otp-img script to automatically find the correct {build_seed} instead of manually input in pre_run_cmd.

Yeah but the gen-otp-img script also has --otp-img {seed} that can randomize the rand values, which is different in every run phase. I think maybe we can try changing the gen-otp-img script to automatically find the correct {build_seed} instead of manually input in pre_run_cmd.

Then that script will need to find some other way to know what seed was used during the build to dump those packages.


Support raml 1 spec

Use new raml-1-parser which supports both vers 0.8 and 1
of RAML
Closes #3

mm.strange, tests passes to me...I'll investigate and add new test for new RAML spec

Thanks for the PR. I didn't realize the new parser was ready. I'm not sure why the tests failed. I'll take a look tonight.

The API has changed in raml-1-parser so simply replacing the library won't work.


adding VS hospitalizations

In today's report the hospitalizations of the past days have also been adjusted. Should we include these updates?

The question remains, if the history should be adjusted. See #278


Add titledoo extension

Description
Add "titledoo", an extension that does one thing: capitalize your title according to The Chicago Manual of Style.
Based on title.sh.
Note
Name originally was simply title but the publish script kept telling me there was already an extension with that name, even though I could not find one. Naming things is hard, so I just named it titledoo because it sounds funny.
Screencast

https://github.com/raycast/extensions/assets/87162/464c699e-77c4-4dc3-a8bd-ca9c01ae6871
Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Hey @rafaelrinaldi ! Thank you so much for your contribution to Raycast!
My name is Milena and I will be reviewing your extension today.
We have an extension for changing case here. Would it make sense to add the Chicago Style to it? Or does it  already cover the use case as well?

Hey @mil3na! Thanks for pointing out that extension, I didn't know about it. Even though it does something similar, it seems like it is slightly different as in theirs seems to be more focused on programming and mine on grammar.

@mil3na Thanks for chiming in. I originally had implemented it with Form but it felt like an overkill as it is intended to only be used for titles. The example you gave should be unrealistic as it looks more like body text than title.
I understand if you don't want to include this but The Chicago Manual of Style has very specific rules and is a bit more complex than simply using title case.
Let me know if you want me to close the PR.

@rafaelrinaldi I understand your point, and I can see the use case for an extension focused on grammar rather than programming. What I'm suggesting here is to conform to good practices and usability rules.  You never know what your users are going to input.
With that said, I don't want you to close your PR, but rather change it a bit to make it broader for extreme use cases. I hope you understand my point of view. Let me know if you wanna discuss it. I'm on the Slack community.

@mil3na No problem at all! Whenever I have some free time I will switch it back to using Form and send it your way. Thanks for bearing with me!

Thank you as well, just ping me if anything :)


Improve SVG muscle select

Right now, the muscles are not selected if we click on the whitespace between the muscle sections. This could also cause problems on mobile, because it's not obvious what's clickable.
We should improve this by adding paths to the SVG around the muscle areas and updating the Illustration.js based on this.

Done!


Fix network providers

Bring the ifconfig and route into the second decade of the 21st century. Possibly ifconfig should be renamed to interface.

Route resource should support IPV6
ifconfig resource to support the new Network Manager keyfile format

I'm going to close this one out at this point. ifconfig in particular needs to get replaced with the modern systemd equiv, but that outside the scope of this issue.


[ROCm][XLA] Adding three passes to  amdgpu compiler

This CL (comes from discussions in #35991) introduced three passes to keep amdgpu_compiler in sync with nvptx_compiler:

reduction_degernerate_dim_remover
reduction_dimension_grouper
reduction_layout_normalizer

@whchung @cheshire

@cheshire Is it causing some internal failures? I don't have visibility in the import/copybara tab.

That's strange, let me try again.


grsecurity vanilla doesn't support virtualbox guestadditions but nixos tries to install them anyway

Issue description
When grsec is enabled and the machine is a virtualbox VM, nixos tries to build the guestadditions against a grsec kernel that isn't compiled with virtualization. This results in strange build failures for GuestAdditions.
The issue is a bit more complicated because the virtualisation is enabled in the hardware-config file and then grsec is enabled in the regular config file, which cause nixos-rebuild to succeed to build the grsec kernel but to fail to build the virtualbox guest additions.
Steps to reproduce

Setup virtualbox VM (optional, this would probably work on any host)
Set 'virtualisation.virtualbox.guest.enable = true;'
Set 'security.grsecurity.enable = true;'
Rebuild (nixos-rebuild switch)

Technical details

System: NixOS: 16.09beta335.7617e7e
Nix version: 1.11.4
Nixpkgs version: 16.09beta335.7617e7e

Virtualbox is unsupported on the stock grsec kernel.
The reason why the nixos grsec module doesn't assert non-virtualbox support is that it's designed to be somewhat kernel agnostic (i.e., to accommodate a custom kernel that might be configured to support virtualbox).
I'll look into adding checks on the kernel config so that you'll get a warning or build failure when combining virtualbox with a non-virtualbox capable grsec kernel.

The guest additions can be compiled on master now, whether it actually works is another matter, but I think there's nothing more to do here.


3 days ago game starts to force exception if Red2Ext is loaded

Fixed only if remove Red4ext then check game files validity (GOG game launcher will download 50 mb of some files and then game's working).
If i reinstall Red4ext - game falls again. Am using Vortex to install Red4Ext.

What is the exception what you are getting?

Ok, lets test from scratch:

I've marked all mods as Deleted in Vortex

I've pressed button "check game files"

I've set status "Enabled" on [Red4Ext]

Game launch without errors [ OK ]

I've set status "Enabled" on [Cyber Engine Tweeks (CET)]

Game launch without errors [ OK ]

I've set status "Enabled" on [redscript]

Game launch without errors [ OK ]

I've set status "Enabled" on [ArchiveXL]

I've set status "Deleted" on [ArchiveXL]

Game launch without errors [ OK ]

I've set status "Enabled" on [TweakXL]

Game launch without errors [ OK ]

I've set status "Deleted" on [Red4Ext]

I've set status "Enabled" on [ArchiveXL]

I've set status "Deleted" on [ArchiveXL]

I've set status "Enabled" on [Red4Ext]

Game launch without errors [ OK ]

I've set status "Enabled" on [Codeware]

Game launch without errors [ OK ]

I've set status "Enabled" on [Native Settings UI 1.96]

Game launch without errors [ OK ]

I've set status "Deleted" on ALL mods

I've set status "Enabled" on [ArchiveXL]

Game launch without errors [ OK ] (seems strange cause of ArchiveXL requires Red4Ext)

I've set status "Enabled" on [Red4Ext]

As a testing result there's a conflict between [ArchiveXL] and [Red4Ext] that is become 3 days ago, taking to the mind the ArchiveXL is stay the same.
Most of common mods like "Legendary Upgrade" needs ArchiveXL that needs Red4Ext.
Exception is critical.

If you're experiencing problems with ArchiveXL, the best course of action would be to ensure it's up to date. As for the RED4ext.SDK popups, they typically arise from third-party mods rather than issues within RED4ext itself.
As a note, the SDK serves as a foundation for all C++ plugins, which can contribute to these occurrences.

I've show you full way i made to reach the exception.
I mean i've deleted all other mods and then did test for you.
Check on your own side, call me on telegram. I speak english bad but i think we will handle it someway.

I read your post, and I saw that every time you enable ArchiveXL you have issues. From that post I understood that ArchiveXL is out of date, or your game is out of date.

To add to my reply above, RED4ext is loading ArchiveXL. Without RED4ext, ArchiveXL is not loaded in memory and you get the script error (second picture).

Dont shame to say "i dont know how to fix", its normal, but not in Cyberpunk itself.
About game out of date - "step 2 - verify game files". Gog keeps game actual.
About archivexl out of date - i reinstalled it 3 times, because it didnt change 3 days ago - conflict is about your changes in Red4ext with old code of ArchiveXL.
I hope you can just retry my steps on clear game installation to receive same errors. I cant ask you for the video, but the post needs to be retried and testet, not just read.

To add to my reply above, RED4ext is loading ArchiveXL. Without RED4ext, ArchiveXL is not loaded in memory and you get the script error (second picture).

If i load ArchiveXL WITHOUT Red4Ext - i get not error. Its strange btw, should be error of missing dependency or something.
If i load ArchiveXL AFTER Red4Ext - i get hash error.
If i load ArchiveXL AFTER DISABLING Red4Ext BUT ENABLED OTHER MODS - i get errors with russian letters cus of russian game locale.

Can you post your latest log file (red4ext-YYYY-MM-DD-HH-mm-ss.log) from <gamedir>\red4ext\logs?

ok, i can.
With mods or without? Or with just 2 mods (ext + archive) ?

With all mods enabled.

ok, doing

red4ext-2024-03-24-21-48-36.log
[2024-03-24 21:48:36.341] [RED4ext] [info] RED4ext (v1.24.3) is initializing...
[2024-03-24 21:48:36.341] [RED4ext] [info] Product version: 2.12
[2024-03-24 21:48:36.341] [RED4ext] [info] File version: <IP_ADDRESS>179
[2024-03-24 21:48:36.341] [RED4ext] [info] Loading game's addresses from 'E:\games\cyberpunk_2077\Cyberpunk 2077\bin\x64\cyberpunk2077_addresses.json'...
[2024-03-24 21:48:37.177] [RED4ext] [info] 908000 game addresses loaded
[2024-03-24 21:48:37.204] [RED4ext] [info] RED4ext has been successfully initialized
[2024-03-24 21:48:37.233] [RED4ext] [info] RED4ext is starting up...
[2024-03-24 21:48:37.233] [RED4ext] [info] Loading plugins...
[2024-03-24 21:48:37.233] [RED4ext] [info] Loading plugin from 'E:\games\cyberpunk_2077\Cyberpunk 2077\red4ext\plugins\ArchiveXL\ArchiveXL.dll'...
[2024-03-24 21:48:37.335] [RED4ext] [info] ArchiveXL (version: 1.12.0, author(s): psiberx) has been loaded
[2024-03-24 21:48:37.335] [RED4ext] [info] Loading plugin from 'E:\games\cyberpunk_2077\Cyberpunk 2077\red4ext\plugins\Codeware\Codeware.dll'...
[2024-03-24 21:48:37.582] [RED4ext] [info] Codeware (version: 1.8.1, author(s): psiberx) has been loaded
[2024-03-24 21:48:37.582] [RED4ext] [info] Loading plugin from 'E:\games\cyberpunk_2077\Cyberpunk 2077\red4ext\plugins\input_loader\input_loader.dll'...
[2024-03-24 21:48:37.587] [RED4ext] [info] Input Loader (version: 0.1.1, author(s): Jack Humbert) has been loaded
[2024-03-24 21:48:37.587] [RED4ext] [info] Loading plugin from 'E:\games\cyberpunk_2077\Cyberpunk 2077\red4ext\plugins\mod_settings\mod_settings.dll'...
[2024-03-24 21:48:37.609] [RED4ext] [info] Mod Settings (version: 0.2.8, author(s): Jack Humbert) has been loaded
[2024-03-24 21:48:37.609] [RED4ext] [info] Loading plugin from 'E:\games\cyberpunk_2077\Cyberpunk 2077\red4ext\plugins\TweakXL\TweakXL.dll'...
[2024-03-24 21:48:37.670] [RED4ext] [info] TweakXL (version: 1.8.1, author(s): psiberx) has been loaded
[2024-03-24 21:48:37.670] [RED4ext] [info] Loading plugin from 'E:\games\cyberpunk_2077\Cyberpunk 2077\bin\x64\Cyberpunk2077.exe'...
[2024-03-24 21:48:37.670] [RED4ext] [info] 5 plugin(s) loaded
[2024-03-24 21:48:37.670] [RED4ext] [info] RED4ext has been started

Lol, what a joke!
NOW, i really deleted ArchiveXL using RMB button then click "Completely delete with archive and files", reinstalled in from nexus mods and game launched without errors, as you recommend me.
Guess version conflict on ArchiveXL side on Nexusmod page. Same version number but different code.

Nice that you got it sorted :)


AttributeError: 'EntryPoints' object has no attribute 'get'

Hi, I got into this problem when I tried to run train.py to test my installation.
Message='EntryPoints' object has no attribute 'get'
Source=C:\Users\Jeff\Desktop\TraderMaster\TradeMaster-1.0.0\TradeMaster-1.0.0\trademaster\environments\custom.py
StackTrace:
File "C:\Users\Jeff\Desktop\TraderMaster\TradeMaster-1.0.0\TradeMaster-1.0.0\trademaster\environments\custom.py", line 2, in
import gym
File "C:\Users\Jeff\Desktop\TraderMaster\TradeMaster-1.0.0\TradeMaster-1.0.0\trademaster\environments_init_.py", line 1, in
from .custom import Environments
File "C:\Users\Jeff\Desktop\TraderMaster\TradeMaster-1.0.0\TradeMaster-1.0.0\tools\algorithmic_trading\train.py", line 15, in
from trademaster.environments.builder import build_environment
AttributeError: 'EntryPoints' object has no attribute 'get'
I'm currently on Cuda 12.1 with pytorch2

you may need to pip install celery pika. I've added them to requirements.txt

you may need to pip install celery pika. I've added them to requirements.txt

Thank you, that did fix it. Now I encounter a problem with Pytorch 2.0 removed torch.six
I will see if I can work around it.

ok, we have only tested on torch 1.12, please refer to https://github.com/TradeMaster-NTU/TradeMaster/blob/1.0.0/installation/requirements.md


When you build and run 'mobile_app' example for web it throws when navigating to index pages (Cupertino, Tabs, Indexed)

If I use the latest version 0.9.0-dev2 and build and run the bundled example mobile_app for web target and run it in Chrome, it throws the exception below during navigation. It seems to only happen when navigating to indexed pages. Also the exception was only thrown on the web build, not an Android or Widows build.
Maybe related to, or same as: https://github.com/tomgilder/routemaster/issues/110?
Error: Expected a value of type 'int', but got one of type 'Null'
    at Object.throw_ [as throw] (http://localhost:50338/dart_sdk.js:5037:11)
    at Object.castError (http://localhost:50338/dart_sdk.js:5010:15)
    at Object.cast [as as] (http://localhost:50338/dart_sdk.js:5319:17)
    at Function.as (http://localhost:50338/dart_sdk.js:18043:19)
    at _engine.EnginePlatformDispatcher.__.[_sendPlatformMessage] (http://localhost:50338/dart_sdk.js:157130:75)
    at _engine.EnginePlatformDispatcher.__.sendPlatformMessage (http://localhost:50338/dart_sdk.js:157034:33)
    at _DefaultBinaryMessenger.[_sendPlatformMessage] (http://localhost:50338/packages/flutter/src/services/system_channels.dart.lib.js:2110:38)
    at _DefaultBinaryMessenger.send (http://localhost:50338/packages/flutter/src/services/system_channels.dart.lib.js:2152:40)
    at OptionalMethodChannel._invokeMethod (http://localhost:50338/packages/flutter/src/services/system_channels.dart.lib.js:938:50)
    at _invokeMethod.next (<anonymous>)
    at runBody (http://localhost:50338/dart_sdk.js:37393:34)
    at Object._async [as async] (http://localhost:50338/dart_sdk.js:37424:7)
    at OptionalMethodChannel.[_invokeMethod] (http://localhost:50338/packages/flutter/src/services/system_channels.dart.lib.js:936:20)
    at OptionalMethodChannel.[_invokeMethod] (http://localhost:50338/packages/flutter/src/services/system_channels.dart.lib.js:1059:34)
    at OptionalMethodChannel.invokeMethod (http://localhost:50338/packages/flutter/src/services/system_channels.dart.lib.js:1039:36)
    at invokeMethod.next (<anonymous>)
    at runBody (http://localhost:50338/dart_sdk.js:37393:34)
    at Object._async [as async] (http://localhost:50338/dart_sdk.js:37424:7)
    at OptionalMethodChannel.invokeMethod (http://localhost:50338/packages/flutter/src/services/system_channels.dart.lib.js:1038:20)
    at setApplicationSwitcherDescription (http://localhost:50338/packages/flutter/src/services/system_chrome.dart.lib.js:321:55)
    at setApplicationSwitcherDescription.next (<anonymous>)
    at runBody (http://localhost:50338/dart_sdk.js:37393:34)
    at Object._async [as async] (http://localhost:50338/dart_sdk.js:37424:7)
    at Function.setApplicationSwitcherDescription (http://localhost:50338/packages/flutter/src/services/system_chrome.dart.lib.js:320:20)
    at main.TitleObserver.new.didChangeRoute (http://localhost:50338/packages/mobile_app/pages/tab_bar_page.dart.lib.js:1801:36)
    at _update (http://localhost:50338/packages/routemaster/src/system_nav_web.dart.lib.js:1274:24)
    at _RouterState.new.[_setStateWithExplicitReportStatus] (http://localhost:50338/packages/flutter/src/widgets/widget_span.dart.lib.js:19076:9)
    at Function.neglect (http://localhost:50338/packages/flutter/src/widgets/widget_span.dart.lib.js:18912:64)
    at routemaster$.RoutemasterDelegate.new.[_updateCurrentConfiguration] (http://localhost:50338/packages/routemaster/src/system_nav_web.dart.lib.js:1280:25)
    at routemaster$.RoutemasterDelegate.new.[_processNavigation] (http://localhost:50338/packages/routemaster/src/system_nav_web.dart.lib.js:1328:40)
    at routemaster$.RoutemasterDelegate.new.[_initRouter] (http://localhost:50338/packages/routemaster/src/system_nav_web.dart.lib.js:1304:33)
    at routemaster$.RoutemasterDelegate.new.[_rebuildRouter] (http://localhost:50338/packages/routemaster/src/system_nav_web.dart.lib.js:1311:24)
    at routemaster$.RoutemasterDelegate.new.[_didChangeDependencies] (http://localhost:50338/packages/routemaster/src/system_nav_web.dart.lib.js:1335:27)
    at routemaster$._RoutemasterStateTrackerState.new.didChangeDependencies (http://localhost:50338/packages/routemaster/src/system_nav_web.dart.lib.js:1713:51)
    at framework.StatefulElement.new.performRebuild (http://localhost:50338/packages/flutter/src/widgets/widget_span.dart.lib.js:50029:20)
    at framework.StatefulElement.new.rebuild (http://localhost:50338/packages/flutter/src/widgets/widget_span.dart.lib.js:27978:12)
    at framework.BuildOwner.new.buildScope (http://localhost:50338/packages/flutter/src/widgets/widget_span.dart.lib.js:49524:55)
    at binding$5.WidgetsFlutterBinding.new.drawFrame (http://localhost:50338/packages/flutter/src/widgets/widget_span.dart.lib.js:52066:77)
    at binding$5.WidgetsFlutterBinding.new.[_handlePersistentFrameCallback] (http://localhost:50338/packages/flutter/src/rendering/layer.dart.lib.js:5054:12)
    at binding$5.WidgetsFlutterBinding.new.[_invokeFrameCallback] (http://localhost:50338/packages/flutter/src/scheduler/binding.dart.lib.js:717:9)
    at binding$5.WidgetsFlutterBinding.new.handleDrawFrame (http://localhost:50338/packages/flutter/src/scheduler/binding.dart.lib.js:689:37)
    at binding$5.WidgetsFlutterBinding.new.[_handleDrawFrame] (http://localhost:50338/packages/flutter/src/scheduler/binding.dart.lib.js:646:12)
    at Object.invoke (http://localhost:50338/dart_sdk.js:175219:7)
    at _engine.EnginePlatformDispatcher.__.invokeOnDrawFrame (http://localhost:50338/dart_sdk.js:156996:15)
    at http://localhost:50338/dart_sdk.js:172643:55

Looks like an issue in Flutter. Comes from trying to update the page's title - I have no idea why.

Weird, I did not really debug it so much yet either, but I did not see it throwing this exception on desktop/device builds, only on Web build... 🤷🏻♂

Flutter issue: https://github.com/flutter/flutter/issues/83351
Will put a workaround in the demo app

Thx @tomgilder, totally works!
And that was simple enough, just an issue with the TitleObserver observer in the demo app.
Interesting that ApplicationSwitcherDescription does not a accept null and that the color in the interface class is an int and not a Color. Could it not be provided there as a Color and later converted to an int, if it has to be that for the SystemChrome interface (which it probably has). Some other of the SystemChrome interface classes do that, or so I recall at least.

Feels like an API that was never supposed to be public to me :-)


Type: Map: Host reject ScMaps that contain duplicate keys

What
Host should reject ScMaps that contain duplicate keys.
Why
Maps with duplicate keys are an indication of bad/wrong input. They're a footgun because they are unlikely to have been signed correctly. They will also not round-trip serialize, so the input and output of a contract fn that passes the structure straight through will not be identical XDR bytes.
Related to https://github.com/stellar/rs-stellar-contract-env/issues/221 https://github.com/stellar/rs-stellar-xdr/issues/98
cc @graydon @jonjove @jayz22

Dependent on https://github.com/stellar/rs-stellar-xdr/issues/106

Superseded by https://github.com/stellar/rs-stellar-contract-env/issues/223


decoding meshoptimized gltf just once

Decoding the mesh optimized in a loop slowed down the extended algo & crashes the app with larger primitives

@pirlande-fw


Where should I read the evit token filtering and fusion algorithm code

I'm sorry I'm using the Timm library for the first time, and I can't find the source code for the EVit section.
Please help me find it, I want to read it carefully!

oh, I find it


Warehouse vs Analytics

I have once read in a documentation here that if we want to enable Analytics, we have to disable Warehouse. But I can't find this article anymore. Is this still true?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: fb71f48d-32a7-5976-f585-902d28d7dc1c
Version Independent ID: b207b4f0-23b7-33b0-ab44-59b2c6546cd8
Content: Install the Analytics extension on Azure DevOps Server - Azure DevOps
Content Source: docs/report/dashboards/analytics-extension.md
Product: devops
Technology: devops-analytics
GitHub Login: @KathrynEE
Microsoft Alias: kaelli

@StavroulaSsi -- thank you for your question.  You may find answers here:

Azure DevOps Support Bot
Azure DevOps on Stack Overflow

@KathrynEE -- please look into this issue.

@StavroulaSsi - Thank you for your inquiry. No, you don't have to uninstall the warehouse in order to use Analytics.  There are some choices you make when you upgrade or create a new project collection on-premises. To learn more, see Availability of Inheritance process model for new project collections.


Add repo by csv

Implementing repo addition by CSV. (Resolves #100)

One thing I'm thinking about - it looks like this makes N GraphQL requests, one for each repo, right? Maybe we ought to have a "bulk add" mutation for adding a batch of repos

Yes Patric we should to, something like passing just a repo string list from Frontend en then it create repos in one request. How can we address it? we have to implement a Graphile makeExtendSchemaPlugin that adds a mutation to create those repos. so... What should we do? address it in another issue to improve this part or implement now in this PR?


ColReader breaks for colname "name"

This is weird one: ColReader does not work on dataframe columns named name.
This occurs because pandas also has an attribute named .name which confuses the fastai method of getting the column via getattr.
Unfortunately, name is a pretty common thing to name your column, including fastai2's own MNIST_TINY labels.csv. This simple fix makes it work.
This kaggle notebook shows a detailed exploration: https://www.kaggle.com/stillsut/fastai2-repro-2
Code details: it looks tempting to just get rid of getattr here, and replace with pandas centric indexing. But other tests rely on getattr and break when we do just do r[c].

Thanks for adding the test and good catch! Can we just have it in one line like this?
o = r[c] if isinstance(c, int) else r[c] if c=='name' else getattr(r, c)

@sgugger I'm on it

@sgugger All set on the correction.

Thanks!


Use numeric-only version numbers

The use of non-numeric components in the package version broke the CLI package test validating the --version output;
not ok 2 <CLI call> --version
# (from function `assert_output' in file test_helper/bats-assert/src/assert_output.bash, line 178,
#  in test file 01.cli-help.bats, line 25)
#   `assert_output --regexp "[[:digit:]]+([.][[:digit:]]+)$"' failed
# cli_call: [n=3] python -m seguid
#
# -- regular expression does not match output --
# regexp : [[:digit:]]+([.][[:digit:]]+)$
# output : 0.1.0a1
# --

For this reason, and because it's not clear whether 0.1.0a1 comes before or after 0.1.0, I think it's better to stick with versiont that has numeric-only components.

I suggest <IP_ADDRESS> for next python version then?


Thanks!

Currently working on my own hub logic based on tplink-smarthome-api and just wanted to say thanks. This is an awesome test library to go with that package :)

I've open sourced my work here: https://github.com/blackflux/kasa-smart-hub
Might be nice to reference those tests that I wrote as an example for the next person. Was struggling a bit due to lack of documentation


proposal: weak: new package providing weak pointers

What is a weak pointer?
Weak pointers (or weak references, as they are referred to in other languages) allow developers to reference memory without preventing the garbage collector from reclaiming it. To prevent visible dangling references, weak pointers become nil when the referenced memory is collected. Weak pointers can be converted to regular ("strong") pointers which do prevent the garbage collector from reclaiming memory, and allow typical use and access to that memory.
Weak pointers are typically a bit harder to work with than regular pointers because they can become nil at any time. Virtually every weak-to-strong conversion must be guarded by a nil check. Often, weak pointers will become nil at unexpected times.
Nonetheless, weak pointers exist in many languages because they are useful. The main use-cases for weak pointers are related to efficient memory management and reclamation. For example, efficiently managing memory for canonicalization maps, or for memory whose lifetime is bound to the lifetime of another object (akin to JavaScript's WeakMap). Another good use case for weak pointers is for hinting to the GC that it's OK to drop some resources because they're cheap to reconstruct later, especially if those resources have a large memory footprint.
Proposal
I propose adding a new weak package to the standard library with the following API.
// Pointer is a weak pointer to a value of type T.
//
// Two Pointer values compare equal if the pointers
// that they were created from compare equal. This property is retained even
// after the object referenced by the pointer used to create a weak reference
// is reclaimed.
//
// If multiple weak pointers are made to different offsets within same object
// (for example, pointers to different fields of the same struct), those pointers
// will not compare equal.
// If a weak pointer is created from an object that becomes unreachable, but is
// then resurrected due to a finalizer, that weak pointer will not compare equal
// with weak pointers created after resurrection.
//
// Calling Make with a nil pointer returns a weak pointer whose Value method
// always returns nil. The zero value of a Pointer behaves as if it was created
// by passing nil to Make and compares equal with such pointers.
type Pointer[T any] struct { ... }

// Make creates a weak pointer from a pointer to a value of type T.
func Make[T any](ptr *T) Pointer[T] { ... }

// Value returns the original pointer used to create the weak pointer.
// It returns nil if the value pointed to by the original pointer was reclaimed by
// the garbage collector.
// If a weak pointer points to an object with a finalizer, then Value will
// return nil as soon as the object's finalizer is queued for execution.
func (p Pointer[T]) Value() *T { ... }

Design discussion
Representation
The weak pointer we propose would be represented via an indirection object under the hood. This means that each pointer that has any weak pointers associated with it also has an associated 8 byte allocation that contains a single pointer. This pointer is the actual weak reference. This representation is very CPU efficient, since the GC can atomically set a single pointer to make all weak references to an object nil.
This 8 byte allocation is rarely a problem in practice since weak pointers are most often useful for memory efficiency anyway. For example, canonicalization maps are deduplicating memory already, so the extra 8 bytes per canonical copy is relatively cheap. However, it may be worth calling out this detail in the documentation as the C# language does.
This representation has other benefits. One benefit is that the API's equality semantics fall out very naturally. Weak pointers created from the same pointer remain equal even after that pointer no longer exists. This makes it possible to build maps keyed by weak pointers. Another benefit is its simplicity: very little of the GC has to change to support weak pointers.
Avoiding object resurrection
A subtle but important property of the weak pointer implementation is that it must not enable object resurrection. This would create many complications, including the fact that weakly-referenced objects would take 2 GC cycles to reclaim; and they could not be involved in cycles, or they would never be reclaimed (much like finalizers).
A simple way to implement weak references that maintains this property is to guard weak-to-strong conversions with ensuring the object is swept. A swept object cannot be resurrected, because it is always definitely reachable or unreachable, nothing in between. This means the weak-to-strong conversion path may need to sweep the object, but this happens at most once per GC cycle, and the Go runtime's sweeper is quite fast, so the cost shouldn't be noticeable in practice.
Why this specific interaction with finalizers?
The interaction between weak pointers and finalizers that resurrect objects is subtle. There are two choices: the weak pointer can go nil before the finalizer runs, or it can track the object's resurrection, and only go nil once the object is well and truly dead. In C# jargon, this is the difference between "short" weak reference and a "long" weak reference.
At first glance, the latter seems clearer since the weak pointer really only goes nil once nothing can reference the object. However, this semantics has a big problem, and it's subtle.
Today, the decision to resurrect an object in a finalizer is internal to an API’s implementation. If we allowed weak-to-strong conversions after finalization, then clients of an API could resurrect an object without the cooperation of its implementation, at which point the object's internals may be in an inconsistent state. This creates the potential for a race that is not immediately apparent to either the API authors or the client. Worse still, these races will be very rare and unlikely to be caught by testing, even with the race detector enabled. If the weak pointer goes nil before the finalizer runs, then such races are impossible.
It is telling that other garbage collected languages either make "short" weak references the default and do not recommend their "long" form (C#), or only offer the "short" form to begin with (Java).
Risks
Breaking the GC abstraction
The unique.Handle proposal explicitly rejected weak pointers as an alternative on the grounds that they are difficult to use. Fundamentally, this is because they break the GC abstraction by revealing the timing with which memory is actually reclaimed, and this is mainly a problem because that timing is unpredictable. The GC abstraction of "infinite memory" (only allocation, no apparent free) is important in general for composability.
While it is true that weak pointers are more difficult to use than regular pointers, we believe that we have picked an API (building on the experiences of other languages) that minimizes surprises, maintains composability, and has a simple implementation. This was discovered during the implementation of unique.Handle and it was compelling enough that it led to this proposal.
Although weak pointers will be misused in some cases, providing documentation, examples, and advice in the GC guide will go a long way to mitigating that.

glad this is being resurrected *scnr*

How does this interact with the unique package (#62483)? Isn't it possible for a user to implement unique (or at least solve the same problems that unique solves) using weak pointers? If we add weak, will we regret having both weak and unique?

What does Make((*T)(nil)) do? Useless and the answer is probably "return a Pointer that always returns nil", but just to make sure.

@Merovius Yep, that's right. Updated the proposal.

Although a weak.Pointer that is immediately nil is a little strange, I've written programs with similar features in other languages where it's been helpful to represent an "optional weak pointer" without adding another level of indirection. I probably wouldn't complain too much if it weren't possible, but it has enough marginal use that I don't think it's worth overcomplicating things to forbid it.
(For example, a Rust analog would be std::rc::Weak::new(), which returns a Weak where upgrade always returns None, which is directly analogous to a weak.Pointer where Value always returns nil.)
Is the zero value of weak.Pointer[T] equivalent to what you'd get from passing nil to weak.Make?

https://github.com/golang/go/blob/377646589d5fb0224014683e0d1f1db35e60c3ac/src/internal/weak/pointer.go#L51
I see "weak pointer" under the "internal" package. Is there any progress on this proposal currently?

@LukeXeon This proposal is awaiting review. If accepted, the internal/weak package already contains an implementation that mostly implements the semantics laid out here. It could just be moved out of internal with a few minor tweaks. Note that, if the proposal is accepted, this would land in Go 1.24, not the upcoming Go 1.23 (it's already too late for Go 1.23).

Unlike server programs that allocate and release memory for each request and persist it in the DB, a weak pointer is essential for client programs that hold multiple containers or partially release items. I feel that Go lacks support for such programs.
(As an aside, #64777 is another example of a feature needed for client programs)

In our discussion yesterday, @bradfitz asked if weak pointers made it possible to maintain a map of expensive derived information about something without preventing the GC of that something. Here is a worked example of how weak pointer enables that:
var cache struct {
    mu sync.Mutex
    m map[weak.Pointer[Foo]]*derived
}

func init() {
    cache.m = make(map[weak.Pointer[Foo]]*derived)
}

func cached(f *Foo) *derived {
    cache.mu.Lock()
    defer cache.mu.Unlock()

    p := weak.Make(f)
    d := cache.m[p]
    if d != nil {
        return d
    }
    d = expensiveComputation(f)
    cache.m[p] = d
    runtime.AddCleanup(f, deleteP, p)
}

func deleteP(p weak.Pointer[Foo]) {
    cache.mu.Lock()
    defer cache.mu.Unlock()

    delete(cache.m, p)
}

I am assuming runtime.AddCleanup from #67535, which is guaranteed to work with any pointer f.
(SetFinalizer might break things if f already had a finalizer, or if f was inside another object.)

@rsc can this please find its way into the official documentation or alternatively the Tour of Go? Such things really need to be easily accessible, and not buried only in an issue comment.

I think it would make sense for this to be an example in the weak package, if the proposal is accepted. Putting it in the Go tour seems TMI.

Yeah, it could otherwise become a "Tor-Tour of Go" (sorry, couldn't resist)

Following up on my comment from last week, here is a potential weak cache abstraction that avoids holding the lock during expensiveComputation and also wraps up the idioms nicely so you don't have to retype them. I am not proposing to add it to the package (others can argue for that if they want) but it's here as an example, and we can include it as an example in the package too.
type Cache[K any, V any] struct {
    f func(*K) V
    m atomic.Map[weak.Pointer[K], func() V]
}

func NewCache[K comparable, V any](f func(*K)V) *Cache[K, V] {
    return &Cache[K, V]{f: f}
}

func (c *Cache[K, V]) Get(k *K) V {
    kw := weak.Make(k)
    vf, ok := c.m.Load(kw)
    if ok {
        return vf()
    }
    vf = sync.OnceValue(func() V { return c.f(k) })
    vf, loaded := c.m.LoadOrStore(kw)
    if !loaded {
        // Stored kw→vf to c.m; add the cleanup.
        runtime.AddCleanup(k, c.cleanup, kw)
    }
    return vf()
}

func (c *Cache[K, V]) cleanup(kw weak.Pointer[K]) {
    c.m.Delete(kw)
}

var cached = NewCache(expensiveComputation)

@rsc
Since the cache doesn't do weak -> strong pointer, and with current GC this should also work, no?
type Cache[K any, V any] struct {
    f func(*K) V
    m atomic.Map[uintptr, func() V]
}

func NewCache[K comparable, V any](f func(*K)V) *Cache[K, V] {
    return &Cache[K, V]{f: f}
}

func (c *Cache[K, V]) Get(k *K) V {
    kw := uintptr(unsafe.Pointer((k))
    vf, ok := c.m.Load(kw)
    if ok {
        return vf()
    }
    vf = sync.OnceValue(func() V { return c.f(k) })
    vf, loaded := c.m.LoadOrStore(kw)
    if !loaded {
        // Stored kw→vf to c.m; add the cleanup.
        runtime.AddCleanup(k, c.cleanup, kw)
    }
    return vf()
}

func (c *Cache[K, V]) cleanup(kw uintptr) {
    c.m.Delete(kw)
}

var cached = NewCache(expensiveComputation)

@DmitriyMV There is a race in that code. It could theoretically happen that the GC identifies k as garbage, puts it back on a free list for future allocation, queues the cleanup, and then the program allocates a new k, gets the recycled address, and reuses the stale value because the cleanup has not gotten a chance to run yet. (It's also not guaranteed to work in an implementation that moves objects, but objects aren't moving today except on the stack, and k escapes to the heap so it won't be a stack object in the current implementation.)

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

I am trying to figure out what the atomic.Map[weak.Pointer[K], func() V] refers to in @rsc's example in https://github.com/golang/go/issues/67552#issuecomment-2200755798.
Is that the sync.MapOf (or maybe it is sync/v2.Map now) proposed in https://github.com/golang/go/issues/47657 (which I think is on hold)?
While searching for that I also came across another related proposal I didn't see referenced here yet: https://github.com/golang/go/issues/43615.
Russ's example also uses runtime.AddCleanup from https://github.com/golang/go/issues/67535 which is not approved yet.
Hopefully these cross-refs are useful to someone, but also it would seem we cannot use that example in the weak package docs if the v2/sync.Map or AddCleanup are not available at the time.

@ChrisHines You can't use the example as written, but you can use sync.Map with type-assertions instead.

I once came to the conclusion that ephemorons (
https://dl.acm.org/doi/pdf/10.1145/263698.263733) were better than weak
pointers and starting with .NET many other post Java languages have come to
the same conclusion and implemented them (see
https://en.wikipedia.org/wiki/Ephemeron for a list). Ephemerons solve some
thorny key/value problems where reachability of key should be independent
of the value structure thus allowing value to reference key without keeping
key alive.
The GC trace implementation is 3 pass instead of the current 2 pass and
complexity is O(ND) where N is the number of unreachable ephemerons  and D
is the depth of the structures needing to the traced from them in pass 3. I
suspect if we do weak pointers there will be a request for ephemerons once
users run into the problems.
I have not thought through the concurrency issues beyond noticing that Go
would be the first to deal with such issues. Implementing iterators that
can reference keys implicitly are another problem I haven't thought through.
In any case if Go doesn't implement ephemorons this issue should track the
discussion..
On Thu, Aug 15, 2024 at 1:20 AM Axel Wagner @.***>
wrote:

@ChrisHines https://github.com/ChrisHines You can't use the example as
written, but you can use sync.Map with type-assertions instead.
—
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/67552#issuecomment-2290649565, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHNNH4F64GQSXLL2HH3FFDZRQ3AZAVCNFSM6AAAAABICGOSGKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJQGY2DSNJWGU
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hi Rick! I'm glad you brought up ephemerons -- they resolve a real issue when working with weak pairs (like in maps) and this proposal certainly should mention them somewhere. This issue will almost certainly come up in the future.
TL;DR: My gut feeling is we won't regret the weak pointers as described in this proposal, and I'm having some difficulty figuring out how to formulate an ephemeron API that covers the use-cases that I've seen pop up. If anybody has additional insights, I'm definitely happy to hear them.
And now, the long version...
In general, my main gripe with ephemerons is the value side. The question on my mind is "which value?" Having only one value for each possible key runs into composability problems like SetFinalizer, so I think that's a no-go.
.NET 4.0 introduced the ConditionalWeakTable which you have to use to specify which value you mean, but I think it ends up being insufficient for some use-cases (like the unique package; that clearly exists now, so I'm thinking any such class of problems). .NET 6.0 later made the underlying abstraction, DependentHandle, public. Maybe that's something we'd want? Some explicit handle representing the dependent association? But even then, you can still recreate weak pointers with this kind of dependent handle by making the key and value the same pointer (I think... please correct me if I'm wrong).
Like, I think in the spirit of Russ' cache example, one might express the map behind such a cache as:
atomic.Map[weak.Pointer[K], DependentHandle[K, func() DependentHandle[K, V]]]

... in order to avoid any leak issues in case the value-generating closure or the cached value itself contains a strong reference to the key. (Which seems unlikely, but is of course still possible.)
I think that first weak.Pointer[K] can be replaced with an ephemeron... but I don't immediately see how. I'll give it some effort to work it out and report back if I find something.
My gut feeling is that we won't regret weak pointers, and we may just end up with both... but I need to give this more thought, and any additional insights would be helpful. The weak pointers as described in this proposal are fairly simple and straightforward (both in implementation and usage), and have clean semantics that fall out nicely from the API.
On a final note, the implementation complexity of ephemerons is also a bit unfortunate, what with the traditional "extra GC phase" implementation strategy. I think it might be possible to simplify this by handling ephemerons while greying objects:

Hold ephemeron values weakly via specials.
When an object is greyed, cheaply check some metadata (we're already in the guts of the mspan at that point, so we could probably have an extra bit next to the mark bits or put a bit in the allocation header to avoid another cache miss).
If there's at least one ephemeron, do a slower lookup for the ephemeron specials, iterate over them, and queue the weakly-held values with the GC.

Of course, the downside here is the extra check on the mark hot path. As I alluded to in (2) above, I suspect we can hide this cost.
(As an additional tangential note, I think Java never got ephemerons, but I'm not sure why.)

I definitely got some things wrong in my previous comment earlier -- I've corrected them now. I've also worked out an example of how ephemerons might be exposed in Go, but there are some difficulties with composability and defining comparability on an ephemeron, such that it actually can be used in all the same ways. I think on a practical level you can write your code in most (maybe all?) use-cases to use an ephemeron instead, but it's more complex and may require you to reimplement a lot more than you bargained for (like, a new special map implementation).
So, I think there's still some utility to keeping weak pointers around, and I also don't think we should ignore the complexity (and possible performance difficulties) introduced by an ephemeron implementation. I'm also happy to hear other opinions.

Section 10 of this paper (https://dl.acm.org/doi/pdf/10.1145/3226225) is an
interesting read. The work is based on the same Sapphire work that the Go
GC is based on so things match up pretty well with the Go GC. It argues why
deletion barriers and atomic phase changes work. Their CLEAR phase is
similar to Go's sweep phase and thus atomic for similar reasons. I am a bit
concerned about making a weak ref Get fast (inlined) and atomic.
Earlier in the paper there are some warnings about how common weak refs
were in some of the DeCapo benchmarks. This made me concerned about sweep
storms caused by weak reference niling. In addition nobody seems to have a
good answer to clearing stale weak entries in large caches. Perhaps we will
end up yet again talking about building some sort of runtime notification
scheme.
WRT Ephermerons - I have no implementation but the big O and complexity of
adding another GC phase feels like the cost / benefit will be too high and
we have no user demand or requests.
None of this is intended to be negative about the proposal as is, I just
wanted to get issues and literature on the record.
On Sat, Aug 17, 2024 at 3:33 AM Michael Knyszek @.***>
wrote:

I definitely got some things wrong in my previous comment earlier -- I've
corrected them now. I've also worked out an example of how ephemerons might
be exposed in Go, but there are some difficulties with composability and
defining comparability on an ephemeron, such that it actually can be used
in all the same ways. I think on a practical level you can write your code
in most (maybe all?) use-cases to use an ephemeron instead, but it's more
complex and may require you to reimplement a lot more than you bargained
for (like, a new special map implementation).
So, I think there's still some utility to keeping weak pointers around,
and I also don't think we should ignore the complexity (and possible
performance difficulties) introduced by an ephemeron implementation. I'm
also happy to hear other opinions.
—
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/67552#issuecomment-2294746516, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHNNH646LWVKABYUOIFHIDZR34EJAVCNFSM6AAAAABICGOSGKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJUG42DMNJRGY
.
You are receiving this because you commented.Message ID:
@.***>

The use of weak pointers and AddCleanup in the example above points out the
big footgun of both SetFinalizer and AddCleanup. Both result in a user
defined function being run asynchronously in undefined order by the GC.
Perhaps AddNotification would be a better API. Instead of passing
AddCleanup a func to call, AddNotification would be passed a channel.
Instead of calling the function the GC would clear the referent and then
put the weak pointer on the channel. The channel would connect to a user
defined goroutine and do whatever is needed at a time and manner completely
under user control. In the example above the user routine would read from
the channel and delete the cache entry. Reducing non-determinism is usually
a win.
On Fri, Aug 23, 2024 at 12:03 PM Rick Hudson @.***> wrote:

Section 10 of this paper (https://dl.acm.org/doi/pdf/10.1145/3226225) is
an interesting read. The work is based on the same Sapphire work that the
Go GC is based on so things match up pretty well with the Go GC. It argues
why deletion barriers and atomic phase changes work. Their CLEAR phase is
similar to Go's sweep phase and thus atomic for similar reasons. I am a bit
concerned about making a weak ref Get fast (inlined) and atomic.
Earlier in the paper there are some warnings about how common weak refs
were in some of the DeCapo benchmarks. This made me concerned about sweep
storms caused by weak reference niling. In addition nobody seems to have a
good answer to clearing stale weak entries in large caches. Perhaps we will
end up yet again talking about building some sort of runtime notification
scheme.
WRT Ephermerons - I have no implementation but the big O and complexity of
adding another GC phase feels like the cost / benefit will be too high and
we have no user demand or requests.
None of this is intended to be negative about the proposal as is, I just
wanted to get issues and literature on the record.
On Sat, Aug 17, 2024 at 3:33 AM Michael Knyszek @.***>
wrote:

I definitely got some things wrong in my previous comment earlier -- I've
corrected them now. I've also worked out an example of how ephemerons might
be exposed in Go, but there are some difficulties with composability and
defining comparability on an ephemeron, such that it actually can be used
in all the same ways. I think on a practical level you can write your code
in most (maybe all?) use-cases to use an ephemeron instead, but it's more
complex and may require you to reimplement a lot more than you bargained
for (like, a new special map implementation).
So, I think there's still some utility to keeping weak pointers
around, and I also don't think we should ignore the complexity (and
possible performance difficulties) introduced by an ephemeron
implementation. I'm also happy to hear other opinions.
—
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/67552#issuecomment-2294746516, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHNNH646LWVKABYUOIFHIDZR34EJAVCNFSM6AAAAABICGOSGKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJUG42DMNJRGY
.
You are receiving this because you commented.Message ID:
@.***>

We'd considered using a channel for AddCleanup, but channels have a few problems. The biggest one is that packages that are unaware of each other must, at minimum, spin up at least one goroutine per package to handle all the package's cleanups. That seems like too much overhead to incentivize moving away from SetFinalizer. Either that, or the community standardizes around some shared package that exposes an API similar to AddCleanup, in which case we've gained little by exposing a channel-based API.
I get your point about the hazards of an API that says "I'll run this function asynchronously in the future" in general, but executing a function asynchronously is always going to be something you can write yourself. And things like time.AfterFunc exist. I don't really see how that's much different from this case. It's not like the GC worker goroutines are executing the functions themselves, they're always executed on a separate goroutine.
FWIW, I think this part of the discussion would be better suited to the AddCleanup issue (#67535). I'll copy the context over.

Have all remaining concerns about this proposal been addressed?
The details are in the top comment under the "Proposal" heading.

It would be great analyzing top production use cases for weak pointers in other programming languages before deciding on how to implement them in Go.
Probably, it would be better providing higher-level solutions for these practical use cases in standard library instead of exposing lower-level weak pointers.

@mknyszek could you please add to your proposal 2-3 examples of practical problems could not be solved now without weak pointers?

Here's one example use: https://github.com/golang/go/issues/67552#issuecomment-2200755798.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group
The details are in the top comment under the "Proposal" heading.

Here's one example use: #67552 (comment).

I'm unaware of other practical cases for weak pointers. Probably, it is better providing generic thread-safe cache implementation inside sync package instead of exposing weak pointers, which will be used mostly for re-creating the same cache implementations in various codebases with various degree of subtle bugs and non-optimal performance.
The API of this cache may look like the following (feel free making it generic - I tried to do this, but the result wasn't good):
// Cache is goroutine-safe cache with automatic cleanup on memory shortage.
//
// TODO: define what does "memory shortage" mean.
// Ideally the cache shouldn't be cleared on every GC cycle
// if there is enough free memory and the memory usage is stable over time.
//
// It is OK to use zero cache.
type Cache struct {
  // Retention is optional retention for the cached items.
  // If it is set to positive value, then items without
  // access for the given duration are automatically deleted.
  //
  // Do not change this field after the first use of the cache.
  Retention time.Duration

  // Free is optional callback, which is called when the cached item is deleted.
  //
  // Do not change this field after the first use of the cache.
  Free func(k, v any)
}

// Get returns value for the given key k stored in c.
//
// Nil is returned if the cache doesn't contain value for the given key.
func (c *Cache) Get(k any) any

// Set stores the given value v under the given key k in  c.
func (c *Cache) Set(k, v any)

According to my practice the Retention field must be set to some positive value most of the time in order to keep the cache size under control while maintaining good cache hit rate when the set of cached items changes over time.

The proposal names three general use-cases:

Canonicalization maps (where unique isn't quite what you want, or doesn't quite work).
Binding the lifetime of one value to another (typically, map[weak.Pointer[K]]*V).
Some kinds of caches (as Russ already gave an example of).

First off, let me say that weak pointers are very niche. I think it's easy to write them off if you've never run into a case where they'd really come in handy. Also, apologies for not walking through concrete examples in the original proposals. Because weak pointers (and their higher-level abstractions) are so niche, it's often a distraction to try to talk about specific examples in detail. But I'll admit that the broader internet is... frighteningly bad at providing concrete examples.
So, let me give it a shot with something I've worked on lately.
golang.org/x/exp/trace.Stack or internal/trace.Stack is an example of where a custom canonicalization map would be useful. Stacks found in execution traces are not currently canonicalized, but they could be, which would make the API easier to use. Canonicalized stacks are useful for building, for example, profiles out of execution traces, as go tool trace does. Making them comparable makes building maps with them much easier.
The thing is, stacks are usually best represented as slices of PCs. But slices cannot be used with unique because of issues with defining equality on slices in general, but with weak.Pointer, we can create a simple canonicalization map purpose-built for stacks.
As an example where binding lifetimes together is useful, we can take the previous example a step further. Every stack consists of a bunch of PCs which have some additional information associated with them. We want to keep that data around as long as that PC is still in use. One thing we can do is canonicalize each PC, turning it into a pointer:
var canonPCs map[uint64]weak.Pointer[uint64] // PC to canonical PC copy.

And then use this canonical pointer to look up the rest of the stack information. (And we get the added benefit of deduplicating it along the way.)
var pcData map[weak.Pointer[uint64]]StackFrame

Why store it separately? Because hashing a StackFrame is pointless and wasteful when a PC is really sufficient for determining location identity. We can also reduce our storage footprint by not also storing the entire StackFrame as a key in the map.
Is this the best design for this? I don't know -- there's certainly a space of designs here and maybe one of them is far and away the best. But I think it illustrates that with weak pointers, we can explore the space of designs to achieve what we want.
Hopefully I didn't totally butcher this example and it makes sense to others as well.
Coming back to the general applicability of weak pointers, I want to say that while what Seebs said in the OP to #43615 is true, that weak pointers are often used with maps, I think that providing the building blocks will capture far more use-cases for a lower maintenance and complexity burden for the Go project.
Today we have proposals for:

maphash.Comparable
runtime.AddCleanup
weak.Pointer

These are three powerful, orthogonal, and also surprisingly simple building blocks that can be used cover most of the "I need a weak " design space.
And I do want to stress that these things are fairly simple in their own right, including weak.Pointer. We would not have a weak.Pointer proposal if it hadn't turned out to be much simpler than expected to implement with nice semantics. In particular, I think getting the equality/comparability semantics is extremely important to be able to do this well.
(As an additional footnote, I don't foresee the semantics described in this proposal as being a problem for possible future GC implementations either. If anyone has insights on that though, it would be good to hear them now.)
To be clear, I do I think it is important to ask why not just try and provide higher-level abstractions as necessary. But I also want to point out that that's been the unstated status quo for years, and we haven't gotten very far with that. I think part of the problem may be that few of the higher-level abstractions really cover enough use-cases to be worth the time to design a really good API. We have sync.Pool, which is great and kinda like a weak cache under the hood, but not much else. I think we may have assumed for a long time that supporting weak pointers would be really complicated. But it turns out that they're not so bad, and paired with some other relatively simple APIs, they're useful when you need them.
Anyway, that's my take.

We would need some other mechanism to remove those entries from the map.

That's correct. Sorry about that; I elided the fact that one would also need to use runtime.AddCleanup to remove entries from the map.

What is the relationship between maphash.Comparable and weak?
See CL 609761, maphash.Comparable does not require a weak package.

A couple clarifying questions.

Two Pointer values compare equal if the pointers that they were created from compare equal.

Is it possible for two weak pointers to compare equal if they were created from different objects? E.g. the former was reclaimed and memory subsequently reused?

It returns nil if the value pointed to by the original pointer was reclaimed by the garbage collector.

Although the language is unambiguous, can it be strengthened to be "if and only if the original pointer was reclaimed"? That is, am I guaranteed a weak pointer's Value() will never return nil as long as I retain a standard reference to the underlying object?

@bdbyrne

Is it possible for two pointers to compare equal if they were created from distinct objects? E.g. the first was reclaimed and its memory subsequently reused.

For an object to be reclaimed, there can't be any pointers to it anymore. So, no.

Although the language is unambiguous, can it be strengthened to be "if and only if the original pointer was reclaimed"?

"If and only if" is not true under the proposed API. It also returns nil if the pointer passed to Make is nil (last paragraph is the doc string of Make).

For an object to be reclaimed, there can't be any pointers to it anymore. So, no.

I think the scenario in question is one where you have a weak pointer to a and all other references are gone so a gets collected. Then, later, b is allocated with the same address that a had previously. Will a new weak pointer to b compare equal to any leftover weak pointers to a?

Ah, that makes sense. The doc comment says

Two Pointer values compare equal if the pointers that they were created from compare equal. This property is retained even after the object referenced by the pointer used to create a weak reference is reclaimed.

I would read that as "yes, in that scenario, the weak pointers are equal", which does seem strange. Especially if it would mean that (by a strict reading) you would now have two weak pointers comparing equal, with one returning nil from Value() and one returning a non-nil pointer. The only way I could reconcile that is by the runtime ruling out that an address is re-used as long as it is still stored in a weak pointer.
So, really "I don't know" and I'll step back from this question, sorry for the noise :)

Is it possible for two pointers to compare equal if they were created from distinct objects? E.g. the first was reclaimed and its memory subsequently reused.

No, that is not possible. Note that equality must be either always true or always false to be useful. Otherwise you can't reliably use weak pointers in maps, for example.

I would read that as "yes, in that scenario, the weak pointers are equal", which does seem strange. Especially if it would mean that (by a strict reading) you would now have two weak pointers comparing equal, with one returning nil from Value() and one returning a non-nil pointer.

Perhaps I didn't explain this well in the original proposal, but weak pointers should be considered to be updated atomically, globally. It's not possible to have any skew, where one simultaneously returns nil and another does not.

The only way I could reconcile that is by the runtime ruling out that an address is re-used as long as it is still stored in a weak pointer.

This is kind of quarantining of memory not necessary, and it would be leaky. The implementation part of the proposal describes how this would work. In short, weak pointers point are themselves objects which are mapped 1:1 with some offset in some other object. The address "weak pointer objects" live at determines their identity.

No, that is not possible. Note that this can't be true for things like using weak pointers in maps to be useful.

Great! Could this also be strengthened in the documentation, such as "Two Pointer values compare equal if and only if the pointers..."? It's not clear to intuit this property in the context of pointers to reclaimed objects.
Going back to my second question, is the following sequence possible?

A heap object v is allocated and a weak pointer w is made from v.
All references to v are dropped.
A GC cycle is run, where v is presumed dead as it has no non-weak references.
v is rehydrated from w.Value().
Due to (4), w is cleared such that w.Value() returns nil.

I'd expect it to be hard/expensive to close that race condition. Semantically returning nil is fine, but you'd want to update the language for "it returns nil if the value pointed to by the original pointer was reclaimed by the garbage collector."


[OSD-22366] addon operator fixable vulnerablities for image

What type of PR is this?
(bug/feature/cleanup/documentation/test/refactor)
What this PR does / why we need it?
To fix vulnerabilities in images.
Which Jira/Github issue(s) this PR fixes?
Jira: OSD-22366
Fixes #
Special notes for your reviewer:
Pre-checks (if applicable):

[ ] Tested latest changes against a cluster
[ ] Ran make go-test command locally to run all the unit tests and mock tests locally.
[ ] Included documentation changes with PR

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

Project coverage is 72.76%. Comparing base (bfcff9f) to head (b145fc2).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #587   +/-   ##
=======================================
  Coverage   72.76%   72.76%
=======================================
  Files          51       51
  Lines        3294     3294
=======================================
  Hits         2397     2397
  Misses        754      754
  Partials      143      143

/retest

No cluster claims were ready.
/retest

/retest

/retest


fix: updated deps

:tada: This PR is included in version 2.4.29 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


fix "fatal error: concurrent map read and map write" bugs when we concurrently execute lots of delete volumes and create or list volumes tasks

- What I did
The globalLock use of struct type VolumeStore is not very correct in docker volume packages, sometimes it will cause "fatal error: concurrent map read and map write" because we concurrently execute lots of delete volumes and create or list volumes tasks. Add globalLock.Lock for read tasks will resolve this error, but the performance of docker would be lower too much, so I change type of globalLock from sync.Mutex to RWMutex, and all read task codes are around with globalLock.RLock, then the concurrent error will not happen, and the performance would not be lower too much either.
- How I did it
Change VolumeStore.globalLock type from Mutex to RWMutex, and add globalLock.RLock() for the read task codes of names, refs, labels and options in VolumeStore
- How to verify it
Concurrently execute lots of delete volumes and create or list volumes tasks, and docker will never down like before.
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)
Signed-off-by: He Xin<EMAIL_ADDRESS>

cc @cpuguy83

Thanks. I thought we caught all of these in the last PR, but I guess we missed some.

ping @tonistiigi @LK4D4 PTAL

Note that this fixes #28237

Also, given that this affects 1.12.x, is there a way to tag this for a potential 1.12 patch release in case another one is released?

@aaronlehmann tricky; GitHub doesn't allow multiple milestones on a PR, we could create a GitHub project (board) for tracking?

@KevinTHU needs rebase :/

@LK4D4 what should I do?

@KevinTHU there's a comment from reviewers; https://github.com/docker/docker/pull/28290#discussion_r87684658, if you can address that.
Also this PR needs a rebase, because there are merge conflicts; can you rebase the PR, and resolve those merge conflicts? Here are some instructions about rebasing; https://docs.docker.com/opensource/workflow/work-issue/#/pull-and-rebase-frequently

@thaJeztah ok, I will add that comment add rebase my code, thx~

PR have been updated

07:00:48 Build timed out (after 200 minutes). Marking the build as failed...=_=!!

Setting to P1 because this fixes a panic.

@aaronlehmann PR was updated, ptal

LGTM
I'm a bit worried that eventually we'll have deadlocks because someone will accidentally change the code to lock s.globalLock before one of the locks in s.locks. As a future improvement, it would be a good idea to simplify the locking in this file, or at least clearly document the order in which locks need to be taken.

As a future improvement, it would be a good idea to simplify the locking in this file, or at least clearly document the order in which locks need to be taken.

Should we create an issue for that, or is someone willing to open a PR to make a start?


Revert "Fix fatal error for relatedEntities API and getProfile API."

typo correction to effect

not doing.


Issue #29

Overall looks good, I will look at it a little closer later.
One detail, remember that "spectra" is plural and "spectrum" is singular. I know we all get sloppy in our speaking, myself included. But let's call the functions check_spectrum and analyze_spectrum since they are doing one at a time. Thanks.


Update resource type for CosmosDB

Microsoft.AzureCosmosDB/databaseAccounts seems to be the wrong resource type for CosmosDB PEs. We've been extensively using Microsoft.DocumentDb/databaseAccounts instead, as this works as expected.

small addition: official docs also seem to point towards Microsoft.DocumentDb

@AbdullahBell
Can you review the proposed changes?
IMPORTANT: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


STAR-871: Fix TopologyChangeTest

I ignored coverage in this case because the part which was changed affects only in-jvm dtest and is covered by them, though they are not run on pr gating


testcases not processed in order

testcases are processed in a seemingly random order. This is undesired.
see: https://oj.paullee.dev/submission/511

resolved as of commit d942fec


Spike on auto indentation issues

To address https://github.com/microsoft/vscode-python/issues/6886 and https://github.com/microsoft/vscode-python/issues/6927
At this point only the following things still have to be resolved:

(#6564) auto-dedent for "return" (we still do it for "pass", "raise", "break", and "continue")
(#6623) auto-dedent (pre-dedent) for "else", "elif", "except", and "finally"

We should look at how Ruby does it in their extension...

Seems like removing the indentationRules key fixes some of the issues: https://github.com/microsoft/vscode-python/blob/9c61d0e0a99caf3a4be1d75db440b27b4f15fcd2/src/client/language/languageConfiguration.ts#L37-L40
However, this means that we should probably use onEnterRules regexes for things like pressing enter after if test:, def foo(self): or class Bar: since these newlines don't get indented correctly.

TODO:

Investigate how indentation works in Ruby
[ ] Check if there are any issues with their rules

Outcome:

If ruby rules work as expected, then we'll adapt their rules into Python extension (Note - separate task/issue/PR)

Re: Adapting Ruby indentation behavior for Python
Please take a step back and carefully consider how much we can really borrow from Ruby.
Crucially, Ruby has an end keyword to mark the end of a block (or what is called a "suite" in Python's grammar specs).
Please see my comment on a related issue for an illustration of how the proper dedent level for else cannot be inferred in Python, in general.
If you want to look at existing work to possibly incorporate into this extension, perhaps it should be the highly regarded Python Indent extension.

FTR:

https://github.com/rubyide/vscode-ruby/blob/278464b1405834dc09777dade65ece3a4b5c918c/packages/vscode-ruby/src/languageConfiguration.ts
https://github.com/rubyide/vscode-ruby/blob/77f4edea9a800ff6290a5a64e7c41697b26ead5f/packages/vscode-ruby/src/ruby.ts#L24

Here are the two regexes from the default VSCode config, expanded verbosely:
// increaseIndentPattern
^
\\s*
(
    (
        begin |
        class |
        (
            (
                private |
                protected
            )
            \\s+
            def
        ) |
        def |
        else |
        elsif |
        ensure |
        for |
        if |
        module |
        rescue |
        unless |
        until |
        when |
        while |
        case
    ) |
    (
        [^#]*
        \\s
        do
        \\b
    ) |
    (
        [^#]*
        =
        \\s*
        (
            case |
            if |
            unless
        )
    )
)
\\b
(
    (
        [^#\\{;]
    ) |
    (
        (
            \" |
            ' |
            \/
        )
        .*
        \\4
    )
)*
( # .* )?
$

// decreaseIndentPattern
^
\\s*
(
    [}\\]]
    (
        (
            [,)]?
            \\s*
            (
                # |
                $
            )
        ) |
        (
            \\.
            [a-zA-Z_]
            \\w*
            \\b
        )
    )|
    (
        end|rescue|ensure|else|elsif|when
    )\\b
)

Here are the two regexes from the actual Ruby extension (more recent), expanded verbosely:
// increaseIndentPattern
^
(
    (
        \\s*
        (
            module |
            class |
            (
                (
                    (
                        private |
                        protected
                    )
                    \\s+
                )?
                def
            ) |
            unless |
            if |
            else |
            elsif |
            case |
            when |
            begin |
            rescue |
            ensure |
            for |
            while |
            until |
            (
                (?=
                    .*? \\b
                    (
                        do |
                        begin |
                        case |
                        if |
                        unless
                    )
                    \\b
                )
                (
                    (
                        "
                        (
                            \\\\. |
                            [^\\"]
                        )*
                        "
                    ) |
                    (
                        '
                        (
                            \\\\. |
                            [^\\']
                        )*
                        '
                    ) |
                    (
                        [^#"']
                    )
                )*
                (
                    (
                        \\s
                        (
                            do |
                            begin |
                            case
                        )
                    ) |
                    (
                        [-+=&|*/~%^<>~]
                        \\s*
                        (
                            if |
                            unless
                        )
                    )
                )
            )
        )
        \\b
        (?!
            [^;]* ;
            .*? \\b
            end \\b
        )
    ) |
    (
        (
            (
                "
                (
                    \\\\. |
                    [^\\"]
                )*
                "
            ) |
            (
                '
                (
                    \\\\. |
                    [^\\']
                )*
                '
            ) |
            (
                [^#"']
            )
        )*
        (
            (
                \(
                (?!
                    [^\)]*
                    \)
                )
            ) |
            (
                \{
                (?!
                    [^\}]*
                    \}
                )
            ) |
            (
                \[
                (?!
                    [^\]]*
                    \]
                )
            )
        )
    )
).*
$

// decreaseIndentPattern
^
\\s*
(
    [}\\])]
    (
        (
            ,? \\s*
            (
                # |
                $
            )
        ) |
        (
            \\.
            [a-zA-Z_]
            \\w*
            \\b
        )
    ) |
    (
        end |
        rescue |
        ensure |
        else |
        elsif |
        when
    )
    \\b
)

For our "else"/"elif"/"except"/"finally" needs, the focus is on the decreaseIndentPattern.

One question I have is if I do:
if a:
    pass
    if b:
        pass
    else:
        pass
        |    # With the cursor here, what must I do to get dedenting to work for an `else` to the top-level `if`?

@jkyeung we can potentially borrow from Ruby thanks to how elsif works as it's similar for at least elif. But the whole point of this spike is to figure out what is feasible and what the ramifications are for the potential solutions.
And the Python Indent extension approach can't be used by us as it overrides the the Enter key which is way to intrusive for us to do.

@jkyeung we can potentially borrow from Ruby thanks to how elsif works as it's similar for at least elif.

Well, I guess you could say it's "similar", but then it's just as similar as Ruby's else is to Python's else. My concern remains the same: Ruby has an end keyword to mark the end of what we would call a suite. In Ruby (and pretty much all languages with block-ending delimiters) we can know with 100% certainty where elsif or else should be indented, no matter how badly formatted the code is, as long as it's valid.
# Ruby
if a
puts 'a'
if b
puts 'b'
elsif c  # must go with b
puts 'c'
end
end

# Ruby
if a
puts 'a'
if b
puts 'b'
end
elsif c  # must go with a
puts 'c'
end

Python does not have this property. (Of course, the following code, as-is, isn't even valid, but the point is we can't know for sure which of two valid indentation options is the right one, and if we pick the wrong one, the meaning of the program changes.)
# Python
if a:
print('a')
if b:
print('b')
elif c:  # no way to know
print('c')

But the whole point of this spike is to figure out what is feasible and what the ramifications are for the potential solutions.

I get that. Without understanding those Ruby-handling regexes, I was preemptively guarding against "oh, it works for Ruby, so let's just slap it in for Python!". For all I know, it may be that those regexes happen to be doing what the Python Indent extension says it is doing for else and friends, including NOT dedenting if already dedented. And if that's the case, I think I'm OK with it. But for all I know, it could also be making assumptions that don't hold for Python (such as "else must be dedented exactly one level relative to the previous line, so no matter where the else is now, we will put it there").
I'll hold further comments until more concrete details are presented.

FWIW, I tried applying just the dedent rules that we reverted and had the exact same problems with inappropriate indent.  Presumably the mere presence of indentationRules (or maybe just its "decreaseIndentPattern" property) is enough to trigger the undesirable behavior.

Given everything I've looked at in the sprint, I don't think it's worth it to pursue this further at the moment.  From what I can tell, VS Code make some assumptions about the existence of an end-of-block syntax (which Python almost uniquely does not have for "suites").
So at this point I'm not convinced that any of the existing options provided by VS Code will meet our needs.  However, it will be worth bringing this up with the VS Code folks as soon as they have interest/time.


Smaller Typography.Title by default

Typography.Title is quite big by default, even with lebel={5} it's too big for our applications. I'd suggest to use smaller font sizes by default here.

Agree, we don't need big splashy titles.


ngfDrop expression is getting evaluated twice upon file drop.

This causes the drop handler to get called twice each time a file or files are dropped..
This looks similar to other issues I've examined, but I'm not sure and most of those were already marked as resolved, so I think this might be a new one.
I set a breakpoint on the drop event, and it breaks on this line in ng-file-upload.js twice:
c[0].addEventListener("drop", function(b) {

The anonymous callback function gets called with the same DragEvent argument both times, which leads me to believe that ngfDrop is getting evaluated twice, instead of the possibility that my app somehow generates two events instead of one when I release the mouse button (mouse-up).
I'm using version 12.2.12.
Please let me know if I can be of any further assistance.

Same issue here, using 12.2.13.
`

Drop file here or click to upload

`
Here's the code snippet of the actual upload segment. This is using Angular ~1.5.

Does it cause any issue or is it just for the sake of extra calculation?

No biggie.  Just the annoyance of unnecessary events rattling around in the
code.  I found a workaround.  Thanks for asking.
-Larry Siden, http://plus.google.com/+LarrySiden
On Mon, Apr 24, 2017 at 2:15 PM, Danial Farid<EMAIL_ADDRESS>wrote:

Does it cause any issue or is it just for the sake of extra calculation?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/danialfarid/ng-file-upload/issues/1866#issuecomment-296777315,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIVWENjrA-6_nmPmn_Z7MVL7kV4RfO8ks5rzObMgaJpZM4MEvQt
.


ds-dev reloading page causes problems due to Twine

This is a more general problem than what is tracked in #9. It primarily has to do with the way we designed the Twine Service interface in Dropserver Go code.
type TwineService interface {
	Start(UserID, *twine.Twine)
	HandleMessage(twine.ReceivedMessageI)
}

The big problem is that when Twine quits, you want to unsubscribe from the various event systems you hooked into. But twine.ReceivedMessageI doesn't give you access to underlying Twine, nor tells you when it needs to stop. (It should).
I think Start should return an interface that has HandleMessage as a function. That way the handler can have access to the Twine object.
Also as a general rule, each instance of Twine should get its own service object.

This is fixed thanks to new TwineService2 interface:
// TwineService2 returns a TwineServiceI on start
type TwineService2 interface {
	Start(UserID, *twine.Twine) TwineServiceI
}

// TwineServiceI handles incoming messages for a twine connection
type TwineServiceI interface {
	HandleMessage(twine.ReceivedMessageI)
}

Thanks to this I was able to retool services such that they close down more completely. See abe0411c530bd928f3ccb3acb2602ea9ec044b08 and 71d0cd6a2cc0db03c5b9c0e367e0cd451ae23186.
Note that the problem with Twine not closing ref request channels is still there, and that leaves goroutines hanging, but it does not affect the function of the rest of the program, as best I can tell.


fix(transformer/class-properties): panic when the callee or member is ParenthesisExpression or TS-syntax expressions.

We need to call get_inner_expression_mut to get actual expressions that we need to deal with

#7750
#7795  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Merge activity

Dec 11, 6:14 AM EST: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.


[server] Add  tests case for RemoteLogITCase

Add creation, upload, download, and metadata update of remote logs lacking necessary tests.

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

This is my first time contributing to Fluss. If there is anything wrong, please let me know. thx!


feat: add board command

At this point, I didn't feel like adding a new message and everything...
Sent from Outlookhttp://aka.ms/weboutlook

From: Michał Moskal @.>
Sent: Monday, February 20, 2023 6:57 PM
To: microsoft/devicescript @.>
Cc: Peli de Halleux @.>; Author @.>
Subject: Re: [microsoft/devicescript] feat: add board command (PR #152)
@mmoskal approved this pull request.
looks good; I guess you could have called into cli to build the JSON but maybe there's no point
—
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fdevicescript%2Fpull%2F152%23pullrequestreview-1306551165&data=05|01|jhalleux%40microsoft.com|a240b4960e9a4202609808db13b75af4|72f988bf86f141af91ab2d7cd011db47|1|0|638125450449954830|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=fKj0TSDqJUe18%2FPr5O67Zw8f8YN%2BwySfpYNSUYNUaLI%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAA73QKJ77ORHM7WQJKNSBG3WYQVJFANCNFSM6AAAAAAVCPQO44&data=05|01|jhalleux%40microsoft.com|a240b4960e9a4202609808db13b75af4|72f988bf86f141af91ab2d7cd011db47|1|0|638125450449954830|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=8D4U2%2BlnQrSqOJvj1V47u225HFFPjSvw11eO8RYyh60%3D&reserved=0.
You are receiving this because you authored the thread.Message ID: @.***>


Support for older versions of firefox

'matches' function is not supported in older versions of firefox and currently this component only have a workaround implemented for old versions of internet explorer. I'm expanding that in order to support old versions of firefox as well.

Great, thanks!


small grammar error

I think this is what you guys meant to put there!

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


ci: build macOS on GitHub Actions

Currently, the released macOS builds are not from GitHub Actions. This PR adds back builds on macOS. This uses parts of the code from the local builder as well as adaptions I made for https://github.com/SevenTV/chatterino7.

I'm currently not interested in maintaining macOS builds in GH Actions