text:
Armstrong auto validation test

Choose a PR Template
Switch to "Preview" on this description then select one of the choices below.
Click here to open a PR for a Data Plane API.
Click here to open a PR for a Control Plane (ARM) API.

test1

test2

test3

API TEST ERROR REPORT

Rule
Message

OPERATION_NOT_TEST
message: ServersMigration_CutoverMigration opeartion is not test.opeartion: ServersMigration_CutoverMigrationlocation: /specification/mysql/resource-manager/Microsoft.DBforMySQL/FlexibleServers/preview/2024-06-01-preview/FlexibleServers.json

OPERATION_NOT_TEST
message: Servers_DetachVNet opeartion is not test.opeartion: Servers_DetachVNetlocation: /specification/mysql/resource-manager/Microsoft.DBforMySQL/FlexibleServers/preview/2024-06-01-preview/FlexibleServers.json

Coverage Report

Operation
Tested properties
Total properties
Coverage

All
26
79
32.0%

Servers_ValidateEstimateHighAvailability
1
1
100.0%

Servers_Failover
0
0
100.0%

Servers_Stop
0
0
100.0%

Servers_Create
20
43
46.0%

Servers_List
0
0
100.0%

Servers_ListByResourceGroup
0
0
100.0%

Servers_Update
2
32
6.0%

Servers_ResetGtid
1
1
100.0%

Servers_Delete
0
0
100.0%

Servers_Get
0
0
100.0%

Replicas_ListByServer
0
0
100.0%

Servers_Restart
2
2
100.0%

Servers_Start
0
0
100.0%

test5

/azp run

test

add

test

test

add

add

repo: ms-zhenhua/azure-rest-api-specs


text:
🛑 Do53 Roost IPv4 UDP is down

In de12b5e, Do53 Roost IPv4 UDP (http://107.189.10.142:9202) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Do53 Roost IPv4 UDP is back up in d1a3330 after 9 minutes.

source: gharchive/issue

repo: mschirrmeister/upptime-loopx

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 Do53 Roost IPv6 UDP is down

In 69c9704, Do53 Roost IPv6 UDP (http://107.189.10.142:9204) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Do53 Roost IPv6 UDP is back up in 6b21a72 after 8 minutes.


text:
🛑 Do53 Roost IPv4 TCP is down

In 140ae16, Do53 Roost IPv4 TCP (http://107.189.10.142:9203) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Do53 Roost IPv4 TCP is back up in 18fc071 after 9 minutes.


text:
add tests for Blob

https://github.com/msgpack/msgpack-javascript/issues/109

Codecov Report

Merging #110 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #110   +/-   ##
=======================================
  Coverage   98.46%   98.46%
=======================================
  Files          15       15
  Lines         914      914
  Branches      196      196
=======================================
  Hits          900      900
  Misses         14       14

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 a6a5ddc...3777300. Read the comment docs.

source: gharchive/pull-request

authors: codecov-io gfx

repo: msgpack/msgpack-javascript

license: ISC


text:
Support serving raw assembly bytes

To support an inline assembly code view in the profiler, we should add an "endpoint" / "URL" to request assembly code, or at least the raw bytes so that the front-end can do the disassembly.
JSON format TBD.
/assemblybytes/v1
Input data

The binary's debugName + breakpadId, or alternatively (or maybe additionally) name + codeId
Start address
End address? Or should it be the implementation's problem to find the function at the start address and then return the entire function's code?

For this API to work, we need to have access to the binary. But we do not necessarily need to have symbols for that binary - or at least I'd like this API to work even when we don't have symbols.
This way, for profiles that were captured on this machine, we can always get assembly code without having to fetch anything from anywhere else; we always have the binary because that's what we were recording.
Being able to get assembly without symbols matters for Windows system libraries, and when profiling official Firefox builds. In both cases, the profiler gets the symbols from the Mozilla symbol server. So the symbols are only on the server. But the assembly is not on the server (or at least not yet) - we want to get the assembly from the locally running binary.
Long story short, what this means is that the API request needs to have a precise start and end address. The profiler UI has obtained symbol information from somewhere (possibly us, possibly some public server), and it knows where the function starts and maybe also has a good guess of where it ends. Then it can just request that address range, and the local symbolication API can look up that range in the text section of the binary without having to understand what it's looking at.

I think it would be better to serve the disassembled instructions as strings. I.e. do the disassembly on the server side, not in the front-end. This would place less of a burden on the front-end, and it would make it easier to integrate it with symbolication information (if that information is available). For example, call instructions could have the destination function name instead of a raw address.
Example JSON result:
{
  "startAddress": "0x1234abcd",
  "size": "0x345",
  "instructions": [
    [0, "sub sp, sp, #0x20"],
    [4, "stp x29, x30, [sp, #0x10]"],
    [12, "add x29, sp, #0x10"],
    [22, "adr x1, $+0x63028"]
  ]
}

This was implemented in samply-api and was picked up with the update in 97e9a6ad2ed7024cecf8bde66c73fc5b837c9ec1.

repo: mstange/profiler-get-symbols


text:
insert script for table ockovaci_misto

closes #1

až bude zamergován #12, tak to přidám do db_data.sql

až bude zamergován #12, tak to přidám do db_data.sql

repo: msusicky/ockovani-covid


text:
v0.33.1 breaks Remix applications using polyfills in NodeJs

After upgrading from msw v2.4.3 to  v2.4.4 our remix apps using MSW started failing with no data being returned from remix loaders.
I then narrowed it down to a change in @mswjs/interceptors from v0.33.0 to v0.33.1
I am not sure exactly what the issue is, but after comparing the changes, I have been able to stop the regression by removing a call to recordRawFetchHeaders

This was added here: https://github.com/mswjs/interceptors/commit/4660558f27e610063ff204ccf4a7595082040a0b#diff-58118abd89f14c6d555b9972de91edd6eeca4ccb3bd73ce0724bc9af9d595281
I have narrowed this down further to us using Remix’s installGlobals in our vite config - we can’t use the node build-in fetch in our case because we need to use the host header

I have attempted to replace using installGlobals by adding undici and directly importing their fetch implementation
Do you think the issue might be with them?

Some more digging, If I go into the remix code which enables specific polyfills they replace global.Headers in Node with this: https://github.com/remix-run/web-std-io/blob/main/packages/fetch/src/headers.js

Hi. Thanks for reporting this.
I believe this has been addressed. Could you please update to the latest version of the package and let me know?

It was actually the bump up to MSW v2.4.9 which showed the issue, but I narrowed down the issue to starting with v2.4.4
I just forced  @mswjs/interceptors to 0.36.0 (using msw  v2.4.9 ) with yarn resolutions but the issue persists.

Gotcha. Then it's a new issue. Could you please provide a reproduction repo for me to see it happening? You can fork our Remix example and start from there. Feel free to update the MSW/Remix versions to suit your scenario. Would be happy to look into it then. Thanks.

I couldn’t get the remix example working in code sandbox at all (skill issue I’m sure) but I ended up pulling out bits of it into an install of the latest remix and have a reproduction: https://github.com/MattyBalaam/msw-remix-issue
What I have realised is that this is only an issue if I use installGlobals();in the vite.config.ts to polyfill the fetch implementation. In my case unfortunately I need to do this because the app accesses some APIs which specificially require a custom HOST header, and the native fetch does not allow this for security reasons.
What seems to happen is that in the polyfill version if I log out into the JS with 	{JSON.stringify(loaderData)} the result is:
"{\"serverSideData\":{\"firstName\":\"John\",\"lastName\":\"Maverick\"},\"test\":\"Hello\"}"
But without the polyfill enabled it is:
{"serverSideData":{"firstName":"John","lastName":"Maverick"},"test":"Hello"}

Testing remix app have an issue. The headers in the response are empty
Response {
  size: 0,
  [Symbol(Body internals)]: {
    body: null,
    type: null,
    size: 0,
    boundary: null,
    disturbed: false,
    error: null
  },
  [Symbol(Response internals)]: {
    url: undefined,
    status: 302,
    statusText: '',
    headers: {},
    counter: 0,
    highWaterMark: undefined
  }
}

Reverting to
  "resolutions": {
    "@mswjs/interceptors": "0.33.0"
  }

helps with the headers
Response {
  size: 0,
  [Symbol(Body internals)]: {
    body: null,
    type: null,
    size: 0,
    boundary: null,
    disturbed: false,
    error: null
  },
  [Symbol(Response internals)]: {
    url: undefined,
    status: 302,
    statusText: '',
    headers: { location: 'weekly' },
    counter: 0,
    highWaterMark: undefined
  }
}

authors: MattyBalaam PilatP kettanaito

repo: mswjs/interceptors


text:
arm64 builds hangs on install-info a lot

Just so we have an issue to link to and discuss maybe

I believe this is a bug in cygwin/msys2-runtime, because it also happened with pacman frequently when it would verify sync db signatures.  The workaround I had for that was to append DatabaseNever to SigLevel.  I didn't know about the ability to so easily override hooks like that.  I was contemplating doing what I would have done with dpkg, dpkg-diverting /usr/bin/install-info.exe and replacing it with true.exe, but I was concerned that would break the pacman -Qkq check.
I could add this hack to my setup script instead, like the other one, since it is just a hack...

I wonder whether this is still the case for v3.4.*...

Me and the GIMP project also have also seen this. There's a comment lost in a Merge Request (Gitlab) somewhere about it. They decided to stop pacman update as part of the builds and the runners are now doing this on a scheduled task with timeout/retry :(

I wonder if it might possibly be https://cygwin.com/pipermail/cygwin/2024-February/255431.html.  Maybe we can try backporting that patch and see if the issues go away?

If anyone else wants to try, I built msys2-runtime and msys2-runtime-3.3 with that patch applied in https://github.com/jeremyd2019/MSYS2-packages/actions/runs/7921543265.  I am planning to try some things with it and see what happens.

https://github.com/jeremyd2019/MSYS2-packages/actions/runs/7924206550 is at least not as immediately broken :wink:.  Will test that

I built both 3.4 and 3.3, and 3.3 for 32-bit (which took some doing because any binutils later than 2.40 resulted in a broken msys-2.0.dll).  I then set both a Windows 11 VM on the Dev Kit and a Windows 10 install on a Raspberry Pi 4 in a loop running pacman (without disabling db signature checking).  The raspberry pi did hang up, but the debugger looks different than I remember.  The dev kit vm is still going at last check.

I think the 32-bit on the raspberry pi hung up in pinfo::release calling CloseHandle.  Not entirely sure which handle.  I'd probably try getting a debug build next, but not sure I care that much about 32-bit (just that I remembered the raspberry pi having hang issues more frequently so wanted to test it too)

Looking back at the cygwin thread, it seems that patch was introduced after a report of a hang with 100% CPU usage, rather than the hang with 0 CPU usage that we see, so I'm not sure it's the same issue.  I guess I'll keep looking into the pinfo::release hang I see on the raspberry pi as I have time.

With debug build it hung up somewhere different, but doesn't make any more sense.  This time it hung up apparently during process teardown, having called _exit(0), eventually getting to proc_terminate, and is hanging calling TerminateThread on what seems to be a valid handle to a thread.  I don't see that thread currently running in the debugger though.  I don't see any reason why TerminateThread should hang.

The 64-bit msys2 on windows 11 did eventually hang too ☹  looking at some of the other messages in the thread I wasn't too positive about that being the issue we were seeing.

I finally have some good news. While I am not even close to a fix, I have a work-around: https://github.com/msys2/MSYS2-packages/pull/4583
Here is a run of Git for Windows' sync job that tries to update, commit & push the git-sdk-arm64 repository. Previously it consistently ran into those hangs, and replacing the pacman.exe built in that PR works around those hangs.
By manually observing the hangs (RDPing into those self-hosted runners) I figured out that there were typically around half a dozen hanging processes whose command-lines were identical to their respective parent processes' command-lines. I've tracked that down to libgpgme's _gpgme_io_spawn() function, which calls a fork() that is immediately followed by another fork() in its child process. GPGME's source code history calls this a "double-fork", and it is not really clear to me why this would be needed.
One thing that helped me tremendously while debugging this was the insight that calling that PowerShell script that runs pacman several times (to do both core and system update, followed by another pacman invocation to allow for Git for Windows' hack that is the post-install script of the git-extra package) works when run in a PowerShell window, but consistently hangs when being run in an SSH session. Or, for that matter, a VS Code terminal (which I ran, for convenience, via a VS Code tunnel).
So these are my thoughts how to proceed from here:

Deploying https://github.com/msys2/MSYS2-packages/pull/4583 should work around those Windows/ARM64 hangs.
We still need to dig into this a bit further, to actually understand what is going wrong.
It might be a Windows bug (or the promised Windows update might be just another work-around), we will see...
The work-around I propose points to the double-fork in GPGME as triggering the issue. It won't be trivial, and it will take time, but I am confident, at least, that this can be turned into a small and simple reproducer.
My hunch is that it is not a Windows bug, but that the pseudo terminal/pseudo console code in the MSYS2 runtime that runs every time a new process is forked is still not race-free.
There are other issues in this area of the MSYS2 runtime that might be related, and need to be addressed even if they are not related. For example, @tyan0 said that crashing sub-processes would likely lead to hangs, too.

In that case, I wonder if there's a race between starting up the wait thread and shutting it down during process exit.  Assuming the second fork is followed by an exec in the (grand)child, that could further complicate things because I think that there is some magic that shuffles around the process tree to try to make it look as though exec actually replaced the process instead of starting a new one.  (I think that may even be involved in the wait thread).
As for a Windows bug, I couldn't see any good reason for TerminateThread to block.  I was a little concerned that maybe terminating a thread could leave the emulation in a bad state.

I've tracked that down to libgpgme's _gpgme_io_spawn() function, which calls a fork() that is immediately followed by another fork() in its child process. GPGME's source code history calls this a "double-fork", and it is not really clear to me why this would be needed.

I read the code, and I think I understand what it is trying to do.  It has this comment:
/* Intermediate child to prevent zombie processes.  */

As I recall, there is a "rule" on *nix that a parent must wait on a child process (or ignore SIGCHLD), or the child will be kept around in the process tables (as a "zombie").  This code seems to not want to wait for the child, and as a library doesn't want to mess with global state like signal handlers.  The intermediate process exits as soon as it forks the child that will exec, so is absolved from having to wait for the child, and the parent process waits on the intermediate process allowing it to be reaped.

@jeremyd2019 I think you’re 100% correct, and TIL: http://stackoverflow.com/questions/10932592/why-fork-twice/16655124#16655124

@jeremyd2019 I believe you’re 100% correct, and TIL: http://stackoverflow.com/questions/10932592/why-fork-twice/16655124#16655124
And I think it’s exactly the reason why it un-hangs if I manually kill the “right” pacman process (the intermediate child apparently).
Hope this information helps in diagnosing the root cause.

Another wrinkle is that Windows doesn't have a concept of exec like on posix/unix, so Cygwin has to do some funky tricks to spawn a new process but make the posix APIs it provides act as though it is still the same process that had called exec.  My personal inkling is that there is a race between that and the teardown of the intermediate child, which is what the execed process is trying to make its parent at the very same time that process is trying to exit.

Well that didn't take long:
#include <stdio.h>
#include <sys/wait.h>
#include <unistd.h>

#ifndef BINARY
#define BINARY "/bin/sleep"
#endif

#ifndef ARG
#define ARG "0.1"
#endif

int main(int argc, char ** argv)
{
    while (1)
    {
        int pid;
        printf("Starting group of 100x " BINARY " " ARG "\n");
        for (int i = 0; i < 100; ++i)
        {
            pid = fork();
            if (pid == -1)
            {
                perror("fork error");
                return 1;
            }
            else if (pid == 0)
            {
                if ((pid = fork()) == 0)
                {
                    char * const args[] = {BINARY, ARG, NULL};
                    execv(BINARY, args);
                    perror("execv failed");
                    _exit(5);
                }
                if (pid == -1)
                    _exit(1);
                else
                    _exit(0);
            }
            else
            {
                int status;
                if (waitpid(pid, &status, 0) == -1)
                {
                    perror("waitpid error");
                    return 2;
                }
                else if (status != 0)
                {
                    fprintf(stderr, "subprocess exited non-zero: %d\n", status);
                    return WEXITSTATUS(status);
                }
            }
        }
    }
    return 0;
}

built that with gcc -DBINARY=\"/bin/true\" -ggdb -o testfork testfork.c and it hung up after 11 lines of the "group of 100x" output.

On the raspberry pi/windows 10 at least, this seems to hang pretty reliably after 11 lines, with either /bin/true or /bin/sleep (leaving 0.1 as the arg).  I still can't get gdb to do anything useful, I'm thinking set detach-on-fork off doesn't work on cygwin.

@jeremyd2019! This is fantastic news! Excellent work. How about contributing this reproducer to the Cygwin (or cygwin-developers) mailing list?

To the surprise of probably nobody, in my experiments this reproducer does not reproduce on my x86_64 machine, neither with MSYS2 nor with Cygwin.

@jeremyd2019! This is fantastic news! Excellent work. How about contributing this reproducer to the Cygwin (or cygwin-developers) mailing list?

https://cygwin.com/pipermail/cygwin-developers/2024-May/012694.html

Another wrinkle is that Windows doesn't have a concept of exec like on posix/unix, so Cygwin has to do some funky tricks to spawn a new process but make the posix APIs it provides act as though it is still the same process that had called exec. My personal inkling is that there is a race between that and the teardown of the intermediate child, which is what the execed process is trying to make its parent at the very same time that process is trying to exit.

Hmm, I was looking at the cygwin/msys2-runtime code for something else, and came across this comment:

FIXME: Is there a race here if we run this while another thread is attempting
to exec()?

Don't know, but LOL anyway

I'm really sorry to add a noobish question, but I have been following this with interest  - as I have observed that the same behaviour seems to be exhibited when working with msys2/pacman via an x64 Windows instance during a docker build (hangs with Pacman).
Given the amazing digging you've done here, and the nature of working with Windows containers/docker build it seems possible that there are similar issues with races on the process forks/zombie processes on arm64 that you folks identify here. I have seen it during a docker build on Windows Server Core 2022.
The workaround in my case is just to tell mys2-runtime and pacman not to auto-update/run on an ridk install: https://github.com/gocd-contrib/gocd-oss-cookbooks/blob/00c499cfffe6ae3daf0e625a1a61140b18a11a6a/provision/provision-install-packages.ps1#L60-L69
Thought I might add that in case you're looking to find a case where even x64 can exhibit similar problems. I've no idea if https://github.com/msys2/MSYS2-packages/pull/4583 would also address that, but that it might be worth adding to the mix. If it's unnecessary FUD, please ignore me :-)

@chadlwilson I guess one way to find out is see if the reproducer produces similar results in container?

@chadlwilson I guess one way to find out is see if the reproducer produces similar results in container?

Yeah, fair comment. Unfortunately I don't have a super easy way to do so as don't have an x64 machine so have to do so via GHA or similar which I haven't got around to yet.

The new 24h2 version of Windows 11 introduces a new x64 emulation engine for arm64 called Prism. I wonder if that would solve any of the hangs we've been seeing on x64-emulated processes like pacman and other tools...

Not though that Prism isn’t really “new” but it does drop some old ARMv8.0 support code. Also, @dscho has mentioned before that it might have been fixed in later builds of 24H2, though it might not be related to “Prism”.

The new 24h2 version of Windows 11 introduces a new x64 emulation engine for arm64 called Prism. I wonder if that would solve any of the hangs we've been seeing on x64-emulated processes like pacman and other tools...

I bring bad news 😞 . My Surface Laptop Copilot+ PC arrived yesterday, and that comes with Windows 11 24H2. Today I started local dev stuff with MSYS2 and I already saw the pacman freeze twice.

I bring bad news 😞 . My Surface Laptop Copilot+ PC arrived yesterday,

Good news 🙂 you can now debug the issue yourself (if possible).

I bring bad news 😞 . My Surface Laptop Copilot+ PC arrived yesterday,

Good news 🙂 you can now debug the issue yourself (if possible).

I could before lol. I have had a Snapdragon 8cx (Gen 1 then Gen 3) laptops since 2019. The issue is that I don't know how. If it was Visual Studio I could probably help

I bring bad news 😞 . My Surface Laptop Copilot+ PC arrived yesterday,

Good news 🙂 you can now debug the issue yourself (if possible).

To bring my latest theory to this thread: I believe the issue happening around the tearing down of the wait thread circa https://github.com/msys2/msys2-runtime/blob/28d69fba269dd4a9f4281f8af7c2775292241e8b/winsup/cygwin/sigproc.cc#L412-L413.  My latest concern I ran into is that because the chld_procs array gets re-arranged when a child is removed, there is no way for the thread itself to keep a valid pointer to NULL out the wait_thread, like it apparently thinks its doing on https://github.com/msys2/msys2-runtime/blob/28d69fba269dd4a9f4281f8af7c2775292241e8b/winsup/cygwin/pinfo.cc#L1330 but is actually only NULLing out a stack variable copy which it made at the beginning of the thread because it was known that the original pointer may not remain valid.  I don't know how to work around this.  Have a function that locks and iterates all of chld_procs comparing wait_thread pointers and NULLing out any that match the one shutting down?  Might that deadlock somehow?  Who knows, this code is complicated, and at this point I'm just blindly trying things and seeing what happens :grin:.  But I haven't had time to even do that lately

Hi folks. I am not well versed in the inner workings of Cygwin but I do know quite well how the emulator works, so I am here to help in as much capacity as I can.
I am told Cygwin does not use RtlCloneUserProcess, but I compiled and ran the test code (as well as pacman) and looked at the state of the hung child and I am seeing something that is not much different than what RtlCloneUserProcess does.
The child process contains a number of threads (on of which named "sig") and they are all blocked on the emulator's code-cache lock. There is no thread in this process owning the lock. This is what creates the deadlock.
As I mentioned, I don't have any insight on how Cygwin implements fork, but the result suggests that the thread owning the emulator lock hasn't (yet?) been migrated over and, without it, nothing can make forward progress in emulation.
This also explains the time-sensitive nature of this problem. Closer to process startup there is more just-in-time translation going on. This lock is only held when code is being modified. If you fork later, you are less likely to have JIT happening on the source process then when you have fork happening on a fresh process. Just-in-time compilation will also be slower on slower machines, such as on a raspberry Pi, than on a DevKit, augmenting the chance fork happens while parts of JIT are still happening on other threads.
For the Cygwin/fork experts in this thread, does what I just said ring a bell?

For the Cygwin/fork experts in this thread, does what I just said ring a bell?

You may need to try asking in cygwin@cygwin.com mailing list, I don't know if any cygwin fork experts are present here.  https://cygwin.com/pipermail/cygwin/2024-July/256271.html is the latest in my thread there, IIRC

The child process contains a number of threads (on of which named "sig") and they are all blocked on the emulator's code-cache lock. There is no thread in this process owning the lock. This is what creates the deadlock.

This sounds highly plausible to me.

Closer to process startup there is more just-in-time translation going on. This lock is only held when code is being modified. If you fork later, you are less likely to have JIT happening on the source process then when you have fork happening on a fresh process.

That is quite an interesting aspect. Now the question is only: would this lock be lifted automatically if the thread lived just a little longer? And maybe the problem is that the Cygwin process exits before those threads could all be joined, assuming that it can rely on exit() to "clean up" the threads?
I wonder whether we can detect that situation in the Cygwin/MSYS2 runtime somewhere close to where the thread is terminating, or maybe this can be done in the emulator just before the thread ends?
Also: would you have any hints how this could be debugged by someone like me, @pmsjt? Maybe some WinDbg wizardry?

I wonder whether we can detect that situation in the Cygwin/MSYS2 runtime somewhere close to where the thread is terminating

This might actually be precisely what the suggested CancelSynchronousIo() call in https://inbox.sourceware.org/cygwin-developers/23f23b0a-e60e-e3ff-4c1e-295599fdc813@jdrake.com/ accomplishes. What do you think @pmsjt ?

I haven't seen anyone bring this up on the cygwin mailing list yet.  @pmsjt I have a couple of questions.  1) how can I tell in a debugger (say, windbg) the state of this lock? 2) is there some way for cygwin code to acquire this lock during fork?  (basically, is it exposed to 'user' code?) That way it could be sure that no other thread owns it.  Note that cygwin is not afraid of doing some pretty questionable hacks to get access to internal variables, so maybe it could disassemble some function to find it 😝

Even if this lock was publicly exposed (which isn't for legitimate reasons), grabbing it from x86-64 code, which is running under the emulator, would just result in a deadlock as the emulator tried to grab the lock to emulate more code.
Ideally, Cygwin would just port to Arm64 so we don't have to deal with this. In absence to this, having the core of the fork code be written in Arm64EC could achieve the goal in a much simpler way. Such code would not be running under the debugger so it can, with reasonable confidence, make forward progress without a dependency on the emulator, its minion background threads and their associated locks.

@pmsjt I couldn’t help but notice some discontent with Cygwin in your recent Twitter posts, and I’m sure you have a legit reason for that. I would like however to kindly ask you to share your findings with the Cygwin mailing list so this could finally be fixed after so many years of back and forth. Pretty please 🙏

Sounds good. Note that the recent comments are for a completely different issue. It has to do with fast_cwd which has been a source of pain for many years, irrespective of emulation.

Darn, I had hoped for some short-term (possibly hacky) workaround.  Getting the gcc toolchain up to snuff and deployed to the point that cygwin could even potentially compile to arm64/arm64ec may be a medium-term milestone, and actual support for all of cygwin being able to be compiled as arm64 is a pretty long-term goal in my view.
Something as hacky as some code that roots around in memory to find and acquire a lock to keep the emulator at bay long enough to complete the fork, even if that code has to be built with clang/llvm separately.
I am kind of interested if RtlCloneUserProcess could reasonably be used in cygwin's fork implementation, with the idea that it would be native arm64 code that would have access to all the necessary internal locking knowledge.

Something as hacky as some code that roots around in memory to find and acquire a lock to keep the emulator at bay long enough to complete the fork, even if that code has to be built with clang/llvm separately.

Well, while the emulator is "at bay", no x86-64 can be assumed to run. If a portion of the code necessary to achieve forward progress is in x86-64, then we have a deadlock.
So, today, is Cygwin strictly compiled (compilable) with GCC? I wonder if there is any chance we can compile successfully just some portions with CLANG, as Arm64EC, as a prototype for this.
RtlCloneUserProcess only clones one thread which is probably the reason the Cygwin authors/maintainers decided to put together something different - an attempt to migrate over the entire state from one process to the next.

So, today, is Cygwin strictly compiled (compilable) with GCC? I wonder if there is any chance we can compile successfully just some portions with CLANG, as Arm64EC, as a prototype for this.

Basically no. Cygwin relies on multiple hacks for DLLs that are done via linker scripts which aren't and won't be supported by LLD COFF backend.

As a hack/proof-of-concept though, a normal native (non-cygwin) dll can be loaded by cygwin though.

But ultimately what can arm64ec code do here, if the lock in question is not exposed (either directly or via functions)?

SuspendThread has this capacity to boot threads outside of simulation before suspending, which can be synchronized via GetThreadContext.
There is potentially a way where the parent makes sure all threads are quiesced (suspended and synchronized) it, itself, exits emulation into EC code and the remaining portion is performed.
I think this would mitigate the problem despite the fact I am not sure if it would solve it entirely.
I am looking at the description of [1] and it seems like even Cygwin's implementation carries-over just one thread. Am I reading this right? If that is the case, then we still have the problem of an emulator worker thread, not in emulation, holding the lock.
This puzzles me. If Cygwin is only carrying-over one thread, then why not use RtlCloneUserProcess? I am sure there was another legitimate reason for it - I just can't see it a.t.m.
[1]
https://cygwin.com/faq.html#faq.api.fork

I am looking at the description of [1] and it seems like even Cygwin's implementation carries-over just one thread. Am I reading this right? If that is the case, then we still have the problem of an emulator worker thread, not in emulation, holding the lock.
This puzzles me. If Cygwin is only carrying-over one thread, then why not use RtlCloneUserProcess? I am sure there was another legitimate reason for it - I just can't see it a.t.m.
[1] https://cygwin.com/faq.html#faq.api.fork

I'm guessing Cygwin's implementation pre-dates the existence of RtlCloneUserProcess.  I mean, there were versions of Cygwin that ran on Win 9x.  Once they had something that "worked", they probably preferred to make tweaks to keep that method working rather than replacing it with something else that might have its own different quirks.

To be fair RtlCloneUserProcess doesn't presently work on emulated processes but that would be potentially a simpler thing to fix than through Cygwin's own code, especially if all of it is x86-64.

The question that has been rattling around in my head is, how does Cygwin make sure no other thread holds the loader lock during fork?

I had a kind of epiphany, perhaps.  We've been concentrating on the technical complexities of the fork emulation mechanism, but what if it's simpler than that?  When I debugged this issue (as best I could) it almost always seemed to come back to a TerminateThread call.  In the cases where it wasn't stuck in the TerminateThread call itself, it wasn't far away either.  I wondered, is there a similar capacity for TerminateThread to "boot threads outside of emulation" before terminating?  I'm guessing not, and that what may be happening is something I suspected early on: TerminateThread is leaving emulation in a bad state, namely leaving this "code-cache lock" owned.
I think I'm going to try throwing in a SuspendThread call before TerminateThread to see what happens, hopefully this makes sure the thread is not holding the lock before it's terminated.

Darn, doesn't seem to have done anything ☹

Yeah, I would not expect that to do anything. Threads are not in simulation when they exit as it is.

I'm trying both SuspendThread and GetThreadContext (https://github.com/jeremyd2019/msys2-runtime/commit/45a7988112372f53498456ae5713041e98aae826), and that seems to be working better.  We'll see what happens.

Found this [1] regarding previous attempts to use RtlCloneUserProcess.
[1]
https://inbox.sourceware.org/cygwin/20180122114925.GT18814@calimero.vinschen.de/

Oh, the code was cross-terminating threads, not self-terminating. Yeah, that can be a bit dicey. Who knows what a thread might be doing when it is being terminated.
Just a small nitpick. You should always initialize Context.ContextFlags to something valid, like ContextControl. Failure to do so may result in stack corruption if the uninitialized combination of flags ends up being valid (by chance) and indicative od extended context (which would cause the syscall to write more than just sizeof(CONTEXT) worth of data.

I've got a run going now with yield (aka Sleep(0)) instead of GetThreadContext: https://github.com/jeremyd2019/msys2-runtime/commit/c65ed8146e923b77ef3677abd3c425e583944749.  Hasn't hung immediately like with nothing between SuspendThread and TerminateThread

I've got a run going now with yield (aka Sleep(0)) instead of GetThreadContext

That's probably not what you're trying to achieve though:
https://devblogs.microsoft.com/oldnewthing/20150205-00/?p=44743

Yeah, seems I do need GetThreadContext for the synchronization side-effect.  The yield does seem to  be working though, but probably less reliably than GetThreadContext would.

Yep, that's pretty much the last two paragraphs:

If you want to make sure the thread really is suspended, you need to perform a synchronous operation that is dependent on the fact that the thread is suspended. This forces the suspend request to be processed since it is a prerequisite for your operation, and since your operation is synchronous, you know that by the time it returns, the suspend has definitely occurred.
The traditional way of doing this is to call GetThreadContext, since this requires the kernel to read from the context of the suspended thread, which has as a prerequisite that the context be saved in the first place, which has as a prerequisite that the thread be suspended.

The issue with Sleep is that it doesn't guarantee that the scheduler will process the suspension request before it gets back to your calling thread.

Thanks.  I thought I was just hacking around blindly trying to find something that helped, and here I'm getting code reviews and everything :grin:.  I'm going to test https://github.com/jeremyd2019/msys2-runtime/commit/7863965c5c806fcdae21c76641e17e33c762cd91 for a while, and if that works I'm going to try submitting https://github.com/jeremyd2019/msys2-runtime/commit/85976656422526e3aa6e4a6444f4f4ce84dccdc1 to cygwin-patches@cygwin.com and see what they say.

@jeremyd2019 great work! May I suggest to expand the commit message a bit, though? Something like this:
cygthread: suspend thread before terminating.

This addresses an extremely difficult to debug deadlock when running
under emulation on ARM64.

A relatively easy way to trigger this bug is to call `fork()`, then within the
child process immediately call another `fork()` and then `exit()` the
intermediate process.

It would seem that there is a "code emulation" lock on the wait thread at
this stage, and if the thread is terminated too early, that lock still exists
albeit without a thread, and nothing moves forward.

It seems that a `SuspendThread()` combined with a `GetThreadContext()`
(to force the thread to _actually_ be suspended, for more details see
https://devblogs.microsoft.com/oldnewthing/20150205-00/?p=44743)
makes sure the thread is "booted" from emulation before it is suspended.  Hopefully this means it won't be holding any
locks or otherwise leave emulation in a bad state when the thread is
terminated.

Also, attempt to use CancelSynchonousIo (as seen in flock.cc) to avoid
the need for TerminateThread altogether.  This doesn't always work,
however, so was not a complete fix for the deadlock issue.

Addresses: https://cygwin.com/pipermail/cygwin-developers/2024-May/012694.html
Signed-off-by: Jeremy Drake <cygwin@jdrake.com>

https://cygwin.com/pipermail/cygwin-patches/2024q4/012886.html

https://cygwin.com/pipermail/cygwin-patches/2024q4/012886.html

Thank you! I have a bias toward what I consider a nicer UI at https://inbox.sourceware.org/cygwin-patches/2c68d6fe-5493-b7e0-6335-de5a68d3cd3f@jdrake.com/T/#u, maybe you like that one, too?

this patch applies cleanly to 3.3 as well, so I've got it built for i686 and running my reproducer on win10/raspberry pi 4 since that seemed to be a very good machine to reproduce the hang on (along with the qc710, which I have used for the prior tests for this patch and is still going)

I can help test too. What should I download and do? In my arm64 pacman locks a lot.

test x86_64 binaries can be found:

for upstream msys2: https://github.com/jeremyd2019/msys2-runtime/actions/runs/11806806336/artifacts/2179071260
for git for windows fork of msys2: https://github.com/git-for-windows/msys2-runtime/actions/runs/11805927624/artifacts/2178808019

in these zips, I just extract the usr/bin/msys-2.0.dll and replace (after backing up!) the one in msys2.

Nicely done @jeremyd2019 . Yes, the whole point with my original suggestion with Suspend + GetContext was so you can make sure exit from simulation is complete. Sleep/Yield would not give you that or any other API.
I'll pull these and give it a go too. This issue usually reproduces almost instantaneously on my Qualcomm 8380 machine. Thanks for sharing the engineering privates with the fix.

This test seems to be holding up
#include <stdio.h>
#include <sys/wait.h>
#include <unistd.h>

#ifndef BINARY
#define BINARY "/bin/true"
#endif

#ifndef ARG
#define ARG "0.1"
#endif

int main(int argc, char ** argv)
{
	while (1)
	{
		int pid;
		printf("Starting group of 100x " BINARY " " ARG "\n");
		for (int i = 0; i < 100; ++i)
		{
			pid = fork();
			if (pid == -1)
			{
				perror("fork error");
				return 1;
			}
			else if (pid == 0)
			{
				if ((pid = fork()) == 0)
				{
					char * const args[] = {BINARY, ARG, NULL};
					execv(BINARY, args);
					perror("execv failed");
					_exit(5);
				}
				if (pid == -1)
				{
					perror("inner fork error");
					_exit(1);
				}
				else
				{
					_exit(0);
				}
			}
			else
			{
				int status;
				if (waitpid(pid, &status, 0) == -1)
				{
					perror("waitpid error");
					return 2;
				}
				else if (status != 0)
				{
					fprintf(stderr, "subprocess exited non-zero: %d\n", status);
					return WEXITSTATUS(status);
				}
			}
		}
	}
	return 0;
}

This does suggest a change that I could potentially do to the emulator to protect to cases such as this: A change to always exit simulation before completing cross-thread termination.

msys2/msys2-runtime#234 (and msys2/msys2-runtime#235 for good measure)

I ran my fork reproducer for over 12 hours, 4x instances on the QC710 running x86_64/msys2-runtime-3.5.4, and 2x instances on the Raspberry Pi 4 8GB running i686/msys2-runtime-3.3.6, and all instances are still going without deadlocks or crashes.

 🕙

Amazing, terrific work everyone! ❤ Thank you so much for this!

Thank you @jeremyd2019 and everyone!

Well. I just went to update my raspberry pi, which I left running 2x instances for however long it's been, and there was a totally different failure:
    185 [main] forky (536) C:\msys32\home\Administrator\forky.exe: *** fatal error in forked process - CreateFileMapping shared.5, Win32 error 1455.  Terminating.
  14439 [main] forky (536) cygwin_exception::open_stackdumpfile: Dumping stack trace to forky.exe.stackdump
     90 [main] forky 295 dofork: child -1 - forked process 536 died unexpectedly, retry 0, exit code 0xC0000142, errno 11
fork error: Resource temporarily unavailable

The stackdump was empty.
 C:\>net helpmsg 1455

The paging file is too small for this operation to complete.

Phew, maybe the scrollback in Windows Terminal exhausted the page file?

0xC0000142 is  STATUS_DLL_INIT_FAILED and 11 is, among others, ERROR_BAD_FORMAT 🤔
1455 is indeed ERROR_COMMITMENT_LIMIT and it seems to be an ordinary out of memory exception.
Is there maybe a memory leak somewhere? Or does your test app just keep on creating forks without exiting the parent process?

In this case the 11 is the cygwin errno, EAGAIN: Resource temporarily unavailable.  https://gist.github.com/jeremyd2019/3156721497096d0bba00ef19a507f619 does keep creating forks without exiting the parent process...  In any event, I don't think it's an error that needs worrying about

In this case the 11 is the cygwin errno, EAGAIN: Resource temporarily unavailable.  https://gist.github.com/jeremyd2019/3156721497096d0bba00ef19a507f619 does keep creating forks without exiting the parent process...

I would indeed assume a process handle exhaustion in this case 🤔


text:
Allow reusing scoped clients setup in symfony framework bundle

Hi there,
In the symfony framework bundle, you can setup clients like so:
framework:
    http_client:
        default_options:
            timeout: 5

        scoped_clients:
            foo.client:
                base_uri: 'https://foo'

if would then be nice if these are reusable by this bundle:
api_platform_ms:
    name: app
    microservices:
        foo:
           http_client: foo.client
           format: jsonhal

This would be good, as at the moment, this bundle does not allow you to configure all the options available on the http client, while implementing the above would allow it, as you'd just define them in the framework bundle.
for example, if I want to configure a timeout for a particular microservice, which is currently not possible with this bundle.
What do you think?
Thanks!

i see this is possible with https://github.com/mtarld/api-platform-ms-bundle/blob/1.x/src/Resources/doc/tools/http-wrapper.md

Yes, exactly you're right! HTTP wrappers are the way to go IMHO

authors: bendavies mtarld

repo: mtarld/api-platform-ms-bundle


text:
🛑 mtbn.fr is down

In f6eaf17, mtbn.fr (https://mtbn.fr) was down:

HTTP code: 503
Response time: 4710 ms

Resolved: mtbn.fr is back up in 4074fcd.

repo: mtauban/parcelle-uptime


text:
Documentation?

Hello, i don't know how to instantiate the editor...
any example?

:(

repo: mthli/Knife

license_source: bigquery


text:
Please consider providing Unum or Posit arithmetic

In his book, The End of Error, John Gustafson describes a new number format called Unum with many interesting properties.
Since then, Prof. Gustafson has also designed several alternative formats that are worth providing. Please see these links:
http://www.johngustafson.net/unums.html
https://posithub.org/about
https://posithub.org/khub_community
https://users.rust-lang.org/t/create-rust-posit-arithmetic-library-based-on-21-february-2017-posit-arithmetic-by-john-l-gustafson-beating-floating-point-at-its-own-game/10077
This would be a great number format to have available in a Prolog implementation, and a quite unique selling point. In fact, the idea is similar to number formats that were available in previous Prolog implementations and designs (Prolog IV).
I hope that you find these number formats interesting, and consider providing them at some point!

It would be a unique selling point indeed! I remember Willi Riha from the Shen community mentioning unums a while back. Creating a Rust implementation of unums could be a fun project onto itself. Chances are fair that one exists already. I will look into it. Thanks!

Is The End of Error still worth a purchase, or have unums been eclipsed by posits? I can't find much on posits.

To the first question: In my opinion, the book is well worth purchasing, due to the many examples and nice illustrations of floating point issues alone already. It is very nicely done.
As to the other part: I have seen posits being described as "a hardware-friendly version of unums":
https://www.johndcook.com/blog/2018/04/11/anatomy-of-a-posit-number/
I think an important takeaway of this is that ideally, several different number formats can be nicely supported, with rational numbers as a very important application, and unums possibly as a quite unique attraction.

https://www.nextplatform.com/2019/07/08/new-approach-could-sink-floating-point-computation/ gives a good overview.

There is also [softposit[(https://crates.io/crates/softposit) crate to build on.

It surprises me that none of the unum/posit projects I've seen experiment with GPU parallelism. Posits/unums are designed with parallelism in mind, no?

GPU parallelism heavily depends on (absence of) state (like all the tiny flags in IEEE that make switching more cumbersome) - unums remove that state.
Currently it seems that Gustafson explores the design space around unums. Unums were much closer to traditional IEEEs that what posits are

... but in any case, it is probably more promising to first get regular Prolog (including partial lists) and constraints up and running.

I have no idea why https://github.com/triska/scryer-prolog/commit/2889631b61809ed766eb4d668715e6cf38b0630b now shows up in the history of this issue.

authors: UWN XVilka jmlMetaswitch mthom triska

repo: mthom/rusty-wam


text:
🛑 https://db.hcys.ps is down

In 6e83e36, https://db.hcys.ps (https://db.hcys.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://db.hcys.ps is back up in c57a4b5.

repo: mtitservice/site


text:
🛑 https://911.ps is down

In a59e6c6, https://911.ps (https://911.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://911.ps is back up in 1282086.


text:
🛑 https://db.hcys.ps is down

In 833e28e, https://db.hcys.ps (https://db.hcys.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://db.hcys.ps is back up in 7ef5564.


text:
🛑 https://reports.mtit.pna.ps is down

In bf2a876, https://reports.mtit.pna.ps (https://reports.mtit.pna.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://reports.mtit.pna.ps is back up in ea4e2b4.


text:
🛑 https://salfeet.plo.ps is down

In 22e695f, https://salfeet.plo.ps (https://salfeet.plo.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://salfeet.plo.ps is back up in dd692d3.


text:
Add a comprehensive test framework.

Test all the things. This should simply be make check from the command line. Also, investigate code quality checkers and re-formatters.

Fixed by 40dc457f1f1fd9595741815521f4faf4dd73b9f0

repo: mu-editor/Mu-naco


text:
rtcmulticonnection

how set own userid for rtcmulticonnection many to many

Use connection.extra to set all external variables.  https://www.rtcmulticonnection.org/docs/extra/

repo: muaz-khan/RTCMultiConnection

license: mit


text:
Include authorized ssh keys management in user plugin

This commit adds the SSH keys management within user creation.
Part of rancher-sandbox/cOS-toolkit#218

Neat! good addition :+1:

authors: davidcassany mudler

repo: mudler/yip


text:
Add option to shown reminder even when ring volume is not muted

Is your feature request related to a problem? Please describe.
I want to use this app to remind myself when the media volume is not muted regardless of the ring volume.
Describe the solution you'd like
Add an option to ignore the state of the ring volume.
Describe alternatives you've considered
Forking this app, but I don't want to do that.
Additional context
Media is muted most of the time and I only enable it when I want to watch something.

Hello, I'm in the process of doing this feature :)

@yoobi Can you check the code of my app https://github.com/mueller-ma/Coffee/ before and implement the PreferenceActivity and Prefs.kt similar here?

Sure, you can assign me #25 as well

Also the repo doesn't have the label Hacktoberfest :)

Also the repo doesn't have the label Hacktoberfest :)

I added the label.

authors: TheDcoder mueller-ma yoobi

repo: mueller-ma/MuteReminder


text:
EVCC ValueError: too many values to unpack (expected 2)when parsing load points from MQTT

I'm trying to run BatControl with the EVCC connection:
Config is:
evcc:
  enabled: true
  broker: localhost
  port: 1883
  status_topic: evcc/status
  loadpoint_topic:
    - evcc/loadpoints/1/charging
    - evcc/loadpoints/2/charging
  tls: false

EVCC data in MQTT looks good to me:

But something seems to be wrong with parsing the load points data.
I'm getting the error:
ValueError: too many values to unpack (expected 2)

Any ideas?
I'm using the latest docker image for BatControl.

Latest is the last release and does support only one loadpoint.
the multiple loadpoint version is not released yet. I can build an intermediate testing image on the current development branch „main“.

Try using tag „main“ instead of latest. This was just built and is like a snapshot build. That should work.

Thanks, the main docker tag works! Very promising project.

repo: muexxl/batcontrol


text:
[Select] Consistency with Autocomplete

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡

Equivalent to react-select's isSearchable={false}.
Disables the search functionality, but is still consistently styled.
Examples 🌈

Motivation 🔦
Having consistent styling of searchable and non-searchable selects is a requirement we're currently facing.
This workaround works: https://codesandbox.io/s/material-demo-ok1kg, but it's not exactly pretty.

EDIT:
Updated workaround with readOnly prop on input suggested by @cooperjones: https://codesandbox.io/s/material-demo-vh5lx

@skoging What's the incentive for using the Autocomplete instead of the Select component if you disable the textbox? I mean, I believe both component styles are very close, what do you miss?

I am also implementing both searchable and non-searchable selects and am running into a similar issue making them consistent (I'm attempting to use the Select component for non-searchable selects). A big difference between the AutoComplete and Select components is the positioning method for the listbox. The Select component uses the Popover component which forces focus and blocks scrolling, while the AutoComplete component uses a Popper which allows scrolling and does not block focus. This leads to differences in the tabbing logic, menu positioning, etc., between the two components. Additionally, the dropdown icon in the AutoComplete component uses an IconButton w/ separate interaction & hover/focus styles whereas the dropdown icon in the Select component uses a non-interactable svg element.
Not sure if this is a workable solution (I haven't had a chance to explore the a11y ramifications or test on less common platforms/browsers), but adding a readOnly attribute to the input element of the AutoComplete component seems to be a pretty good work-around to get a non-searchable combobox. The readOnly attribute maintains the listeners on the text input element (onFocus, onClick, onBlur, etc.) while also preventing any text from being entered.

@cooperjones I think we'll revisit the Select with regards to Popper vs Popover. The current solution has a mobile first approach where the Popover makes more sense. But for a select input on desktop a Popper makes more sense.
Need to do some research though first and see how this is used.

@eps1lon 💯👍 .
@cooperjones Thanks, so to sum-up, we have the following difference:

The Select positioning is different from the Autocomplete.

vs

This can be configured with the Popover placement props to be identical:
<Select
  MenuProps={{
    getContentAnchorEl: null,
    anchorOrigin: {
      vertical: 'bottom',
      horizontal: 'center',
    },
    transformOrigin: {
      vertical: 'top',
      horizontal: 'center',
    },
  }}
>

Actually, I'm even wondering if we shouldn't make it the default, per the latest specification:

The scrolling behavior is different. We have a couple of related issues to this: #17353, #11243 or https://github.com/mui-org/material-ui/issues/17636#issuecomment-536716503. I do think that it's something we should consider as important and at the minimum provide an opt-in prop. Should the capability to scroll be opt-out? Or change based on the platform? This I don't know. It would require some research. So I think that expect unification on this end too.

I think that the difference of interaction with the dropdown icon is justified by the presence/none-presence of a textbox. Is it safe to say that it's a detail, not important?

There is a significant difference in terms of performance. While the Select uses the MenuItem > ListItem > ButtonBase > TouchRipple rendering chain, the Autocomplete uses a li for each option. #17806. I believe the rendering difference is in the order of magnitude, but to be confirmed with a rigorous benchmark. This is the difference between rendering 240 items below 100ms and above. However, we might have another per issue with the autocomplete, I see a forced reflow from the scrollTop = 0 logic:

Thanks for the response to this issue. It's good to see that it has generated a discussion around the differences and inconsistencies between Select and Autocomplete, both when it comes to styling and performance.
I think @cooperjones highlighted the main incentives for using Autocomplete as a Select, and in addition the performance differences mentioned can be very noticable.
With the readOnly workaround being much less hacky, this isn't a particularly high priority issue for us. In my opinion the focus should be on getting the Autocomplete component stable and into core. Then perhaps take look at the future of the Select component, using the lessons and experiences gained implementing the Autocomplete.

So this disables the text input but how do I disable the clear and drop down?

I have added these but It doesn't seem to work for me
  MenuProps={{
    getContentAnchorEl: null,
    anchorOrigin: {
      vertical: 'bottom',
      horizontal: 'center',
    },
    transformOrigin: {
      vertical: 'top',
      horizontal: 'center',
    },
  }}
>````
![1](https://user-images.githubusercontent.com/37615728/99946851-bb376b80-2d7f-11eb-856f-bd360c2d2f69.png)
![2](https://user-images.githubusercontent.com/37615728/99947241-5a5c6300-2d80-11eb-8a91-e6d0d5cc5492.png)

@Nziranziza It's expected, there isn't enough space to display the whole list below the select.

So far, we are waiting for the reimplementation of the Select (e.g. to use Popper over Popover) before closing this issue.

So far, we are waiting for the reimplementation of the Select (e.g. to use Popper over Popover) before closing this issue.

@oliviertassinari is there an issue or PR to keep track of the progress?

No, consider, this issue and all the other open issue as part of the same underlying problem. The Select likely deserves to be rewritten from scratch at this point.

authors: Nziranziza bmulcahy cooperjones danielpza eps1lon oliviertassinari skoging

repo: mui-org/material-ui


text:
[core] Standardize the component injection pattern

I couldn't find a clean way to support the render props pattern.
Doing such would require to greatly reduce the usage of JSX. It will really harm source code readability.
Instead, I have been focusing on standardizing our component injection story.
This way, we can go back to the render props after stable v1 is released and see if source code readability worth be sacrificed for the render prop pattern.
Closes #10476. Might be better to start from a fresh issue in the future.
Breaking change
<TablePagination
- Actions={TablePaginationActionsWrapped}
+ ActionsComponent={TablePaginationActionsWrapped}

<Dialog
- transition={Transition}
+ TransitionComponent={Transition}

<Menu
- transition={Transition}
+ TransitionComponent={Transition}

<Snackbar
- transition={Transition}
+ TransitionComponent={Transition}

<Popover
- transition={Transition}
+ TransitionComponent={Transition}

<StepContent
- transition={Transition}
+ TransitionComponent={Transition}

The only question I have (and I don't have a strong opinion) is whether the first character of the prop should be capitalised or not?

The only question I have (and I don't have a strong opinion) is whether the first character of the prop should be capitalised or not?

This is a compliment to the existing component property, which pertains to the root element.  I feel like these props should follow lowerCamelCase.

If this is the direction to go, the property name should remain capitalized:

to be consistent with cases such as inputProps vs InputProps
stops the destructuring aliasing needed such as

const { transitionComponent: TransitionComponent } = this.props
return <TransitionComponent/>

stops the destructuring aliasing needed such as...

This is a good point.  Maybe we should go further and change component to Component for consistency and to eliminate the destructuring.

@oliviertassinari You left out Snackbar.d.ts :-D
On it now.

authors: franklixuefei kgregory mbrookes oliviertassinari rosskevin


text:
Fixes Uncontrolled dirty check

[x] I have followed (at least) the PR section of the contributing guide.

This fixes #17018 where the label is not being properly moved up to do the input being uncontrolled.
I added a failing test and then reverted a small portion of #16526. (Will wait until it is confirmed on CI that the test is failing before pushing the fix)
Relates to https://github.com/react-hook-form/react-hook-form/issues/220
/cc @oliviertassinari

Working on addressing the other test that is failing now

@eps1lon What do you think of making the initial issue as won't fix? It would effectively mean that we don't support react-hook-form. The motivation would be 1. To keep the InputBase logic as simple as possible. 2. To discourage the usage of third party libraries that don't use React in an idiomatic way.

@stramel Thanks for your time! I'm closing: https://github.com/mui-org/material-ui/pull/17025#issuecomment-523541442.

authors: oliviertassinari stramel


text:
[docs] Added new customized switch examples

[x] I have followed (at least) the PR section of the contributing guide.

Added Android 12 switch and custom icon in thumb example to the docs
Issue: #25919
Fix #25985
Preview: https://deploy-preview-26096--material-ui.netlify.app/components/switches/#customized-switches

Looks great. A couple of suggestions on the iOS Switch.

we should remove the border for the unchecked version
we should make the background darker grey

I will update the iOS Example as well to more closely resemble the "real" iOS switch control.
Another question: I don't know how to fix the remaining failing test. What has to be done to fix it?

I will update the iOS Example as well to more closely resemble the "real" iOS switch control.

Great!

Another question: I don't know how to fix the remaining failing test. What has to be done to fix it?

We will just approve the new screenshot in the end, no need for fixing anything :)

For iOS, see https://github.com/mui-org/material-ui/issues/25985#issuecomment-827083489

I have updated the iOS Switch including proper disabled state. What do you think?
Images:

For reference screenshots from iOS:

I have updated the iOS Switch including proper disabled state. What do you think?

Looks awesome!

I have pushed the effort one step further, mainly by adding the Material-UI Switch (MUI has its own branding which is not to be confused with Material Design).

I have quite struggled to implement this. It took me more time than I had anticipated. @siriwatknp did his share too in https://mui-treasury.com/styles/switch/. @DanielBretzigheimer I wonder how we could simplify the customization of the component. A few thoughts:

the input catches the dev tools inspector, it's such a pain. I doubt we can solve this. One this that would help is to flatten the structure, have the input as a direct children of the root.
the DOM nodes are verbose, e.g. MuiButtonBase-root MuiIconButton-root MuiIconButton-sizeMedium MuiSwitch-switchBase MuiSwitch-colorSecondary PrivateSwitchBase-root Mui-checked css-1eusvr7-MuiButtonBase-root-MuiIconButton-root-MuiSwitch-switchBase). It makes it hard to understand DOM structure. I think that we should at the very least drop the IconButton #21503.
the style of MuiSwitch-thumb has to be moved into two different places simply to apply to leverage the check pseudo-class. Maybe it would be simpler if the thumb had its own pseudo-class. Not sure, because it's mostly disturbing by not being on the root. So I guess that if we move the pseudo-class to the root, we would be good.

I fully agree with you on the input part. Clearing up the DOM Structure seems like a good Idea, using a IconButton was confusing for me.
I will have a look into it and will try to find a better solution. Should I append the changes to this PR or create another one? Also, this will certainly be a breaking change, but this seems to be okay?

@DanielBretzigheimer If you can explore this in another pull-request, it would be awesome. I have linked the two relevant issue in my previous comment. As for this PR, no, it's already larger than it needs to be, no more :).


text:
[docs] Content 3: Field and Text Input demos

https://deploy-preview-903--base-ui.netlify.app/new/components/field

@vladmoroz

The input is 42px tall but other buttons/controls are 40px. Heights should be consistent across components. I would use height rather than padding to achieve this.
The input hint seems too far from the input. It also seems odd to me that the label and hint are not equidistant from the input.

authors: colmtuite vladmoroz

repo: mui/base-ui


text:
Scannable Card Collection

A collection of cards placed in a consistent pattern. See examples in Material Design.

[x] This is not a v0.x issue.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior 🤔

The card collection should be responsive. # of cards in a row should depend on min/max width props. In other words, if the cards become too wide, then number of cards in the row should be increased. If they become too narrow, then number of cards in the row should be decreased.
Current Behavior 😯

Nothing like this exists.
Examples 🌈

https://material.io/design/components/cards.html#card-collections
Context 🔦

I am trying to display a list of images inside cards, with descriptions in the card body. Looked at GridList, but that does not match the look I am trying to achieve.

This was fairly easy to do by changing the requirement to fixed-width cards:
<Box display="flex" flexWrap="wrap" justifyContent="center">
    <Card ... />
    <Card ... />
    <Card ... />
</Box>

I am closing this. Please feel free to comment if you know of better ways.

Have a look of this https://stackoverflow.com/questions/62548114/cards-lists-react-material

repo: mui/material-ui


text:
Allow to disable some theme-aware properties of sx

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Summary 💡
Allow to disable some feature of sx in theme.
Examples 🌈
Theme config
const theme = createTheme({
  sx: {
    border: ...,
    grid: ...,
    palette: ...,
    sizing: false, // disable sizing feature
    spacing: ...,
    ...
  }
})

Result
<Box sx={{ width: 1 }}> // Equivalent to width: '1px'

Motivation 🔦
I want to disable sizing feature from theme-aware properties of sx.
So when I set width: 1 it will  resolves to width: '1px' instead of width: '100%'

Thanks for the issue. Is this related specifically for the sizing and the usage of the value 1 or are there other use-cases you have in your codebase?
It kind of reminds me of https://github.com/mui/material-ui/issues/33525 (although not too much related), which is about changing the behavior of the sx prop. I almost feel like people should be able to provide their own sx style function (maybe as part of the team), which would override the default behavior. cc @siriwatknp for thoughts (we are already kind of doing this in the Material UI and Joy UI, but maybe we should go one step further and allow this in userland too).

My original problem is only about the sizing.
But I think it would be great if we could customize the behavior of sx in userland.
So we can solve various issues without waiting for the official release.
In the example, we can customize the spacing of sx to support for aliases.
import { spacingDefaultTransform } from '@mui/...'

const spacingAliases = {
  xs: '4px',
  s: '8px',
  m: '16px',
  ...
}

const theme = createTheme({
  sx: {
    sizing: false, // disable sizing, do not transform the value
    spacing: (value) => {
      return spacingAliases[value] ?? spacingDefaultTransform(value);
    },
  }
})

<Box sx={{
  width: 1, // 1px
  marginTop: 'xs', // 4px
  padding: 's', // 8px
  gap: { xs: 's', md: 'm' }, // { xs: '8px', md: '16px' }
}}>

Interesting, the comment you've added is very similar to the other issue (unless you were proposing API for that particular issue). It's definitely interesting problem. In that case, I am closing this issue in favor of https://github.com/mui/material-ui/issues/33525 Please share your thoughts there and upvote that issue :)


text:
[docs] Main "Base UI" website still using old Unstyled sample code

Duplicates

[X] I have searched the existing issues

Related page
https://mui.com/base-ui/
Kind of issue
Broken demonstration
Issue description
I found the unstyled Tabs component I wanted on the main Base UI site. So I copied the code into my app and… it failed. This turned out to be because the TabsUnstyled format was removed about a year ago. But the example code still says to use it:
import { TabsUnstyled } from '@mui/base/Tabs';
import { TabsListUnstyled } from '@mui/base/TabsList';
import { TabPanelUnstyled } from '@mui/base/TabPanel';
import { TabUnstyled } from '@mui/base/Tab';
import { styled } from '@mui/system';

[… etc]

Context 🔦

To anyone wishing to open a PR for this issue, replacing all occurrences of TabsUnstyled, TabsListUnstyled, TabPanelUnstyled, TabUnstyled to Tabs, TabsList, TabPanel, Tab from below file should be good.
/docs/src/components/productBaseUI/components/BaseTabsDemo.tsx

There also seems to be a forgotten file with a TabsUnstyled example. I suppose it should be deleted
https://github.com/mui/material-ui/blob/master/docs/src/pages/components/tabs/UnstyledTabsCustomized.preview


text:
[material-ui][createTypography] Button text wrap issue

[x] I have followed (at least) the PR section of the contributing guide.

Closes #38675

@siriwatknp Could you review?

Hello guys can you help what should I do to pass these checks
I want to be a part of MUI Community
thanks to all.

@siriwatknp Pending review.

authors: ZeeshanTamboli ehsanullahhaidary


text:
Allow minimum and maximum value for component number props

This would help with fixing this issue https://github.com/mui/mui-toolpad/issues/826 by using a single source of truth for the minimum component dimensions.
Also closes https://github.com/mui/mui-toolpad/issues/461
Using it already for Select component minimum width as an example.
https://user-images.githubusercontent.com/10789765/187513853-ed12ff95-b256-4cf0-90e4-aa616ca933ec.mov

proptype is based on json-schema, I think  that can describe min and max values. perhaps we should just reuse that?

I'm still not understanding the minimum width use case and how it should behave. Suppose minimum width is 50px, and I put 100 Selects in one row, what happens? what overflows or wraps?

proptype is based on json-schema, I think that can describe min and max values. perhaps we should just reuse that?

didn't know about that, i'll take a look

Looks like I already solved the whole issue in this PR after all, slightly unintentionally:
https://user-images.githubusercontent.com/10789765/187966124-55b8dea7-7fbc-4192-addb-ad59e64dcc36.mov
I've tested a bit and basically as long as we don't set a minimum width in the component CSS this kind of issue does not happen, the components always adjust to the width of the container.

If we make the screen very very narrow and have a lot of components they do overflow as it's inevitable, but I think the best option is to just let that happen rather than hiding the overflow.

In the future we can probably improve support for small device screens.
So what do you think? In my opinion we can merge this.

If you don’t agree with adding the new width prop it’s also not strictly necessary, we can remove it and use whatever default values the MUI component uses.
In my opinion this width prop is useful without being detrimental - it gives the user more control over how the element looks, and it sets a minimum width that doesn’t look so bad when the select is empty, just like the minimum width before this PR.
But the width prop is just an extra thing.

Also if you like this idea we can disable the width control when full-width is enabled, I just don't want to do it ahead of time if we don't want to go in this direction.

👌

authors: Janpot apedroferreira prakhargupta1

repo: mui/mui-toolpad


text:
Send DFI lower than Miner Fee

I tried the bridge a long time ago and sent a DFI amount that is less than the miner fee. The bridge recognized the transaction. However, the "Submit to Binance Chain" button cannot be pressed. Since then I'm stuck and I can't make new transactions because it recognizes the old transaction every time.

I can config this. the same seems to happen for me.
I just sent 0.0005 DFI to the bridge address. All goes well, up to the point where i have to click the Submit to Binance Chain Button. In the UI it seems, like nothing happens when i click on it.
In the Browser Log i see the following:
Submitting via Wallet Provider
MintProcessStep.tsx:347 0x85852282891f6de700096371192684f6f2a69c00 965880a7210443acbd86ce253b285feeeb798f9d5f43c8f10a8fc95946c1f6fc 0 50000 dfi 0xe477ece76481d8157d5a4308f8cc3713b29579d530c48fbbfd8a3c3cedb34959 0x0720c85ba1b6587bb6f8effa55b13919763df3aaed291f76cafe28863e58b518 28
walletHooks.ts:670 0x85852282891f6de700096371192684f6f2a69c00 965880a7210443acbd86ce253b285feeeb798f9d5f43c8f10a8fc95946c1f6fc 0 -950000 DFI 0xe477ece76481d8157d5a4308f8cc3713b29579d530c48fbbfd8a3c3cedb34959 0x0720c85ba1b6587bb6f8effa55b13919763df3aaed291f76cafe28863e58b518 28

errors.js:76 Uncaught (in promise) Error: invalid number value (arg="amount", coderType="uint256", value=-950000, version=4.0.48)
    at Object.s [as throwError] (errors.js:76:17)
    at e.encode (abi-coder.js:393:20)
    at abi-coder.js:645:59
    at Array.forEach (<anonymous>)
    at B (abi-coder.js:644:12)
    at e.encode (abi-coder.js:804:16)
    at t.encode (abi-coder.js:941:77)
    at t.value (web3-eth-abi.umd.js:43:38)
    at t.value (web3-eth-contract.umd.js:137:49)
    at t.value (web3-eth-contract.umd.js:548:61)

Seems like for some reason the amount is set to -950000  ?

okay, i see. it makes kinda sense. as amount is in sats and it is amount - fee this results in negative for this low amounts..
Maybe it does make sense to display a message with minimum amount at least?

repo: muirglacier/bridge-ui


text:
Store.Chat.find is not working

This method Store.Chat.find("5511912345678") is not working anymore to send messages to contacts not present in chat history.
Anyone solved this issue?
Thanks

https://github.com/mukulhase/WebWhatsapp-Wrapper/issues/382

@bobaoapae that solution only works if you already have a chat open with that id. To open a new chat if it doesn't exist, as Store.Chat.find used to do, you should use the following snippet:
var chat = Store.Chat.find("IDTOFIND") ;
if(chat === undefined)
{
chat = new Store.Chat._model({id:new Store.UserConstructor("IDTOFIND")});
Store.Chat.add(chat);
}
return chat;

check this https://github.com/mukulhase/WebWhatsapp-Wrapper/issues/383

@bobaoapae i was getting some weird error today doing exactly that lol

@bobaoapae  doesnot work  i get this : sentinel: "INIT DERIVED PROP"

http://prntscr.com/mxtvta

authors: bobaoapae dubriel mmoreirasouza mosaw

repo: mukulhase/WebWhatsapp-Wrapper


text:
BAT framework: Could not find or load main class org.mule.weave.v2.runtime.utils.WeaveRunner

Hi,
I can't seem to able to get the BAT working using this plugin. I followed the official guide (https://docs.mulesoft.com/api-functional-monitoring/bat-intellij-idea) which led me to installing this plugin, but when I try to run one of the tests, it always exits with "Could not find or load main class org.mule.weave.v2.runtime.utils.WeaveRunner". I tried installing the Mule 4 plugin as well, downloading the latest mule-ee runtime and pointing the mule framework config to this folder. As last step I did "Add framework support" on my BAT project and all mule jars appeared in the "External libraries", but still it is throwing this error. What am I doing wrong ?
Thanks in advance.

Hi,
Try doing this:
1 - Close intelli.
2 - Remove intellij files & folders from your test project (.idea folder and.iml file, in you case is bat.iml).
4 - Re-configure intellij file executing bat idea command on the project root.
5 - Open the project on intellij again, set up JDK on the project.
6 - Open the test you want to execute, right clic on the editor - > Run -> Bat Test NameOfYourTest
Let me know if it helps!

Hi,
Ok it works now... Still wondering why it didn't work in the first place. Only thing I did different this time I think is not using the built-in terminal of IntelliJ but an external one, must be something that IntelliJ does behind the scenes with its files.
Thanks a lot !

No problem, you have to run the bat idea command before open it with intellij. i think that was the problem.


text:
boss

boss，take me!

just follow me!

just follow me!

authors: QinZXX murmur-wheel

repo: murmur-wheel/graphics-samples


text:
Main

[ ] commit ammend (change commit before)
[ ] if different commit

hello


text:
Stuck at please wait

What version of Music Assistant has the issue?
2022.11.0
The problem
Installed Via hacs
restarted HA
Can see the Integration, but when adding its stuck at:
"Please wait, starting configuration wizard for Music Assistant"
How to reproduce
Install and try to add the integration
Relevant log output
Nothing in my home-assistant.log
Additional information
No response
What version of Home Assistant Core are your running
2022.11.2
What type of installation are you running?
Home Assistant Container
On what type of hardware are you running?
Linux

Re-install Fixed this

repo: music-assistant/hass-music-assistant


text:
fix flakey test which can inherit MDCs from other testcases

I think the MDC when you create a log event gets some static magic so if you don't have one to avoid magic you can just pass in an empty map.
The failure I guess depends on the order run.

Codecov Report

Merging #10 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #10   +/-   ##
=========================================
  Coverage     87.56%   87.56%
  Complexity       90       90
=========================================
  Files            11       11
  Lines           201      201
  Branches         11       11
=========================================
  Hits            176      176
  Misses           23       23
  Partials          2        2

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 ca5aa1f...c2947f5. Read the comment docs.

Merge with https://github.com/mustaine/logcapture/pull/12

authors: codecov-io mustaine pityq

repo: mustaine/logcapture


text:
turbopack support

By default, when using turbopack dev it throws an error
@apps/www:dev: [next]  ⨯ ModuleBuildError: ./apps/@www/videos/payments.mp4
@apps/www:dev: [next] Unknown module type
@apps/www:dev: [next] This module doesn't have an associated type. Use a known file extension, or register a loader for it.
@apps/www:dev: [next]
@apps/www:dev: [next] Read more: https://nextjs.org/docs/app/api-reference/next-config-js/turbo#webpack-loaders

+1

Thanks for reporting!
yes, for now turbopack doesn't support inline webpack loaders which next-video uses for the video type.
we might need to export this as a separate package to make this to work.
not sure if we'll get to this before Turbopack reaches parity.

I did some digging again and the blocker is Turbopack requires support for importing binaries (raw) files (mp4's).
https://github.com/vercel/next.js/discussions/72147

Tried this today and managed to get a few steps in but it's still complaining about them when I view one of the pages
    experimental: {
        turbo: {
            resolveExtensions: ['.mdx', '.tsx', '.ts', '.jsx', '.js', '.mjs', '.json', '.mp4'],
            rules: {
                './videos/*.mp4': {
                    loaders: ['next-video/webpack/video-raw-loader.js'],
                    as: '*.json',
                },
                './videos/*.mp4.json': {
                    loaders: ['next-video/webpack/video-json-loader.js'],
                    as: '*.json',
                },
            },
        },
    },

Extension seems to be wrong:
Failed to compile

./videos/coblocks-ai.mp4.json.json
Code generation for chunk item errored
An error occurred while generating the chunk item [project]/videos/coblocks-ai.mp4.json.json (json)

Caused by:
- failed to convert rope into string
- invalid utf-8 sequence of 1 bytes from index 35

yes, thanks for digging in! Turbopack is trying to convert the imported file to a string I believe which is not we want. it should stay raw (binary)

authors: kevinschaich luwes ryanleecode wladpaiva

repo: muxinc/next-video


text:
Seeds for Reproducing Results

Hi,
I am trying to reproduce the reported results when training on 4 A100 GPUs. I am using the provided configurations for all evaluations (fully supervised, zero-shot, few-shot, and base-to-novel), but the accuracy tends to fall by 1-2%.
Can you please share the seeds used obtained the reported results.
Also, what are the hardware specs used for training the results reported in the paper?
Thank you!

Hi @fzohra,
Thank you for showing interest in our work!
Regarding your queries, please note the following:

Firstly, have you tried to reproduce the results using our pretrained models? It will be good to verify if your GPU machine can correctly reproduce results using the provided pretrained models.
The fluctuation in the results specially in the few-shot training setting could be due to random variations when tested on different machines. We have also observed same trend when we trained same models on different machines.
Regarding the seeds, we are directly using the splits provided in  datasets_splits/hmdb_splits. After training, we evaluate models on 3 validation splits and report the numbers averaged over these 3 validation splits.
Lastly, we also used 4 A100 GPUs to train the models in few-shot and base-to-novel benchmarks. The overall batch size should be the same as provided in the config files.

I hope this is helpful for you. Please let us know if you have any additional questions!
Thank you.

Thanks for the reply!
I'm currently using v100 and 4 gpus and am trying to reproduce the results for the base to novel evaluation on ssv2. I've increased batch size to 8 when training to maintain an effective batch size of 64.
I'm using the splits defined in datasets_splits/base2novel_splits/ssv2_splits.
Using the provided pretained weights (seed1, seed2, and seed3), I am able to reproduce the results doing inference on the three base and novel classes. On the base classes the average is Acc@1 16.148 Acc@5 39.474. On the novel classes, the average is Acc@1 12.337 Acc@5 31.536.
However, when I train the model, the results are lower. As you can see in the following table, the accuracy on the base validation sets for each split after 11 epochs of training is 14.356, which is less than the 16.148. I don't have the numbers anymore for when I was reproducing on an a100's but it was a similar scenario. Would really like to reproduce the baseline to be close to the pre-trained weights.

|   | base to novel split 1 | base to novel split 2 | base to novel split 3 | base avg
-- | -- | -- | -- | -- | --
vifi-clip [reproduced] | ssv2 (bs=8, ga=2, gpu=4) |   |   |   |
  | epoch 0 | Acc@1 7.346 Acc@5 18.542 | Acc@1 7.358 Acc@5 18.588 | Acc@1 7.386 Acc@5 18.650 | Acc@1 7.363 Acc@5 18.593
  | epoch 1 | Acc@1 7.938 Acc@5 20.188 | Acc@1 8.035 Acc@5 20.444 | Acc@1 8.081 Acc@5 20.569 | Acc@1 8.018 Acc@5 20.400
  | epoch 2 | Acc@1 9.038 Acc@5 23.366 | Acc@1 9.066 Acc@5 23.303 | Acc@1 9.163 Acc@5 23.109 | Acc@1 9.089 Acc@5 23.259
  | epoch 3 | Acc@1 9.789 Acc@5 26.071 | Acc@1 10.165 Acc@5 26.213 | Acc@1 10.592 Acc@5 27.084 | Acc@1 10.182 Acc@5 26.456
  | epoch 4 | Acc@1 11.851 Acc@5 30.194 | Acc@1 12.153 Acc@5 30.091 | Acc@1 12.534 Acc@5 30.997 | Acc@1 12.179 Acc@5 30.427
  | epoch 5 | Acc@1 13.183 Acc@5 33.468 | Acc@1 13.087 Acc@5 33.514 | Acc@1 13.423 Acc@5 33.440 | Acc@1 13.231 Acc@5 33.474
  | epoch 6 | Acc@1 13.588 Acc@5 34.157 | Acc@1 13.314 Acc@5 34.248 | Acc@1 14.009 Acc@5 34.476 | Acc@1 13.637 Acc@5 34.294
  | epoch 7 | Acc@1 14.009 Acc@5 34.937 | Acc@1 13.610 Acc@5 35.023 | Acc@1 14.487 Acc@5 35.000 | Acc@1 14.035 Acc@5 34.987
  | epoch 8 | Acc@1 14.226 Acc@5 35.239 | Acc@1 13.787 Acc@5 35.490 | Acc@1 14.470 Acc@5 35.228 | Acc@1 14.161 Acc@5 35.319
  | epoch 9 | Acc@1 14.288 Acc@5 35.330 | Acc@1 13.952 Acc@5 35.786 | Acc@1 14.710 Acc@5 35.495 | Acc@1 14.317 Acc@5 35.537
  | epoch 10 | Acc@1 14.402 Acc@5 35.364 | Acc@1 13.969 Acc@5 35.871 | Acc@1 14.698 Acc@5 35.552 | Acc@1 14.356 Acc@5 35.596

authors: fzohra muzairkhattak

repo: muzairkhattak/ViFi-CLIP


text:
Fix editing of pictures

Adding a picture when editing shouldn't replace other picture.

Fixed.

repo: muzhack/muzhack


text:
MVC_SPEC-59 Added ValidationError interface and updated BindingResult

This PR adds the new ValidationError interface and modifies BindingResult to return sets of ValidationError instead of raw ConstraintViolation.

From my perspective, this PR is ready to be merged.

@ivargrimstad Thanks for your feedback! :)

authors: chkal ivargrimstad

repo: mvc-spec/mvc-spec


text:
chore(Dependencies) : update sbt-scalajs, scalajs-library, ... from 1.5.1 to 1.6.0

Updates

org.scala-js:sbt-scalajs
org.scala-js:scalajs-library
org.scala-js:scalajs-test-bridge

from 1.5.1 to 1.6.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (1.5.1).
You might want to review and update them manually.
modules/scalcite-ui/yarn.lock

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-js" } ]

labels: library-update, semver-minor, old-version-remains

Superseded by #299.

repo: mvillafuertem/scalcite


text:
Refactor client factories to avoid forcing references

References are ok, but sometimes they don't make sense for some particular factories.

Closed by #50

repo: mvlabat/muddle-run


text:
HTML seen in confirmation message

See screenshot (mac)

I'm seeing a bunch of issues like this which look like graphics glitches.
I think it might be related to: https://github.com/mwcproject/mwc-qt-wallet/issues/129
Can we make the scale factor configurable?

I will review the massages. Seems like we need to separate html and plain text

authors: bayk cgilliard

repo: mwcproject/mwc-qt-wallet


text:
Stop the license plugin from generating dangling JavaDoc comments

The JavaDoc style comment is incorrect for Java and Kotlin.
IntelliJ is constantly complaining (rightly so) about the generated
license headers. This will be resolved in the next release of the license plugin
by default.

Coverage remained the same at 100.0% when pulling 9b7b086ff71bd0150c3705bac95914a2c40d813c on jeffgbutler:master into 45b2e14fa7b6f5d9f896935bb5655d47f8fa9c72 on mybatis:master.

@jeffgbutler The 'java' side is fixed in license-maven-plugin by default in 4.0 which is still in RC status.  I'm not sure they have kotlin but have built a relationship over there so I'll check and if not I'll get that added as the default.

@jeffgbutler ok kotlin is in there but listed as 'kotlin' using 'kt' as tye type.  This is just for reference as we don't have this in play yet and will be some time since we are still waiting on jacoco update.
    KOTLIN("kt", HeaderType.JAVADOC_STYLE),

although...just realized it's wrong.  So...I'll work with license plugin team to get that switched to slashstar_style.

@jeffgbutler Looking at their code, I presume 'groovy' / 'scala' should be same as done here.  Do you know?

@hazendaz Cool - it's definitely wrong for Kotlin. I was gonna do a PR for it, but if you can work directly with them it would be better.
I assume it needs to change for groovy and scala too - but I'm no expert in those languages.

@jeffgbutler Thanks.  I suspect the same on groovy/scala but no expert there either.  I can get PRs in with them pretty quickly.  I'll look up those other 2 languages and confirm.  I'm sure google rule sets will indicate the right approach.  Appreciate it!

@jeffgbutler I looked up groovy and scala directly.  Both use slash star in their code bases so if they do, that is the right way.  Opened {PR}(https://github.com/mycila/license-maven-plugin/pull/186)

authors: coveralls hazendaz jeffgbutler

repo: mybatis/mybatis-dynamic-sql


text:
Async Validators

This adds support for asynchronous validators to ember-validations.
The base validator already supported asynchrony, but the individual validators were synchronous. This centralizes the logic of getting the value in the base validator, resolves it, then passes it to the individual validators to handle synchronously.
This is more of a stop-gap easy win to get asynchronous validators. Ideally the validator call methods would return promises themselves instead of being synchronous.

are we changing the signature of call for all validators? if so, this would require a "major" version bump for the project. for those who have created custom validators, would this require them to refactor?

One small comment/question.
Otherwise :+1:
p.s. Are you planning on opening PR to master repo for this addon?

we should also rebase before we merge

@egaba88 as for the call(value) signature changing, it's only adding to it, not changing anything existing. ie, nothing is currently relying on any values coming from call() so any custom validators should still be fine. This just allows future validator developers to get an asynchronous value without having to implement it themselves.

@mpanic No, this isn't going to be reported to Airbrake. These are just UI validations and will happen often and are expected to. And yes, I'm going to open a PR upstream into the main ember-validations repo.

Also, the errors object in here is local to the current validation model. It doesn't interfere with any window-level stuff.

@egaba88 how come we need a rebase?

so that its not messy going into the parent repo

Rebase will group all your commits together and apply them on top of the most recently merged changes from master. It's much cleaner and we should use it here, but we use git flow instead.

there is a git flow feature rebase command. i like to rebase my branches before i merge them into develop for our repos.
ideally, we would want to do this because it allows the commit trees to have "feature filled" commits.

Ah cool. I squashed all my commits. Going to close this PR and open one into DockYard's repo

authors: egaba88 jbuckner mpanic philgran

repo: myfitnesspal/ember-validations


text:
Demand for low population airports

At the moment, airports with low population (lower than 40,000-50,000) don't create any demand and therefore no loyalists are generated.
With this code change, for airports with population <50,000 the population for calculation is adjusted to 50,000. This creates demand from and to those airports.
(Maybe we need a slight downsizing. Although looking at the numbers, Nakina airport had 444 aircraft movements in June 2007 (see https://www150.statcan.gc.ca/n1/en/pub/51-008-x/51-008-x2007006-eng.pdf?st=ReEsC9Z2), so even if it's mainly private aircraft, this could be realistic here.)

For low income airports, demand is still nil (or very very low):

Are you sure this is a bug? I see a lot of airports under 50,000 population coverage where people have loyalists:

Yellowknife (YZF)
Churchill (YYQ)
Gander (YQX)
Goose Bay (YYR)
etc.

Are you sure this is a bug? I see a lot of airports under 50,000 population coverage where people have loyalists:

Yellowknife (YZF)
Churchill (YYQ)
Gander (YQX)
Goose Bay (YYR)
etc.

They all have charms, either isolated town or even vacation. Places without charms don't produce loyalists for population somewhere between 40k and 50k.

repo: myflyclub/airline


text:
New release with improved error handling

Hi there! Do you have any plans to release a new version with the improved error handling, rejecting always with extended error instances?
I discovered this great library this morning and have been testing it since. In my previous code I used my own wrapper around request-promise which had practically the same API than axios, so I've replaced it really fast. Everything has been working great until I started testing error handling. I cloned the repo and I was confused because it looked right, but I just discovered that it's implemented in master but not released yet :'(
Tell me if you need any help with this release (important bugs not yet solved, etc.).

same as here.It cannot handle errors properly.

axios@0.13.0 has been released with this improvement.

authors: mzabriskie rubennorte tarim

repo: mzabriskie/axios


text:
Questions about results on ImageNet dataset

Hi,
Good works!
I am reading the paper and finding that table 4 is kind of confusing. May I ask why the accuracies of M_i sometimes are greater than(or equals to)the full model (WRN-50-2, EfficientNet-B7)?

Hi,
Good works!
I am reading the paper and finding that table 4 is kind of confusing. May I ask why the accuracies of M_i sometimes are greater than(or equals to)the full model (WRN-50-2, EfficientNet-B7)?

Acute observations.
M_i of EfficientNet-B7, S=2 is better or equal to the full model EfficientNet-B7, S=1 .
I think this is possibly due to the effect of co-training.
Honestly, I do not know the real reason and cannot show you more data now, but this is a reasonable one.
It is also consistent with the report of EfficietNet, i.e., EfficientNet-B7 (84.4%, 66M, crop 600, wider, deeper) vs. EfficientNet-B6 (84.2%, 43M, crop 528),.
EfficientNet-B6 may also achieve 84.4% or 84.3% with a bigger crop, 600.
Some of the M_i is better than some full models, this is because some M_is is bigger than what you think.
For example, M_i of SE-ResNeXt-101, 64x4d have similar capacity as SE-ResNeXt-101, 32x4d.
In this case, it is reasonable for M_i to get better performance than some relatively small full models.
This is decided by the dividing fashion.
Finally, this situation also demonstrates the superiority of increasing the number of networks and co-training.

Thanks for the rapid answering.

Thanks for the rapid answering.
I think the co-training might be the reason. This is interesting if it works universally.
When you refer to "bigger than what you think", do you mean the complexity of M_i is not similar to half of the full model complexity?

Somehow, yes.
If we only look at the #Params, one small network is roughly 1/S as the original.
But, according to Eq.(2) and Eq.(3), the #Params become 1/S, but the number of output feature maps is 1/sqrt(S) as the original.
In other words, M_is produce more feature maps than M when they have the same #Params in total.
This is also the secret of group/depthwise convolution.
However, the above explanation is not so suitable for the division of ResNeXt.
As we divide the number of groups, and the number of feature map channels change with the groups linearly.

I understand. This is the same situation with EfficientNet. I would like to training co-training then.
May I ask whether the method performs well for small models like (EffcientNetB0-B3) on ImageNet?

I understand. This is the same situation with EfficientNet. I am interested in the effect of co-training and I will try to use co-training in my work then.
May I ask whether the method performs well for small models like (EffcientNetB0-B3) on ImageNet?

I think this method may not work well with small models like (EffcientNetB0-B3) on ImageNet.
It even does not work well with Wide-ResNet-50 on ImageNet as I showed in the paper.
According to my practice, if your model is 3x wide than ResNet-50, you will get a gain by dividing and co-training on ImageNet.
This also means it better to increase the number of networks in this situation rather than the width.
For small datasets, it seems dividing and co-training always works.

Thanks for your reply! I have a better understanding of the method now.

Hi,
One last question. Is the method works well when split>2 on ImageNet? Will more splits bring performance improvement like CIFAR-100?

Hi,
One last question. Is the method works well when split>2 on ImageNet? Will more splits bring performance improvement like CIFAR-100?

I only test S=2 on ImageNet.
This is decided by the sequential training method  I used (refer to the last paragraph of  Sec. 4.4. Ablation study) and limited resources.
E.g., the training of EfficientNet-B7, S=2 takes 12+ days. You can use tensorboard to visualize the log and see the time.
I cannot tell you the answer as I never test it.
But I think it will work well with some super large networks like FixResNeXt-101 32x48d or EfficientNet-L2.
See https://paperswithcode.com/sota/image-classification-on-imagenet.
It will be easier to test the idea with a framework that supports concurrent training of multiple networks.

I will close the issue since all my questions have been answered.
Thanks for your patient reply.

authors: mzhaoshuai silent-chen


text:
🛑 mziyut.com is down

In 427ca08, mziyut.com (https://mziyut.com) was down:

HTTP code: 500
Response time: 106 ms

Resolved: mziyut.com is back up in e67e2ea after 13 minutes.

repo: mziyut/upptime


text:
Fixed concurrent request by copying object values

@n0mad01 I believe this will fix #49 by copying a default object rather than reusing the same object across function calls.  I'm going to test locally, and I'll update you.  Please let me know if you see any concerns with the approach in the meantime.

I tested this locally on my own app, and this fixes the issue I pointed out in #49.  My output now looks as expected:

requested from https://bittrex.com/Api/v2.0/pub/market/GetTicks?marketName=BTC-AUR&tickInterval=oneMin&=1503262961.843 in: 1.01s
requested from https://bittrex.com/Api/v2.0/pub/market/GetTicks?marketName=BTC-FAIR&tickInterval=oneMin&=1503262961.843 in: 1.265s
requested from https://bittrex.com/Api/v2.0/pub/market/GetTicks?marketName=BTC-EFL&tickInterval=oneMin&=1503262961.843 in: 1.484s
requested from https://bittrex.com/Api/v2.0/pub/market/GetTicks?marketName=BTC-GLD&tickInterval=oneMin&=1503262961.843 in: 1.489s
requested from https://bittrex.com/Api/v2.0/pub/market/GetTicks?marketName=BTC-EXCL&tickInterval=oneMin&_=1503262961.843 in: 1.478s
etc...

thanks a lot!


text:
Don't publish empty patches

For #655 #294
This update explicitly checks if generatePatch indicates a change, and if not, will skip publishing that patch.
e.g. If the current data looks like: { a: 1, b: 2, c: 3 } and there's an open query such as { a, b }, if c changes and we invalidate on the server, it would previously publish an empty patch to that user.
Also, I'm not super familiar with Typescript, so the correct types might need to be added.

Hey @n1ru4l, when you get a chance would you mind taking a look over these changes?

@dburles Hey, sorry for the delay I just pushed some minor adjustments, for using a symbol instead of undefined. I will now rebase the branch and release it :)

@dburles Thank you for taking the initiative on this! Highly appreciated ❤

No problem, thanks!


text:
Better typings for effect props

I'm not sure why the effect is a type of EffectCallback | Object. So I propose to change it.

Спасибо за исправление! Я в typescript не очень силен к сожалению.  Выглядит замечательно, авто дополнение в IDE должно быть счастливо :)