v2 embedding docs don't explain background plugin cases

This was raised by @ryanheise in flutter/flutter/issues/47153#issuecomment-578418750:

The critical thing I was looking for in this project [the android_alarm_manager plugin] was how to initialise the background isolate.
There are various comments in FlutterBackgroundExecutor which touch on things that I would love to see fully explained in the guide and API documentation:
      // We need to create an instance of `FlutterEngine` before looking up the
      // callback. If we don't, the callback cache won't be initialized and the
      // lookup will fail.
      FlutterCallbackInformation flutterCallback =
          FlutterCallbackInformation.lookupCallbackInformation(callbackHandle);

This isn't mentioned in the migration guide and is also not mentioned in the javadoc for FlutterCallbackInformation.
Also:
      // The pluginRegistrantCallback should only be set in the V1 embedding as
      // plugin registration is done via reflection in the V2 embedding.
      if (pluginRegistrantCallback != null) {
        pluginRegistrantCallback.registerWith(new ShimPluginRegistry(backgroundFlutterEngine));
      }

The migration guide does not explain how this reflection approach works.
Assuming that for each FlutterEngine instance, the GeneratedPluginRegistrant is automatically called and a new instance of the plugin class is created and attached to the engine resulting in a 1-to-1 mapping between engines and plugins, how does a plugin instance detect whether it is running in a flutter engine that is associated with the activity/ui vs the headless engine? I used to be able to test whether registrar.activity() returned null, but now I assume I have to override onAttachedToEngine and figure this out from the FlutterPluginBinding parameter.
The androidalarmmanager plugin overrides this and uses getFlutterEngine which looks almost promising except that this is a deprecated API:
  @Override
  public void onAttachedToEngine(FlutterPluginBinding binding) {
    onAttachedToEngine(
        binding.getApplicationContext(), binding.getFlutterEngine().getDartExecutor());
  }

And even if it were fine for me to call the deprecated getFlutterEngime method, I do not see any way from there to get the RenderSurface and test whether it's null.
I can now see that ServiceAware might be the way to do it, but this API doesn't seem to work, and none of the official plugins demonstrate how to use it. I made my plugin implement both ActivityAware and ServiceAware but only the lifecycle methods of the former were actually called. I also passed in my Service instance as the constructor argument when creating the background FlutterEngine but this itself didn't cause the ServiceAware callbacks to be called.
In any event, I got my plugin working with v2 using a different approach.
As some constructive feedback, I do appreciate all the hard work the Flutter team is doing, BUT I also hope that this migration experience is not something I will ever have to go through again. My suggestion is that a comprehensive migration guide should be in place before the release is rolled out, and should be prominently linked to from the release notes.

/cc @xster @matthew-carroll

Indeed. Though we're also unlikely to have a good backgrounding guide until we figure out the right backgrounding best practice https://github.com/flutter/flutter/issues/32164.

Hi, I also am encountering same issue now. There was an excellent guideline to show to create application with background process with v1 embedding. In order to understand the required changes from v2 embedding, I had created an issue to seek the help from the flutter team. The author of the guideline did an appreciate update in last year.
However, I am facing issues after I followed the steps that given in the guide. As plugin registration is done via reflection in the V2 embedding, I skipped the following codes.
sBackgroundFlutterView = new FlutterNativeView(context, true);
PluginRegistry registry = sBackgroundFlutterView.getPluginRegistry();
sPluginRegistrantCallback.registerWith(registry);
FlutterRunArguments args = new FlutterRunArguments();
args.bundlePath = FlutterMain.findAppBundlePath();
args.entrypoint = callbackInfo.callbackName;
args.libraryPath = callbackInfo.callbackLibraryPath;
sBackgroundFlutterView.runFromBundle(args);

and try to use following codes to create a new Flutter background isolate (FlutterEngine i guess):
sBackgroundFlutterEngine = new FlutterEngine(context);
DartExecutor.DartCallback args = new DartCallback(context.getAssets(), FlutterMain.findAppBundlePath(context), callbackInfo);
sBackgroundFlutterEngine.getDartExecutor().executeDartCallback(args);

The isolate creation seems work fine after changing these codes, but there are some plugins (e.g., path_provider) are failed to call in the created isolate (i.e., background isolate). The MissingPluginException is raised after using it in the background isolate. I believe it may caused by the plugin not be registered appropriately. Are there any missing steps that leading this exception happen? Or are there any workaround for me to use plugin in the background isolate?
If this issue can be solved, this guideline can help others to get a practical experience on running Dart code in background. Any suggestion is appreciated and welcome!

I'll try to look deeper into these confusion points and documenting them better when I've gotten through with some of the more urgent bugs.
@matthew-carroll can you provide some ideas on my issue? Thanks!

I'll try to look deeper into these confusion points and documenting them better when I've gotten through with some of the more urgent bugs.

@matthew-carroll can you provide some ideas on my issue? Thanks!

It seems I had solved the problem, please check my update in here.

I don't think I'll have any time to look into this. The best contact at this point is @xster. I haven't touched this code since I left the organization a year ago.


[MPWG Steering Meetings] Scheduled and pushed via twitter

Push twice before the meeting: Thursday before and Monday

Agenda minutes

zoom access

Time:

11am-12pm PDT

Schedule:

January 12th
April 13th
July 13th
Oct 12th

instead of zoom access, lets just add the poublic calendar access link that will contact theÑ
Zoom, agenda & date and time.

Twitter description
Join & contribute to the @MicroProfileIO Steering Committee call on 00/00 11 am-12 pm PDT [calendar link], where the  #MPCharter [link] is the baseline for all the decisions. #OpenSource
#ByCommunityForCommunity
with 2 links:

https://www.eclipse.org/org/workinggroups/microprofile-charter.php
<EMAIL_ADDRESS>

All set up on tweet deck.

You are fantastic @rstjames!
Can you please either update row 2 inventory media schedule  rows: I, J, K & FB? If you cannot, send the data via this ticket and I could help.
Ideally, everyonetime a card gets scheduled, the update is tracked via the inventory. Ideally, this is done by anyone who closes the tickets.
https://docs.google.com/spreadsheets/d/1-j0SmFHSRw4pXMsdsY1x0R2HffIUZ3SQni_5zpoBdE8/edit#gid=0

@aeiras I this is too much overhead to do every time things are sent out...  What will we use all this data for? And who has time to do something with it? Microprofile is a community project and I think we should keep the overhead down as much as possible.

@rstjames,
What do you think of the data you found in the MP <> MP onabording interview documents for the 4 MicroProfilers who are now linked to the consecutive media push for 2021?
Stating the day and how many times a message goes out per month or quarter matters. We can adjust what we choose to track.
Every single time a process is pilot, the goal is to be the example of how stuff was done so that new MicroProfilers can be enabled to rock it without hand-holding.
Thanks for allowing this follow up,


Create filter for withholding tax

Is your feature request related to a problem? Please describe.
Only show banks that do not have withholding tax
Describe the solution you'd like
Have a checkbox on top where you can filter out banks that have witholding tax
Additional context
Ugly and unstable script that works in console for now
function removeTax(bank)
{
  if(bank.getElementsByClassName('styles_chipNoTax___2wRF4 styles_chip___2iBM3').length === 0)
  {
	bank.hidden = true
  }
}

var banks = document.getElementsByClassName('styles_container___23AP0')
var banksArray = Array.from(banks)
banksArray.reverse().forEach(removeTax)

Added in 0.4.0. Package is pushed to CWS, waiting to be published.


cmd/gofmt: Faulty Comment Re-Arrangement in Argument Lists

Hi,
I noticed today that gofmt (on the Playground at least) reformats /* */ comments that are inlined in argument lists inconsistently and in a non-faithful manner to their original ordering in the list:
Pre-Gofmt
fmt.Println(/* before first */ "first", /* before second */ "second")
demo
Post-Gofmt
fmt.Println( /* before first */ "first" /* before second */, "second")
demo
Notice how in the Post-Gofmt case it moves the comment that occurred after the comma to before.
This behavior is incongruent to what happens when the argument lists are spread across multiple lines:
Newline Distributed Pre-Gofmt
package main

import "fmt"

func main() {
    fmt.Println(
    /* before first */ "first")
    fmt.Println(
    /* before first */ "first",
    /* before second */ "second")
}

demo
Newline Distributed Post-Gofmt
package main

import "fmt"

func main() {
    fmt.Println(
        /* before first */ "first")
    fmt.Println(
        /* before first */ "first",
        /* before second */ "second")
}

demo
For the pre cases, be sure to click Format in the Go Playground demo to see the post-state.

This is a known issue, but I couldn't find an existing bug report for it.

This looks like #9460.

I ran into this issue (I'm not sure this is a real issue, tho).
Go does not support named argument. So I wrote parameter names as prefixed comment in function call as below.
someFunc(/*name:*/ n, /*debug:*/ true)

However, gofmt formats it as following.
someFunc(/*name:*/ n /*debug:*/, true)

The /*debug:*/ comment is placed in the first argument though it's for the second argument.

Is there any update on this?  The problem exists in go 1.64.4

No update. Nobody is working on this.

@ncruces gofmt is notoriously difficult to change (mea culpa), and because of all the implications we (the Go team) should make changes here. That said, we don't have any bandwidth for this at the moment. Note that external help is not discouraged, but since any changes will be carefully reviewed in detail, this may not help much.

I'm having this problem with SQL requests.
My IDE only colorizes and autocomplete SQL requests....
Only if I add a comment that hints that the next string is a SQL request.
Example:
err = db.Select(&someSlice, /*language=sql*/ `
    SELECT something
    FROM somewhere
`)

My problem is that gofmt moves the comment to the end of the previous argument, which breaks the syntax highlighting
err = db.Select(&someSlice /*language=sql*/, `
    SELECT something
    FROM somewhere
`)


v2:bug(Modal): Android back button doesn't invoke onDismiss

Short description of the problem:
If I create a Modal an add an onDismiss listener. This won't be called if you press the back button on Android.
What behavior are you expecting?
onDismiss should also be called when I hit the Backbutton on Android
Steps to reproduce:

Create an Modal and add onDismiss listener with e.g.: an alert call
Open modal
press the back button
no alert will be opened :cry:

    let modal = Modal.create(Page1);
    this.greeting="";
    modal.onDismiss(()=>{
     alert("onDismiss called")
    });
    this.nav.present(modal);

Which Ionic Version?  2.0-beta.10
Plunker that shows an example of your issue
http://plnkr.co/edit/xZTtaAmv9D0JLugGIuXy?p=preview
Run ionic info from terminal/cmd prompt: (paste output below)
Your system information:
Cordova CLI: 6.2.0
Gulp version:  CLI version 3.9.1
Gulp local:   Local version 3.9.1
Ionic Framework Version: 2.0.0-beta.10
Ionic CLI Version: 2.0.0-beta.30
Ionic App Lib Version: 2.0.0-beta.16
OS: Distributor ID:	Debian Description:	Debian GNU/Linux 8.5 (jessie)
Node Version: v5.12.0

Any solution?
I have the same issue. :(


Stabilize upsampling_2d test

Current upsampling_2d_test is unstable.

jenkins, test this please

LGTM!

I will make a backport after #3382 will be merged.


Add a method of uncharging glories for amulet of eternal glory

🚀 Feature Proposal
Currently, the only way to uncharge glories is to do gnome restaurant for a 1/3 chance to use some glory charges. Needless to say, this is extremely slow. To hunt for the amulet of eternal glory, it's basically required to make fresh glories.
There should be a command to uncharge Amulet of glory (6) to Amulet of glory (5) so that they can be charged again for more chances at the amulet of eternal glory. For example, consider one teleport to take 3 ticks (1.8 seconds) -> round up to 2 seconds per amulet uncharged, or even make it a bit slower than that.
This would also likely need the +chargeglories command changed to accept Amulet of glory (5) for charging.

Would love to see this feature as I come closer to having to do that grind for CL

Would love to see this feature as I come closer to having to do that grind for CL

This is something i plan to work on soon unless someone beats me to it.


Edge Dropdown Bug

Description
When using the date picker on Edge it continuously opens when you try and close it

Steps to reproduce
Use vaadin-date-picker v2.0.2 in polymer 2 on Edge
Browsers Affected

[ ] Chrome
[ ] Firefox
[ ] Safari
[x] Edge
[ ] IE 11
[ ] iOS Safari
[ ] Android Chrome

I was able to fix this locally by removing this.open() from _onUserInput()
https://github.com/vaadin/vaadin-date-picker/blob/7c62532202b785939e4885c44125eaab06ca09e1/vaadin-date-picker-mixin.html#L744
Hope this helps. Thanks for the great components

Possibly related: https://github.com/vaadin/vaadin-combo-box/issues/506

Hi, I tried to reproduce the issue and it does not happen anymore. Probably some fix in text-field might fix it.
Please do you mind to check whether it has gone by visiting the vaadin-date-picker demo page?
Here a screenshot with it working in my system:
http://recordit.co/Koht1irQAY/gif/notify

Double checked by @YuriyVaadin and couldn't reproduce.
Closing, @ryanburns23 feel free to reopen if you continue having the issue.


[mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2: Problem and solution

First of all, I want to thank the author for the excellent adaptation of this solution in ESPHome.
version 2.8 added much-needed components. This is the control of vanes).
However, it added a problem for my device  SRK 63 ZSPR-S.
I upgraded from 2.7 to 2.8 and got the error:  [mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
this error made the integration not working.
`INFO ESPHome 2023.11.0
INFO Reading configuration /config/esphome/ac-ctrl-mits2.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing ac-ctrl--mits2 (board: d1_mini; framework: arduino; platform<EMAIL_ADDRESS>HARDWARE: ESP8266 160MHz, 80KB RAM, 4MB Flash
Dependency Graph
|-- ESPAsyncTCP-esphome @ 2.0.0
|-- ESPAsyncWebServer-esphome @ 3.1.0
|-- DNSServer @ 1.1.1
|-- ESP8266WiFi @ 1.0
|-- ESP8266mDNS @ 1.2
|-- ArduinoJson @ 6.18.5
Compiling .pioenvs/ac-ctrl--mits2/src/main.cpp.o
Linking .pioenvs/ac-ctrl--mits2/firmware.elf
RAM:   [=====     ]  46.0% (used 37676 bytes from 81920 bytes)
Flash: [=====     ]  47.7% (used 498401 bytes from 1044464 bytes)
Building .pioenvs/ac-ctrl--mits2/firmware.bin
esp8266_copy_factory_bin([".pioenvs/ac-ctrl--mits2/firmware.bin"], [".pioenvs/ac-ctrl--mits2/firmware.elf"])
========================= [SUCCESS] Took 13.13 seconds =========================
INFO Successfully compiled program.
INFO Resolving IP address of ac-ctrl--mits2.local
INFO  -> <IP_ADDRESS>
INFO Uploading /data/build/ac-ctrl--mits2/.pioenvs/ac-ctrl--mits2/firmware.bin (502560 bytes)
INFO Compressed to 341194 bytes
Uploading: [============================================================] 100% Done...
INFO Waiting for result...
INFO OTA successful
INFO Successfully uploaded program.
INFO Starting log output from ac-ctrl--mits2.local using esphome API
WARNING Can't connect to ESPHome API for ac-ctrl--mits2: Error resolving IP address: [Errno -5] No address associated with hostname (APIConnectionError)
INFO Trying to connect to ac-ctrl--mits2 in the background
INFO Successfully connected to ac-ctrl--mits2 in 0.013s
INFO Successful handshake with ac-ctrl--mits2 in 0.235s
[11:34:26][I][app:102]: ESPHome version 2023.11.0 compiled on Nov 15 2023, 11:33:50
[11:34:26][C][wifi:559]: WiFi:
[11:34:26][C][wifi:391]:   Local MAC: C8:C9:A3:54:89:5E
[11:34:26][C][wifi:396]:   SSID: [redacted]
[11:34:26][C][wifi:397]:   IP Address: <IP_ADDRESS>
[11:34:26][C][wifi:398]:   BSSID: [redacted]
[11:34:26][C][wifi:400]:   Hostname: 'ac-ctrl--mits2'
[11:34:26][C][wifi:402]:   Signal strength: -41 dB ▂▄▆█
[11:34:26][C][wifi:406]:   Channel: 11
[11:34:26][C][wifi:407]:   Subnet: <IP_ADDRESS>
[11:34:26][C][wifi:408]:   Gateway: <IP_ADDRESS>
[11:34:26][C][wifi:409]:   DNS1: <IP_ADDRESS>
[11:34:26][C][wifi:410]:   DNS2: <IP_ADDRESS>
[11:34:26][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:26][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:26][W][component:215]: Components should block for at most 20-30ms.
[11:34:26][C][logger:416]: Logger:
[11:34:26][C][logger:417]:   Level: DEBUG
[11:34:26][C][logger:418]:   Log Baud Rate: 0
[11:34:26][C][logger:420]:   Hardware UART: UART0
[11:34:26][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:26][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:26][W][component:215]: Components should block for at most 20-30ms.
[11:34:27][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:27][W][component:214]: Component  took a long time for an operation (0.07 s).
[11:34:27][W][component:215]: Components should block for at most 20-30ms.
[11:34:27][C][uptime.sensor:031]: Uptime Sensor 'MHI-AC-Ctrl__2 Uptime'
[11:34:27][C][uptime.sensor:031]:   Device Class: 'duration'
[11:34:27][C][uptime.sensor:031]:   State Class: 'total_increasing'
[11:34:27][C][uptime.sensor:031]:   Unit of Measurement: 's'
[11:34:27][C][uptime.sensor:031]:   Accuracy Decimals: 0
[11:34:27][C][uptime.sensor:031]:   Icon: 'mdi:timer-outline'
[11:34:27][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:27][W][component:214]: Component  took a long time for an operation (0.07 s).
[11:34:27][W][component:215]: Components should block for at most 20-30ms.
[11:34:27][C][template.select:065]: Template Select 'MHI-AC-Ctrl__2 Fan Control Left Right'
[11:34:27][C][template.select:065]:   Icon: 'mdi:arrow-left-right'
[11:34:27][C][template.select:066]:   Update Interval: 60.0s
[11:34:27][C][template.select:069]:   Optimistic: YES
[11:34:27][C][template.select:070]:   Initial Option: Left
[11:34:27][C][template.select:071]:   Restore Value: NO
[11:34:27][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:27][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:27][W][component:215]: Components should block for at most 20-30ms.
[11:34:27][C][template.select:065]: Template Select 'MHI-AC-Ctrl__2 Fan Control Up Down'
[11:34:27][C][template.select:065]:   Icon: 'mdi:arrow-up-down'
[11:34:27][C][template.select:066]:   Update Interval: 60.0s
[11:34:27][C][template.select:069]:   Optimistic: YES
[11:34:27][C][template.select:070]:   Initial Option: Up
[11:34:27][C][template.select:071]:   Restore Value: NO
[11:34:27][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:27][W][component:214]: Component  took a long time for an operation (0.07 s).
[11:34:27][W][component:215]: Components should block for at most 20-30ms.
[11:34:27][D][api:102]: Accepted <IP_ADDRESS>
[11:34:27][C][template.switch:068]: Template Switch 'MHI-AC-Ctrl__2 3D Auto'
[11:34:27][C][template.switch:070]:   Icon: 'mdi:video-3d'
[11:34:27][C][template.switch:090]:   Restore Mode: always OFF
[11:34:27][C][template.switch:057]:   Optimistic: YES
[11:34:27][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:27][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:27][W][component:215]: Components should block for at most 20-30ms.
[11:34:27][D][api.connection:1089]: Home Assistant 2023.11.2 (<IP_ADDRESS>): Connected successfully
[11:34:27][C][dallas.sensor:075]: DallasComponent:
[11:34:27][C][dallas.sensor:076]:   Pin: GPIO4
[11:34:27][C][dallas.sensor:077]:   Update Interval: 60.0s
[11:34:27][D][dallas.sensor:082]:   Found sensors:
[11:34:27][D][dallas.sensor:084]:     0x893c01f096baa728
[11:34:27][C][dallas.sensor:089]:   Device 'MHI-AC-Ctrl__2 External Sensor Temperature'
[11:34:27][C][dallas.sensor:089]:     Device Class: 'temperature'
[11:34:27][C][dallas.sensor:089]:     State Class: 'measurement'
[11:34:27][C][dallas.sensor:089]:     Unit of Measurement: '°C'
[11:34:27][C][dallas.sensor:089]:     Accuracy Decimals: 1
[11:34:27][C][dallas.sensor:097]:     Address: 0x893c01f096baa728
[11:34:27][C][dallas.sensor:098]:     Resolution: 12
[11:34:27][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:27][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:27][W][component:215]: Components should block for at most 20-30ms.
[11:34:27][C][mhi_ac_ctrl:144]: MHI-AC-Ctrl Climate 'MHI-AC-Ctrl__2'
[11:34:27][C][mhi_ac_ctrl:145]:   Min. Temperature: 18.0°C
[11:34:27][C][mhi_ac_ctrl:146]:   Max. Temperature: 30.0°C
[11:34:27][C][mhi_ac_ctrl:147]:   Supports HEAT: YES
[11:34:27][C][mhi_ac_ctrl:148]:   Supports COOL: YES
[11:34:27][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:27][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:27][W][component:215]: Components should block for at most 20-30ms.
[11:34:27][C][version.text_sensor:021]: Version Text Sensor 'MHI-AC-Ctrl__2 ESPHome Version'
[11:34:27][C][version.text_sensor:021]:   Icon: 'mdi:new-box'
[11:34:27][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:27][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:27][W][component:215]: Components should block for at most 20-30ms.
[11:34:27][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:27][W][component:214]: Component  took a long time for an operation (0.07 s).
[11:34:27][W][component:215]: Components should block for at most 20-30ms.
[11:34:27][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:27][W][component:214]: Component  took a long time for an operation (0.08 s).
[11:34:27][W][component:215]: Components should block for at most 20-30ms.
[11:34:27][C][captive_portal:088]: Captive Portal:
[11:34:27][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:27][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:27][W][component:215]: Components should block for at most 20-30ms.
[11:34:27][C][web_server:168]: Web Server:
[11:34:27][C][web_server:169]:   Address: ac-ctrl--mits2.local:80
[11:34:27][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:27][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:27][W][component:215]: Components should block for at most 20-30ms.
[11:34:27][C][mdns:115]: mDNS:
[11:34:27][C][mdns:116]:   Hostname: ac-ctrl--mits2
[11:34:28][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:28][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:28][W][component:215]: Components should block for at most 20-30ms.
[11:34:28][C][ota:097]: Over-The-Air Updates:
[11:34:28][C][ota:098]:   Address: ac-ctrl--mits2.local:8266
[11:34:28][C][ota:101]:   Using Password.
[11:34:28][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:28][W][component:214]: Component  took a long time for an operation (0.07 s).
[11:34:28][W][component:215]: Components should block for at most 20-30ms.
[11:34:28][C][api:139]: API Server:
[11:34:28][C][api:140]:   Address: ac-ctrl--mits2.local:6053
[11:34:28][C][api:144]:   Using noise encryption: NO
[11:34:28][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:28][W][component:214]: Component  took a long time for an operation (0.07 s).
[11:34:28][W][component:215]: Components should block for at most 20-30ms.
[11:34:28][C][wifi_signal.sensor:009]: WiFi Signal 'MHI-AC-Ctrl__2 WiFi Signal'
[11:34:28][C][wifi_signal.sensor:009]:   Device Class: 'signal_strength'
[11:34:28][C][wifi_signal.sensor:009]:   State Class: 'measurement'
[11:34:28][C][wifi_signal.sensor:009]:   Unit of Measurement: 'dBm'
[11:34:28][C][wifi_signal.sensor:009]:   Accuracy Decimals: 0
[11:34:28][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:28][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:28][W][component:215]: Components should block for at most 20-30ms.
[11:34:28][C][wifi_info:009]: WifiInfo IPAddress 'MHI-AC-Ctrl__2 IP'
[11:34:28][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:28][W][component:214]: Component  took a long time for an operation (0.07 s).
[11:34:28][W][component:215]: Components should block for at most 20-30ms.
[11:34:28][C][wifi_info:011]: WifiInfo SSID 'MHI-AC-Ctrl__2 SSID'
[11:34:28][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:28][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:28][W][component:215]: Components should block for at most 20-30ms.
[11:34:28][C][wifi_info:012]: WifiInfo BSSID 'MHI-AC-Ctrl__2 BSSID'
[11:34:28][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:28][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:28][W][component:215]: Components should block for at most 20-30ms.
[11:34:28][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:28][W][component:214]: Component  took a long time for an operation (0.07 s).
[11:34:28][W][component:215]: Components should block for at most 20-30ms.
[11:34:28][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:28][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:28][W][component:215]: Components should block for at most 20-30ms.
[11:34:28][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:28][W][component:214]: Component  took a long time for an operation (0.09 s).
[11:34:28][W][component:215]: Components should block for at most 20-30ms.
[11:34:29][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:29][W][component:214]: Component  took a long time for an operation (0.07 s).
[11:34:29][W][component:215]: Components should block for at most 20-30ms.
[11:34:29][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:29][W][component:214]: Component  took a long time for an operation (0.07 s).
[11:34:29][W][component:215]: Components should block for at most 20-30ms.
[11:34:29][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:29][W][component:214]: Component  took a long time for an operation (0.06 s).
[11:34:29][W][component:215]: Components should block for at most 20-30ms.
[11:34:29][W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[11:34:29][W][component:214]: Component  took a long time for an operation (0.07 s).
[11:34:29][W][component:215]: Components should block for at most 20-30ms.`
the WEB looks like this:

I'm not a programmer. My friend is a soldering iron)))
So I started comparing files. I was looking for differences. I noticed that the author additionally uses a different cache calculation for SPI. This interfered with normal work.
I locked a line in the file: mhi_ac_ctrl.h

This allowed the integration to work normally.
`
INFO ESPHome 2023.11.0
INFO Reading configuration /config/esphome/ac-ctrl-mits2.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing ac-ctrl--mits2 (board: d1_mini; framework: arduino; platform<EMAIL_ADDRESS>HARDWARE: ESP8266 160MHz, 80KB RAM, 4MB Flash
Dependency Graph
|-- ESPAsyncTCP-esphome @ 2.0.0
|-- ESPAsyncWebServer-esphome @ 3.1.0
|-- DNSServer @ 1.1.1
|-- ESP8266WiFi @ 1.0
|-- ESP8266mDNS @ 1.2
|-- ArduinoJson @ 6.18.5
Compiling .pioenvs/ac-ctrl--mits2/src/main.cpp.o
Linking .pioenvs/ac-ctrl--mits2/firmware.elf
RAM:   [=====     ]  46.0% (used 37676 bytes from 81920 bytes)
Flash: [=====     ]  47.7% (used 498353 bytes from 1044464 bytes)
Building .pioenvs/ac-ctrl--mits2/firmware.bin
esp8266_copy_factory_bin([".pioenvs/ac-ctrl--mits2/firmware.bin"], [".pioenvs/ac-ctrl--mits2/firmware.elf"])
========================= [SUCCESS] Took 12.78 seconds =========================
INFO Successfully compiled program.
INFO Resolving IP address of ac-ctrl--mits2.local
INFO  -> <IP_ADDRESS>
INFO Uploading /data/build/ac-ctrl--mits2/.pioenvs/ac-ctrl--mits2/firmware.bin (502512 bytes)
INFO Compressed to 341168 bytes
Uploading: [============================================================] 100% Done...
INFO Waiting for result...
INFO OTA successful
INFO Successfully uploaded program.
INFO Starting log output from ac-ctrl--mits2.local using esphome API
INFO Successfully connected to ac-ctrl--mits2 in 17.675s
INFO Successful handshake with ac-ctrl--mits2 in 0.089s
[11:45:18][I][app:102]: ESPHome version 2023.11.0 compiled on Nov 15 2023, 11:44:43
[11:45:18][C][wifi:559]: WiFi:
[11:45:18][C][wifi:391]:   Local MAC: C8:C9:A3:54:89:5E
[11:45:18][C][wifi:396]:   SSID: [redacted]
[11:45:18][C][wifi:397]:   IP Address: <IP_ADDRESS>
[11:45:18][C][wifi:398]:   BSSID: [redacted]
[11:45:18][C][wifi:400]:   Hostname: 'ac-ctrl--mits2'
[11:45:18][C][wifi:402]:   Signal strength: -43 dB ▂▄▆█
[11:45:18][C][wifi:406]:   Channel: 11
[11:45:18][C][wifi:407]:   Subnet: <IP_ADDRESS>
[11:45:18][C][wifi:408]:   Gateway: <IP_ADDRESS>
[11:45:18][C][wifi:409]:   DNS1: <IP_ADDRESS>
[11:45:18][C][wifi:410]:   DNS2: <IP_ADDRESS>
[11:45:18][C][logger:416]: Logger:
[11:45:18][C][logger:417]:   Level: DEBUG
[11:45:18][C][logger:418]:   Log Baud Rate: 0
[11:45:18][C][logger:420]:   Hardware UART: UART0
[11:45:18][C][uptime.sensor:031]: Uptime Sensor 'MHI-AC-Ctrl__2 Uptime'
[11:45:18][C][uptime.sensor:031]:   Device Class: 'duration'
[11:45:18][C][uptime.sensor:031]:   State Class: 'total_increasing'
[11:45:18][C][uptime.sensor:031]:   Unit of Measurement: 's'
[11:45:18][C][uptime.sensor:031]:   Accuracy Decimals: 0
[11:45:18][C][uptime.sensor:031]:   Icon: 'mdi:timer-outline'
[11:45:18][C][template.select:065]: Template Select 'MHI-AC-Ctrl__2 Fan Control Left Right'
[11:45:18][C][template.select:065]:   Icon: 'mdi:arrow-left-right'
[11:45:18][C][template.select:066]:   Update Interval: 60.0s
[11:45:18][C][template.select:069]:   Optimistic: YES
[11:45:18][C][template.select:070]:   Initial Option: Left
[11:45:18][C][template.select:071]:   Restore Value: NO
[11:45:18][C][template.select:065]: Template Select 'MHI-AC-Ctrl__2 Fan Control Up Down'
[11:45:18][C][template.select:065]:   Icon: 'mdi:arrow-up-down'
[11:45:18][C][template.select:066]:   Update Interval: 60.0s
[11:45:18][C][template.select:069]:   Optimistic: YES
[11:45:18][C][template.select:070]:   Initial Option: Up
[11:45:18][C][template.select:071]:   Restore Value: NO
[11:45:18][C][template.switch:068]: Template Switch 'MHI-AC-Ctrl__2 3D Auto'
[11:45:18][C][template.switch:070]:   Icon: 'mdi:video-3d'
[11:45:18][C][template.switch:090]:   Restore Mode: always OFF
[11:45:18][C][template.switch:057]:   Optimistic: YES
[11:45:18][C][dallas.sensor:075]: DallasComponent:
[11:45:18][C][dallas.sensor:076]:   Pin: GPIO4
[11:45:18][C][dallas.sensor:077]:   Update Interval: 60.0s
[11:45:18][D][dallas.sensor:082]:   Found sensors:
[11:45:18][D][dallas.sensor:084]:     0x893c01f096baa728
[11:45:18][C][dallas.sensor:089]:   Device 'MHI-AC-Ctrl__2 External Sensor Temperature'
[11:45:18][C][dallas.sensor:089]:     Device Class: 'temperature'
[11:45:18][C][dallas.sensor:089]:     State Class: 'measurement'
[11:45:18][C][dallas.sensor:089]:     Unit of Measurement: '°C'
[11:45:18][C][dallas.sensor:089]:     Accuracy Decimals: 1
[11:45:18][C][dallas.sensor:097]:     Address: 0x893c01f096baa728
[11:45:18][C][dallas.sensor:098]:     Resolution: 12
[11:45:18][W][component:214]: Component  took a long time for an operation (0.05 s).
[11:45:18][W][component:215]: Components should block for at most 20-30ms.
[11:45:18][C][mhi_ac_ctrl:144]: MHI-AC-Ctrl Climate 'MHI-AC-Ctrl__2'
[11:45:18][C][mhi_ac_ctrl:145]:   Min. Temperature: 18.0°C
[11:45:18][C][mhi_ac_ctrl:146]:   Max. Temperature: 30.0°C
[11:45:18][C][mhi_ac_ctrl:147]:   Supports HEAT: YES
[11:45:18][C][mhi_ac_ctrl:148]:   Supports COOL: YES
[11:45:18][C][version.text_sensor:021]: Version Text Sensor 'MHI-AC-Ctrl__2 ESPHome Version'
[11:45:18][C][version.text_sensor:021]:   Icon: 'mdi:new-box'
[11:45:18][C][captive_portal:088]: Captive Portal:
[11:45:18][C][web_server:168]: Web Server:
[11:45:18][C][web_server:169]:   Address: ac-ctrl--mits2.local:80
[11:45:18][D][mhi_ac_ctrl:154]: received status=143 value=7 power=0
[11:45:18][D][climate:380]: 'MHI-AC-Ctrl__2' - Sending state:
[11:45:18][D][climate:383]:   Mode: OFF
[11:45:18][D][climate:388]:   Fan Mode: HIGH
[11:45:18][D][climate:400]:   Swing Mode: OFF
[11:45:18][D][climate:403]:   Current Temperature: 21.75°C
[11:45:18][D][climate:409]:   Target Temperature: 18.00°C
[11:45:18][D][sensor:093]: 'MHI-AC-Ctrl__2 Outdoor unit discharge pipe': Sending state 35.00000 °C with 1 decimals of accuracy
[11:45:18][C][mdns:115]: mDNS:
[11:45:18][C][mdns:116]:   Hostname: ac-ctrl--mits2
[11:45:18][C][ota:097]: Over-The-Air Updates:
[11:45:18][C][ota:098]:   Address: ac-ctrl--mits2.local:8266
[11:45:18][C][ota:101]:   Using Password.
[11:45:18][C][api:139]: API Server:
[11:45:18][C][api:140]:   Address: ac-ctrl--mits2.local:6053
[11:45:18][C][api:144]:   Using noise encryption: NO
[11:45:18][C][wifi_signal.sensor:009]: WiFi Signal 'MHI-AC-Ctrl__2 WiFi Signal'
[11:45:18][C][wifi_signal.sensor:009]:   Device Class: 'signal_strength'
[11:45:18][C][wifi_signal.sensor:009]:   State Class: 'measurement'
[11:45:18][C][wifi_signal.sensor:009]:   Unit of Measurement: 'dBm'
[11:45:18][C][wifi_signal.sensor:009]:   Accuracy Decimals: 0
[11:45:19][C][wifi_info:009]: WifiInfo IPAddress 'MHI-AC-Ctrl__2 IP'
[11:45:19][C][wifi_info:011]: WifiInfo SSID 'MHI-AC-Ctrl__2 SSID'
[11:45:19][C][wifi_info:012]: WifiInfo BSSID 'MHI-AC-Ctrl__2 BSSID'
[11:45:19][D][api:102]: Accepted <IP_ADDRESS>
[11:45:19][D][api.connection:1089]: Home Assistant 2023.11.2 (<IP_ADDRESS>): Connected successfully
[11:45:19][D][mhi_ac_ctrl:154]: received status=142 value=0 power=0
[11:45:19][D][climate:380]: 'MHI-AC-Ctrl__2' - Sending state:
[11:45:19][D][climate:383]:   Mode: OFF
[11:45:19][D][climate:388]:   Fan Mode: HIGH
[11:45:19][D][climate:400]:   Swing Mode: OFF
[11:45:19][D][climate:403]:   Current Temperature: 21.75°C
[11:45:19][D][climate:409]:   Target Temperature: 18.00°C
[11:45:19][D][sensor:093]: 'MHI-AC-Ctrl__2 current power': Sending state 0.00000 A with 2 decimals of accuracy
[11:45:19][W][component:214]: Component  took a long time for an operation (0.05 s).
[11:45:19][W][component:215]: Components should block for at most 20-30ms.
[11:45:21][W][component:214]: Component  took a long time for an operation (0.05 s).
[11:45:21][W][component:215]: Components should block for at most 20-30ms.
[11:45:21][D][mhi_ac_ctrl:154]: received status=70 value=147 power=0
[11:45:21][D][climate:380]: 'MHI-AC-Ctrl__2' - Sending state:
[11:45:21][D][climate:383]:   Mode: OFF
[11:45:21][D][climate:388]:   Fan Mode: HIGH
[11:45:21][D][climate:400]:   Swing Mode: OFF
[11:45:21][D][climate:403]:   Current Temperature: 21.75°C
[11:45:21][D][climate:409]:   Target Temperature: 18.00°C
[11:45:21][D][climate:380]: 'MHI-AC-Ctrl__2' - Sending state:
[11:45:21][D][climate:383]:   Mode: OFF
[11:45:21][D][climate:388]:   Fan Mode: HIGH
[11:45:21][D][climate:400]:   Swing Mode: OFF
[11:45:21][D][climate:403]:   Current Temperature: 21.50°C
[11:45:21][D][climate:409]:   Target Temperature: 18.00°C
[11:45:22][D][mhi_ac_ctrl:154]: received status=144 value=0 power=0
[11:45:22][D][climate:380]: 'MHI-AC-Ctrl__2' - Sending state:
[11:45:22][D][climate:383]:   Mode: OFF
[11:45:22][D][climate:388]:   Fan Mode: HIGH
[11:45:22][D][climate:400]:   Swing Mode: OFF
[11:45:22][D][climate:403]:   Current Temperature: 21.50°C
[11:45:22][D][climate:409]:   Target Temperature: 18.00°C
[11:45:22][D][sensor:093]: 'MHI-AC-Ctrl__2 Outdoor unit discharge pipe super heat': Sending state 0.00000 °C with 1 decimals of accuracy
[11:45:23][D][mhi_ac_ctrl:154]: received status=145 value=0 power=0
[11:45:23][D][climate:380]: 'MHI-AC-Ctrl__2' - Sending state:
[11:45:23][D][climate:383]:   Mode: OFF
[11:45:23][D][climate:388]:   Fan Mode: HIGH
[11:45:23][D][climate:400]:   Swing Mode: OFF
[11:45:23][D][climate:403]:   Current Temperature: 21.50°C
[11:45:23][D][climate:409]:   Target Temperature: 18.00°C
[11:45:23][D][text_sensor:064]: 'MHI-AC-Ctrl__2 Protection error state': Sending state 'Normal'
[11:45:23][D][sensor:093]: 'MHI-AC-Ctrl__2 Protection error state': Sending state 0.00000  with 0 decimals of accuracy
[11:45:23][W][component:214]: Component  took a long time for an operation (0.05 s).
[11:45:23][W][component:215]: Components should block for at most 20-30ms.
`
I hope that my research will help the author to solve the problem.
PS
I apologize for the long logs. I don't know how to hide them)

But does the vane controls and 3D auto still work?

Yes. It was reverse engineered that these functions needs a bigger frame size to communicate with the AC unit and this is what you probably reverted with the commented line in mhi_ac_ctrl.h

I agree with you.
I guessed that these frame size changes were made to implement 3D Auto and left/right steering.
But these changes broke the integration (

@AlexzeyK Thank you for sharing this. I was a bit surprised that the amount of posts/reports with this issue are not bigger than they actually are. Now I probably found why.
It seems it has to do with the model/compatibility of the model itself. For newer models, I think the code is perfectly fine. They indeed support the bigger frame size of 33 (the line you commented out). The older models do not seem to stick with the 'latest standard' and cannot handle this bigger frame size.
I first had this project implemented for a very long time on my own airco-units (installed in 2016) with indoor units SRK35ZM-S and SRK50ZM-S (basically, I expect all SRK xx ZM-S to be the same). It has worked fine but just like in your case, with the latest commits it stopped working. The 'loop error code: -2' like messages were there like crazy which also somewhat indicates an issue with the communication of the units. Even though this happens to me every now and then (even with the old code), it was never like the flooding I get when the frame_size is set to 33.
Last week I installed the same module in a newer unit: SRK35ZS-W. I discovered that the exact same code, without changing/commenting the frame_size line, is working fine for this unit. So it is a compatibility issue with just specific units.
Now, although this is a theory; my unit never officially supported the 'WF-RAC' official wifi modules of MHI. Apart from the fact that it is very hard to reach the 'CNS' interface port, I imagine it is also because the units are not compliant with the 'latest' interface standard and therefore, the module doesn't work properly with this units. This probably counts for all the units without official 'WF-RAC' support; it might work, but depending on the model (and possibly it's internal firmware) the latest release will not work due to the unsupported frame_size.
@ginkage  is this something maybe to add to the README to make users aware?
I think it's good to get a list of units that face this issue. @AlexzeyK maybe you can share the indoor-unit you have that faces this issue as well?
Thank you all for contributing to this project!

@Dennis-Q  Thank you for communicating about this issue. I mentioned my block model in the first post.

It's hard to accept that my model is older than 2016)
Let me know if you need my help (test the code, sniff the block dialog)

https://github.com/RobertJansen1/MHI-AC-Ctrl-ESPHome/tree/legacy_support
i patched the files and added an option to configure this setting from the yaml file. if this can be tested, it would be greatly appreciated and i can add documentation for it if this works :)

@AlexzeyK  thank you for sharing (again). I honestly have read your post a long time ago and forgot you did have the model in there. I understand your frustration regarding the 'old model'.
@RobertJansen1
I added the 'globals' part you added to my own esphome yaml and used the .h and .cpp files from your legacy_support branch. It is working exactly as you would expect (identical to the manual change); with '33' value the log is flooded with the loop error: -2, but when set to '20', it is working perfectly fine (apart from some of the features).
So this means we won't have left-right and up/down, but it seems that the up/down is also incorrectly reported. Is this something that easily can be debugged? I understand it is somewhat unrelated.
Also; I wonder if we should add something more (maybe to the esphome yaml) to not expose 3D Auto and left-right options when they won't work anyway (e.g. frame size set to 20).
Thank you for working on this so quickly. I thought I suggested to implement such a feature in the code with my comment from this morning, but it seems I removed that part haha. Feels like coincidence that you started working on this yesterday already, looking at the commits of the branch :)

@RobertJansen1  I just tried your version with legacy_support. I apologize for the delay - the subject is in the workspace)
The behavior of my SRK 63 ZSPR-S  completely matches the description Dennis-Q
also with value 33 i get -2 error.
likewise with a value of 20 I get working integration except for 3D control and horizontal blind control.

oke, did some yaml magic to have one line comment / uncomment the new features, or enable legacy mode. it also removes 3d auto and vanes lr for unsupported models, and updated the readme.

Great work, looking good and I think all is clear. I did do some suggestion in my comment of your pull request. Thanks for the effort taken!

@heartkingz the pull request has not been committed yet. If you can't wait, you can use @RobertJansen1 his repo for now:
https://github.com/RobertJansen1/MHI-AC-Ctrl-ESPHome/tree/master

@heartkingz the pull request has not been committed yet. If you can't wait, you can use @RobertJansen1 his repo for now: https://github.com/RobertJansen1/MHI-AC-Ctrl-ESPHome/tree/master
And indeed; changing the framesize in the .h file from 33 to 20 (or commenting out the line) will probably fix your issue.

Ah i was just looking for the wrong repo lol. Thanks for clarifying!

I have one more question for you: where and what should I write in the code so that the air conditioners turn on with certain parameters? After the power supply is restored, the devices should turn on:

cooling mode
The power of the flow is maximum
Shoulder blades (vertical/horizontal) - swaying.

This should direct the module MHI-AC-Ctrl if there is no connection to the server (i.e. in offline mode) or before connecting to the server.

i think you could do with some magic in the on_boot parameters of esphome, and maybe also add a disconnected. that is offtopic for this issue though, if you want more help with that, please create a new issue.
i will close this issue, as the problem was solved and merged into master.


Can't invoke FFmpeg methods(FFmpeg.getInstance() and new ExecuteBinaryResponseHandler())

I'm trying to use FFmpeg if Android Studio(java) with a device J415G Android Pie SDK 28(if i'm not mistaken)
The problem is that i can use FFmpeg calling the command without problems:

FFmpeg.execute("--here goes the commands");

BUT, i can't find/call some important methods(they weren't defined):

FFmpeg.getInstance()
ExecuteBinaryResponseHandler()

I found only 3 FFmpeg.execute() definitions:

public static int execute(final String command)
public static int execute(final String command, final String delimiter)
public static int execute(final String[] arguments)

None of those arguments expected a new ExecuteBinaryResponseHandler()
In other words i can't check if executed commands were successful, can't check if FFmpeg is supported, and so on..

FFmpeg.getInstance(this).isSupported()

What i did to "install" FFmpeg in Android Studio was add the following line in gradle file. As expected method FFmpeg.execute works, but can't use most of others FFmpeg methods...

dependencies {
implementation 'nl.bravobit:android-ffmpeg:1.1.7'
}

Is this a issue or am i doing something wrong?
Sorry for any trouble i'm very newbie in Android development...
And thanks for help

Sorry i imported two libraries by mistake and was trying to use bravobit commands with the another ffmpeg library...


fix miri invocation

Cc jonhoo/flurry#93

Codecov Report

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

Impacted Files
Coverage Δ

src/lib.rs
61.71% <0.00%> (ø)

src/external_trait_impls/rayon.rs
82.22% <0.00%> (ø)

src/external_trait_impls/serde.rs
67.56% <0.00%> (ø)

src/iter.rs
91.42% <0.00%> (ø)


private registration view

Add a view that will check uuid in the url, based on this uuid form for ticket is rendered.

Make sure TicketType UUID get from url and ACCESSIBILITY is Private
TicketType has to be in available date range
ticket with price is in requested state, everyone else in state registered
Those in requested state have description required field in the form

There is an issue #125 that changes the directory structure to avoid conflicts, lets do the parent issue first.

I'll do it

Unfortunately I don't have time to finish it this week.

@ricco386, @ZoltanOnody I just submited a pr. I didn't get all of what was required, but I guess most of my merge request makes sense. I guess it would be possible to improve it, but that can be discussed there rather than here :-)

@simonsmiley thanks, I have explained everything needed in the PR #167 I guess it is clear there, but if you have more questions do not hesitate to ask.


fmtlib places files outside of .data when not linking against Python

When using -DLINK_AGAINST_PYTHON=FALSE (for instance, for building wheels), Eigen and related libs are placed in nmodl/.data, but fmtlib doesn't respect this and stubbornly puts items in other places. Below is an excerpt from the install_manifest.txt file (tested with latest master):
/lib/libfmt.a
/include/fmt/args.h
/include/fmt/chrono.h
/include/fmt/color.h
/include/fmt/compile.h
/include/fmt/core.h
/include/fmt/format.h
/include/fmt/format-inl.h
/include/fmt/os.h
/include/fmt/ostream.h
/include/fmt/printf.h
/include/fmt/ranges.h
/include/fmt/std.h
/include/fmt/xchar.h
/lib/cmake/fmt/fmt-config.cmake
/lib/cmake/fmt/fmt-config-version.cmake
/lib/cmake/fmt/fmt-targets.cmake
/lib/cmake/fmt/fmt-targets-release.cmake
/lib/pkgconfig/fmt.pc
/nmodl/.data/lib/libpywrapper.dylib
/nmodl/_nmodl.cpython-311-darwin.so
/nmodl/.data/include/newton/newton.hpp
/nmodl/.data/include/Eigen/CholmodSupport
/nmodl/.data/include/Eigen/StdVector
/nmodl/.data/include/Eigen/StdDeque
... other files in /nmodl/.data/

I don't know if this is intended or not, but it's somewhat annoying since the wheel built with scikit-build-core (see #1147) has lib (or lib64 on Linux) and include directories along with the nmodl one.

We don't install fmt anymore.

For future readers, this was fixed by #1193


Faster creation of teams and namespaces

It might be useful to have a way to create teams and namespaces faster. That is, if you are planning to create teams and namespaces that are pretty similar and that they have a similar team members list.

Cool idea, would have been convinient for a migration..
And it sounds like a job for portusctl.

I just found out, why it is cool: I made a similiar proposal recently #1024 :-)
Furthermore I suggest looking again over #763 and decide whether a formal API with a well defined subset of the functionality might be desirable and should be used for this proposal underneath portusctl

This is already handled through #1403 and #1412.


add support in fortran types for preprocessed files with uppercases

just had fortran files with uppercases extension to enable also preprocessed files

the number of extensions was upper than 12. I remove some, I will propose another


fix partial transparency

This commit replaces drawImage by drawAlpha, a function that draws an image handling transparent pixels correctly.
The formula is taken from https://en.wikipedia.org/wiki/Alpha_compositing
This is a workaround to fix #6. We should probably fix Mini Micro's drawImage instead.

Hmm.  Mini Micro's drawImage works exactly as intended.  I'm not sure that drawing pixel by pixel is the right solution to this problem, either.  More likely, the problem is overdraw — i.e. drawing an alpha image multiple times without clearing first.  Or perhaps we're not consistently resetting fatbits before drawing.
I think this needs a bit more thought before merging.  Get with me on Discord and let's discuss!

Well you were right, I was wrong!  drawImage was, at the very least, using a nonstandard compositing operation.  The standard one both matches expectations better, and fixes issue #6.  Thanks for your patience and help in clearing this up!


⚠ gorzdrav.org has degraded performance

In fab6d15, gorzdrav.org (https://gorzdrav.org) experienced degraded performance:

HTTP code: 200
Response time: 2826 ms

Resolved: gorzdrav.org performance has improved in aa1ee2b.


Size prompt when name changes

I'm getting the "Allow this website to use space on your disk?" prompt when I change the localforage.name from default, at least the first time after the website stores data in the browser (is registered in the browser's Website Data). Safari 9.0.

Sorry for the late response. Did you see this message the first time you used the default DB as well? I don't think the name should affect whether or not a message appears, but if you already created a DB in the past with the default name you might not be getting errors.

Not sure but I'll check this out next time I use localForage.

Safari has a very unpredictable way of calculating the total available size. If you create too many databases with different names (even if they are very small, or don't have any data at all!) eventually Safari will complain.
If you are only running into this in your dev environment, then the best bet is to probably just clear all Safari data and start over. (See "Remove all website data..." in the Safari settings.)

Good to know.
If we can reproduce this from a fresh browser state, feel free to reopen, but I'll close this for now.


Fix Ubuntu build with system libzint

ffi-1.17.0 doesn't look any longer automatically into /usr/local/lib for libraries. Instead the /etc/ld.so.conf and ld.so.cache is used to find libraries. But new libraries needs to be added to the cache first in order to be found.

The standardrb job could be changed to https://github.com/standardrb/standard-ruby-action which seems easier than the current (failing) one.


Raising the token limit to 255.

Make sure the tokenizers in quickwit, and in particular the raw tokenizer has a token limit of 255 (as opposed to 100 today).
(This is enforced by a TokenFilter.)
Extra careful. @PSeitz is introducing a new tokenizer-manager for fast fields. We want to modify both.
Related with #3296

I assigned myself since I do some changes there anyways

What about the default and en_stem? They have a limit of 40 currently

we can raise to 255 too.

Closed by #3404


Plumb an allocator interface through the C++ runtime API

The C API allows for an iree_allocator_t to be passed to all functions that may allocate (directly or indirectly). It'd be nice to carry that through the C++ API such that it can be used for all heap allocations. We can also pass the allocator down through the HAL to let Vulkan use it.
I don't think it's important to get the VM using an allocator - the codegen sequencer will be the choice for low memory consumption/code size.
As part of this it would be worth switching to fixed arrays (not absl::FixedArray, but an actual fixed array), intrusive lists, etc to avoid unneeded allocations of containers.

(the HAL drivers we care about in core are moving to C)


Fix callback type mismatch in Flop.Schema

Hello again :wave:
When deriving a schema without specifying a default_order map,
dialyzer complains that the implementation of default_order/1 does not
match the signature of the specified callback.
my_schema.ex:-1:callback_type_mismatch
Type mismatch for @callback default_order/1 in Flop.Schema behaviour.

Expected type:
%{
  :order_by => nil | [atom()],
  :order_directions =>
    nil
    | [
        :asc
        | :asc_nulls_first
        | :asc_nulls_last
        | :desc
        | :desc_nulls_first
        | :desc_nulls_last
      ]
}

Actual type:
nil

Coverage decreased (-0.3%) to 96.203% when pulling e639a31aa6c2cf0c1fb8f436e0219a15aa340963 on maltoe:fix/callback-type-mismatch into 5a316b71f12c44e7f4517f799f478e661796b53b on woylie:main.

Thank you!


feat: use vectoring to jump straight to interruptN

Previously, the vector table was set up in a pseudo-direct mode where all interrupts were redirected to a single _start_trap handler regardless of number.
This change introduces 31 new _start_trapN targets that encode which interruptN function to jump to, at a cost of 180 bytes per function (~5kb total).
Not shown (because the linker scripts live in the HAL) are the big block of PROVIDES:
PROVIDE(_start_trap1 = default_start_trap1)
PROVIDE(_start_trap2 = default_start_trap2)
...
PROVIDE(_start_trap31 = default_start_trap31)

As a side benefit, this does enable overriding on a per-irq basis and could even allow someone to switch back to the current psuedo-direct mode if they so chose (though, I think they wouldn't see anything get GC'd yet).
Potential improvements include:

Shrinking the saved register set to just being the callee-save parts of the C ABI, since only default_start_trap really has a use for the full frame
Finer-grained control around which interrupts are vectored, and which are semi-direct: maybe we can get away with just three modes at the start (all direct, only 1-16 vectored, all vectored), but I'm curious if we could find  a way to precisely express in a downstream crate "I want precisely 1, 2, 4..." to be vectored. Maybe a proc macro or other generator script?

Maybe a macro to generate all those default_start_trapX would be nice

Shrinking the saved register set to just being the callee-save parts of the C ABI, since only default_start_trap really has a use for the full frame

We need the full trap frame in e.g. esp-wifi for the task scheduler (in a timer triggered interrupt). But maybe having this a feature would be an option

Thanks for taking a look @bjoernQ and @onsdagens!

Maybe a macro to generate all those default_start_trapX would be nice

I tried a few things, but I wasn't super thrilled with any of them. Do you have an idea of what you'd want it to look like? Lacking the ability to evaluate e.g. n - 1 in a declarative macro it seemed like I'd have to list out all the interrupt numbers either way. It also looks like I'd have to pull in or crib from https://github.com/dtolnay/paste to glue the identifiers together, because std's concat_idents! isn't really up to the job.

We need the full trap frame in e.g. esp-wifi for the task scheduler (in a timer triggered interrupt). But maybe having this a feature would be an option

Oh, interesting: is it just the timer triggered interrupt that needs the whole frame? This change would allow overriding a specific entry point to pass whatever, but there's probably a lot we could do to make it easier.

What is your take on how the hardware -> CPU interrupt mapping should work?

I think we're of similar mind that priority -> irq num is a good broad default for a bunch of different cases, but offers the opportunity for a few improvements. Truth be told, I haven't gelled an idea yet of what I want to do, so hopefully you don't mind a bit of a brain dump.
<brain dump>
In addition to the points you raised about using the full suite of available hardware I've got some concerns about the shape of defined handlers. In our project, pretty much immediately @dougli1sqrd built us a way to register a closure so we could stop messing with statics quite so much, which was nice. Sadly, I had to pretty severely limit it as part of this work to only take function pointers and not full closures. The dynamically generated functions were getting emitted as part of .text, which was landing in flash and I couldn't see a way to have them end up in RAM instead.
There's also 4-5 pieces that need to line up just so for the handler to get called at all (interrupt::map, interrupt::set_priority, interrupt::enable_cpu_interrupt, having interuptN defined, and then whatever the source needs to generate the interrupt in the first place), and the lack of feedback when something goes wrong makes me wonder if there isn't a better way to express some of those constraints.
That's to say nothing of interupt::set_kind, which is actually a safety concern. Somewhere in my drafts I have a half-assed write up of an issue we ran into, but roughly: we were losing interrupts for the UART fifo because we'd read() them all down, and then in between receiving None and when we cleared the (edge) interrupt more bytes would be received so the edge never fired again. The upshot for this discussion is that whether something's an edge or level trigger means the handler (sometimes?) has to change to avoid racy behavior, but anyone can call interrupt::set_kind from anywhere at any time :hot_pepper:
It does seem common to have the magic mapping of e.g. fn GPIO() -> GPIO interrupts in the embedded space, though. I don't have enough experience to understand where that comes from and what's particularly attractive about it; is it an arduino thing?
</brain dump>
So yeah. My plan is to try and push the vectoring a little further "down" closer to the user-defined handlers, which I expect will be informative to me about what the challenges are, since I don't think I really understand them yet. "Fence was torn down; other side contained tiger. 0 stars."

i let the framework map the HW interrupts so no sharing of the CPU interrupts happens if possible (less than 31 enabled interrupts), and generate interrupt handlers automatically

Oooh, that sounds neat: can you share a link? In messing around with the debug assist (which was really an exercise in interrupt handling too), I wrote a little baby assembler in an effort to get runtime-remappable vector slots so I could avoid having to clobber the whole interrupt table to change one target. But, alas, writes to flash memory don't exactly work the way writes to RAM do :upside_down_face:, so there was at least a partial hard dependency on moving the vector to RAM. Or, the changes in this PR would let me do what I needed much more readily by just overriding e.g. _start_trap31.
Thanks for getting the discussion rolling: I'm looking forward to collaborating more on this!

Finer-grained control around which interrupts are vectored, and which are semi-direct: maybe we can get away with just >three modes at the start (all direct, only 1-16 vectored, all vectored), but I'm curious if we could find a way to precisely >express in a downstream crate "I want precisely 1, 2, 4..." to be vectored. Maybe a proc macro or other generator script?
maybe weakly linked default_start_trapx() pointing to the "direct" handler could be something? letting the user hook the vector table directly by overriding them? not sure if it's possible, just brain dumping. would be really interested in something like this though since right now i've just kicked the can down the road and feature gated each of the CPU interrupts so i can have the linker not complain about missing symbols and work on RTIC directly instead.

It does seem common to have the magic mapping of e.g. fn GPIO() -> GPIO interrupts in the embedded space, though. I >don't have enough experience to understand where that comes from and what's particularly attractive about it; is it an >arduino thing?
It sort of makes sense on a Cortex-M at least since HW interrupts are 1 to 1 with what actually happens on hardware level. In the case of ESP's though, you've got this arbitrary user defined mapping between HW interrupts and CPU interrupts, with the CPU interrupts being what is actually driving the interrupt flow on hardware level, meaning a GPIO interrupt doesn't always move you to the same vector table entry depending on implementation. So i think it would make sense to stray from convention and make everything more transparent in this case, at least as a feature.

Oooh, that sounds neat: can you share a link?
These generate handlers for software/hardware interrupts
https://github.com/onsdagens/rtic/blob/improved-rt/rtic-macros/src/codegen/async_dispatchers.rs
https://github.com/onsdagens/rtic/blob/improved-rt/rtic-macros/src/codegen/hardware_tasks.rs
by hooking bindings from here:
https://github.com/onsdagens/rtic/blob/improved-rt/rtic-macros/src/codegen/bindings/esp32c3.rs
the enabling and mapping of interrupts happens here:
https://github.com/onsdagens/rtic/blob/improved-rt/rtic-macros/src/codegen/bindings/esp32c3.rs#L74
it's all a bit ugly and hacky still, working PoC state. Also probably not applicable in your case depending on what you're trying to do since all of the vector table hooking happens at compile-time.

after some experimenting i've ended up with this https://github.com/onsdagens/esp32c3-rtic-rt/blob/main/src/lib.rs .
It doesn't cover corner cases yet (exception handling etc.), and it could look much neater, but the core idea with using weak linkage and letting the user override default behavior (the "direct" handler for example, or in this case just panic looping if a reasonable handler isn't provided) as they wish is there.

Oh, I like that: both paying far fewer bytes per function and keeping the whole layout thing out of linker scripts and in the esp-riscv-rt crate seem like wins to me.
I do think it trades off the hook-ability/code size a little bit though: e.g. esp-backtrace wants to override the DefaultExceptionHandler so that it can print a debug message which is pretty nice. I've been thinking about doing the same for DefaultHandler so that it can say "you forgot to override interrupt 27." I don't think that'd be possible with the Rust-only scheme, though. Right now how I think that works is that there's a PROVIDE(DefaultHandler = DefaultInterruptHandler) as well as a bunch of PROVIDE(interruptN = DefaultHandler), and a similar two-step lookup for the exception handling. That does two things:

If someone like esp-backtrace defines an ExceptionHandler or DefaultHandler directly, downstream consumers can still override interruptN without issue
All of the absent interruptNs don't actually exist, the ELF just has a bunch of pointers that get replaced with the single address of the DefaultHandler

I think the rust-level equivalent would be more like:
#[linkage = "weak"]
#[no_mangle] // or #[export_name = "..."]
extern "C" fn default_handler() {
    loop {}
}

#[linkage = "weak"]
#[no_mangle]
extern "C" fn handler1() {
    default_handler()
}

which would recover the ability to override the default once. It'd still cost us 4*31 bytes or so over the linker script version when no handlers are defined. That looks like a cost baked in to the relative in-expressiveness of the rust linker model (per the discussion around this pre-RFC, which someone might be able to pick back up with our non-GNU example). I wonder how weak linkage interacts with PROVIDEs; could we have a situation where the linker script bits become optional as a way to save a few bytes? That seems like it'd be cool.

I wonder how weak linkage interacts with PROVIDEs; could we have a situation where the linker script bits become optional as a way to save a few bytes? That seems like it'd be cool.

I don't think i follow :sweat_smile:

If we told the linker PROVIDE(handler1 = DefaultInterruptHandler) with a #[linkage = "weak"] definition for handler1, what would it do? If it prefers to use DefaultInterruptHandler in that case, then we'd save the 4 bytes for the jump instruction, and we'd be in a situation where not having (that part of) the linker script would still allow the program to build, it would just cost a few bytes at runtime.
At least to my aesthetic sense, well-scoped opt-in complexity like that which solves a concrete problem is very nice: it's a good way to learn about linker scripts and PROVIDEs, because anyone reaching for it knows exactly what they're looking for out of it.

It sort of makes sense on a Cortex-M at least since HW interrupts are 1 to 1 with what actually happens on hardware level. In the case of ESP's though, you've got this arbitrary user defined mapping between HW interrupts and CPU interrupts, with the CPU interrupts being what is actually driving the interrupt flow on hardware level, meaning a GPIO interrupt doesn't always move you to the same vector table entry depending on implementation. So i think it would make sense to stray from convention and make everything more transparent in this case, at least as a feature.

I've been musing on these truths that you provided, and I think you're exactly right: in our case, at least, the by-name GPIO binding isn't really helping us much, and I think if we made the cpu interrupt mapping explicit we could probably end up with a pretty good outcome. Especially if/when my extern "riscv-interrupt-m" PR gets merged, since then an application might reasonably be able to define its own interrupt handlers with no other support.

If we told the linker PROVIDE(handler1 = DefaultInterruptHandler) with a #[linkage = "weak"] definition for handler1, what would it do? If it prefers to use DefaultInterruptHandler in that case, then we'd save the 4 bytes for the jump instruction, and we'd be in a situation where not having (that part of) the linker script would still allow the program to build, it would just cost a few bytes at runtime.
At least to my aesthetic sense, well-scoped opt-in complexity like that which solves a concrete problem is very nice: it's a good way to learn about linker scripts and PROVIDEs, because anyone reaching for it knows exactly what they're looking for out of it.

Now i gotcha, i agree.

I've been musing on these truths that you provided, and I think you're exactly right: in our case, at least, the by-name GPIO binding isn't really helping us much, and I think if we made the cpu interrupt mapping explicit we could probably end up with a pretty good outcome. Especially if/when my extern "riscv-interrupt-m" PR gets merged, since then an application might reasonably be able to define its own interrupt handlers with no other support.

Not sure which PR you're referring to. I think this PR warrants something be done about the interrupt enable on HAL level as well, to make the mapping explicit as you said. Right now it's sort of arbitrary which makes sense if you're not hooking the vector table anyway.
How are you looking on time? I'd love to see this upstreamed somewhere in the near future, since my RTIC port is pretty much merge ready, only thing missing is all-vanilla crates.

The PR that'd open up some possibilities here is https://github.com/rust-lang/rust/pull/111891 : then we might be able to delete everything related to interrupts from this crate except the vector itself (+/- some linker shenanigans). But, that'll probably take weeks if the rust-lang docs are to be believed.
So I'm thinking for the purposes of this PR the goal ought to be enabling the downstream work you & I are trying to do: to me, the shortest path to that sounds like getting the _vector_table set up with 32 individually override-able slots by way of some combination of assembly, weak linkage, and/or linker script shenanigans.
Then, once your generated handlers can successfully be slotted in to the table and I can skip over the whole handle_interrupts machinery for my real-time-bounded handler, we can start experimenting in the HAL with different options for expressing more natural mappings and making it easier to write non-default interrupt handlers. How does that sound to you?

That's to say nothing of interupt::set_kind, which is actually a safety concern. Somewhere in my drafts I have a half-assed write up of an issue we ran into, but roughly: we were losing interrupts for the UART fifo because we'd read() them all down, and then in between receiving None and when we cleared the (edge) interrupt more bytes would be received so the edge never fired again. The upshot for this discussion is that whether something's an edge or level trigger means the handler (sometimes?) has to change to avoid racy behavior, but anyone can call interrupt::set_kind from anywhere at any time hot_pepper

Is there a reason why you were using edge interrupts with UART? AFAIK, edge mode is only required for peripherals that don't support level based interrupts (i.e they hold there signal until cleared).

It does seem common to have the magic mapping of e.g. fn GPIO() -> GPIO interrupts in the embedded space, though. I don't have enough experience to understand where that comes from and what's particularly attractive about it; is it an arduino thing?

I suppose this most likely stems from the fact that ARM chips have an interrupt handler per peripheral (up to 256 or something like that), all of which are dispatched by the CPU directly. The ARM part is relevant as most of the rust-embedded early days were shaped around ARM (RISCV support was early stages + not much silicon around). In general though, when you're not trying to shave microsecond interrupt latencies down, it is very convenient to have peripheral based interrupt handlers. Before I added it in https://github.com/esp-rs/esp-hal/pull/118, the interrupt examples we not so nice to read; they used the CPU handlers directly and then did register reads to figure out which peripheral bits needed clearing. It also makes writing async drivers much cleaner and simpler.

I'd also like to add a feature flag providing simple trap entry hooks so you don't have to provide a context store/restore for each of the overridden handlers, but that's probably irrelevant to what you've done here, so i'll do it in another PR i think.

Is there a reason why you were using edge interrupts with UART? AFAIK, edge mode is only required for peripherals that don't support level based interrupts (i.e they hold there signal until cleared).

Not an on-purpose reason, we got it from the example: https://github.com/esp-rs/esp-hal/blob/171e66e87ad994cc9f8004a42d7ea6461214c20e/esp32c3-hal/examples/serial_interrupts.rs#L73 . That example actually has the same safety issue: if more than 30 bytes come in over the UART between the .read() and the .reset_rx_fifo_full_interrupt() (which in this case only seems possible because  of the writeln!s, for us it was a combination of a low threshold + a 400k baud input) then the edge interrupt gets cleared while the rx_fifo_full signal is high, so it never rises again.

Firstly, this is awesome! I would love to see this land. I wasn't aware of the functionality in LLVM. This could be a huge perf win without costing much if at all on ergonomics/maintainability.

Thanks! I was thrilled with how that turned out; I had stumbled across the interrupt clang attribute at some point, and it seems like pretty much a slam dunk for a lot of cases. I think it'll even allow some ergonomics wins for any handler that doesn't need the full trap frame (there's no provision for recovering that from LLVM that I can see).
And I appreciate the additional context around peripheral-based interrupt handlers: that PR and the async drivers sound like something I can learn a lot from checking out.

I'd also like to add a feature flag providing simple trap entry hooks so you don't have to provide a context store/restore for each of the overridden handlers, but that's probably irrelevant to what you've done here, so i'll do it in another PR i think.

Oh, sorry yeah I meant to look into that: I think it does make sense to do it separately, since you've got more context on it at this point. I'm definitely happy to review, though!
A feature flag sounds good, though if you wanted to avoid that I think you could try putting it in a .trap.* sub-section. After https://github.com/esp-rs/esp-hal/pull/541 landed it should get GC'd if there are no references to it.


Don't add Model getters or setters to the stack unless they are functions.

Fixing https://github.com/LearnBoost/mongoose/issues/704 - don't add Model getters or setters to the stack unless they are functions.

It should throw an Error when it's not a function in my opinion. Failing silently isn't nice.


Fixes how the default scripts location is determined.

We shouldn't be assuming that it's in My Documents.
According to #2447 there may still be an actual crash involved here, and I don't think this will necessarily resolve it.

👍


fix: make scrollbars draggable when offsets are set

Cf https://github.com/excalidraw/excalidraw/issues/2915#issuecomment-772807009
Today when setting offsetLeft or offsetRight when using the package library, scrollbars will display, but can't be dragged. This is an attempt to fix it.

In unrelated issue.. I think we should include pull requests here as well:

https://github.com/excalidraw/excalidraw/blob/master/.github/workflows/lint.yml#L3
https://github.com/excalidraw/excalidraw/blob/master/.github/workflows/test.yml#L3

Maybe that's why actions from external branches are not running (sometimes).

Thanks for the fix!


State is not reset after form completion

After submitting the form, you cannot submit again as the field does not reset
https://github.com/AbanoubNassem/filament-grecaptcha-field/assets/43909932/63b0358c-b866-4948-a441-6e9f8470eb47
GRecaptcha::make('captcha')
    ->label('')
    ->validationMessages([
        'required' => 'You must complete the captcha.',
    ]),

check the console does it output any error messages ?

Yes, I am having this same issue, where the it does not reset. And there is no error in the console too.

any update?

Same problem here. When there is an error in a field, the recaptcha does not reset. Is seems the resetCaptcha event in g-recaptcha.blade.php doesnt get fired when Livewire is reloaded.

Dispatch an event from the livewire component
$this->dispatch('reset-recaptcha');

And in blade
x-on:reset-recaptcha="window.grecaptcha.reset()"

Hope that helps...

I have no clue what filament introduced to break the reset event, am looking into it


Duplicate Files and folders are showing on connecting external storage

Describe the bug
Showing duplicate file instances when using FILES to view my phone files by connecting usb  See the video in Screenshot Section
To Reproduce
Steps to reproduce the behavior:

Connect a phone with usb and turn on file sharing option
Go inside the phone storage , [your phone name] > internal shared storage > android
now go back  to internal shared storage
See error

Expected behavior
There should be one main file showing, not duplicates
Screenshots
A video showing the bug
https://user-images.githubusercontent.com/58888934/104607087-7278a080-56a6-11eb-9afa-28ae84b55250.mp4
Desktop:

OS Version: [Windows 10  20H2 19042.746]
App version: [v1.0.0]

Additional context
This problem occur even after restarting the app and reconnecting the usb
Log file
debug.txt
debug_fulltrust.txt

Thanks for the report. The issue has been fixed.
For now the workaround is to turn off the "Enable file cache" setting

Thanks for the report. The issue has been fixed.
For now the workaround is to turn off the "Enable file cache" setting

I’m JUST learning Git from GitHub and I’m liking it EXCEPT a bunch of people will come in and fix up and finish My program before I even have a chance to finish reading everything. I love the concept but I NEED TO LEARN HANDS ON OR ELSE THE LESSON WONT STICK IN MY MIND. I know I’m slow in completing them but one I do have a life that requires My  benevolent soul to dominate her. 12.20/21.01

I’m JUST learning Git from GitHub and I’m liking it EXCEPT a bunch of people will come in and fix up and finish My program before I even have a chance to finish reading everything. I love the concept but I NEED TO LEARN HANDS ON OR ELSE THE LESSON WONT STICK IN MY MIND. I know I’m slow in completing them but one I do have a life that requires My  benevolent soul to dominate her. 12.20/21.01

@DevMark-code Your thought is learning center which actually great, this is a public repository and have many helpful people like you,
If you want to learn handson try
good first issue
Or
Learn from successful closed pull request.

@DevMark-code Your thought is learning center which actually great, this is a public repository and have many helpful people like you,
If you want to learn handson try
good first issue
Or
Learn from successful closed pull request.


DiagnosticCollection.set([Uri, [Diagnostic[]][]) is not reliable

The documentation for DiagnosticCollection.set([Uri, Diagnostic[]][]) states the following:

Diagnostics of multiple tuples of the same uri will be merged, e.g [[file1, [d1]], [file1, [d2]]] is equivalent to [[file1, [d1, d2]]]. If a diagnostics item is undefined as in [file1, undefined] all previous but not subsequent diagnostics are removed.

However, this doesn't work in practice because the entries end up being sorted by uri, but the sort is not stable. Here's the code that does the sort. This can result in entries being reordered so that this...
[file1, undefined]
[file1, [diagnostic1, diagnostic2]]

...becomes this...
[file1, [diagnostic1, diagnostic2]]
[file1, undefined]

That results in diagnostics being cleared when they aren't supposed to be.

In the C# extension, I tried sorting entries using the same code as VS Code and could clearly see the impact of not having a stable sort.
Here are the entries before sorting:

Here they are after sorting:

Note that several elements are reversed. These elements have the same uri.

Awesome find and analysis. @DustinCampbell should have commit rights

So, that's what you get when you rely on un-specified behaviour... It seems that v8 is especially mean because it uses stable-sorting for small arrays and unstable-sorting for larger arrays.
From here

Small arrays are sorted using a simpler algorithm which happens to be stable.
You need a larger array to trigger the quicksort algorithm which is non-stable.

Nice fix!

Verified by code review and running the test with the fix reverted.


cleanup release artifacts

remove not needed istioctl and istioctl-stage directories
save the gcr and docker specific images under docker/*/ directory
fixes #2904

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

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
a28d2483356de5082270616859cd86f2a766a097
link
/test istio-unit-tests

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

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

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
a28d2483356de5082270616859cd86f2a766a097
link
/test istio-unit-tests

prow/istio-presubmit.sh
a28d2483356de5082270616859cd86f2a766a097
link
/test istio-presubmit

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

I'm not sure what the motivation of the change besides further hiding artifacts deeper in the directory tree (and not storing istioctl).  I think some of the tests try to pick up the istioctl on GCS, either directly or by looking at the ISTIOCTL_URL parameter in istio.VERSION.  So, some more changes might be needed for that to cleanup the reference in istio.VERSION and possibly with the tests that try to consume it.
The other part of the change is putting subdirectories under docker/ . I was originally thinking that only tars would be stored in here, and out of an additional sense of paranoia I had the scripts also specify tar as part of the wildcard search.  We don't necessary need to hold to this philosophy, but if in release/cloud_builder.sh someone specifies -c to disable docker generation then this mean docker/ won't get copied (around line 110), which means that the artifacts won't also get copied/reserved.  So, after this change opting out of docker also means the archives won't get preserved, and that doesn't seem very clean to me.  Options that come to mind is to use a separate archive/ directory, or just remove the support for the -c and -b parameters (I mostly added them for flexibility and for dev purposes to speed speed up the build or only test a specific part of the build that was changed).

i changed the code not to depend on istioctl url, and am planning on not removing it from istio.VERSION also. PTAL

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

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
c6beb04bc61245215accb854cf27c8c2a938b335
link
/test e2e-bookInfo

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

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

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
c6beb04bc61245215accb854cf27c8c2a938b335
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
c6beb04bc61245215accb854cf27c8c2a938b335
link
/test istio-pilot-e2e

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

Offhand I can't find any uses of the istioctl_url that concern me (across istio, test-infra, release, and fortio repos).  I'd prefer to see all uses of the url go away, but it seems like it's still used as part of a dev doing a "make push" and trying to test against that (e.g., tests/e2e_istio_preinstalled.sh).  I suppose an option is to change the workflow to be based around istio tars that contain istioctl, rather than just istioctl itself, but that's probably more like a feature (likely one not everyone would like) than a bugfix.
Anyway, the main question/concern I have is what to do about ISTIOCTL_URL in daily/monthly release builds.  The istio-archive target is still passing -i to updateVersions.sh and will effectively specify a URL that points to a non-existent file.  Are we going to turn a blind eye to this, or should functionality be added to updateVersions.sh so that an option/parameter (e.g., a new -I, or passing a blank string to -i) causes ISTIOCTL_URL to not be output in the resulting istio.VERSION file?

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

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
c6beb04bc61245215accb854cf27c8c2a938b335
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
c6beb04bc61245215accb854cf27c8c2a938b335
link
/test istio-pilot-e2e

prow/istio-presubmit.sh
0a27a9d6382676dfb9bb3bf62cbd8093541aa02a
link
/test istio-presubmit

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

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

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
c6beb04bc61245215accb854cf27c8c2a938b335
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
c6beb04bc61245215accb854cf27c8c2a938b335
link
/test istio-pilot-e2e

prow/istio-presubmit.sh
0a27a9d6382676dfb9bb3bf62cbd8093541aa02a
link
/test istio-presubmit

prow/istio-unit-tests.sh
0a27a9d6382676dfb9bb3bf62cbd8093541aa02a
link
/test istio-unit-tests

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

@mattdelco renoved istioctl_url, we need to whittle fix istio.VERSION and its uses... for now this is a small cleanup

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

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
c6beb04bc61245215accb854cf27c8c2a938b335
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
c6beb04bc61245215accb854cf27c8c2a938b335
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-simple

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

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

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
c6beb04bc61245215accb854cf27c8c2a938b335
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-bookInfo

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

/retest

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

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
c6beb04bc61245215accb854cf27c8c2a938b335
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-bookInfo

prow/istio-unit-tests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test istio-unit-tests

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

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

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-bookInfo

prow/istio-unit-tests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test istio-unit-tests

prow/istio-pilot-e2e.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test istio-pilot-e2e

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

/test istio-unit-tests
/test istio-pilot-e2e

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

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-simple

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

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

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-bookInfo

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

/test istio-pilot-e2e
/test e2e-simple
/test e2e-bookInfo

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

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test istio-pilot-e2e

prow/e2e-bookInfoTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-bookInfo

prow/e2e-simpleTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-simple

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

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

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-bookInfo

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

fixes #4022

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

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test istio-pilot-e2e

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

One problem with squirreling PROXY_TAG away in Gopkg.toml is with the "vendor.check" target in the Makefile (which is run as part of "make init" so it's a commonly executed target/rule).  The Gopkg.lock/Gopkg.toml files are diff'ed against the ones under vendor/ to help confirm that vendor/ matches the expectations of the istio repo.  My concern is that the update bot will update the sha in istio repo's Gopkg.toml and thus make this check fail.  The choices would seem to be to make the diff smarter (unlikely option), or also update the vendor repo (which also means updating istio repo to also point at the newer commit of the vendor repo, which also doesn't seem a likely option), or store the PROXY_TAG somewhere else (e.g., in the Makefile itself).

I changed the Makefile not to diff gopkg.toml between vendor and istio I think Gopkg.lock is good enough
Metadata in Gopkg.toml is supposed to carry information for other build tools by design.

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

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test istio-pilot-e2e

prow/istio-unit-tests.sh
fb7ae3f6a863d6f0426d9a208515910d2bb00c97
link
/test istio-unit-tests

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

/test istio-unit-tests

I changed the Makefile not to diff gopkg.toml between vendor and istio I think Gopkg.lock is good enough

I don't think that's correct. I'm having issues avoid people messing up vendor (because of the submodule subtleties) and that's why I put those checks
specifically - the reason for that is ensure "dep status" stays error free
can you check if "[meta]" is ignored for the input sha ? ie can that section be changed and it doesn't change the output sha in the lock ? (try "make depend.status" and see you don't get errors)

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

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
fb7ae3f6a863d6f0426d9a208515910d2bb00c97
link
/test e2e-simple

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

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

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
69a865b413143cbc8662cca94322398844ae98f7
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
fb7ae3f6a863d6f0426d9a208515910d2bb00c97
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
fb7ae3f6a863d6f0426d9a208515910d2bb00c97
link
/test e2e-bookInfo

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

/hold

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

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
fb7ae3f6a863d6f0426d9a208515910d2bb00c97
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
fb7ae3f6a863d6f0426d9a208515910d2bb00c97
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
fb7ae3f6a863d6f0426d9a208515910d2bb00c97
link
/test istio-pilot-e2e

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

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

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
fb7ae3f6a863d6f0426d9a208515910d2bb00c97
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
fb7ae3f6a863d6f0426d9a208515910d2bb00c97
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
8b7ed39e1d4037417e53d70426384a3c64bbf85b
link
/test e2e-simple

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

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

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
fb7ae3f6a863d6f0426d9a208515910d2bb00c97
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
8b7ed39e1d4037417e53d70426384a3c64bbf85b
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
8b7ed39e1d4037417e53d70426384a3c64bbf85b
link
/test e2e-bookInfo

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

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

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
8b7ed39e1d4037417e53d70426384a3c64bbf85b
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
8b7ed39e1d4037417e53d70426384a3c64bbf85b
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
8b7ed39e1d4037417e53d70426384a3c64bbf85b
link
/test istio-pilot-e2e

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


Add a lint tox env to remove unuseds.

Sorry about that - little thrash there. All good to go for review now.


feat(decode): adding support for base64 urls

@theonetheycallneo — merged to master, this is now in<EMAIL_ADDRESS>:wave: thanks for your contribution!


Old 0.1 version on the latest docs

RTD built latest doc on b55abdc31e5a905389da26352a9beab2a6c87bfa commit using 0.1.dev128 version.
Expected result
There should be v7.1.1.devN
Actual result
Screenshot:

Additional context
Logs on RTD:
$ python -m sphinx -T -E -W --keep-going -b dirhtml ...
Running Sphinx v6.2.1
pip-tools version: 0.1.dev128
pip-tools release: 0.1.dev128
...

I think this happens because they make a shallow clone. I like to unshallow it to make the machinery discover the proper version.

Running the tox build-docs env succeeds detecting the right version:
pip-tools version: 7.1.1
pip-tools release: 7.1.1.dev5

There is run git fetch --unshallow.
We might be able to unshallow the clone in the RTD configuration like this:
build:
  os: ubuntu-22.04
  jobs:
    post_checkout:
      - git fetch --unshallow  || true

@chrysle thanks for the snippet. Addressed in #1941.


Replace requires_system_checks False values with []

Support for boolean values for requires_system_checks was removed in Django 4.1 (and deprecated since 3.2 so safe to replace).
The replacement for False is []: https://github.com/django/django/commit/c60524c658f197f645b638f9bcc553103bfe2630

Ah just saw #1736 & #1754