Omxplayer alsa : no sound with mutiple bluetooth speakers and video is too fast

Hey !
I tried playing a mkv video with omxplayer and a 5.1 virtual system (composed of 5 different bluetooth speakers and 1 suboofer).
I configure my audio system with .asoundrc and it works fine with aplay mysound.wav.
But when I run :
omxplayer myvideo.wav : video runs well and sound is local (-o local).
omxplayer -o alsa myvideo.wav : video runs fast and no sound. When I decrease speed manually to speed null, and then increase : video runs at "normal" speed and the sound appears but in stereo.
I also run omplayer -o alsa myvideo.wav with one speaker by default in .asoundrc and it worked very fine.
Does someone can help me please ?

Here is my .asoundrc (quite long, I know) :
pcm.!default {
    type plug;
    slave.pcm "surround";
}

pcm.surround {
    type route;
    slave.pcm {
        type multi;
        slaves {
	    a { channels 1 pcm "left" }
            b { channels 1 pcm "right" }
            c { channels 1 pcm "center" }
            d { channels 1 pcm "subwoofer" }
            e { channels 1 pcm "leftSur" }
            f { channels 1 pcm "rightSur" }
        }

        bindings {
         0 { slave a channel 0 }
         1 { slave b channel 0 }
         2 { slave c channel 0 }
         3 { slave d channel 0 }
         4 { slave e channel 0 }
         5 { slave f channel 0 }
        }

    }

    ttable [
        [ 1 0 0 0 0 0 ]
        [ 0 1 0 0 0 0 ]
        [ 0 0 1 0 0 0 ]
        [ 0 0 0 1 0 0 ]
        [ 0 0 0 0 1 0 ]
        [ 0 0 0 0 0 1 ]
    ]

}

pcm.stereo {
    type route;
    slave.pcm {
        type multi;
        slaves {
            a { channels 1 pcm "left" }
            b { channels 1 pcm "right" }
        }

        bindings {
         0 { slave a channel 0 }
         1 { slave b channel 0 }
        }
    }

    ttable [
        [ 1 0 ]
        [ 0 1 ]
    ]
}

pcm.one {
    type route;
    slave.pcm "left";
    slave.channels 2;
    ttable.0.0 1;
    ttable.1.1 1;
}

pcm.left {
    type plug;
    slave.pcm {
        type bluealsa;
        interface "hci0";
        device "00:E0:4C:3E:7E:C0";
        profile "a2dp";
    }
}

pcm.center {
    type plug;
    slave.pcm {
        type bluealsa;
        interface "hci0";
        device "00:E0:4C:0E:69:A5"
        profile "a2dp";
    }
}

pcm.right {
    type plug;
    slave.pcm {
        type bluealsa;
        interface "hci0";
        device "00:E0:4C:D7:57:80";
        profile "a2dp";
    }
}

pcm.rightSur {
    type plug;
    slave.pcm {
        type bluealsa;
        interface "hci1";
        device "00:E0:4C:7C:1A:62";
        profile "a2dp";
    }
}

pcm.leftSur {
    type plug;
    slave.pcm {
        type bluealsa;
        interface "hci1";
        device "00:E0:4C:8B:19:72";
        profile "a2dp";
    }
}

pcm.subwoofer {
    type plug;
    slave.pcm {
        type bluealsa;
        interface "hci1";
        device "40:EF:4C:C7:DF:95";
        profile "a2dp";
    }
}

ctl.left {
    type bluealsa;
    interface "hci0";
}

ctl.center {
    type bluealsa;
    interface "hci0";
}

ctl.right {
    type bluealsa;
    interface "hci0";
}

ctl.rigthSur {
    type bluealsa;
    interface "hci1";
}

ctl.leftSur {
    type bluealsa;
    interface "hci1";
}

ctl.subwoofer {
    type bluealsa;
    interface "hci1";
}

Hi.   Is there an update, resolution or confirmation of this issue?  I'm facing the same problem.  Video and sound work fine when playing over HDMI audio. However, when trying to play via bluetooth using the -o alsa option the video plays too fast with no sound. Slowing the video down (hitting 1) corrects the fast play and the sound starts.  Even more confusing is that perhaps 1 out of every 5 times everything works fine from startup.  Using the alsa option to play via i2s works fine.  This is on Raspberry Pi Stretch.

Not sure if this is the correct place for this issue on second thought?  Is it more a omxplayer problem?

Hi!
I finally used gstreamer playbin and it worked very fine.

Same issue here on a pi zero w, thanks for reporting.
I tried gst123 -a alsa myvideo.mp4 but no luck

After 30 months it is clear there are no omxplayer experts following this list. This looks like a raspberrypi specific issue to me, as the upstream omxplayer sources do not support the option -o alsa. There have been very many improvements to bluealsa since this issue is raised, so I am closing this issue.
If it turns out the omxplayer still has bluealsa-specific issues with the latest bluealsa code please feel free to re-open.

Still having this exact same issue. Looks like omxplayer is deprecated, but vlc is not a replacement. Has anyone found the fix?

Has anyone found the fix?

The "fix", if one is possible, would have to be in omxplayer. And as you say, omxplayer is now deprecated by its own maintainer, so any update to it is now most unlikely.
It says on the omxpayer site:
Please try using vlc. If t[here](https://github.com/RPi-Distro/vlc/issues) are features of omxplayer that vlc does not handle then try reporting here.

So perhaps reporting your issues there is a way forward.

Yep, I've reported my issue there. VLC doesn't seem to work at all with bluealsa, so yeah ...

VLC doesn't seem to work at all with bluealsa

Please open a new issue here describing the problem you are having with VLC and bluealsa. Perhaps that one can be fixed

I found a workaround that somewhat works. Using python I open a subprocess with the video and then immediately send a keystroke to it. I haven't been able to send multiple keystrokes to it, so I suppose the video doesn't run at 100% speed (but 97.5%?). However, the sound works over bluetooth every time now.
from subprocess import Popen, PIPE

p = Popen(["omxplayer -o alsa:bluealsa video.mp4"], stdin=PIPE, shell=True)
p.communicate(input=b'1')

I also tried using omxplayer as a python module, but it seems like you cannot send audio parameters to it, so that's not an option.


Multiple consecutive pings in x time before you reboot due to drop outs or latency (due to bad weather etc)

At given times of the day and especially in bad weather you can experience "drop outs" that can last for 20-30 seconds.  Right now this will trigger a reboot that adds another 2 minutes into the process.  If the monitor was to do 4 pings 10 seconds apart before triggering a reboot this would allow for those moments of drop out or latency.
This seemed to be different enough from the "enhance ping" issue where it talks about multiple hosts vs multiple pings across a timeframe interval.

I was modelling it from how my asus router did it.

Really? It surprises me you haven't tested running your script on the router using optware to supply python. Since my pi is my dns server it works out about the same for me.
On Oct 13 2021, at 5:27 pm, highvolt-dev @.***> wrote:

Thanks, @famewolf (https://github.com/famewolf) - I have a dual WAN asus router as well, that helps.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (https://github.com/highvolt-dev/tmo-monitor/issues/19#issuecomment-942734439), or unsubscribe (https://github.com/notifications/unsubscribe-auth/ABCY74GED2SNOPR3GFQ6EALUGX2UVANCNFSM5F53TEYQ).
Triage notifications on the go with GitHub Mobile for iOS (https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or Android (https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub).


Investigate password reset form behaviour

Has been reported not to correctly leave the page after a password reset and displays unusual display issues in production - as if css is missing.

Previous commit confirmed to solve the rendering issue. Will still investigate forwarding behaviour and re-evaluate error messages displayed.


Added Solution to rat in a maze problem

Hello!
I've added the solution. Please review and merge.
Thanks.
Best,
Sai.

Closes #3


Immudb version update to 1.3.0

Update:

Image updated from 1.0.5 to 1.3.0
immudb-config-generator updated with changed in SQL syntax
Update in immudb-config-generator yaml file

@gopal-mahajan , is the attribute name 'size' in rsaudit table  or  'responsize'

@gopal-mahajan , is the attribute name 'size' in rsaudit table or 'responsize' ?

column name should be size as discussed with @swaminathanvasanth

The implementation was changed before I could discuss with @gopal-mahajan
Now all the API servers will use "size" as the column name for response size.
Lets keep the table column name as "size" itself. @karun-singh @abhi4578

Is the column with varchar data types in various table have sufficient characters allocated? especially table used by auth with attribute body[2048]? Can in some cases the characters be reduced or should be increased ? @gopal-mahajan
client.sqlExec("CREATE TABLE auditingtable(id VARCHAR[128] NOT NULL, userRole VARCHAR[64] NOT NULL,userID VARCHAR[128] NOT NULL,iid VARCHAR[250] NOT NULL,api VARCHAR[128] NOT NULL,method VARCHAR[32] NOT NULL,time INTEGER NOT NULL,iudxID VARCHAR[256] NOT NULL,PRIMARY KEY id);")
client.sqlExec("CREATE INDEX ON auditingtable(userID, iudxID, time, api);")
client.useDatabase("iudxauth")
client.sqlExec("CREATE TABLE table_auditing(id VARCHAR[128] NOT NULL, body VARCHAR[2048] NOT NULL,userid VARCHAR[128] NOT NULL,endpoint VARCHAR[128] NOT NULL,method VARCHAR[32] NOT NULL,time INTEGER NOT NULL,PRIMARY KEY id);")

client.sqlExec("CREATE INDEX ON table_auditing(userid, endpoint, time);")
client.useDatabase("iudxrsorg")

client.sqlExec("CREATE TABLE rsaudit (id VARCHAR[128] NOT NULL,api VARCHAR[128] NOT NULL,userid VARCHAR[128] NOT NULL,epochtime INTEGER NOT NULL,resourceid VARCHAR[256] NOT NULL,isotime VARCHAR[64] NOT NULL,providerid VARCHAR[128] NOT NULL,size INTEGER, PRIMARY KEY id);")
client.sqlExec("CREATE INDEX ON rsaudit(userid, epochtime, providerid, resourceid);")

Is the column with varchar data types in various table have sufficient characters allocated? especially table used by auth with column body[2048]? Can in some cases the characters be reduced or should be increased ? @gopal-mahajan . The 1.3.0 version forces to make varchar len bounded, and therefore need to carefully allocate the sizes for the columns. It should be sufficient enough so that insert with big column values would not cause error) or that total index length is less than 1k bytes, index length=sum of lengths of each index field allocated bytes.
client.sqlExec("CREATE TABLE auditingtable(id VARCHAR[128] NOT NULL, userRole VARCHAR[64] NOT NULL,userID VARCHAR[128] NOT NULL,iid VARCHAR[250] NOT NULL,api VARCHAR[128] NOT NULL,method VARCHAR[32] NOT NULL,time INTEGER NOT NULL,iudxID VARCHAR[256] NOT NULL,PRIMARY KEY id);")
client.sqlExec("CREATE INDEX ON auditingtable(userID, iudxID, time, api);")
client.useDatabase("iudxauth")
client.sqlExec("CREATE TABLE table_auditing(id VARCHAR[128] NOT NULL, body VARCHAR[2048] NOT NULL,userid VARCHAR[128] NOT NULL,endpoint VARCHAR[128] NOT NULL,method VARCHAR[32] NOT NULL,time INTEGER NOT NULL,PRIMARY KEY id);")

client.sqlExec("CREATE INDEX ON table_auditing(userid, endpoint, time);")
client.useDatabase("iudxrsorg")

client.sqlExec("CREATE TABLE rsaudit (id VARCHAR[128] NOT NULL,api VARCHAR[128] NOT NULL,userid VARCHAR[128] NOT NULL,epochtime INTEGER NOT NULL,resourceid VARCHAR[256] NOT NULL,isotime VARCHAR[64] NOT NULL,providerid VARCHAR[128] NOT NULL,size INTEGER, PRIMARY KEY id);")
client.sqlExec("CREATE INDEX ON rsaudit(userid, epochtime, providerid, resourceid);")

unbound varchar possible in immudb if not indexed

body in table_auditing is now unbounded.
Also tested with by puttiung 4k chars in the insert, it works


[BUG]

Environment
Self-Hosted (Docker)
System
Ubuntu 20.04 LTS
Version
2.1.1
Describe the problem
I had dashy working fine with docker-compose and then I decided to add keycloak authentication.
I served up keycloak. Created a realm and a user and a client.
I added the following keycloak info to my dashy-config.yml
  auth:
    enableGuestAccess: false
    users: []
    enableKeycloak: true
    keycloak:
      serverUrl: 'http://localhost:8085'
      realm: 'dashy-realm'
      clientId: 'dashy'

I re-created the container via portainer
If you access the dashboard URL, after it attempts to init this error is shown and followed by "Loading" and this loop continues forever.
It looks like something's gone wrong...

This is likely caused by the app source not being found at the current domain

If you need additional support, check the browser console then raise a ticket

Additional info
The log output as seen via portainer:
$ vue-cli-service build --watch --mode production

$ node server

Checking config file against schema...

✔ Config file is valid, no issues found

SSL Not Enabled: Public key not present

 ██████╗  █████╗ ███████╗██╗  ██╗██╗   ██╗

 ██╔══██╗██╔══██╗██╔════╝██║  ██║╚██╗ ██╔╝

 ██║  ██║███████║███████╗███████║ ╚████╔╝

 ██║  ██║██╔══██║╚════██║██╔══██║  ╚██╔╝

 ██████╔╝██║  ██║███████║██║  ██║   ██║

 ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═╝  ╚═╝   ╚═╝

*******************************************************************************************

Welcome to Dashy! 🚀

Your new dashboard is now up and running with Docker

*******************************************************************************************

Using Dashy V-2.1.1. Update Check Complete

✅ Dashy is Up-to-Date

-  Building for production...

 WARN  A new version of sass-loader is available. Please upgrade for best experience.

 DONE  Build complete. Watching for changes...

Please tick the boxes

[X] You have explained the issue clearly, and included all relevant info
[X] You are using a supported version of Dashy
[X] You've checked that this issue hasn't already been raised
[X] You've checked the docs and troubleshooting guide
[X] You agree to the code of conduct

This issue is covered in the docs, Troubleshooting → Keycloak Redirect Err


request description of data and clock pins specifying both GP# and pad#

Current main.c,  calibration.c and test.c have
// SET THESE TO THE GPIO PINS CONNECTED TO THE
// HX711's CLOCK AND DATA PINS
const uint clkPin = 14;
const uint datPin = 15;
request
const uint clkPin = 14;  /* GP14  pad 19 /
const uint datPin = 15;  / GP15 pad 20 */
This might help someone else to avoid making the same mistake I did: connecting to pads 14 and 15.

Thanks.
I've updated the documentation to those files and the readme.

Thanks.
OF COURSE the methods which select the pins use the GP not the pads#...
but have programmed for 40 years with the precept:
If I messed it up, someone else might too.
Thank you for responding positively.
On Thu, May 19, 2022 at 12:53 AM Daniel Robertson @.***>
wrote:

Thanks.
I've updated the documentation to those files and the readme.
—
Reply to this email directly, view it on GitHub
https://github.com/endail/hx711-pico-c/issues/19#issuecomment-1131199826,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABIOVQDDQTYEYQLVFLENO6TVKXCK5ANCNFSM5WKH4RUQ
.
You are receiving this because you authored the thread.Message ID:
@.***>


pip download URL down

The package was hosted on http://lobstertech.com, which now is down since a while. There are things like epub who depend on it in their requirements.txt. Could you please host it on Github? If you need help in maintaining the package etc.. please let me know.

Hi  @jart any chance of updating the version pypi ?

There's one problem with that. I don't have access to the PyPi account anymore. It's tied to the LobsterTech domain so I can't reset the password. My attempt to reach out to the PyPi people failed last time I tried. I can give it another go if you guys like?

That would be awesome, I've found them helpful in the past - though probably like everything in open source, they are probably understaffed.

Sigh they have absolutely no contact information. I'm going to try tweeting at people until someone helps me.

Will try some myself, hopefully different ones.

Worst comes to the worst could make fabulous2 and upload to pypi - but it would be un-ideal.

It would be unfortunate if we had to fork the PyPi repo. So it'd be really good if we could find a way to get in touch with the guys running that service.
If you're truly motivated to breathe new life into this project, I'd be willing to consider granting you the necessary permissions to be its new maintainer. Is this something you would seriously consider? Because if you're serious, I'll be happy to put the time and effort into reviewing your work history to make sure the project will be going into capable hands, which I'm sure you have.

I found this library while looking at ANSI libraries for a work project, and the image display parts look really nice.
Given my previous record, I tend to be a bit of a fly-by developer - in that I'll come in and sort things, out then come back again in about a year, so not necessarily great as a maintainer.
I am interested in colour terminal stuff since the days DOS, so won't rule it out - I'd just like to use the project a bit first before volunteering for this.
You're right - forking the project on pypi would be unfortunate, I'll see keep seeing if I can find anyone who has something to do with pypi.

Hi, is there a support ticket on pypi (via the support link on the pypi site) related to the lost login?

I had no idea a support page existed. Ticket filed! https://sourceforge.net/p/pypi/support-requests/627/

Cool the password is reset! I can now update this. I'll probably do it in the next few days.

Thanks @r1chardj0n3s, I guess randomly pinging people on twitter eventually works - I guess, I should go open a ticket to add a more prominent link to the support page now :)

Thank you for your patience everyone. I've fixed the download link for 0.1.5 on PyPi. I've also published a new release: 0.1.6. This project is now in a much healthier state. Since I've refreshed my memory on how everything works, I'm committed to being more active in my maintenance of this project in the future.

https://github.com/jart/fabulous/releases
https://pypi.python.org/pypi/fabulous/0.1.6
https://pypi.python.org/pypi/fabulous/0.1.5

Ok I tested things more thoroughly and had to bundle the grapefruit dependency. Now Fabulous will work 100% for sure from pip and easy_install. You have to use the 0.1.7 though. Old releases probably won't work.

I also set up a GitHub pages website for Fabulous! https://jart.github.io/fabulous/

Great :) fantastic work, updating this and making it accessible for the future.


BonMot supports all Apple platforms, not just iOS.

Just a minor tweak now that BonMot supports all platforms, rather than just iOS.

          1 Error

:no_entry_sign:
Found 1 link issue

Link issue by awesome_bot

Line
Status
Link

1312
404
https://github.com/rob-nash/Fetcher

  Generated by :no_entry_sign: Danger

Looks like a 404 got past @danger-awesome-ios and into master (or that repo was deleted).

Hey @ZevEisenberg , thanks for tweaking!


doc: provide more examples for parameter validation

Is your feature request related to a problem? Please describe.
Hertz integrates with go-tagexpr for paramater binding and validation. However, go-tagexpr itself is poorly documented, therefore it becomes difficult for people who are new to hertz to add their first vd tag.
Describe the solution you'd like
I would recommand add examples for the following tags:

length validation for string and list len($)>0
regex pattern match for string regexp('^\\w*$')"
value validation for numertic field $>0
validation for pointer field num==nil || num>0
validation for enum types type=="hello" || type == "world"
custom error message msg:'C must be false when S.A>0'"

I have used these tags extensively in production and these tags should cover a widely range of use cases.
Also, we could provide a example of defining vd tags in idl, this should also helps.
Describe alternatives you've considered
Alternative, we can add these examples to reference if it doesn't fit into the scope of Binding and validate

Additional context
I have been used vd for almost 2 years. I constantly found myself confused and frustared with go-tagexpr's documentation. Hopefully, with these examples, hertz users can get started with vd with much less pain.

related issue: https://github.com/cloudwego/hertz/issues/632

Could you help to add more examples? @Haswf

@Haswf We have refactored the parameter binding and validation capabilities (https://github.com/cloudwego/hertz/pull/541), and the new validation function will use "go-playground/validator".
The "go-tagexpr" will be moved to "hertz-contrib".
You can write a new example after the new version is released


Host stuck in activating state forever , even after rancher agent is running.

Server version - rancher/server:v0.23.0-rc2
steps to reproduce the problem:
Added a digital Ocean machine with labels  (name = value) . Host got added successfully thought it took a long time.
Added another digital Ocean machine with labels  (name = value) . Host is stuck in "activating" state for more than 30 minutes now. I see the rancher agent is already installed and is running on the machine,
Added another digital Ocean machine without any labels . Host is stuck in "activating" state for more than 30 minutes now. I see the rancher agent is already installed and is running on the machine,

Wasn't this resolved Sangeetha?

Server version - rancher/server:v0.23.0-rc5
This issue is not reproducible anymore.
I was able to add many Digital Ocean machines with and without labels and had no issues.


Add fix for #343 Use ResolveReferences task

This task seems to stably return the reference list now.
Added a test using an executable that references a pcl assembly

We should enable all the PCL tests on linux now that that is supported.

Do you want to do that as a separate PR or?

I think it's best here so we can see the tests passing across the board.

Otherwise your new test isn't exercised on Unix.

Seems some tests are failing, not sure if the correct tasks are in place for all situations, might have to drop this completly if I cant get it working tomorrow.

Yes, two failing:
9191) Test Failure : FSharp.Compiler.Service.Tests.ProjectOptionsTests.Project file parsing -- 2nd level references
2920     Expected: "Found 'FSharp.Core.dll'"
2921Actual: "Failed to find 'FSharp.Core.dll'"

29312) Test Failure : FSharp.Compiler.Service.Tests.ProjectOptionsTests.Project file parsing -- Exe with a PCL reference
2932     Expected: set
2933  ["FSharp.Core.dll"; "SQLite.Net.Platform.Generic.dll";
2934   "SQLite.Net.Platform.Win32.dll"; "SQLite.Net.dll";
2935   "System.Collections.Concurrent.dll"; "System.Collections.dll";
2936   "System.ComponentModel.Annotations.dll";
2937   "System.ComponentModel.EventBasedAsync.dll"; "System.ComponentModel.dll"; ...]
2938Actual: set
2939  ["FSharp.Core.dll"; "System.Core.dll"; "System.Numerics.dll"; "System.dll";
2940   "mscorlib.dll"]

Ha switching to ResolveReferences fixes the references pcl issue but breaks all other use cases, it seems that the evaluated item ReferencePath is not empty but the evaluated item Reference exists although the references are not path resolved just fully qualified names.

Can you explain a bit more? Almost all the tests pass so things don't seem too bad! Your new test project should probably be under data with the other non-canonical tests, and I think it will have some difficulty passing because it references assemblies from the non-existent packages directory (I think SQLite.Net comes from NuGet). Perhaps they can just be removed?

I do see that things are worse on Windows though.

Should have posted this here:
2nd level references test fails on Linux. Output includes:
InvalidCastException, ITask: Microsoft.Build.Framework.ITask, Microsoft.Build.Framework, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a Task type: Microsoft.Build.Tasks.Message, Microsoft.Build.Tasks.v4.0, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Error initializing task Message: Cannot cast from source type to destination type.
Error initializing task Message: System.InvalidCastException: Cannot cast from source type to destination type.
  at Microsoft.Build.BuildEngine.BuildTask.InitializeTask () [0x00000] in <filename unknown>:0

Classic old friend

I've pushed what I tried here, which seems decent, although your new test doesn't pass. As I said, the SQLite dlls are not there so it isn't that surprising.

Having pcl working is the most important think for me, it's unshippable without that.  :-(

On 2 Jun 2015, at 12:17, Robin Neatherway<EMAIL_ADDRESS>wrote:
I've pushed what I tried here, which seems decent, although your new test doesn't pass. As I said, the SQLite dlls are not there so it isn't that surprising.
—
Reply to this email directly or view it on GitHub.

Have you tried it with the SQLite dlls present? Perhaps it works fine. All the other PCL tests work OK.

Yes Ive tried, we are no further forward its still exactly the same issue, no implicit pcl references are present.

@rneatherway I just corrected the package folder, although it makes no difference even if you restore the package.

@rneatherway The only way I can figure at the moment is evaluating the names evaluation group _DesignTimeFacadeAssemblies and if it exists return those assemblies too.

Hmm. I don't understand that because we are running ImplicitlyExpandDesignTimeFacades. What is different when compared to this project and all the others where the PCL works? What is the diff between the log outputs?

Heres a gist of the 259 vs sqllite test:
https://gist.github.com/7sharp9/9f1466ae40b86919a8f1

It makes no difference, mine has the package restored

With the sqllite one there is an extra property _DesigntimeFacadeAssemblies which is not present in the 259 test.

The only reference I can find is here:
https://github.com/Microsoft/msbuild/blob/82177a50da735cc0443ac10fa490d69368403d71/src/XMakeTasks/Microsoft.NETFramework.CurrentVersion.targets#L99-L102

Hey did you notice this at the end of the sqlite one:

Target named 'ImplicitlyExpandTargetFramework' not found in the project.

Yep, that target doesn't exist as its a property of the pcl reference rather than the project under test

What do you mean? That target is found in Microsoft.Common.targets. If I build your sqlite project with xbuild then it runs that target.

Im guessing its not looking there

The previous line, though, is

Done building target "ResolveAssemblyReferences" in project "/Users/dave/code/FCS/tests/projects/sqlite-net-spike/sqlite-net-spike.fsproj" ("/Library/Frameworks/Mono.framework/Versions/4.0.1/lib/mono/4.5/Microsoft.Common.targets").

I think that perhaps the issue is that it doesn't run ImplicitlyExpandTargetFramework and then as a result it doesn't run ImplicitlyExpandDesignTimeFacades either because it is after it in the list of targets.

By the ways its not just the sqllite test project that behaves this way and project that references a pcl is missing the references.

Understood. When you first submitted this PR did it work, but it just broke other things?

Yeah, everything else broke but referenced pcl projects worked.
I had a quick look in monodevelop to see how the overrided GetReferences method worked in C#, it looks like the framework references are appended here:
https://github.com/mono/monodevelop/blob/b10a2f2b566a33ec333d5b9e5fa3d1c1e16829cf/main/src/core/MonoDevelop.Core/MonoDevelop.Projects/PortableDotNetProjectFlavor.cs#L79-L85

Just to clarify a single `ResolveReferences" works perfectly:

Thanks, very interesting. Is that back with the v12 MSBuild or v4?
I found that in the case where the test fails it is instead pulling in the assemblies from mono/xbuild-frameworks/.NETPortable/v4.5 rather than mono/4.5/Facades/, which includes more assemblies. The difference is the flag settings:
~/dev/other/FSharp.Compiler.Service $ monodis --assembly /usr/lib/mono/4.5/Facades/System.Xml.XmlSerializer.dll
Assembly Table
Name:          System.Xml.XmlSerializer
Hash Algoritm: 0x00008004
Version:       <IP_ADDRESS>
Flags:         0x00000001
PublicKey:     BlobPtr (0x00000001)

~/dev/other/FSharp.Compiler.Service $ monodis --assembly /usr/lib/mono/xbuild-frameworks/.NETPortable/v4.5/System.Xml.XmlSerializer.dll
Assembly Table
Name:          System.Xml.XmlSerializer
Hash Algoritm: 0x00008004
Version:       <IP_ADDRESS>
Flags:         0x00000071
PublicKey:     BlobPtr (0x0000028c)

Thats with this current PR with the single target ResolveReferences.
Maybe we should work backwards, with this PR pcl projects resolve correctly as do projects that reference a pcl, the thing that doesnt work is the Project file parsing -- 2nd level references test which only returns one reference.

If I enable logging the results look curious:
https://gist.github.com/7sharp9/04743db202e079f943c0

That's really odd, but I think I see the issue. For some reason it actually goes off to build Test1 (referenced by Test2, the main project file), and this then fails because the source files aren't present, and why should they be! So perhaps this would work in a normal situation where the referenced project actually compiles, but it still seems a bit strict, and also slow! We don't want to compile all the referenced projects I don't think.

Right, I found this: https://github.com/mono/mono/blob/master/mcs/tools/xbuild/data/14.0/Microsoft.Common.targets#L345

  <!-- If building from a .sln.proj or from IDE, then referenced projects have already
       been built, so just get the target paths -->

Which then calls the MSBuild task. Because it hasn't been built, it then builds it. I don't think we want to do this. We fake it later anyway by loading the referenced projects and finding their OutputFile.
Happily, I found that swapping the order of the multi-task option seems to work. Try:
project.Build([| "ResolveAssemblyReferences";
                         "ImplicitlyExpandDesignTimeFacades";
                         "ImplicitlyExpandTargetFramework" |])  |> ignore

so that it doesn't matter if ImplicitlyExpandTargetFramework isn't present.

Oh god. That link I sent shows that ResolveProjectReferences only builds the referenced projects if $(BuildingInsideVisualStudio) = 'true'. Do you know how to set a variable like that?

Thanks MS for posting open-sourcing Visual F# tools: https://github.com/Microsoft/visualfsharp/blob/fsharp4/vsintegration/src/vs/FsPkgs/FSharp.Project/Common.Source.CSharp/Project/ProjectNode.cs#L3432

OK, it appears that our victory is complete. We just have to use an undocumented variable to pretend to be Visual Studio. Obvious really...
@7sharp9 please can you add your android project as a test so that we can make sure we don't break that in the future.
I'm not clear on whether we should be using MSBuild 4 or 12 really. The other scenarios that I'm aware of (xbuild, and now the Visual F# Tools) both use conditional compilation to prepare different versions compiled against different versions of the MSBuild assemblies. Perhaps we should do the same and pass the choice onto consumers of FCS.

This should also fix #342 and #294.

Ah right, so without v12 it fails on Windows. Mono is more robust. The tests pass on my Linux machine.

@rneatherway I can try adding the android project, although Android will not be installed on the CI systems will it?

Oh it needs some extra packages, sorry I didn't realise. Probably not the way to go then.

Because I had to revert back to MSBuild 12 so that it works on Windows, this will not fix the android issue anymore, at least not without binding redirects.

I've lost track of this conversation - could someone summarize the state of play? :) Thanks!

Hi Don, well it took a lot of effort, but I think it is a unquestioned improvement. The headline is that we are using the target ResolveReferences rather than the old ResolveAssemblyReferences; ImplicitlyExpandTargetFramework. This should run all the same tasks that the build would run, rather than hackishly adding extra targets ourselves. One such is ResolveProjectReferences, which prevents us having to recurse on the projects manually. However, it then actually tries to build the referenced projects, because that is how Microsoft.Common.targets works unless you set the property "BuildingInsideVisualStudio" to "true". So I've done that. This should be much more robust.
However, there are two outstanding issues:

The sqlite test (project referencing a PCL-using DLL) doesn't pass on Windows. To debug that I need to see the LogOutput from FCS compared to msbuild /v:diag on Windows. I think it may be a ToolsVersion issue, see '2'.

The ToolsVersion and MSBuild version assembly issue.
a) On Windows, using MSBuild v4 causes many tests to fail, presumably the 'New API' is not well supported if at all in those assemblies.
b) Generally, using MSBuild v12 causes Websharper/Android/custom Tasks that inherit from MSBuild v4 Task (e.g. #342 and #294) to fail with an InvalidCastException. We could try, although I haven't yet, using a binding redirect e.g. on FSharp.AutoComplete as Xbuild v12 does. However, xbuild doesn't use a binding redirect for Microsoft.Build.Tasks.vXX.dll and I don't see how that could work because the assemblies have different names. So I'm thinking that perhaps we are not setting the engine/project ToolsVersion correctly.

I'm concerned that we are possibly setting ourselves an impossible task in having a single version of FCS that works for all projects and installed versions of MSBuild. Both xbuild and the Visual F# VS integration use conditional compilation and thus assume that a particular instance of MSBuild is present. Perhaps @tpetricek's plan to bundle a particular version, which aligns with this model, is actually wise.
I have noticed that the Visual F# VS integration invokes the target Compile and only falls back to ResolveReferences: https://github.com/Microsoft/visualfsharp/blob/fsharp4/vsintegration/src/Salsa/salsa.fs#L223

@rneatherway Does running the Compile target on windows make it succeed?

No, it doesn't make any difference. The log output from FCS is much less useful on Windows, see here: https://gist.github.com/rneatherway/5c8028fa0b84a40e3fa9
For some reason it just doesn't give the same level of detail as msbuild does, while on Mono that works fine.

Hmm, well they're both building with v12 due to:
Project file contains ToolsVersion="4.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="12.0". For more information, please see http://go.microsoft.com/fwlink/?LinkId=293424.

In XS with C# the target reference assemblies are added to the returned references if the project context is pcl anyway.  This stuff is pretty difficult to resolve nicely it seems.

Yeah, I noticed that. I was somewhat heartened because at least they are both doing the same thing. It's hard to see what the problem is exactly because of the logger not being verbose enough. It might be fruitful to try the same logger that they use in Visual F# tools: https://github.com/Microsoft/visualfsharp/blob/fsharp4/vsintegration/src/Salsa/salsa.fs#L219
If it's possible to determine that the project reference is PCL somehow then could we just hackily add the target reference assemblies?

I think you would have to enumerate the target references and project references and detect it there, or alternatively there will probably be a property thats set thats states that this is the case.  The _DesignTimeFacadeAssemblies has the reference list so its just doing the detection thats the difficult bit.

Is property populated on Windows?

@rneatherway  Re problem 2 above - as far as I can see from my comment here https://github.com/fsharp/FSharp.Compiler.Service/issues/342#issuecomment-106627742, the cast failure is when casting from type
Task type: Xamarin.Android.Tasks.ResolveSdks, Xamarin.Android.Build.Tasks, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null

to
ITask: Microsoft.Build.Framework.ITask, Microsoft.Build.Framework, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

Note that the target interface type being cast to is in Microsoft.Build.Framework (which looks like it will need a binding redirect from <IP_ADDRESS> --> <IP_ADDRESS> for things to work), not Microsoft.Build.Tasks.vXX.dll (which doesn't need a binding redirect).
It seems to me that adding the <IP_ADDRESS> --> <IP_ADDRESS> binding redirect for Microsoft.Build.Framework  would solve this problem in the cases where we can assume MSBuild <IP_ADDRESS> on the target machine. However I also notice Tomas' comment here: https://github.com/fsharp/FSharp.AutoComplete/issues/11, which says we can't particularly assume either MSBuild <IP_ADDRESS> or <IP_ADDRESS> on the target machine for tools like FsAutocomplete.exe (though it might be reasonable to expect one of the two)  In that case I've no real idea how one is meant to deliver tools that depend minimally on the MSBuild v<IP_ADDRESS> API, except by bundling the MSBuild <IP_ADDRESS> DLLs.with your application.  Perhaps we should ask someone on the MSBuild team for guidance about what they expect people to do for such tools.
Could you add a failing test for problem (2)?

Ah, my mistake. I assumed that as it was a Task it was in the Tasks dll. You're right, the binding redirect should be fine there.
I tried to construct a test for problem (2), but the WebSharper issue no longer occurs and I don't have access to Android projects. @7sharp9 how could we add a test for that?
I'm strongly leaning towards bundling a version of MSBuild with FCS as being the correct resolution for this issue, but it would be great to ask somebody in the know.
As for the windows issue, with massive thanks again to MS for the recent open-sourcing spree, I have found a suitable logger to subsitute for my BasicStringLogger (https://github.com/Microsoft/msbuild/blob/master/src/XMakeBuildEngine/Logging/SerialConsoleLogger.cs) so I should be able to get some more debug output for that tonight.

@rneatherway I dont know, Android projects will require the android msbuild tasks to be present on the cI server:
  <Import Project="$(MSBuildExtensionsPath)\Xamarin\Android\Xamarin.Android.FSharp.targets" />

You could make a new task DLL, e.g. by copying and modifying this stuff?  Or this DLL or this DLL are MSBuild task DLLs with a 4.0 dependency?  I presume trying to load that as a custom task will fail?

Should be OK to just modify the paths of the targets file and custom task assembly then put them in the project directory. If you do that then we probably don't want to commit the assemblies to this repo but we could at least test whether it is working on an ad-hoc basis. I'm not aware of any other custom tasks that exhibit this behaviour now that Websharper works. If you know of any we could use that instead.

The other thing you could do to harden the testing is to invoke type checking on the project and assert that there are no Errors present.

Well I tried using a ConsoleLogger, but unfortunately for some reason it doesn't give and more information really, just:
Target "ResolveAssemblyReferences" in file "C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets":
  Using "ResolveAssemblyReference" task from assembly "Microsoft.Build.Tasks.v12.0, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
  Task "ResolveAssemblyReference"
  Done executing task "ResolveAssemblyReference".
Done building target "ResolveAssemblyReferences" in project "sqlite-net-spike.fsproj".

But not what and how it happened. By contrast, running msbuild.exe from the command line gives much information:
Target "ResolveAssemblyReferences: (TargetId:12)" in file "C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets" from project "D:\dev\FSharp.Compiler.Service\tests\service\data\sqlite-net-spike\sqlite-net-spike.fsproj" (target "ResolveReferences" depends on it):
Using "ResolveAssemblyReference" task from assembly "Microsoft.Build.Tasks.v12.0, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "ResolveAssemblyReference" (TaskId:7)
  Task Parameter:
      Assemblies=
          mscorlib
          FSharp.Core
          System
          System.Numerics
          SQLite.Net.Platform.Win32
                  HintPath=..\..\..\..\packages\SQLite.Net-PCL.3.0.5\lib\net4\SQLite.Net.Platform.Win32.dll
          SQLite.Net
                  HintPath=..\..\..\..\packages\SQLite.Net-PCL.3.0.5\lib\net40\SQLite.Net.dll
          SQLite.Net.Platform.Generic
...
<snip>

but I don't know the name of this logger to use it programmatically.

OK... apparently there is a property called ResolveAssemblyReferencesSilent which disables logging for that task specifically. I'll have to try that, but it will be after the weekend.
<ResolveAssemblyReferencesSilent
  Condition="'$(ResolveAssemblyReferencesSilent)' == '' and
  '$(TraceDesignTime)' != 'true' and
  '$(BuildingProject)' == 'false'">
    true
</ResolveAssemblyReferencesSilent>
<ResolveAssemblyReferencesSilent
  Condition="'$(ResolveAssemblyReferencesSilent)' == ''">
    false
</ResolveAssemblyReferencesSilent>

It would be good to get this one resolved so that project cracking is usable :-(

I couldn't get it working without using the Build target. Of course this then actually builds things, which is slow and therefore bad. So I ripped off the sneaky HostCompilation trick from visualfsharp's salsa.fs, which skips the compilation step and keeps things fast. A console app with a proof of concept is at https://github.com/rneatherway/msbuildresolution, and is much easier to test than waiting 10 minutes for the FCS unit tests.

This seems to work locally. I had to relax the condition on Dave's new PCL test because Windows uses a slightly different set of assemblies, but I think it still suffices to check that the PCL reference assemblies are being pulled in.

@rneatherway sounds like progress!

It is my belief that this is ready to be merged now. I don't think it fixes #342 (android), but it would be nice to have confirmation from @7sharp9. I've come to also believe that this should be fixed by using an assembly binding redirect (and bundling MSBuild a la #338).

A binding redirect would have to be applied to the originator process, unless this was invoked oop

Yes I understand. I think this is consistent with xbuild, msbuild and Visual Studio.

Ok, I was going over this issue with one of the guys here and he was of the opinion that this function should be done out of process otherwise unknown external dlls could be loaded into the monodevelop process.  We have a similar method in MonoDevelop which is running targets for MonoDevelop, all out of process for these reasons.

Ah right, because of the custom tasks etc? That makes sense. Would that mean having an exe wrapper that just printed the results on standard out? Or is there a cleverer way of doing that in .NET?
Either way, I would be glad to merge this and do a release as it at least fixes the PCL referencing issue and generally makes things more robust. @dsyme are you OK with that?

@rneatherway Did you make changes to both new and old project cracking?

Yes, the old API now uses the ResolveReferences with the BuildingInsideVisualStudio property set. It's actually easier with the old API than the new.

@rneatherway MonoDevelop does it like this:
https://github.com/mono/monodevelop/blob/master/main/src/core/MonoDevelop.Core/MonoDevelop.Projects.Formats.MSBuild/MSBuildProjectService.cs#L504-L608
And theres a reference resolution task already in existence too, I might have linked you to this a week back maybe.
https://github.com/mono/monodevelop/blob/master/main/src/core/MonoDevelop.Core/MonoDevelop.Projects.Formats.MSBuild/RemoteProjectBuilder.cs#L188-L216

I see. I think they should be using ResolveReferences there with the property set like I did. They can probably avoid adding the PCL references afterwards manually that way.
I notice this comment:
//always start the remote process explicitly, even if it's using the current runtime and fx
//else it won't pick up the assembly redirects from the builder exe

is pretty telling. I suppose we could always use that method, but I'm pretty happy with where we are now.

Having unknown references polluting the current runtime process is quite nasty too so its better to be an isolationist here I think.

@7sharp9 - it seems it would be best to implement the isolation via an appdomain or an external process. Can you do that as part of XS/MD addin implementation or do you think we should do it in FCS?
@rneatherway - yes we can merge and re-release.

@dsyme Well I would expect to be able to call an exposed method without having to wrap it in another process, it probably should be part of FCS.
Ive been told calling msbuild has to be done out of process, so I wont be able to use this functionality as it stands. :-(

@7sharp9 - well, you can use it, you just have to call it out of process :)
I agree it would be good to do that automatically though, I suppose by including a fsservice.exe in the "tools" directory that can be invoked behind the scenes

At the moment I don't have time to refactor to use out of process though, Ill have to do that before this release goes out, I suppose Android is broken until then too.


Fix sources

NIKON link changed
HOYA website (hoyaoptics.com) is down. New link found - @BrianGun could you verify that this link is OK? Added support in build script for direct AGF downloads (previously only supported ZIP archives).
Sumita link changed. @BrianGun there's a download option for discontinued glasses - do we want this?

Also extended ZIP file support to automatically pick the first AGF file in the downloaded ZIP archive.

Codecov Report

Merging #96 (6dfe488) into main (103c70f) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #96   +/-   ##
=======================================
  Coverage   47.61%   47.61%
=======================================
  Files          57       57
  Lines        6620     6620
=======================================
  Hits         3152     3152
  Misses       3468     3468

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 103c70f...6dfe488. Read the comment docs.

Don't think we want to include discontinued Sumita glasses, or other manufacturers, in the default download. Let users get them in a separate step if they need them.


Start minimized

Hello.
On system startup, Emoji Keyboard always opens. That is annoying. I just want the indicator in the system tray.

emoji-keyboard should start minimized by default unless you launch it with -k flag.
Check startup applications / autorun .desktop file, there's probably -k flag in the exec line.

Hmm, It seems I was using an older version of emoji-keyboard that I installed using the PPA. I removed it and installed the latest .deb file and it is fine now.
Thanks.


Memory leak for simple get call

While trying to optimize the memory usage of my code, i noticed, that there seems to be a memory leak when calling reqwest::get()
use reqwest;
use std::error;

fn main() -> Result<(), Box<error::Error>> {
    let _ = reqwest::get("https://www.ycombinator.com")?.text()?;
    Ok(())
}

When i check this simple code snippet with valgrind --leak-check=full valgrind reports 690 lost bytes.
==17381== Memcheck, a memory error detector
==17381== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==17381== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==17381== Command: target/debug/reqwest
==17381==
==17381==
==17381== HEAP SUMMARY:
==17381==     in use at exit: 104,588 bytes in 3,335 blocks
==17381==   total heap usage: 32,500 allocs, 29,165 frees, 3,095,914 bytes allocated
==17381==
==17381== 114 bytes in 1 blocks are definitely lost in loss record 596 of 665
==17381==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17381==    by 0x5DC7640: __libc_alloc_buffer_allocate (alloc_buffer_allocate.c:26)
==17381==    by 0x5E71097: alloc_buffer_allocate (alloc_buffer.h:143)
==17381==    by 0x5E71097: __resolv_conf_allocate (resolv_conf.c:410)
==17381==    by 0x5E6E093: __resolv_conf_load (res_init.c:587)
==17381==    by 0x5E705A8: __resolv_conf_get_current (resolv_conf.c:162)
==17381==    by 0x5E6EDFC: __res_vinit (res_init.c:609)
==17381==    by 0x5E6FF9F: maybe_init (resolv_context.c:122)
==17381==    by 0x5E6FF9F: context_get (resolv_context.c:184)
==17381==    by 0x5E6FF9F: __resolv_context_get (resolv_context.c:195)
==17381==    by 0x5E2F97D: gaih_inet.constprop.7 (getaddrinfo.c:767)
==17381==    by 0x5E31CE3: getaddrinfo (getaddrinfo.c:2300)
==17381==    by 0x9BDFA2: <std::sys_common::net::LookupHost as core::convert::TryFrom<(&'a str, u16)>>::try_from (net.rs:194)
==17381==    by 0x9B61A2: try_into<(&str, u16),std::sys_common::net::LookupHost> (convert.rs:519)
==17381==    by 0x9B61A2: <(&str, u16) as std::net::addr::ToSocketAddrs>::to_socket_addrs (addr.rs:879)
==17381==    by 0x3B5DC1: <hyper::client::connect::dns::GaiBlocking as futures::future::Future>::poll (dns.rs:212)
==17381==
==17381== 576 bytes in 2 blocks are possibly lost in loss record 624 of 665
==17381==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17381==    by 0x40134A6: allocate_dtv (dl-tls.c:286)
==17381==    by 0x40134A6: _dl_allocate_tls (dl-tls.c:530)
==17381==    by 0x58FB227: allocate_stack (allocatestack.c:627)
==17381==    by 0x58FB227: pthread_create@@GLIBC_2.2.5 (pthread_create.c:644)
==17381==    by 0x9BFDB1: std::sys::unix::thread::Thread::new (thread.rs:69)
==17381==    by 0x5475E6: std::thread::Builder::spawn_unchecked (mod.rs:488)
==17381==    by 0x547D72: std::thread::Builder::spawn (mod.rs:382)
==17381==    by 0x54308E: futures_cpupool::Builder::create (lib.rs:427)
==17381==    by 0x3B53A5: hyper::client::connect::dns::GaiResolver::new (dns.rs:115)
==17381==    by 0x1E3C53: <hyper::client::connect::http::HttpConnector>::new (http.rs:78)
==17381==    by 0x22EF31: reqwest::connect::http_connector (connect.rs:208)
==17381==    by 0x22ED77: reqwest::connect::Connector::new_default_tls (connect.rs:79)
==17381==    by 0x317F4D: reqwest::async_impl::client::ClientBuilder::build (client.rs:156)
==17381==
==17381== LEAK SUMMARY:
==17381==    definitely lost: 114 bytes in 1 blocks
==17381==    indirectly lost: 0 bytes in 0 blocks
==17381==      possibly lost: 576 bytes in 2 blocks
==17381==    still reachable: 103,898 bytes in 3,332 blocks
==17381==         suppressed: 0 bytes in 0 blocks
==17381== Reachable blocks (those to which a pointer was found) are not shown.
==17381== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17381==
==17381== For counts of detected and suppressed errors, rerun with: -v
==17381== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

Is this a known issue?

It seems to think some memory is lost from ToSocketAddrs? A simple way to try that out without reqwest is this program:
fn main() {
    let _ = TcpStream::connect("your.domain");
    // and just drop everything else...
}

This doesn't seem to leak any memory
==3015== Memcheck, a memory error detector
==3015== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3015== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==3015== Command: target/debug/reqwest
==3015==
==3015==
==3015== HEAP SUMMARY:
==3015==     in use at exit: 0 bytes in 0 blocks
==3015==   total heap usage: 14 allocs, 14 frees, 2,243 bytes allocated
==3015==
==3015== All heap blocks were freed -- no leaks are possible
==3015==
==3015== For counts of detected and suppressed errors, rerun with: -v
==3015== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I tried running valgrind on the same program, and it didn't report any leaked memory. I noticed that my valgrind reports v3.11.0, whereas yours is v3.13.0. I don't know if that is the difference...

See https://github.com/seanmonstar/reqwest/issues/1445


_MBCS and _UNICODE are not discussed

Hi Everyone. I was looking at cpp-docs/docs/preprocessor/predefined-macros.md. I noticed neither _MBSC or _UNICODE are discussed.
There is a discussion of _MBSC or _UNICODE at Generic-Text Mappings in tchar.h.
It may be a good idea to add them to the list. I wanted to cite this list, but the discussion is missing.
(Edit by @corob-msft to point link at documentation instead of source file.)

@noloader
These macros, while ubiquitous, aren't mentioned in this particular document because they're not predefined by the compiler.  The confusion may arise because they're usually defined for you by template-created projects, they're required for certain library behavior, and you can set them in a projects Property Pages dialog.

@noloader
Also, it's helpful if you use the feedback control at the bottom of the public documentation page to raise an issue. It fills in an issue template with info we need for bug assignments and tracking. Thanks!


number results as terminal

Fixed by https://github.com/simonseyock/jsdoc-type-pratt-parser/pull/60


Create notebook examples for scheduling jobs

Create examples of how to schedule a job using:

[x] Prefect
[ ] Airflow

https://www.prefect.io/ has open-sourced the scheduler. @Jarrioja lets take some time to play with this


List all Rasa stories requiring specified slots, forms or responses

AS AN Architect
I WANT to have a REST service to list all Rasa rules requiring specified slots
SO THAT there wouldn't be duplicate services for it
Acceptance Criteria

[ ] Use POST endpoint /rasa/stories/search with input parameters type: slots/forms and input: {JSON array}
[ ] Rasa stories.yml as source of truth
[ ] Search within OpenSearch

OpenSearch fed with input via a separate pipeline

Examples
Search for required slots
Slots are defined by defining slot_was_set, for example, rules.rule.steps.slot_was_set, rules.rule.condition.slot_was_set, etc.
version: "3.0"
stories:
- story: Deactivate custom fallback form
  steps:
  - action: custom_fallback_form
  - slot_was_set:
    - asukoht: Tallinn
  - action: action_react_to_affirm_deny_in_custom_fallback_form

or https://github.com/buerokratt/Training-Module/blob/main/mock1/data/stories.yml#L9-L14
Search for required forms
Forms are defined by defining action, for example, stories.story.steps.action with value(s) having a suffix _form
For example
version: "3.0"
stories:
- story: Deactivate custom fallback form
  steps:
  - action: custom_fallback_form
  - slot_was_set:
    - asukoht: Tallinn
  - action: action_react_to_affirm_deny_in_custom_fallback_form

or https://github.com/buerokratt/Training-Module/blob/main/mock1/data/stories.yml#L11
Forms are defined by defining active_loop, for example, stories.story.steps.active_loop with value(s) having a suffix _form
version: "3.0"
stories:
- story: User interrupts the form and doesn't want to continue
  steps:
  - intent: request_restaurant
  - action: restaurant_form
  - active_loop: restaurant_form

Search for required responses within stories
Responses are defined by defining action, for example, stories.story.steps.action with value(s) having a prefix utter_
For example
version: "3.0"
stories:
- story: andmekaitse_küsimused
  steps:
  - intent: andmekaitse_küsimused
  - action: utter_andmekaitse_küsimused

or https://github.com/buerokratt/Training-Module/blob/main/mock1/data/stories.yml#L7

sample input to /rasa/stories/search
{
    "type": "response",
    "response": "utter_common_hüvasti_jätmine"
}

@janyprus please link this issue with an appropriate pull request.

Pull requests #163 and #167

@turnerrainer will explain how to test it


Special characters in SIP password

Hello.
I can not use the SIP account with special characters, for example @. The standard version with %40 does not work. Checked for the latest version of the baresip 0.5.4.
Sorry for my poor English.

maybe we should add a new ;password=xxx parameter and deprecate the
password field in the SIP uri ?

@PikaYellow35 could you please test this patch:
diff --git a/src/account.c b/src/account.c
index e23d5c8..c3f26eb 100644
--- a/src/account.c
+++ b/src/account.c
@@ -396,7 +396,9 @@ int account_alloc(struct account **accp, const char *sipaddr)
                        goto out;
        }
        else {
-               err = pl_strdup(&acc->auth_pass, &acc->laddr.uri.password);
+               err = re_sdprintf(&acc->auth_pass, "%H",
+                                 uri_password_unescape,
+                                 &acc->laddr.uri.password);
                if (err)
                        goto out;
        }

it adds unescaping of the password field, so you use e.g. %40 instead of @
/Alfred

I'm sorry for the long answer. Thanks for patch. I'm recompile baresip and report the results.

Yes, it work. Many thanks. =)

@PikaYellow35 many thanks for reporting and testing


Endpoint not found

I installed the Elyra extension through the source code, but when I opened jupyterLab in my browser, I received some popups:

When I open JupyterLab in my browser, does Elyra communicate with urls on other ports?I am a remote server on the cloud and only open port 8000. Is this the problem?

ok, when I restarted the jupyterhub, the problem went away


Fix the setuptools code so that the correct names are used (resolves #266)

resolves #266

Jenkins, test this please.

Tests not required since this is targeting setup.py. Protect installs locally with setuptools>=39.0.1 + packaging and setuptools <39.0.1 - packaging.
merging


Add ability to abort modal close

We're currently running a fork of ember-promise-modals but it looks like most of our changes are now possible using the official addon. Our one remaining custom change is the addition of a beforeClose modal option.
Our typical use-case for beforeClose is when we have modal UI that allows user input, when that modal is closed if there are unsaved changes we want to abort the close and open another modal to get confirmation.
Simplified example:
setupController(controller, model) {
    this.newsletterModal = this.modals.open(
        EditNewsletterModal,
        {newsletter: model},
        {beforeClose: this.confirmUnsavedChanges}
    );
}

async confirmUnsavedChanges() {
    if (!this.model.hasDirtyAttributes) { return true; }

    // result: true = close and discard, false = abort close, allow further edits and save
    this.confirmModal = this.modals.open(ConfirmUnsavedChangesModal);

    return this.confirmModal;
}

Does something like this sound like an appropriate addition? Is there something like this already available that I've missed?
Our implementation in the fork was very basic and can be seen in this commit.

Hi, thanks for opening this.
Our team had a look at the suggestion but preferred not to implement it. Our reasoning is that preventing the modal from being closed should be managed from the modal itself, so the close action should not be called in the first place if there are validation errors and such. If it's not possible for some reason, it's still possible to extend the addon's functionalities.
We prefer to not change the addon's public API that way unless this use case comes up frequently.


Testing component governance task - this is throwaway work

Platforms Impacted

[ ] iOS
[ ] macOS

Description of changes
THIS IS NOT A REAL PR - this is testing the component governance task in our build pipelines/prechecks.
Verification
(how the change was tested, including both manual and automated tests)

Before
After

Screenshot or description before this change
Screenshot or description with this change

Pull request checklist
This PR has considered:

[ ] Light and Dark appearances
[ ] iOS supported versions (all major versions greater than or equal current target deployment version)
[ ] VoiceOver and Keyboard Accessibility
[ ] Internationalization and Right to Left layouts
[ ] Different resolutions (1x, 2x, 3x)
[ ] Size classes and window sizes (iPhone vs iPad, notched devices, multitasking, different window sizes, etc)
[ ] iPad Pointer interaction
[ ] SwiftUI consumption (validation or new demo scenarios needed)
[ ] Objective-C exposure (provide it only if needed)

Microsoft Reviewers: Open in CodeFlow

Ah, I have found the main difference - vNext-prototype branch has the component governance task defined, but main does not! I will keep hunting for the root cause for this task failing in our pipelines.


Android script fix & Askar impl on Kotlin mobile demo

Adjusted the directory on the android script.
Added a AskarWallet to the Kotlin mobile demo

@JamesKEbert Your right I missed that commit. Please review again. Thanks for the observation. Also please take a look at my implementation of keyMethod per your suggestion.


[Bug][Zentao] Zentao's bug sync failed, due to raw data with numeric priOrder

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
Sync with Zentao project partially failed.
After investigating it, it seems due to JSON unmarshal failure with the ZentaoBugRes's JSON.
What do you expect to happen
Hope sync succeeds.
How to reproduce
Maybe it could be reproduced with several different Zentao's version
Anything else
We have synced a few bugs previously successfully.
I have noticed, that in the Zentao BUG raw JSON, sometimes it uses the numeric priOrder, while sometimes it uses the string priOrder.
like(maybe newer version Zentao):
{"priOrder": 3}

or(maybe some legacy version):
{"priOrder": "3"}

it seems currently only Zentao's BUG has such behaviors, I'll check this for other issue types for Zentao later.
I'll provide the PR if tested successfully locally based on: https://github.com/matrixji/incubator-devlake/commit/96748e6945a4a127bffb683e978a2fa4c73a7ebd
Version
v.0.19.0-rc4, master
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Or you can  solve it like this:
https://github.com/apache/incubator-devlake/blob/main/backend/core/models/common/string_float64.go#L37
https://github.com/apache/incubator-devlake/blob/main/backend/plugins/zentao/models/project.go#L177

Hi @matrixji , long time no see. If you're planning to submit a PR, please self-assign the issue.

Or you can solve it like this: https://github.com/apache/incubator-devlake/blob/main/backend/core/models/common/string_float64.go#L37 https://github.com/apache/incubator-devlake/blob/main/backend/plugins/zentao/models/project.go#L177

That should works, @d4x1 thanks for your advise

@matrixji https://github.com/apache/incubator-devlake/releases/tag/v0.20.0-beta7 has been released


implementation of uint320 to replace uint512

currently this repo is using uint512 for the Poly1305 mac/tag generation.
But since the multiplication of (acc+block) and r inside the Poly1305 does not exceed 2^288, a uint320 would be enough,  It will use less operations and gain faster performance.

implemented pull:#13


This project rocks!!!

I just wanted to express how cool this work is. It's great! saves hours of work.!
Big thanks!!

Thanks for the issue :)


pnpm users should be warned about @zag-js/store duplication error

🚀 Feature request
When using @zag-js/react sometimes pnpm save two instances of @zag-js/store in node_modules(actually I don't know if this only occurs on monorepos), this breaks valtio behavior(as stated here https://github.com/pmndrs/valtio/discussions/706), throwing this error:

StackTrace
 error   proxyState is not iterable
  File:
    /Users/carlos/Documents/Projetos/Javascript/nen/node_modules/@zag-js/react/node_modules/@zag-js/store/dist/index.mjs:235:51
  Code:
    234 |   }
    > 235 |   const [target, ensureVersion, createSnapshot] = proxyState;
          |                                                   ^
      236 |   return createSnapshot(target, ensureVersion(), handlePromise);
      237 | }
      238 | function ref(obj) {
  Stacktrace:
TypeError: proxyState is not iterable
    at snapshot (file:///Users/carlos/Documents/Projetos/Javascript/nen/node_modules/@zag-js/react/node_modules/@zag-js/store/dist/index.mjs:235:51)
    at file:///Users/carlos/Documents/Projetos/Javascript/nen/node_modules/@zag-js/react/dist/index.mjs:70:11
    at Object.useSyncExternalStore (/Users/carlos/Documents/Projetos/Javascript/nen/node_modules/react-dom/cjs/react-dom-server.node.production.min.js:67:8)
    at exports.useSyncExternalStore (/Users/carlos/Documents/Projetos/Javascript/nen/node_modules/react/cjs/react.production.min.js:25:469)
    at useSnapshot (file:///Users/carlos/Documents/Projetos/Javascript/nen/node_modules/@zag-js/react/dist/index.mjs:51:24)
    at useMachine (file:///Users/carlos/Documents/Projetos/Javascript/nen/node_modules/@zag-js/react/dist/index.mjs:119:17)
    at usePressable (file:///Users/carlos/Documents/Projetos/Javascript/nen/node_modules/@ark-ui/react/pressable/use-pressable.mjs:14:25)
    at file:///Users/carlos/Documents/Projetos/Javascript/nen/node_modules/@ark-ui/react/pressable/pressable.mjs:25:30
    at Uc (/Users/carlos/Documents/Projetos/Javascript/nen/node_modules/react-dom/cjs/react-dom-server.node.production.min.js:70:44)
    at Xc (/Users/carlos/Documents/Projetos/Javascript/nen/node_modules/react-dom/cjs/react-dom-server.node.production.min.js:75:395)
    at Z (/Users/carlos/Documents/Projetos/Javascript/nen/node_modules/react-dom/cjs/react-dom-server.node.production.min.js:78:89)
    at Xc (/Users/carlos/Documents/Projetos/Javascript/nen/node_modules/react-dom/cjs/react-dom-server.node.production.min.js:75:509)
    at Z (/Users/carlos/Documents/Projetos/Javascript/nen/node_modules/react-dom/cjs/react-dom-server.node.production.min.js:78:89)
    at Qc (/Users/carlos/Documents/Projetos/Javascript/nen/node_modules/react-dom/cjs/react-dom-server.node.production.min.js:87:219)
    at Immediate._onImmediate (/Users/carlos/Documents/Projetos/Javascript/nen/node_modules/react-dom/cjs/react-dom-server.node.production.min.js:98:56)
    at process.processImmediate (node:internal/timers:476:21)

pnpm users should be warned in docs(and possibly in ark docs too) about the @zag-js/store duplication error. The fix is to force resolution of only one @zag-js/store package in node_modules:
"pnpm": {
  "overrides": {
    "@zag-js/store": "^0.12.0"
  }
}

🧱 Problem Statement / Justification
This should be added to inform people about valtio limitation. We could add a FAQ or troubleshooting section?

Good catch! I've gone ahead to update the docs.

Thanks for the fix! This issue also occurs if you are using Yarn with the pnpm linker, in  which case the solution is to use resolutions in package.json:
  "resolutions": {
    "@zag-js/store": "^0.12.0"
  },

Thanks for the fix! This issue also occurs if you are using Yarn with the pnpm linker, in which case the solution is to use resolutions in package.json:
  "resolutions": {
    "@zag-js/store": "^0.12.0"
  },

This issue occurs even with node-module as linker. However, this did the trick.


Reduce power consumption on ESP32

The below can be added to the YAML for the ESP to reduce the clock speed of the ESP32 to lower power consumption. It's the lowest speed that supports Wi-Fi, and it works perfectly for me:
esphome:
  platformio_options:
    board_build.f_cpu: 80000000L

I'm not sure how to share this here without logging an "issue".

How much does it reduce the power by? Is it a significant amount?  Do you have any benchmarks?

@wernerhp
Not exactly, but it does make a slight difference. And just for controlling the gate it doesn't need the extra speed.
Below are some indications, but I can't confirm how accurate they are.
https://esp32.com/viewtopic.php?t=2662#:~:text=At 80 MHz%2C with two,one CPU it consumes 40mA.


How to position pointer star?

For the code:
Cat* cat;

the default behavior formats it as:
Cat *cat;

I'm hoping there's an option to format it as:
Cat* cat;

I'm wondering whether it is possible. Thanks.

Sorted out by placing .clang-format in the same directory as the source code with the following content:
PointerAlignment: Left


Renaming a Type will delete the old one and recreate a new one - but without relations

Renaming this type:
type EmailUser2 implements Node {
  createdAt: DateTime!
  downvotedComment: [Comment!]! @relation(name: "UsersDownvotedComment")
  downvotedPosts: [Post!]! @relation(name: "UserDownvotedPost")
  email: String @isUnique
  groups: [Group!]! @relation(name: "UserOnGroup")
  id: ID! @isUnique
  name: String @isUnique
  password: String
  posts: [Post!]! @relation(name: "UserOnPost")
  profilePic: File @relation(name: "UserOnFile")
  updatedAt: DateTime!
  upvotedComment: [Comment!]! @relation(name: "UsersUpvotedComment")
  upvotedPosts: [Post!]! @relation(name: "UserUpvotedPost")
  adminGroups: [Group!]! @relation(name: "GroupOnUser")
  comments: [Comment!]! @relation(name: "CommentOnUser")
  contributer: Contributor @relation(name: "ContributerOnUser")
  isAdmin: Boolean @defaultValue(value: false)
  karma: Int
}

led to the following deploy changes:

The old type is deleted and a new once created as is expected. But only non-relation fields are being created for the new one.

This is now fixed 🙂


problems with cluster update merging and load balancing

Title: problems with cluster update merging and load balancing
Description:
Apologies for the vague title, but we don't have very many details on the issue yet.
Our internal control plane has a suite of integration tests that it runs with Envoy docker images. One of the tests sets up 2 upstream Envoys and 1 downstream, and ensures that requests are evenly divided among the 2 upstreams when using the round robin LB strategy. This test (and a few others) started breaking under the newest version of Envoy.
After bisecting, we landed on https://github.com/envoyproxy/envoy/commit/fad993e5aed40fba95897e9017afd19bdf170ed0 as the commit that broke us. To confirm, we made our control plane disable the feature by setting update_merge_window to 0, and our tests pass again.
I figured I'd file an issue about this in case anyone else starts seeing problems, but I haven't dug in deeper to see what the problem is yet.
More details:
When running the failing test with a breakpoint and inspecting /clusters, I see the following. Both upstreams are healthy, and there are 0 connections and requests attempted as expected
upstream--development::<IP_ADDRESS>:32992::cx_active::0
upstream--development::<IP_ADDRESS>:32992::cx_connect_fail::0
upstream--development::<IP_ADDRESS>:32992::cx_total::0
upstream--development::<IP_ADDRESS>:32992::rq_active::0
upstream--development::<IP_ADDRESS>:32992::rq_error::0
upstream--development::<IP_ADDRESS>:32992::rq_success::0
upstream--development::<IP_ADDRESS>:32992::rq_timeout::0
upstream--development::<IP_ADDRESS>:32992::rq_total::0
upstream--development::<IP_ADDRESS>:32992::health_flags::healthy
upstream--development::<IP_ADDRESS>:32989::cx_active::0
upstream--development::<IP_ADDRESS>:32989::cx_connect_fail::0
upstream--development::<IP_ADDRESS>:32989::cx_total::0
upstream--development::<IP_ADDRESS>:32989::rq_active::0
upstream--development::<IP_ADDRESS>:32989::rq_error::0
upstream--development::<IP_ADDRESS>:32989::rq_success::0
upstream--development::<IP_ADDRESS>:32989::rq_timeout::0
upstream--development::<IP_ADDRESS>:32989::rq_total::0
upstream--development::<IP_ADDRESS>:32989::health_flags::healthy

Now after sending 5 requests through, all of them end up at the same upstream. No connection is attempted to the other
upstream--development::<IP_ADDRESS>:32992::cx_active::0
upstream--development::<IP_ADDRESS>:32992::cx_connect_fail::0
upstream--development::<IP_ADDRESS>:32992::cx_total::0
upstream--development::<IP_ADDRESS>:32992::rq_active::0
upstream--development::<IP_ADDRESS>:32992::rq_error::0
upstream--development::<IP_ADDRESS>:32992::rq_success::0
upstream--development::<IP_ADDRESS>:32992::rq_timeout::0
upstream--development::<IP_ADDRESS>:32992::rq_total::0
upstream--development::<IP_ADDRESS>:32992::health_flags::healthy
upstream--development::<IP_ADDRESS>:32989::cx_active::1
upstream--development::<IP_ADDRESS>:32989::cx_connect_fail::0
upstream--development::<IP_ADDRESS>:32989::cx_total::1
upstream--development::<IP_ADDRESS>:32989::rq_active::0
upstream--development::<IP_ADDRESS>:32989::rq_error::0
upstream--development::<IP_ADDRESS>:32989::rq_success::5
upstream--development::<IP_ADDRESS>:32989::rq_timeout::0
upstream--development::<IP_ADDRESS>:32989::rq_total::5
upstream--development::<IP_ADDRESS>:32989::health_flags::healthy

Now when I docker stop the envoy listening on :32989 and send 10 more requests, they all end up on the remaining upstream that wasn't getting requests before
upstream--development::<IP_ADDRESS>:32992::cx_active::1
upstream--development::<IP_ADDRESS>:32992::cx_connect_fail::0
upstream--development::<IP_ADDRESS>:32992::cx_total::1
upstream--development::<IP_ADDRESS>:32992::rq_active::0
upstream--development::<IP_ADDRESS>:32992::rq_error::0
upstream--development::<IP_ADDRESS>:32992::rq_success::10
upstream--development::<IP_ADDRESS>:32992::rq_timeout::0
upstream--development::<IP_ADDRESS>:32992::rq_total::10
upstream--development::<IP_ADDRESS>:32992::health_flags::healthy
upstream--development::<IP_ADDRESS>:32989::cx_active::0
upstream--development::<IP_ADDRESS>:32989::cx_connect_fail::0
upstream--development::<IP_ADDRESS>:32989::cx_total::1
upstream--development::<IP_ADDRESS>:32989::rq_active::0
upstream--development::<IP_ADDRESS>:32989::rq_error::0
upstream--development::<IP_ADDRESS>:32989::rq_success::5
upstream--development::<IP_ADDRESS>:32989::rq_timeout::0
upstream--development::<IP_ADDRESS>:32989::rq_total::5
upstream--development::<IP_ADDRESS>:32989::health_flags::/failed_active_hc

fyi @rgs1

This seems a genuine bug, this isn't WAI for cluster merging AFAICT.

Thanks for reporting @mpuncel — mind sharing your LB configs? Do requests still go to only one host if you send, say, 100?
@htuch yeah, definitely not expected... My first guess would be that the underlying LB might not be friendly to the fact that some updates are skipped. Note that we've only used merged updates with the subset LB, so they might be some weirdness with other LBs...

cc: @tonya11en given he reported #5056, and this might or might be related.

@mpuncel these stats will be super useful if you can get them during the repro:
cluster_updated
cluster_updated_via_merge
update_merge_cancelled
update_out_of_merge_window

Huh I tried doing a lot more requests and I did end up seeing some hit the other upstream. So maybe it's a weighting issue.
After 139 requests:
upstream--development::<IP_ADDRESS>:33002::rq_total::13
upstream--development::<IP_ADDRESS>:32999::rq_total::126

After another 20:
upstream--development::<IP_ADDRESS>:33002::rq_total::15
upstream--development::<IP_ADDRESS>:32999::rq_total::144

Here are the stats:
cluster_manager.cluster_updated: 24
cluster_manager.cluster_updated_via_merge: 9
cluster_manager.update_merge_cancelled: 0
cluster_manager.update_out_of_merge_window: 22

Here's the cluster's config:
dynamic_active_clusters {
  version_info: "d0c073c54a5410fd30f4a38746fa40fd"
  cluster {
    name: "upstream--development"
    type: EDS
    eds_cluster_config {
      eds_config {
        ads {
        }
      }
    }
    connect_timeout {
      seconds: 1
    }
    health_checks {
      timeout {
        seconds: 5
      }
      interval {
        seconds: 5
      }
      unhealthy_threshold {
        value: 1
      }
      healthy_threshold {
        value: 1
      }
      http_health_check {
        host: "upstream--development"
        path: "/_status"
        use_http2: true
      }
    }
    circuit_breakers {
      thresholds {
        priority: HIGH
        max_connections {
          value: 10000
        }
        max_pending_requests {
          value: 10000
        }
        max_requests {
          value: 10000
        }
        max_retries {
          value: 10000
        }
      }
      thresholds {
        max_connections {
          value: 10000
        }
        max_pending_requests {
          value: 10000
        }
        max_requests {
          value: 10000
        }
        max_retries {
          value: 10000
        }
      }
    }
    tls_context {
      common_tls_context {
        tls_certificates {
          certificate_chain {
            filename: "/secrets_aliases/service2service.crt"
          }
          private_key {
            filename: "/secrets_aliases/service2service.key"
          }
        }
        validation_context {
          trusted_ca {
            filename: "/secrets_aliases/service2service.ca.pem"
          }
          verify_subject_alt_name: "upstream.global.square"
        }
        alpn_protocols: "h2"
        alpn_protocols: "http/1.1"
      }
    }
    http2_protocol_options {
    }
    lb_subset_config {
      subset_selectors {
        keys: "multienv"
      }
      subset_selectors {
        keys: "label"
      }
      subset_selectors {
        keys: "sjc1"
      }
      locality_weight_aware: true
    }
    common_lb_config {
      healthy_panic_threshold {
      }
      locality_weighted_lb_config {
      }
    }
    upstream_connection_options {
      tcp_keepalive {
        keepalive_probes {
          value: 2
        }
        keepalive_time {
          value: 30
        }
        keepalive_interval {
          value: 30
        }
      }
    }
    drain_connections_on_host_removal: true
  }
  last_updated {
    seconds:<PHONE_NUMBER>
    nanos: 249000000
  }
}

The relevant route is this:
routes {
  match {
    prefix: "/"
    headers {
      name: "X-SQ-ENVOY-GNS-LABEL"
      present_match: true
      invert_match: true
    }
  }
  route {
    weighted_clusters {
      clusters {
        name: "upstream--development_vip"
        weight {
        }
      }
      clusters {
        name: "upstream--development"
        weight {
          value: 100
        }
      }
    }
    metadata_match {
      filter_metadata {
        key: "envoy.lb"
        value {
          fields {
            key: "multienv"
            value {
              bool_value: false
            }
          }
        }
      }
    }
    timeout {
      seconds: 900
    }
    retry_policy {
      retry_on: "connect-failure,resource-exhausted,unavailable,retriable-status-codes"
      num_retries {
        value: 4
      }
      retry_priority {
        name: "envoy.retry_priorities.previous_priorities"
        config {
          fields {
            key: "update_frequency"
            value {
              number_value: 2.0
            }
          }
        }
      }
      retry_host_predicate {
        name: "envoy.retry_host_predicates.previous_hosts"
      }
      host_selection_retry_max_attempts: 3
      retriable_status_codes: 429
    }
    max_grpc_timeout {
    }
  }
}

After sending a lot of requests and continually measuring the request ratio between the two hosts, it seems like ~10.2% of requests go to the one and the rest to the other. So this seems to confirm it's a weighting issue. Unfortunately Envoy doesn't have endpoints in /config_dump yet so I can't really confirm that we're not doing stupid with the weights in our control plane (but as mentioned earlier this works if we turn off the update merging)

@mpuncel weights are available in /clusters output.

@mpuncel hmm is it possible to run these tests with h1 (instead of h2)? we've only used subsets + update merging with h1....  wonder if that's somehow related.

Embarrassingly, I realized the last update from me I actually had my breakpoint at a spot where the weights were not even.
I'm now thinking that the only issue here is that my test isn't waiting long enough for the merge to happen. If I add a sleep after making changes before putting requests through it works. Apologies for the false alarm, I really appreciate the quick responses.