Discussion: Find a way to make OSC7 work

I think we all agree that we want a sequence that'll work for a client app to set the current working directory of the Terminal. How exactly that's enabled is still up for discussion. There's already existing user scripts, tools, etc that are using OSC7 to set the CWD of the Terminal. However, those who are using it are using it to set the path relative to the "container" - e.g. in WSL, the "container root" is /, but as far as the OS is concerned, that path is actually \\wsl$\DistroName\.
I'm aware we've already got #3158 tracking adding support for OSC7, but there's a ton of folks that are all following that discussion as the "enable opening a new tab with the same directory", and I'd rather keep this discussion more focused.
(That being said - the rest of this post is basically my verbatim notes, turned into a thread. I've got some though experiments below for what we could do here, but none of them are particularly good.)
For the completeness of discussion, let's also refer to

#8166 OSC 9;9 - the ConEmu sequence for setting the working directory
#7526 Support for the file:// URI when emitted as part of OSC 8 hyperlinks
#331 Users wanting to be able to drag/drop a file onto the Terminal running WSL, and have the pasted path be in WSL format, not Windows
#592 Less importantly, but users also want to be able to set a
startingDirectory as a WSL path, not just as a Windows path.

Let's imagine emitting this sequence in the following scenarios:

From cmd.exe
From powershell (Core?) on Windows
From WSL
From WSL running in a non-WSL profile

This scenario is important, because we can't use the profile to determine
how we'd want to convert the path

From anything over ssh

This most definitely won't work. Fortunately, we can use the hostname to
prevent these sequences from being accepted. It's up to the user to make
sure that the machine they're ssh'd to doesn't have the same hostname.

From inside a Docker container
from inside cygwin
Inside tmux or screen, or any other ort of multiplexer that might need to get in between the client app and the terminal emulator
When emitted by a remote machine connected to with the Azure Cloud Shell

OSC7 Conclusions
(I originally wrote this for https://github.com/microsoft/terminal/pull/7668#issuecomment-724129902)
Basically, we've got two simultaneously incompatible issues. Either we:

Support this sequence with no "smart" path translation. We'll need to
literally use whatever directory they emit (assuming the hostname matches)

Users who are currently using OSC 7 in their *nix scripts and emitting file://$hostname/$PWD in WSL, cygwin, will get unexpected behavior. We'll try and treat $PWD as a path to a Windows directory - which might be a path that exists. When they try to open a new tab with that same directory, it'll open not in the distro the sequence originated in, but in the Windows filesystem. Not great!

Find some way to magically translate paths provided by OSC7 into the correct Windows path. WSL clients won't need to change any of the scripts they were already using for this to "just work".

There's no heuristic way of doing this, without the client application providing some extra information to us. We can't inspect the process tree to figure out if the process that's emitting this sequence is a WSL process or a docker process or an ssh, and even if we could, then we wouldn't be able to correlate wsl.exe to the distro within WSL that's being used. Similarly, we can't use the profile to do this, because the user might be using WSL w/in their "Command Prompt" profile (for example).
We could introduce some other sequence for additional metadata to be provided. Something like "I know I'm a WSL, and I'm <distroName>, when I emit paths, handle them specially". If we did introduce such a new custom sequence, then we're not really faithfully implementing OSC7 now are we? For clients to work as they did before, they'd still need to add emitting this custom sequence

I think at the end of the day, I agree with @j4james. If we implement OSC7 as requiring a Windows-style path, then that'll necessitate that client applications will need to be modified to work right on Windows, and I hate that idea.
OSC9;9 - the ConEmu solution
This one doesn't seem that bad. Since it's a windows-first sequence, it doesn't need to know anything else about who's emitting the path. We can always assume it has been emitted as a Windows path. On the surface, this seems to work great, save for one scenario - ssh. This sequence doesn't accept any sort of hostname, it only takes the path. So if you were ssh'd into another machine, and that one emitted a OSC9;9, then there's no way of determining that sequence wasn't intended for the current machine.
I think I'm okay with us implementing this as-is for the time being though. It's not a perfect sequence, but it's good enough, and doesn't come with the compat baggage that OSC7 does. It can certainly be supported with the caveat "This won't work in an ssh session, or in any scenario where it's emitted by a remote connection. It will always be treated as a path on the local machine".

NOTE: The following is just brainstorming from me. I'm gonna file a new issue
to track the discussion of this proposal, because I don't want to further
muddle the discussion here.

Creating a custom sequence
While noodling on all this, I considered, "what would we want for a perfect set working directory sequence"? Why isn't OSC7 good enough for us? I think my analysis is that the thing emitting the sequence shouldn't need to know if it's inside a container, inside a WSL, running in an ssh session. The client application should be able to emit the same sequence regardless, and the Terminal should be able to just do the right thing.
The WSL path -> Windows path thing is tricky, but could we work around it somehow?
I'm thinking it might be useful to introduce some new "path metadata" sequence, that controls how paths emitted by OSC7 are handled. While this wouldn't strictly be in-line with the rest of the OSC7 spec, it would allow these sequences to be used otherwise unmodified on Windows, and might help make emitting these sequences in containers more useful. I'm thinking something like
Idea 1 - K/V Pairs used by the Terminal to reverse-engineer the path
OSC 9001 ; 1 ; key = value ST

Which lets the client specify a set of key, value pairs that should be used by the terminal when handling paths emitted by the client, and that's it.
This sequence would have to be emitted on startup of something like WSL, docker, or ssh, and they'll be responsible for setting these values for the terminal[1]. So WSL would emit something like:
OSC 9001 ; 1 ; wslDistro = Ubuntu ST
OSC 9001 ; 1 ; hostname = %COMPUTERNAME% ST

The Terminal could then use these pieces of information to make smarter decisions about paths.
[1]: Obviously, this could be emitted during login in .profile or something else, as a stopgap while we wait for WSL to emit something like this. I'd think users would want to use it sooner than later, and if there's a way for the shell to determine it's running in WSL, then fine, I won't stop users from writing new code that'll work both now and in the future.
Idea 1 conclusion
This is a terrible idea, because it requires the terminal emulator to be aware of any and all of these possible scenarios. Every terminal emulator out there would need to be manually updated to be able to handle WSL paths, cygwin paths, docker paths. If any other container-like environment was created, then the terminal emulator would also need to be updated to have other logic for that case as well.
Also, how does nesting these things work? How would the logic of wsl->cmd->cygwin work?
Idea 2 - Specify a commandline for path translation
The thing that's creating the nesting pushes/sets a path transform onto the Terminal. So wsl.exe would say
^[]9001;2;wslpath.exe -w ^[\

Then, when the client emits a path, we'd use the provided commandline to translate the path for us. We'll run the given commandline, and if the exit code is non-zero, we'll use the output of that commandline as the real path.
We'd need both a transform for outbound paths (paths emitted by the client) and inbound paths (paths created by the Terminal, e.g. the drag-drop path situation).
Idea 2 conclusion
Obviously this is a terrible idea. All you have to do is have your script emit ^[]9001;2;malicious.exe^[\ and now you've got a malicious exe running on every prompt, with the path that's being used by the user.
Also, how would this work with ssh? we'd filter the paths out by hostname, but what if you ssh'd to a Windows machine, then ran wsl in there? That WSL would inform the terminal to treat paths like they were WSL paths. However, WSL is running on the remote machine, not the local one! The terminal can't use that wslpath.exe
Idea 3 - Static path translation mapping
Static path translation table. The containerizer (wsl, cygwin, docker) sets up a list of paths and what they should be mapped to. E.g.
^[]9001;3;/mnt/c=C:\^[\
^[]9001;3;/=\\wsl$\Ubuntu\^[\

The above example would set up two pairs of mappings (/mnt/c -> C:/), and
(/ -> \\wsl$\Ubuntu\). When the terminal emulator receives a path from OSC7 or OSC8,
then  it'll look through the table and find the mapping with the longest prefix
match for the given path.
So, if someone emits ^[]7;file://localhost/mnt/c/foo^[\, both / and /mnt/c
will match, but we'll take /mnt/c since that's the longer match. We'll then
substitute that prefix with whatever it's mapped to, so /mnt/c/foo becomes
c:/foo
We'll do the reverse when someone drag/drops a path onto the Terminal

[ ] How would this work with ssh?
[ ] How would this work with cygwin?
[ ] How would this work with tmux?
[ ] How would this work with multiple nesting?

Simple example - wsl -d Ubuntu, then pwsh.exe, then wsl -d Debian. Now
we're in Debian, and we want the paths to be translated to \\wsl$\Debian\,
not \\wsl$\Ubuntu\. That's fine, when WSL enters the Debian instance,
it'll emit the sequence again, re-mapping / to the new root. However, if
we exit Debian, now the pwsh.exe would need to reconfigure the roots
itself.
Heck, even simpler - wsl -d Ubuntu then pwsh. Does pwsh then set up the mappings itself?
Is it the responsibility of the person emitting them to clean up after
itself? That's almost never the case with other sequences. (consider SGR
sequences.  People who care about the paths being remapped should assume that
any child subprocess might change them.

So that would mean that after every command (like, as a part of the
prompt), the shell would need to set up the mappings again. This is
basically the same as just emitting a Windows path in OSC7 to begin
with! Like, the only benefit we get is that child processes would
inherit your mapping by default, but they could always overwrite it.

[ ] How could this be used maliciously?
[ ] Path slashes! If the path we drag is c:\foo\bar, then will we generate
/mnt/c/foo\bar or /mnt/c/foo/bar?

Recall that cmd.exe can be a bit of a stickler about paths with \ vs /.

[ ] Is = a valid path character in either *nix or NTFS? If it is, then
we'll need something else as a delimiter that's not a path character

Idea 3 conclusion
IMO this is no worse than asking people to change their scripts to emit a
Windows path in OSC7. If they already have to change their scripts, then adding
this mapping script once in their profile or wherever will make it just work for
all the tools they're using, not just the ones they can change
Nevermind. This is just about as bad as just forcing people to use Windows paths in the prompt in the first place.
Idea 4 - stick the metadata right in the OSC7 sequence
Could we add additional parameters to OSC7, after the path, that a terminal emulator could use to say "Ah yes, this path might be inside a container, lets handle it specially"? This kinda admits that we won't be able to add any other sequence that'll make OSC7 work on its own without modification. If the takeaway from idea 3 was "no matter what we do, the shell needs to reconfigure the path mapping whenever a child exits", then I'm starting to worry that could be extrapolated to any design we make.
Idea 4 Conclusion
So I guess, if we're going to be asking people to modify their existing tools that use OSC7, then why not just use OSC7 as-is, with the caveat "If this is running on Windows, it's gotta emit the Windows-relative path"
Reference

The following post by @TBBle is incredibly useful

https://github.com/microsoft/terminal/pull/7668#issuecomment-695818825
Anyway, how to generate the URL is not the main issue for Windows Terminal, it's how to parse it. Ideally, we want to receive URLs that are already in the right format to just pass through urlmon or similar, and get back a UNC or filesystem path.
To get everything interoperating well, we need to handle (off hand):

Paths from CMD, which are going to need to be file://localhost/$CWD, because CMD only knows DOS paths.
Paths from PowerShell, which could be DOS path or UNC path. PowerShell can tell these apart, because $executionContext.SessionState.Path.CurrentLocation knows if it's on a 'Drive' or not, so this can easily do different things for either type of path.
Paths from cygwin-based systems, e.g., Git Bash or MSYS2), which I believe can only see DOS paths, and can convert from cygwin paths using cygpath --mixed ${PWD}, and then it looks just like CMD, above.

Edit: Actually you can cd to UNC paths in the cygwin virtual filesystem, and in this case, the local PWD is the UNC path. Helpfully, cygpath --mixed ${PWD} works for all these cases anyway.

Edit: Also, using --mixed instead of --windows so the slashes are already correct, so the OSC 7 URL can be literally file://$(hostname)/$(cygpath --mixed $PWD) and it seems that'll always work.

Paths from WSL, which from within the WSL session are Unix paths, and have two major mappings:

/mnt/X/... where X is a drive-letter should map through to a DOS path for that Drive.

Otherwise, it needs to to a UNC path //wsl$/${WSL_DISTRO_NAME}/${CWD}.

Edit: I kind-of wish WSL has something like cygpath now, to hide all the above.

Paths from an SSH session, which we ideally want to ignore early. However, these may look identical to a UNC path's file:// URL. That might actually be desirable, if I am SSH'd to a machine on my LAN, and then launch a PowerShell tab and it does actually go into the same directory, via UNC. However, that'd be an unusual CIFs layout (NFS 3 worked that way though...) so I can't see this as being a common use-case.

Happily, it seems ${WSL_DISTRO_NAME} exists, and I assume it's inserted by the wsl shell launcher, so it is possible to generate the full correct file:// URL in one's PS1 env-var. This even means you can key off the presence of ${WSL_DISTRO_NAME} (or ${WSL_INTEROP} perhaps) to share the same OSC 7 generation code with out-of-WSL environments.
One possible approach to the above: is that if everyone generating OSC 7 commands for Windows paths agrees to only generate a modified-'legacy file:// URL' format, i.e. file://<gethostbyname()>///<UNC hostname>/<UNC path> or file://<gethostbyname()>/<DOS Path>, then WT could recognise when <gethostbyname()> matches the current $COMPUTERNAME, and replace it with localhost (making it a correct "legacy" file:// URL) before passing it through to the URL handler to get the actual working directory.
Then any other hostname, except 'localhost' and 'empty string', could be treated as 'remote' and ignored. For 'localhost' and 'empty string' hosts, we'll just trust the user isn't generating those from a remote host. There's nothing else we can do there.
This seems the closest in-spirit to the Freedesktop file:// URL specification, and means that URLs generated for OSC 7 on Windows will be semantically-similar to URLs generated for OSC 7 on UNIX-type systems, and can be parsed the same way.

Other tabs I had open:

https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/7
https://github.com/alacritty/alacritty/pull/2937
https://stackoverflow.com/questions/14018280/how-to-get-a-process-working-dir-on-windows
https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC

I'll keep thinking about this, but let's use this as a place to continue thinking about how we might do right by the users here.

I don't know if I'm missing something, but this really doesn't seem like it should be that complicated to me. If the path looks something like X:\foo\bar or \\foo\bar, then we assume it's a normal Windows path which we can handle as is. If it's something like /foo/bar, then we assume it's going to require some translation based on the current profile.
If the profile command line is something like wsl -d DISTRO then I figured we could just prefix the path with \\wsl$\DISTRO (or something along those lines - I'm probably oversimplifying, but I'm sure there's an algorithm for this). Worst case we have to launch an instance of wslpath to do the translation for us and pipe back the result.
And I'm assuming cygwin could be handled in the same way. Either there's an algorithm we can use to work out the correct path ourselves, or we launch an instance of cygpath to do the translation for us.
If we're concerned about performance, we could always do something like translating just the root path, and then reuse that translation for future paths sharing the same root. But in most scenarios where the path is needed, the overhead probably wouldn't even been noticed.
Yes this is going to require a lot of special case code for every variant of shell we want to support, and it's not going to be pretty. But I'd much rather have that mess isolated in the Terminal instead of every application and shell script having to deal with it.
And remember this problem is specific to Windows Terminal. Once wsl supports Linux GUI applications, there are assumedly going to be plenty of other terminal apps running on wsl that won't have this problem. So if you're expecting applications to treat us differently, it's not good enough to detect that they're in a wsl instance - they need to tell that they're running in Windows Terminal, which is not something we've wanted to encourage.
And before anyone starts bringing up edge cases where this won't work, ask yourself whether that is a realistic scenario that users would expect to work? And there is always still the option of a custom sequence to handle special cases, or requiring the path be in a particular format. The important thing is that the out-of-the-box solution handles the 99% of cases where the user is just launching a regular shell, and having the terminal recognise a standard OSC 7 sequence to track the active directory.

The edge case that I immediately think of is running WSL from a "Command Prompt" profile. If you enter any one of these "containered" environments from a profile that doesn't match, then immediately any logic that uses the profile to do the translation isn't going to work. If that's an acceptable outcome, then yea, this is easy to do. Heck, we could just slap a "wslDistro": "Ubuntu" property in the dynamically generated profiles, and use the existence of that property let us identify if a profile is a WSL distro and which one it is.
I'm still holding out hope that there's a way to do it without that, but the hope is fading fast.

it's not good enough to detect that they're in a wsl instance - they need to tell that they're running in Windows Terminal, which is not something we've wanted to encourage.

You're absolutely right about that. I'll make sure to keep that in mind, that being in WSL does not guarantee that the path must be Windows-friendly, only that being in WT does. And I'm sure as heck not going to ship anything that forces developers to check if they're in WT.

The edge case that I immediately think of is running WSL from a "Command Prompt" profile.

Is this really that common though? And what would a user expect to happen in this scenario if they opened a "duplicate" tab? Are they expecting it to open a cmd shell starting in the directory they were in in the WSL shell? Even if we did know how to map that, it doesn't seem like a reasonable expectation to me. Unless the path happened to be /mnt/c/something it's probably not even feasible for a cmd shell. I'd think a more reasonable behaviour would be to use the last directory from the base profile, and that's something we could easily do.

In #7668 I choose to move the burden to shells, which make things easier on the terminal side. And yes it can properly handle “running WSL from a "Command Prompt" profile”, since it’s profile-agnostic. James is leaning towards keeping the ugliness inside terminal, in a case-by-case fashion to handle the path transformation in WSL, Cygwin, etc.
One of the reasons why I like the shell approach, is that I feel the ugliness is relatively smaller than the terminal approach. I mean it’s bash/zsh, right? People have already been putting everything in it since those shells were born. The other reason is that during the discussion in #7668 I found that the path transformation isn’t just simple string replacement. To transform the path competently, we need wslpath, which is inside the WSL environment. This just adds even more ugliness in the terminal approach.
Now that I think of it, neither of them is a perfect solution. The tricky part of is the nature of WSL.  It’s so special that none of the VT sequences was ready to handle it.
In conclusion, WSL is, after all, a Microsoft product. If we choose the terminal approach, I think it’s fair to handle it in WT, to make life easier for people. I’m not feeling the same for Cygwin or other kinds of profiles, though.

I mean it’s bash/zsh, right?

No, it's potentially used in other applications too. For example, egmontkob added an option to Midnight Commander that would make it report it's current directory via the OSC 7 sequence too. If we don't implement OSC 7 correctly then we just aren't going to be able to interoperate with apps like that. And if we aren't benefiting from interoperability, then why bother implementing the sequence in the first place?

if we aren't benefiting from interop ... why bother

Fully agree. We should accept what apps generate and attempt to determine, to the best of our knowledge, how to interpret that.
If this means that our autogenerated WSL distribution profiles act better[1] than "User ran wsl.exe from cmd and now something acts silly", I think that I'm willing to accept it.
1: (assuming we do some profile magic to make them "aware" of their namespace prefix)

Great! I think we have an agreement that the terminal approach is the correct way to handle OSC 7.
Still I’d like to make ConEmu’s OSC 9;9 to work. This sequence needs integration from shell at the time it was born. And it’s clearly Windows-first. I’d like to think it a pioneer on our way towards a more complete OSC 7 solution, which presumably takes longer time.
I want people to have a working even though not perfect solution. I’ll copy #7668 to another PR that uses OSC 9;9. Together with all the shell scripts, people can enjoy the CWD feature if they are willing to tweak the shells. Sounds good?

I think we're all in agreement here. Glad this discussion was able to bear fruit after all! I'll close this thread now that we have a path forward with `OSC7. Thanks everyone!


restructure the multi-head attention layer

We can optimize the memory consumption of the multi-head attention layer by combination of layers. By doing this, we could reduce the memory further.

compute multi-head one by one.
re-implement the multi-head attention layer as an backbone layer.

:octocat: cibot: Thank you for posting issue #1998. The person in charge will reply soon.

To list for 1

Enhance split layer to split input by given number(number of head).


Multi-line overbraces push annotated terms out of alignment with equation

Description
2+ line annotations push the math content down, out of line from the rest of the equation. Example:
$ S = overbrace(beta (alpha) S I, "one line") - overbrace(mu (N), "two" \  "line") $

The µ(N) term is out of line with the rest of the equation. This does not happen in the reverse direction with underbraces:
$ S = underbrace(beta (alpha) S I, "one line") - underbrace(mu (N), "two" \  "line") $

I asked about this in the forum and got a fix to this behavior, but I suspect this is not intended behavior.
Reproduction URL
No response
Operating system
macOS
Typst version

[X] I am using the latest version of Typst

Probably not intentional, but this is also abuse of inline math

Sorry, meant to have it as block. I edited my question.

Here's a slightly less hacky workaround
(I've also used the text font for text)
#let mt = text.with(font: "Libertinus Serif")
$ S = overbrace(beta (alpha) S I, #mt[one line]) - overbrace(mu (N), inline(vec(delim: #none,#mt[two],#mt[lines]))) $


Collaboration with ModernFlyouts

Hi @krlvm, Nice project by the way, very useful.
I'm one of the developers of ModernFlyouts, this is a functionality we have been looking into adding for a while, when one of our users suggested a collaboration with your project
I just thought I would enquire whether you would be interested in a collaboration / project merge of some sort?

Hello,
I used ModernFlyouts and developed this project half a year ago when I needed a button on the taskbar that I could double-click to pause or resume playing media, and then added a user interface for it that tried to resemble standard Windows flyouts.
It would be great to incorporate it into ModernFlyouts, although I don't have much experience with C# (mostly Java) and Windows UI development. A significant obstacle may be the code that I wrote quickly and dirty in an effort to complete development as soon as possible.
At the moment, this project has several problems: sometimes strange work and crashes after waking up the PC from sleep mode or changing the user and glitchy animation on Windows 10 from version 19H1 to the release of Windows 11, associated with a bug of an undocumented API used to get the acrylic effect.
I would be glad if it would be possible to solve these problems and merge the projects.

Hi @krlvm, apologies for the delayed response I've been quite busy recently.
ModernFlyouts is built in C# and XAML - winUI 2 Xaml islands hosted in wpf.
Dou have a discord account to discuss this further?


Question: How to write an MSBuild extension that is extensible

Moved from https://github.com/dotnet/sdk/issues/898 on behalf of @AArnott
I'm working to port my CodeGeneration.Roslyn MSBuild extension to .netstandard so that it works under dotnet build. The design is that folks can build on my SDK NuGet package to write their Roslyn-based code generator, and then the end user chains in my build-time NuGet package which "discovers" these code generation extensions and loads the code generator assemblies to do the work on my scaffolding.
In the conversion, I hit two major roadblocks from .netstandard limitations:

Assembly.LoadFile is missing. I understand this is coming in .netstandard 2.0 but is there any supported alternative in the meantime for an MSBuild Task to load some assembly based on its path? I mean, MSBuild Core itself can do it, so how is that done so I can emulate it?
No AppDomain support. This is super useful for two reasons: I can control the version of Roslyn assemblies that are loaded to the ones I was compiled against, thus avoiding assembly load failures. It also lets me unload these extension assemblies when I'm done with them so they don't lock files on disk when the build is over (including VS in proc design-time builds). If MSBuild Core similarly keeps msbuild.exe processes running after a build, we have a significant problem, but if it doesn't, I might omit AppDomain support from just the .netstandard build of this MSBuild Task, then cross my fingers and hope for the best about the Roslyn assembly versions.

Thoughts?

I mean, MSBuild Core itself can do it, so how is that done so I can emulate it?

See CoreCLRAssemblyLoader.cs
cc @tmeschter

Thanks, @nguerrera. I'll target my MSBuild Task to net452 and netcore instead of netstandard then. That works as MSBuild is only either of those and I can already cross target that. The meat of my code is in a netstandard library and can remain that way so that extensions to my extension can remain .netstandard based.
That leaves the AppDomain support question and whether Roslyn assembly versions and "TSR" style OOP build nodes will be a problem. I may find that out myself soon.

Currently, .NET Core MSBuild does not support node reuse (TSR OOP build worker nodes), so that should be fine. We may want to bring it back at some point, but it's not currently on our radar.

Thanks. I can't close this transferred issue, so feel free to close it anyone who can.

I notice that when I compile my MSBuild Task project for net452, the dependency assemblies are copied into the outdir as well. But when I compile for netcoreapp1.0, no PackageReference dependencies get copied in (though ProjectReferences do). Why is that? I'm investigating diagnostic logs now to find a workaround in the meantime because I need all non-platform dependencies regardless of target platform.

I haven't been able to figure this out. I've tried forcing all references to copy local and it doesn't work:
  <Target Name="CopyLocalPackageReferences"
          AfterTargets="ResolveReferences"
          Condition=" '$(TargetFramework)' == 'netcoreapp1.0' ">
    <ItemGroup>
      <Reference>
        <Private>true</Private>
        <CopyLocal>true</CopyLocal>
      </Reference>
      <ReferencePath>
        <Private>true</Private>
        <CopyLocal>true</CopyLocal>
      </ReferencePath>
    </ItemGroup>
  </Target>

I wonder though if this is even the right approach. I'd settle for it, to be sure, if it worked. But CoreCLR patterns are that dependencies can come from the package cache (at least in some cases). And sometimes this can be quite important because suppose I depended on an assembly that varies its implementation based on the operating system it runs on. NuGet can express that, but I can't simply "copy local" all the DLLs into my MSBuild Core task's bin directory and have it run everywhere that msbuild core can.
Is there a supported path for MSBuild Core tasks to have dependencies that are as rich as a CoreCLR app's dependencies can be?

In particular, my MSBuild Tasks dll, when built for netcoreapp1.0, produces a *.deps.json file that it seems (ideally) MSBuild Core or CoreCLR itself could pick up and use to find all the runtime dependencies. Of course somehow these packages would need to have been restored -- without being part of the dependency graph of the app being built.

Ya, the lack of AppDomains on .NET Core is breaking me. MSBuild Core ships with some Roslyn DLLs but not all that I need, so I have to ship some, but unless the versions I ship are exactly the version that MSBuild ships, I'm broken on .NET Core. :(

So after updating the Roslyn my MSBuild task compiles against to match MSBuild Core's (which is just a temporary workaround), I hit a similar issue with Validation.dll. I compile against <IP_ADDRESS>, but another MSBuild extension this test project uses itself depends on <IP_ADDRESS>. And despite CoreCLR's policy (AFAIK) of just loading the DLL it finds and disregarding the version, CoreCLR is only willing to read the <IP_ADDRESS> version (because that came first) and then throws because it can't load the <IP_ADDRESS> version, even though it's right there and could be loaded. So CoreCLR both discriminates on assembly version and isn't willing to load both. Now I don't know what to do.

@AArnott I am not familiar with the details of your problem, but it seems to me that .NET Core version of MSBuild should use a separate AssemblyLoadContext for each build task it loads and load its dependencies to that context to isolate the task from other task dependencies. Is it not doing so currently?

Thanks for your thoughts, @tmat.
Evidently not. The Nerdbank.gitversioning task's Validation.dll is polluting the task I'm working on.
Even if msbuild created separate AssemblyLoadContexts for each Task, would that protect each Task from pulling in the Roslyn assemblies that ship with msbuild?
Is a separate AssemblyLoadContext something my task can create, or is that reserved for just the host?

To copy package dependencies to output, you can use CopyLocalLockFileAssemblies=true. This is defaulted to false for netcoreapp because .NET core has the capability to resolve from nuget cache.

And despite CoreCLR's policy (AFAIK) of just loading the DLL it finds and disregarding the version

The CoreCLR policy is to bind to DLL with >= version, not to disregard version.

it seems to me that .NET Core version of MSBuild could use a separate AssemblyLoadContext for each build task it loads and load its dependencies to that context to isolate the task from other task dependencies. Is it not doing so currently?

It seems it did at one time and there were problems so the default context was used for everything: https://github.com/Microsoft/msbuild/commit/8099cb33cffcd822341edf15167c7f5212b83ac0

Is a separate AssemblyLoadContext something my task can create, or is that reserved for just the host?

AFAIK, you can create them yourself. cc @gkhanna on that and for any other clarification that might help resolve this.
In general, the whole story around deploying an msbuild task via nuget needs significant work. I should be able to package only my assemblies and manifest my dependencies in the package somehow.

you can use CopyLocalLockFileAssemblies=true

Thanks. That worked great.

In general, the whole story around deploying an msbuild task via nuget needs significant work. I should be able to package only my assemblies and manifest my dependencies in the package somehow.

That's what I was starting to realize and hope.

The CoreCLR policy is to bind to DLL with >= version, not to disregard version.

That sounds OK. Except when someone needs version <IP_ADDRESS> and finds it, and loads it. Then later when another assembly needs <IP_ADDRESS> and can find it, but isn't allowed to load it because one is already loaded.

It seems it did at one time and there were problems so the default context was used for everything: 8099cb3
EDIT: I think it previously used one extra non-default load context and not one for each task. Regardless, it seems the problems that blocked that would also block doing one per task.

It seems to me that the use of ALC per task wouldn't be blocked anymore since the CoreCLR bug has been fixed.

Except when someone needs version <IP_ADDRESS> and finds it, and loads it. Then later when another assembly needs <IP_ADDRESS> and can find it, but isn't allowed to load it because one is already loaded.

You can't replace an assembly with another assembly in-place, other than doing EnC on the difference :). I think in a plugin system like msbuild needs to isolate the plugins to different ALCs and only load msbuild assemblies that implement the types used to communicate between the plugins in a default ALC. In such a model each ALC would only load assemblies that are known at build time of the plugin.

Is a separate AssemblyLoadContext something my task can create, or is that reserved for just the host?

AFAIK, you can create them yourself.

Yes, it turns out you can. It's almost trivially easy. I think I might like 'em better than AppDomains. :) One just has to derive from AssemblyLoadContext and then can set whatever assembly resolving policy they want within it. I proved that I can load two versions of the Validation assembly in the same dotnet.exe console app using what I would fully expect to work in an msbuild task.

Implementing an AssemblyLoadContext per plugin in MSBuild was definitely something I thought about while fixing up the MSBuild assembly loading for .NET Core. At the time, however, there were bugs in assembly loading that would have broken scenarios we had to support, and the primary goal was parity with the MSBuilds assembly loading behavior on Desktop.
I think the idea still makes sense once those bugs are worked out (though we would probably want an ALC per folder rather than per task since you can probably assume all the assemblies in a given directory are meant to work together, and you won't have multiple versions of an assembly in the same folder anyway, but that's an implementation detail).
Being able to query a *.deps.json to find the location of a desired assembly would certainly be useful. That functionality should be exposed by .NET Core rather than MSBuild itself, however--you don't really want every app with an extensibility model to reinvent that logic.

Yes, these are fine points. Thanks, @tmeschter.

Being able to query a *.deps.json to find the location of a desired assembly would certainly be useful. That functionality should be exposed by .NET Core rather than MSBuild itself

How do you feel about driving CoreCLR to add such a feature?

@AArnott

I'm not sure this is a free ticket to solve my msbuild task problems though, since msbuild itself and all other tasks run in AssemblyLoadContext.Default, it might be that I can keep my own dependencies pure -- except when they are also found in the default context (and they will be, with the wrong versions). And my understanding is that my load context doesn't get asked if the assembly is already discoverable in the default one.

Your AssemblyLoadContext will only be asked to resolve an assembly when it is requested by an assembly already loaded in that context.
I think what you want to do is separate things out so the task assembly contains very little logic--just enough to create a new AssemblyLoadContext and then use that ALC to load the assembly with the real "meat" of your extension. From that point on your ALC will be called on to resolve everything needed by your extension. I expect it would handle some known assemblies itself, and fall back on the default ALC for everything else.
Does that make sense? If MSBuild itself created per-extension ALCs this wouldn't be necessary, but I think it's workable.

@AArnott

How do you feel about driving CoreCLR to add such a feature?

I don't think I'm the right person for that--I'm back on Roslyn after a brief stint on MSBuild, so I no longer have all the context.

EDIT: except that it copies a bunch of framework assemblies as well that I'm sure msbuild core already ensures are available elsewhere, but I'll live with that for now.

I'm bumping in to this myself: https://github.com/dotnet/sdk/issues/933


1.20.2 when?

really want to use the mod, any idea when .2 will be released?

it updated last week didnt it?

entity refactor branch but not main branch

ahh ight, well cant wait for new update! appreciate the port ty


[Qualcomm feedback] 3.2.2. Platform Hardware Components - Hardware Root-of-Trust : PCIe accessible HROT requirement

Reference: https://lists.riscv.org/g/tech-ap-tee-io/topic/103498833#47
Why impose such functionality on an HROT while all the protocol complexity should be in TSM? Why do TSM and HROT must have an SPDM link in between them? The figure implies that

The idea behind that requirement is to keep the TSM implementation generic and not specific to any platform.
Unlike devices, RP IDE key management is not specified and each RISC-V platform may have its own protocol or interface for that. Having TSM directly support that means we would eventually have to support a growing list of vendor and hardware specific interfaces. On the other hand, RoTs are very much bound to the platform they running on and it seems reasonable to expect them to be able to program RP IDE keys using a platform specific interface. Moreover they are part of the TCB and can securely hold the IDE keys.
So if we want to keep the TSM implementation platform agnostic, have it generate and own the RP IDE keys but delegate the IDE key programming to the RoT, we need to find a way for the TSM to share those keys with the RoT. The PCIe IDE KM protocol is basically designed for that, and relies on SPDM and DOE for doing so.
So I don't think we're burdening the RoT with complexity, but rather preserving the TSM from carrying platform and vendor specific implementations.

So if we want to keep the TSM implementation platform agnostic, have it generate and own the RP IDE keys but delegate the IDE key programming to the RoT, we need to find a way for the TSM to share those keys with the RoT. The PCIe IDE KM protocol is basically designed for that, and relies on SPDM and DOE for doing so.

This is good justification.
Looking at PCIe spec, it allows IDE setup with IDE_KM or vendor specific way.
I think we should allow using both standard and vendor specific implementation.

So if we want to keep the TSM implementation platform agnostic, have it generate and own the RP IDE keys but delegate the IDE key programming to the RoT, we need to find a way for the TSM to share those keys with the RoT. The PCIe IDE KM protocol is basically designed for that, and relies on SPDM and DOE for doing so.

As stated, the propagation of TSM generated IDE keys to PCIe RP is not specified by PCIe. Introducing SPDM as mandatory secure communication vehicle between TSM and RoT may address the problem of platform agnostic TSM implementations but imposes substantial requirements on the RoT which now has to be able to support SPDM. SPDM is fairly new protocol, even more complex to design and verify than TLS. Many of the SPDM design objectives do not really apply for this link (TSM->RP), since here it is about securing a SoC- or platform internal communication path, as opposed to setting up a link from the TSM to an arbitrary device DSM connected via the PCIe network.
We therefore should allow for vendor specific implementations.

This is closed with https://github.com/riscv-non-isa/riscv-ap-tee-io/pull/105


Update Go deps

Codecov Report

Merging #45 (4dd59fe) into main (e93061d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #45   +/-   ##
=======================================
  Coverage   76.78%   76.78%
=======================================
  Files          55       55
  Lines        2098     2098
=======================================
  Hits         1611     1611
  Misses        397      397
  Partials       90       90

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 e93061d...4dd59fe. Read the comment docs.


added memory profiling for training and finetuning runs

Patch Description
Added the ability to generate memory profiling information and save it in the checkpoint directory. Chose to go with PyTorch profiler over other alternatives because of its ability to offer better stack traces.
Testing steps
Ran training for 8m and 125m models to generate traces and observed these traces.

sample out put of memory consumption during training of the 8m model

Please fix the nit before committing


fix: http error to match non 200

it seems that elasticsearch responds with mostly 200 responses when indexing documents, so this specific check for 201s causes a lot of errors to get logged. update the if statement so that 200s don't cause an error to get returned

I don't think we should be checking for both unless we know that it returns both under different conditions. Like if we know it returns a 201 if a new document is created, but 200 if an existing document is updated then great. Otherwise I'd expect it to only return one or the other?


Update export.py

Added model export inference backend options. cpu or cuda. Added validations.
PS. Not tested

torch.cuda.is_available()


[BUG] Harvester 1.3.2 --> 1.4.0 Upgrade Stuck at Pre-Draining: "upgrade-repo-hvst-upgrade-xxxxx" VM cannot migrate to another host

Describe the bug
When upgrading Harvester from 1.3.2 to 1.4.0, the upgrade hangs at a pre-draining phase for the first node.  Investigating shows a VM that has been created on the first node called "upgrade-repo-hvst-upgrade-546w8" (presumably generated by the upgrade process).  The VM switches between a running and migrating state with an error of "NoSuitableNodesForHostModelMigration: Migration cannot proceed since no node is suitable to run the required CPU model..."
To Reproduce
Steps to reproduce the behavior:

Create a running, 3-node Harvester cluster on v1.3.2
Wait for the upgrade button to be displayed
Attempt to perform the upgrade
Observe the hang in the pre-drained state

Expected behavior
The upgrade should complete without issue.
Support bundle
Can be provided on request through a OneDrive share (too large to attach here)
Tokens, passwords, and secrets are automatically removed from support bundles. If you feel it's not appropriate to share the bundle files publicly, please consider:

Wait for a developer to reach you and provide the bundle file by any secure method.
Join our Slack community (https://rancher-users.slack.com/archives/C01GKHKAG0K) to provide the bundle.
Send the bundle to<EMAIL_ADDRESS>with the correct issue ID.  -->

Environment

Harvester ISO version: 1.3.2
Underlying Infrastructure:  3 each Dell R740XD

Additional context
I suspect that disparate CPU models may be to blame here.  The servers have the following CPU:
harvester-01	Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz

harvester-02	Intel(R) Xeon(R) Gold 5118 CPU @ 2.30GHz

harvester-03	Intel(R) Xeon(R) Gold 5118 CPU @ 2.30GHz

The Harvester upgrade VM is initially placed on the harvester-01 server, which has a different CPU type than the other two servers.
In reviewing the log message of the VM, the CPU tags that it is trying to match when migrating to a different host are as follows:
 required features: map[cpu-feature.node.kubevirt.io/amd-ssbd:true cpu-feature.node.kubevirt.io/amd-stibp:true cpu-feature.node.kubevirt.io/arch-capabilities:true cpu-feature.node.kubevirt.io/hypervisor:true cpu-feature.node.kubevirt.io/ibpb:true cpu-feature.node.kubevirt.io/ibrs:true cpu-feature.node.kubevirt.io/ibrs-all:true cpu-feature.node.kubevirt.io/invtsc:true cpu-feature.node.kubevirt.io/md-clear:true cpu-feature.node.kubevirt.io/mds-no:true cpu-feature.node.kubevirt.io/pdcm:true cpu-feature.node.kubevirt.io/pku:true cpu-feature.node.kubevirt.io/pschange-mc-no:true cpu-feature.node.kubevirt.io/rdctl-no:true cpu-feature.node.kubevirt.io/skip-l1dfl-vmentry:true cpu-feature.node.kubevirt.io/ss:true cpu-feature.node.kubevirt.io/stibp:true cpu-feature.node.kubevirt.io/tsc_adjust:true cpu-feature.node.kubevirt.io/tsx-ctrl:true cpu-feature.node.kubevirt.io/umip:true cpu-feature.node.kubevirt.io/vmx:true cpu-feature.node.kubevirt.io/xsaves:true cpu-model-migration.node.kubevirt.io/Cascadelake-Server:true]

Note the Cascadelake-Server:true requirement.  The Intel Gold 5218 is Cascade Lake based, while the Intel Gold 5118 is Skylake-based.  This is likely why the VM is not migrating successfully.
Regardless of the underlying CPU architecture on the host, the VM should still be able to run on any of these three nodes.

@zanewgray For now, there is a workaround at https://github.com/harvester/harvester/issues/3015#issuecomment-1455923329. See if it helps, assuming that your workload can run on both CPU models.

The upgrade-repo VM provides upgrade-relevant metadata and image archives, so shutting it off and bringing it up again should be okay. It will be scheduled to other nodes that are not under pre-draining. Live-migrating the upgrade-repo VM is just good to have but not required.

Can anyone share the kubectl command to shutdown VM, please?

AFAIK, from KubeVirt's viewpoint, deleting the VMI resource can reboot the virtual machine. It's quite like the "destroy domain" vibe in the libvirt world. The good part of it is it will try to gracefully shut down the virtual machine. But I think the best way is to download the virtctl binary and use it to operate the virtual machine.


Improve performance of SqlString.escape()

Strategies include:

Manually escaping strings rather than using a string replace function with a regex
Only calling typeof on the input value once
Not performing extra type checks if the input type has already been determined

Benchmark
See this gist for the code.

Value
Before (ops/sec)
This PR (ops/sec)
Speedup (PR/before)

'string'
3,471,750
9,132,497
2.63

'line\nbreak'
1,411,773
4,783,601
3.39

'to \'escape\''
1,201,451
3,894,069
3.24

'supercalifragilisticexpialidocious'
3,418,065
3,684,563
1.08

'"supercalifra\r\ngilisticexpi\talidocious"'
997,873
2,067,678
2.07

'Lorem ipsum...id est laborum.'
1,459,101
355,183
0.24

Nice! Code certainly looks weird with the slicing, but I guess if it's faster... :) And thanks a lot for providing that gist with the benchmark code! That would allow us to play with this a bit, for example, to test how it changed very long strings instead of just short ones (only because I have in the past seem optimizations that help one case, but really hurt another case), to have a better overall idea. Otherwise, I think it should be merged soon!

Thanks! And that's a good idea. I updated the benchmark to include longer strings and it looks like the longer the string gets, the slower my implementation becomes. Would you agree that I should use the original code as a fallback for long strings?

Perhaps. Are you saying that the longer the string becomes, the more this change actually becomes a de-optimization compared to the original implementation?
I have tried a few times to do "magic numbers" where an implementation will flip to a different one (where one is faster for the short case and one is faster for the long case), but it can sometimes be hard to really know at which number to make the flip (the number may very well different depending on the v8 engine version).
I guess one question I would ask myself is "is this the most optimal implementation, or was it coincidentally optimal for some small case?" What I mean by that is I have seen, when only looking at the small case, that sometimes there are different implementations that can get both short and long cases that were just not immediately obvious when only focusing on the short case.
Anyway, I think that, at the very least, probably adding a magic implementation switch would be good, but also if you want to think some more on the optimization, feel free :)

Yes, that is what I meant to say.
Unfortunately the only optimizations left that I know of are micro-optimizations, and their small performance benefits are not worth making the code less readable. I know my current implementation cannot be optimized further because of the following: The case where the .replace() call is much faster is when the input is a long string that doesn't have any characters to be escaped, so a majority of my code never get's used. In that case, even if I take out all of the unused code, the .replace() method is still about 4x faster (against "Lorem Ipsum"). For reference, here's what my code would look like without the unused code:
function escapeString(val) {
  for (var i = 0; i < val.length; i++) {
    switch (val.charCodeAt(i)) {
    }
  }
  return "'" + val + "'";
}

So in that sense, it cannot be optimized more. However, this gives us a better idea of why my method is faster when either a) the string is short, or b) the string has many characters that need to be escaped. I'm assuming my method is faster because it is 100% client JS where as with .replace() it has to go back and forth between the client code/provided callback and the V8 internals. With the long, plain string, .replace() wins because it only goes into the V8 internals once, and the V8 code is faster than just JS code.
Now there are two things that can still be done. The first is trying to find the magic number. The second is putting this somewhere:
if (!/[\0\b\t\n\r\x1a\"\'\\]/.test(val)) {
  return "'" + val + "'";
}

Even though that reduces performance a little for short strings and strings that contain characters that need to be escaped, it greatly improves performance for longer strings that do not contain characters that need to be escaped.
One option is to optimize more for the common cases without de-optimizing the rarer cases. Do you have any suggestions on what the common cases might be? From what I've seen, most strings don't have any of those characters that need escaping.

Awesome, I love this research :)

Do you have any suggestions on what the common cases might be?

That is definitely a good question, and I'm not too sure off-hand. Just thinking about some of my MySQL usages that are out there, most of my calls to .escape is just with a number primitive, with the second most being strings. From the string perspective, I image the vast majority do not conain any characters that need to be escaped, even long strings. If they do have characters that need to be escaped, it would be due to the single or the double quote characters. Certainly the cases where I am using long strings are typically going to be storing some kind of serialization, either HTML or JSON, both of which typically contain many double quote characters (and single quotes for HTML).
So from just thinking out loud to myself, perhaps a more common case for long strings would be (1) nothing is being escaped at all (perhaps it's some kind of simple CSV?) (2) there are lots of escaped characters within the string. I wonder (2) fares over all.
Also, on the note of optimizations, I noticed that in this module, that giant regular expression is a literal within the function. I feel like I've heard that doing that is not great for v8, and that hoisting the regular expression out and into a global helps a lot. I wonder how much that would help here. The function in the .replace could also potentionally be hoisted out since it doesn't close over any variable.
Another thing is that I usually find that regular expressions are very fast to execute in the v8 engine. I wonder if there is a way to replace that for loop with a regular expression that finds the next character to escape, rather than looking up the char code for each character? Perhaps that's what's eating up all the time in the new function. I'm thinking something along the lines of:
var chars = /[\0\b\t\n\r\x1a\"\'\\]/g;
function escapeString(val) {
  chars.lastIndex = 0;
  var match;
  while((match = chars.exec(val))) {
    switch (val.charCodeAt(match.index)) {
    }
  }
  return "'" + val + "'";
}

That is probably pretty cose to what .replace does internally, though not sure if it's faster or not :)

Based on your suggestions, I created a new benchmark. The benchmark tests 4 possible solutions:

escapeString0 - The same as the current solution but with the regex and callback hoisted
escapeString1 - Loops over each character and slices + replaces if it sees a character that needs to be escaped (the solution currently in this PR)
escapeString2 - The same as escapeString1 but returns early if a regex determines that the string has no characters that need to be escaped.
escapeString3 - Uses regex.exec() to jump to the parts of the string that need to be escaped and slices + replaces

Here are the results I got with Node v6 (V8 5.0):

0: 'lastname'
$ node escapeString.js 0
escapeString0 x 5,351,206 ops/sec ±0.64% (90 runs sampled)
escapeString1 x 9,682,148 ops/sec ±0.54% (90 runs sampled)
escapeString2 x 9,878,574 ops/sec ±1.02% (85 runs sampled)
escapeString3 x 10,784,952 ops/sec ±0.56% (90 runs sampled)
Fastest is escapeString3

1<EMAIL_ADDRESS>$ node escapeString.js 1
escapeString0 x 4,964,859 ops/sec ±0.46% (90 runs sampled)
escapeString1 x 5,930,044 ops/sec ±0.56% (93 runs sampled)
escapeString2 x 11,861,430 ops/sec ±0.64% (89 runs sampled)
escapeString3 x 11,503,335 ops/sec ±0.52% (92 runs sampled)
Fastest is escapeString2

2: 'line\nbreak'
$ node escapeString.js 2
escapeString0 x 2,118,420 ops/sec ±1.23% (88 runs sampled)
escapeString1 x 5,347,677 ops/sec ±0.70% (88 runs sampled)
escapeString2 x 4,134,228 ops/sec ±0.58% (88 runs sampled)
escapeString3 x 3,796,514 ops/sec ±0.43% (93 runs sampled)
Fastest is escapeString1

3: '"supercalifra\r\ngilisticexpialidocious"'
$ node escapeString.js 3
escapeString0 x 1,348,827 ops/sec ±0.70% (89 runs sampled)
escapeString1 x 2,245,956 ops/sec ±0.46% (91 runs sampled)
escapeString2 x 2,240,128 ops/sec ±0.62% (89 runs sampled)
escapeString3 x 1,576,402 ops/sec ±0.52% (89 runs sampled)
Fastest is escapeString1

4: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.'
$ node escapeString.js 4
escapeString0 x 1,576,430 ops/sec ±1.03% (86 runs sampled)
escapeString1 x 365,171 ops/sec ±1.26% (88 runs sampled)
escapeString2 x 2,011,189 ops/sec ±0.53% (90 runs sampled)
escapeString3 x 2,030,396 ops/sec ±0.61% (90 runs sampled)
Fastest is escapeString3

5: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.\nUt enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.\nDuis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.\nExcepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.'
$ node escapeString.js 5
escapeString0 x 635,228 ops/sec ±0.57% (89 runs sampled)
escapeString1 x 297,829 ops/sec ±0.63% (84 runs sampled)
escapeString2 x 309,280 ops/sec ±0.50% (89 runs sampled)
escapeString3 x 1,028,440 ops/sec ±0.56% (88 runs sampled)
Fastest is escapeString3

6: '{"name":"John Brown","id":123456789,"now":"2016-04-30T02:27:34.096Z","settings":{"on":true,"value":5,"defaultView":"activity"}}'
$ node escapeString.js 6
escapeString0 x 372,327 ops/sec ±0.78% (89 runs sampled)
escapeString1 x 466,481 ops/sec ±0.48% (93 runs sampled)
escapeString2 x 467,594 ops/sec ±0.60% (89 runs sampled)
escapeString3 x 330,521 ops/sec ±0.45% (94 runs sampled)
Fastest is escapeString2,escapeString1

The results are pretty interesting. The performance of each method seems to be a function of the string length and the ratio of escape characters to normal characters. escapeString0 and escapeString3 are slower when there are a lot of characters that need to be escaped and escapeString1 and escapeString2 are slower when the string is longer than ~25 characters and there are few characters to escape. escapeString2 is always fast when there are no characters to escape and escapeString3 is always fast when there are no or few characters to escape.
I feel like strings 2 and 3 are less common, but it's still helpful to see how each solution performs on them. String 5 is fairly common for things that involve messaging or commenting.
Based on that, I think escapeString2 and escapeString3 are the best candidates, although escapeString3 is the worst with JSON.

@dougwilson I took your suggestion and used it to create a solution that is faster in all cases (with the help of this benchmark - which I had previously made a comment about on this PR but removed because it was outdated and added too much noise here). I updated the code and the benchmark results in the description of this PR.

@nwoltman awesome!


Add "X modules reloaded in Y time" feature (default?)

I was playing around with timing how long ghcid takes given certain runtime flags and had to do:
date && ghcid

Then copy the start time, copy the time that ghcid loaded, and subtract the difference.
It would be nice if ghcid already did this for us because we could pay attention to things like how ghc versions affect ghc reload time and get a better feel on how new modules/packages affect ghcid responsiveness.

Happy to take a patch.


Changed onError() to setErrorHandler()

As per the discussion here: https://github.com/async-interop/event-loop/issues/33
There was some talk in the discussion about whether you would be able to enable/disable/reference/unreference this and treat it like other events.
This PR doesn't do that, because I think it raises a few complications (are error handlers automatically unreferenced?) that might lead to bugs and ultimately doesn't add any functionality.
If anyone disagrees with my assessment, feel free to thumbs down here and we'll move the discussion back to the issue.

The PR should probably mention in the docblock what null does. (reset)

@kelunik - It says:
"Setting the callback to null will clear the error handler. "
Do you mean in the @param annotation?

OH, missed that. Would probably move it to @param, yes.

@AndrewCarterUK Do you want to move it into the @param?

@AndrewCarterUK Could you rebase to current master?

Can do, will have to be Sunday morning because I'm not around until then.
If anyone wants to take over, the branch is under the async-interop group, so you should all be able to write to it. I'm happy for someone to merge after it's been rebased and the @param annotation has been cleared up.

Rebased, ready to merge.

Merged :+1:


AWS Multi Pem Cluster

Hello,
I have a question.
I have a lot of servers in different regions on AWS. So my connections commands like this.

alias capinv6="ssh -i '/Users/murat/Downloads/x.pem'<EMAIL_ADDRESS>alias capinv7="ssh -i '/Users/murat/Downloads/x.pem'<EMAIL_ADDRESS>alias capinv5="ssh -i '/Users/murat/Downloads/y.pem'<EMAIL_ADDRESS>alias capinv4="ssh -i '/Users/murat/Downloads/y.pem'<EMAIL_ADDRESS>alias capinv3="ssh -i '/Users/murat/Downloads/z.pem'<EMAIL_ADDRESS>alias capinv2="ssh -i '/Users/murat/Downloads/z.pem'<EMAIL_ADDRESS>alias capinv1="ssh -i '/Users/murat/Downloads/z.pem'<EMAIL_ADDRESS>
How can I create a cluster to open these connections with a single command?
Thanks for your help,
Murat

Even though there's an extra option in i2cssh you can use to set the priv key (-Xi=x.pem or -Xi=y.pem, etc), this doesn't apply to hosts, but only to global options or per cluster. In your case I'd use your ssh config file (~/.ssh/config) and add different IdentityFiles for each host (or subnet). In your case you'd have something like:
Host 35.180.999.99
  User ubuntu
  IdentityFile /Users/murat/Downloads/x.pem

Host 13.39.999.99
  User ubuntu
  IdentityFile /Users/murat/Downloads/y.pem

And if your identity files map to different subnets, you can even fo something like
Host 13.39.*
  User ubuntu
  IdentityFile /Users/murat/Downloads/y.pem

For the i2ssh config you would just do:
version: 2
clusters:
  mycluster:
    hosts:
      - 35.180.999.99
      - 13.39.999.99
      - 52.47.999.99
      - ...

Also, thank you for the question, because I found a bug with parsing the extra from the config file :)

Thank you very much 🚀

My pleasure!


Inventory Item Inspect Mouse Error

When panning an object with a right click, as soon as you let go the mouse always 'teleports' to the left side of the screen. It does it during Item Inspect and during the primary Inventory screen.

Details
Inventory Inspect, Right-Click. Using 3440 x 1440 21:9 resolution.
Game Version
1.7.23
New Game
Yes
Reproduction Steps
As soon as you finish Character Creation, just press I to go into your inventory and right-click in the open space to try and pan, let go and you will see it.

This issue is valid, however I suspect it would be an engine-level problem.

Out of scope due to engine-level fix.


fix group text action collision with another datagrid

When you have 2 datagrid on one page. You can find this problem. Problem is with addGroupTextAction. Te hidden text input has same class as all datagrids. When you use group action on 2nd datagrid and 1st datagrid has addGroupTextAction too, text input is opens on 1st datagrid. This fix solves it using  unique classes. (2nd way is edit JS)

I think it's already fix, right @paveljanda?

I am not sure about it. I will test it.

It's broken still in v5.x and also in master. @Matousek thanks a lot!


Removes approver constraint for tier 0 zookeeper

Isn't there a test that checks tier 0s have an approver? I think we have to remove the unit test now.


add scroll to top when clicking on intra-page link

As per @bartekn's suggestion in https://github.com/stellar/laboratory/pull/142
Clicking on the buttons linking to other pages will make sure the user is scrolled to the top

👍

+1


How can I get the number of unique arrays

Hello,
Having a table like:
CREATE TABLE test_array2 (arr Array(Nullable(Float64))) ENGINE = Memory;
INSERT INTO test_array2(arr) values ([1,2]),([3,4]),([5,6]),([7,8]);

How Can I get number of unique arrays ? Seems uniq is not working with array fields
Silviu

Maybe try arrayUniq Function ?

This function returns if I'm not wrong unique elements across all arrays.
not unique arrays for example if I have [1,2], [3,4], [5,6] I expect 3 but
returns 6 (1,2,3,4,5,6)
Silviu
On Thu, Mar 8, 2018 at 11:10 AM, 张健<EMAIL_ADDRESS>wrote:

Maybe try arrayUniq Function ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/yandex/ClickHouse/issues/2010#issuecomment-371426078,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEl3i90vTJoaOzzKHahqbEamF5Hbg4NZks5tcPVxgaJpZM4SiSLU
.

Not yet, I had almost fixed this.

Hello @alexey-milovidov  any idea when this bug will be fixed ?

It was left unfinished, but thank you for reminder, I'll try to keep up!


Move to native context menu

@shcheklein commented

Context menus in VS Code look different (have borders that give them better contrast)

Let's compare the current menu style with the latest UI changes and see if there is a better solution.

This is coming soon: https://github.com/microsoft/vscode/issues/54285
We should invest some time into seeing if it will be possible for us to use it or not.

Sounds great @mattseddon , so what would be the next step?

Allocate engineering resources to look at the API and decide whether or not we can migrate from our custom context menus.

This is what needs to be looked at: https://github.com/microsoft/vscode/issues/54285#issuecomment-1242267823

Way to much scope, not clear if it's needed atm.


Element var in properties dialog constructor undefined

When I tried to compile the coffeescript I got an error saying the 'element' var in properties.coffee was undefined. I moved the var to the context of this by adding the @ symbol.

Thanks for that :+1:


German translation done

This ist the German translation of the en.json file. Checked translations in configuration form: Looks good and does not break lines.

Wow fantastic thank you so much! @brockhaus - feel free as well to put your nickname in the maintainer of that language if you would like (completely optional). Will test it out and release soon!


Cartesian3 use teme or ecef or other

Thanks for contributing to the Cesium Community!
If you have a question, please search the forum:
http://cesiumjs.org/forum.html
and start a new forum thread, if needed, instead of creating this issue.
Otherwise, we look forward to your bug report or feature request in this issue.

Delete this message before clicking Submit.

Hi @Carolineliu. Yes, Cartesian3 objects without any transforms applied use ECEF.
Generally, please ask questions over at the Cesium Forum.  There are members of the community and developers from the team who answer these kinds of questions there. Additionally, Cesium's a big project, so we use GitHub for feature requests and bug tracking exclusively. Thanks!


Integration and API Testing

Based on the API testing script by Akiff

Script is working, next step is figure out how to run it in a GHA

It may be possible to speed things up a bit by starting up von-network and aries-vcr in parallel, though you would need a way to sync the two since the aries-vcr agents need to connect to the ledger.  There is currently no official way to run steps in parallel, although there are a couple workarounds mentioned here; https://github.community/t/steps-in-parallel/16343

What about using one of the BCovrin instances instead of von-network?

What about using one of the BCovrin instances instead of von-network?

I like the fact that the tests are independent of any hosted ledger - personal opinion.

The only difference is that with a local von-network we use the same DID (and therefore cred def id) on everyrun, whereas with a persistent ledger we need to create a new (different) DID for each run.  As long as these differences don't leak into the aries-vcr api output then it's no issue using one of the bcovrin ledgers.

Switched the tests to use the dev bcovrin ledger.  Personally I prefer using the built-in/local von-network, as the bcovrin ledger introduces an external dependency to the tests.  Running a local von network adds 30-40 seconds out of about 9 minutes overall to run the full process.

I was only suggesting that because there was some question about the scripts not running because there was too much going on.  I'm good with a local ledger as long as it doesn't break the process.  Sorry if that wasn't clear.


New Argument Passing Syntax Doesn't Support List-style Objects

I've recently discovered that a common pattern
let ids = [ 1; 2; 3 ]
Orm.selectWhere state None ( """id in (:1)""", [ ids ] )

Is not supported. Unfortunately, to address this, we're going to have to allow any object to be passed in and match on the reflected type. Slow, but the only way to support this pattern... which needs to be supported.
Also, while I want to ensure speed and use arrays, forcing it on the user can be cumbersome. Let's genericise the type to a seq and let the user decide.

resolved by #25


Add support for custom user claim name

This adds support for setting a custom user claim name. The default remains user_name.

@gavingolden Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@gavingolden Thank you for signing the Contributor License Agreement!

Thank you for the PR @gavingolden. This is now in master.


Add cross hairs to charts

Will give users an indication that they can zoom in on the charts if they want to

Done!


[9.x] Add class support for console routing

Currently, Artisan::command() only supports closure as the second parameter. With this PR, it enables http route-style such as:
Artisan::command('cli', [ClassName::class, '__invoke'])

~I'd like to add some test but I'm not sure how considering the ClosureCommand this class is mostly based on doesn't have test associated with it.~ Found the tests
Code for callable class binding is from https://stackoverflow.com/a/71010794

If you are making a class anyways I would just define the signature in the class and register it like normal.

If you are making a class anyways I would just define the signature in the class and register it like normal?

I've been doing that but one needs to register the class in the Console\Kernel instead. This adds api surface to allow callable class--in addition to closure--to be registered in the routes/console.php, similar to http routes.

Added some test, but it seems the class binding failed in php 8.1.

I'm on some kind of break. I'll retry/update this sometime soon.

Tracked the error on prefer-lowest test fail due to changes on serializer
https://github.com/laravel/serializable-closure/compare/v1.0.5...v1.1.0


[Enhancement] Support expression conversion of struct sub-column in Iceberg

Fixes #issue
What type of PR is this:

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[FE Incremental Coverage Report]
:heart_eyes: pass : 19 / 20 (95.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/connector/iceberg/ScalarOperatorToIcebergExpr.java
19
20
95.00%
[426]

@mergify backport branch-3.2

@mergify backport branch-3.1

backported to 3.1 by PR https://github.com/StarRocks/starrocks/pull/33898


Improve README and add CONTRIBUTING

Most students won't know how to build a VSCode extension.  We need some proper docs on which resources to use, how to use the dev environment, how to contribute, etc.

I will be working on this. Please assign this to me.


Exception AndroidKeyStoreRSAPrivateKey

I am unable to decrypt in your app.  See this exception:

Hello Im facing the similar error , any solution?


0.x ci update

motivation: 5.6 is out
changes:

use release version of 5.6
add docker setup for 5.7 (using nightly for now)

@swift-server-bot test this please


[Color Picker- Editor]: Color Contrast ratio of 'Copy to Clipboard' button is 1.695:1 which is less than 3:1.

Microsoft PowerToys version
"0.41.1"
Running as admin

[ ] Yes

Area(s) with issue?
ColorPicker
Steps to reproduce
Test Environment:
OS: Windows 10 Version Dev
App version: 0.41.1
App name: PowerToys
Screen Reader: Narrator
Tool: Accessibility Insight for Windows
Repro Steps:

Launch 'PowerToys' application.
Navigate to 'Color Picker' tab.
Then Open 'Color Picker' using defined Shortcut key.
Pick any color.
Inside Color Picker Editor, Navigate to 'Copy to Clipboard' button.
Check its Color Contrast and Observe the issue.

User Impact:
Low vision user are impacted here as they will not able to see control properly as luminosity ratio is not good.
WCAG Reference:
https://www.w3.org/TR/WCAG21/#non-text-contrast
Attachment:

✔ Expected Behavior
Color Contrast ratio of 'Copy to Clipboard' button should be greater than and equal to 3:1.
❌ Actual Behavior
Color Contrast ratio of 'Copy to Clipboard' button is 1.695:1 which is less than 3:1.
Other Software
No response

This feels like a fairly straight-forward fix. Placing in 0.45 so we can continue prioritizing crashing bugs for the next release.


unconditional synthesis on external dataset

Hello,
I am working on a project aimed at generating drum loops conditioning only on global class labels (without neural vocoding on mel-spectrograms). I modified the diffwave model of this repository:
https://github.com/lmnt-com/diffwave/tree/master/src/diffwave
and I encountered the same issue of more users, that is, unconditional generation doesn't seem to work. I was wondering if the outdated S4 layer of this repository is a serious enough problem to dissuade me from even attempting to train the diffwave+sashimi model from scratch on my drum loops dataset. If that is, may I ask how long could it take for the model to reach a stable version for training on external data? Is there a problem preventing the stable v2 version of the S4 layer from working with Diffwave? I hope my question isn't too out of place. I'm excited to properly try the model once it's functional

Yes, I also originally found that the lmnt-com repo doesn't work for unconditional generation before switching to the philsyn repo.
The S4 layer of this repository is a stable version. It's up to date with something close to the most recent released version (V3). You should be able to train either Diffwave+Wavenet or Diffwave+Sashimi from scratch from the master branch.
You may have gotten confused by the README claiming the models are outdated, but note that that section of the README applies only to the pretrained models on the checkpoints branch. I made minor wording adjustments to the README to try to clarify this, but let me know if it's still unclear.

Thank you a lot, I was exactly pushed to ask for clarifications after reading the README section with the warning about training from scratch. Now it's much clearer and I'm relieved to know I can rely on the model for my experiments


Angular CLI does not work with Protractor 6

Bug report
After upgrading from version 5.4.2 to version 6.0.0, when I try to run ng e2e it fails with the following:
Cannot automatically find webdriver-manager to update.
Update webdriver-manager manually and run 'ng e2e --no-webdriver-update' instead.
Error: Cannot automatically find webdriver-manager to update.
Update webdriver-manager manually and run 'ng e2e --no-webdriver-update' instead.
    at ProtractorBuilder._updateWebdriver (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular-devkit/build-angular/src/protractor/index.js:83:23)
    at MergeMapSubscriber.rxjs_1.of.pipe.operators_1.concatMap [as project] (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular-devkit/build-angular/src/protractor/index.js:26:200)
    at MergeMapSubscriber._tryNext (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular-devkit/build-angular/node_modules/rxjs/internal/operators/mergeMap.js:69:27)
    at MergeMapSubscriber._next (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular-devkit/build-angular/node_modules/rxjs/internal/operators/mergeMap.js:59:18)
    at MergeMapSubscriber.Subscriber.next (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular-devkit/build-angular/node_modules/rxjs/internal/Subscriber.js:67:18)
    at MergeMapSubscriber.notifyNext (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular-devkit/build-angular/node_modules/rxjs/internal/operators/mergeMap.js:92:26)
    at InnerSubscriber._next (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular-devkit/build-angular/node_modules/rxjs/internal/InnerSubscriber.js:28:21)
    at InnerSubscriber.Subscriber.next (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular-devkit/build-angular/node_modules/rxjs/internal/Subscriber.js:67:18)
    at SafeSubscriber.__tryOrUnsub (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular/cli/node_modules/rxjs/internal/Subscriber.js:209:16)
    at SafeSubscriber.next (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular/cli/node_modules/rxjs/internal/Subscriber.js:147:22)
    at Subscriber._next (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular/cli/node_modules/rxjs/internal/Subscriber.js:90:26)
    at Subscriber.next (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular/cli/node_modules/rxjs/internal/Subscriber.js:67:18)
    at SafeSubscriber.__tryOrUnsub (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular-devkit/build-angular/node_modules/rxjs/internal/Subscriber.js:209:16)
    at SafeSubscriber.next (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular-devkit/build-angular/node_modules/rxjs/internal/Subscriber.js:147:22)
    at MergeMapSubscriber.notifyNext (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular-devkit/build-angular/node_modules/rxjs/internal/operators/mergeMap.js:92:26)
    at InnerSubscriber._next (/home/francesco.borzi/sources/ngx-duration-picker/node_modules/@angular-devkit/build-angular/node_modules/rxjs/internal/InnerSubscriber.js:28:21)

Switching back to 5.4.2 solves this issue for me.
Here some information about my system:
Angular CLI: 7.3.7
Node: 10.15.3
OS: linux x64
Angular: 7.2.11
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.13.7
@angular-devkit/build-angular     0.12.4
@angular-devkit/build-optimizer   0.12.4
@angular-devkit/build-webpack     0.12.4
@angular-devkit/core              7.3.7
@angular-devkit/schematics        7.3.7
@angular/cli                      7.3.7
@ngtools/webpack                  7.2.4
@schematics/angular               7.3.7
@schematics/update                0.13.7
rxjs                              6.4.0
typescript                        3.2.4
webpack                           4.28.4

This is because the Angular CLI does not currently support Protractor 6 yet. I did let one of the maintainers know things were changing.

Blocked. Still need to release a working version of Protractor 6 and coordinate with the CLI team.

Any update on this :question:

Any update on when resolution or workaround?

Any hope of getting this resolved for Angular 7?  I am trying to test an app which uses Material, and it seems that Chrome driver does not work correctly in some situations (angular/components#9755).  The Gecko driver works as expected, however it throws error in ci environment due to angular/webdriver-manager#303.  This appears to have been corrected in version 13.0.0, and is now available in angular/protractor#5209.  I know v7 is in LTS, but would still be nice to get a fix for it.

More info: the Angular team will be responsible for the next release of Protractor. It will be published when they are ready.

@cnishina any info on the approximate release date?

I do not. I'm still working on cleaning up webdriver-manager and there is one outstanding bug + documentation for Protractor. This isn't my main focus so it's difficult to tend to these things on my free time.

@cnishina, thank you. And thank you for the work you do.

Is it possible to release the webmanager v13 as part of Protractor v5 so we can take advantage of it now?

Hi I'm using 5.4.2 and my tests were working till yesterday! there is some walkaround? @cnishina

I've just given a try again and the problem is still there. Are there any news on this?
Angular CLI: 9.0.0-rc.5
Node: 10.16.1
OS: darwin x64

Angular: 9.0.0-rc.5
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.900.0-rc.5
@angular-devkit/build-angular     0.900.0-rc.5
@angular-devkit/build-optimizer   0.900.0-rc.5
@angular-devkit/build-webpack     0.900.0-rc.5
@angular-devkit/core              9.0.0-rc.5
@angular-devkit/schematics        9.0.0-rc.5
@ngtools/webpack                  9.0.0-rc.5
@schematics/angular               9.0.0-rc.5
@schematics/update                0.900.0-rc.5
rxjs                              6.5.3
typescript                        3.6.4
webpack                           4.41.2

Had the same error message during ng e2e, turned out you need to add Protractor to the devDependencies:
npm add --save-dev protractor

Had the same error message during ng e2e, turned out you need to add Protractor to the devDependencies:
npm add --save-dev protractor


Regarding colorizing gray names

What should be added?

The option "Colorize users without color set (gray names)" should be off by default instead of on.
Why should it be added?

People who are new to twitch get very confused with the grey usernames that are in chatterino. Making the default to be colorized makes more sense since you get less question from the newer people who start out with chatterino. For people who already use chatterino they know there is probably a setting to enable that.


Update pandas_dataframe.py

Added a secondary way of loading records into a pandas dataframe.

That's a useful example. Thanks you!


Shapes using a Dictionary to store data leak memory

Certain collision shapes have memory leaks originating from the Dictionary that is used to store their data. The simple script below illustrates the problem:
extends Node

# Leaks
func _process(delta):
	for i in 1000:
		var cap := CapsuleShape3D.new()

# Doesn't leak
func _process(delta):
	for i in 1000:
		var box := BoxShape3D.new()

I don't have the ability to test this for myself right at this moment, but do you see the same behavior if you use Godot Physics?

There is no leak using Godot Physics

0.13.0-stable has just been released, which includes the fix for this.
Note that the release in the Godot Asset Library is still pending approval as of typing this, so you might need to download it from the link above.


DBZ-6787  Dedupe table list while incremental snapshot

@jpechane @mfvitale What would be the correct way to test this ? I could only see integration tests for this class and also thre unit tests are there but they are there only for the buildChunkQuery part.

@mfvitale / @jpechane
It is right now not feasible to add test for this case. The reason being if we add a test like this --
@Test
    public void snapshotWithDuplicateDataCollections() throws Exception {
        populateTable();
        startConnector();
        sendAdHocSnapshotSignal(tableDataCollectionId(), tableDataCollectionId());

        final int expectedRecordCount = 2*ROW_COUNT;
        Testing.Debug.enable();
        final Map<Integer, Integer> dbChanges = consumeMixedWithIncrementalSnapshot(expectedRecordCount);
        for (int i = 0; i < expectedRecordCount; i++) {
            assertThat(dbChanges).contains(entry(i + 1, i));
        }
    }

in AbstractIncrementalSnapshotTest.java
Then the problem is the function consumeMixedWithIncrementalSnapshot stores the consumed entries in a map. So, even thought we receive double the entries here, we are not able to consume 2*ROW_COUNT entries.
This needs to be refactored to fix this.

@mfvitale / @jpechane It is right now not feasible to add test for this case. The reason being if we add a test like this --
@Test
    public void snapshotWithDuplicateDataCollections() throws Exception {
        populateTable();
        startConnector();
        sendAdHocSnapshotSignal(tableDataCollectionId(), tableDataCollectionId());

        final int expectedRecordCount = 2*ROW_COUNT;
        Testing.Debug.enable();
        final Map<Integer, Integer> dbChanges = consumeMixedWithIncrementalSnapshot(expectedRecordCount);
        for (int i = 0; i < expectedRecordCount; i++) {
            assertThat(dbChanges).contains(entry(i + 1, i));
        }
    }

in AbstractIncrementalSnapshotTest.java
Then the problem is the function consumeMixedWithIncrementalSnapshot stores the consumed entries in a map. So, even thought we receive double the entries here, we are not able to consume 2*ROW_COUNT entries.
This needs to be refactored to fix this.

Try to look to more low lever method in AbstractConnectorTest like consumeRecords

@mfvitale Thanks for that. I have added the required test.

@jpechane Can you take a pass ?

@akanimesh7 Applied, thanks!

Nice!


Support ray query

refer to NVIDIA Vulkan Ray Tracing Tutorial -> ray query,  I add ray query in .frag shader:
screen.frag
#version 460
#pragma shader_stage(fragment)

#extension GL_EXT_ray_tracing : enable
#extension GL_EXT_ray_query : enable

...

layout(binding = 0, set = 0) uniform accelerationStructureEXT topLevelAS;

...

void main() {
...

  // Ray Query
  vec3 origin = vec3(0.1);
  vec3 direction = vec3(1.0); // vector to light
  float tMin = 0.01f;
  float tMax = 100000000.0f;

  // Initializes a ray query object but does not start traversal
  rayQueryEXT rayQuery;
  rayQueryInitializeEXT(rayQuery, topLevelAS, gl_RayFlagsTerminateOnFirstHitEXT,
                        0xFF, origin, tMin, direction, tMax);

  // Start traversal: return false if traversal is complete
  while (rayQueryProceedEXT(rayQuery)) {
  }

...
}

I pass the instance accelerationContainer to render bind group:
index.mjs
...

  let renderBindGroupLayout = device.createBindGroupLayout({
    entries: [
      {
        binding: 0,
        visibility: GPUShaderStage.FRAGMENT,
        type: "acceleration-container"
      },
...
    ]
  });

...

  let renderBindGroup = device.createBindGroup({
    layout: renderBindGroupLayout,
    entries: [
      {
        binding: 0,
        accelerationContainer: instanceContainer,
        offset: 0,
        size: 0
      },
...
    ]
  });

then I run the index.mjs in nodejs, it error:
Error: Validation Error: acceleration container binding is not supported in this shader
    at ValidateBindingTypeWithShaderStageVisibility (../../src/dawn_native/BindGroupLayout.cpp:67)
    at ValidateBindGroupLayoutDescriptor (../../src/dawn_native/BindGroupLayout.cpp:133)
    at CreateBindGroupLayoutInternal (../../src/dawn_native/Device.cpp:837)
    at Immediate.<anonymous> (D:\Github\WebGPU-Sample\node_modules\webgpu\index.js:41:30)
    at processImmediate (internal/timers.js:458:21)

When I continue working on the ray tracing extension then I'll probably add support for ray queries. Also please post issues regarding ray tracing here

Thanks very much~


Mix task to show current streaks

@chriserin this is really cool! Thank you!
I have two requests; first, could you add a @moduledoc and @shortdoc ala lib/mix/tasks/ecto.twiki.ex. This would document the interface in the code and via the mix help command.
Second, could you rebase master onto this branch? There's a dependency conflict I resolved on master that affects mix tasks.

Comments addressed!  Thank you @jwworth :1st_place_medal: !

Awesome! Thank you! 🔥


Added sandbox endpoint support

This is a a fix for #6 with working unit tests. Credits do go to #7 @Webvida.

Any chance this get merged?


Fix: id null check fails if using postgres

I looked into the reason this beforeSave hook was failing on postgres, per #306, and here's what I found:
The original code in the hook is doing a check to see if id is null, which fits with the sqlite3 driver, but when using postgres id isn't null—it's a string that looks like nextval('users_id_seq'::regclass).
For the purpose of checking/fixing in the social-network example, I'm doing a typeof check on id since the id of a saved model should be a number, which works, but it seems like maybe there's an underlying issue here:
It seems like the id check you're doing here is intended to determine whether or not a model has been persisted to the database, and I'm wondering if this a feature you might want to add—sort of like persisted? or new_record? in Rails.
Thoughts?

This is a really nice find! That string 'nextval('users_id_seq'::regclass)' seems like a bug with the pg driver or knex.
--

you might want to add—sort of like persisted? or new_record? in Rails.

That is an awesome idea! Can you create an issue to track this as a feature request?


Add support for AMD GPUs via ROCm

I was wondering if we could add support for AMD GPUs running ROCm in the near future? I could help and could test it on two different AMD cards.
I think in order to get there, we might have to do the following:

Provide all the ROCm related packages.
Probably best to do this in another environment than the default one right now. I was wondering how we avoid duplicating most of the code here? (My Nix greatness is rather limited I have to say)

Set some environment variables, so that ROCm knows which GPU architecture we are using. This is particularly important in order to get this running on GPUs that are not officially supported by ROCm, but work nonetheless (which is basically all RDNA3, RDNA2 consumer and workstation GPUs, and also a significant number of RDNA-based GPUs).
 Since users will have different GPUs, is there a (possibly hacky) way to pick this up dynamically from the environment?

I think we're getting there...!


Dashboard SkillServiceCard md and lg screens fix

The cards need to work properly on md and large screens too. The files that will need to be changed to fix this will be SkillServiceCards.tsx and Card.tsx.

let me check

Fixed


idevicerestore issues with libmobiledevice code

hi @nikias and @taanders and all,
kindly give me some instruction about libmobiledevice for windows i found some error which is given below, what happen on window iphone is not placed in restore mode. while iTunes update the firmware at this stage and also 3uTools what happen with libmobiledevice code, it happen with usbmuxd or others class which is not connect device to properly to window system...
kindly provide me some update.......
Release.txt
thanks in advanced @nikias and @taanders and all,

Hi @yogendra123456, thanks for reporting this issue!
Could you report this issue to upstream?
Thanks.

We haven't been able to repro this; if more information comes up, or this issue appears again, please reopen.


exploit boost.multiprecision aliases

As with the fp library, make multiprecision.h simpler by using the boost::multiprecision::cpp_int (or whatever) types.

partially done


Add proper description on parameters used in defining custom claims for SP

Documentation: Configuring a Service Provider [1].
Issue Identified: Under the section "Claim mapping", it has a detailed description of claims. And there is a description how to define claims using Custom Claim Dialect.
While we define custom claims, there are two values as "Requested Claims" and "Mandatory Claims". Please add the difference on them and describe examples on this.
Add the description of what is subject claim URI and role claim URI.
[1] https://docs.wso2.com/display/IS540/Configuring+a+Service+Provider

Thank you for your contribution!
We are closing this issue since it has not been prioritized for a long time. Chances are that it has already been solved in more recent versions. If not, we will be re-evaluating this when it becomes a priority.


Don't specify registry specific path

Why:
The authenticate-packages.md componet is used across all GitHub Package ecosystems. We shouldn't include the ecosystem specific path on the example.
Here are some ecosystem specific URLs that are used:
nuget.pkg.github.com/OWNER
maven.pkg.github.com/OWNER/REPOSITORY
docker.pkg.github.com/OWNER/REPOSITORY/IMAGE-NAME

We could generalize it to simply mention PACKAGE-REGISTRY.pkg.github.com.

What's being changed:
Change Docker specific PACKAGE-REGISTRY.pkg.github.com/OWNER/REPOSITORY/IMAGE-NAME to generic PACKAGE-REGISTRY.pkg.github.com.

Check off the following:

[ ] All of the tests are passing.
[ ] I have reviewed my changes in staging. (look for the deploy-to-heroku link in your pull request, then click View deployment)
[ ] For content changes, I have reviewed the localization checklist
[ ] For content changes, I have reviewed the Content style guide for GitHub Docs.

Thanks @jcansdale! I'll get this triaged for review ⚡


Added Support to WASD keys

I added support to WASD keys for the movement. I'm still newbie, but wanted to contribute, because I loved you project.
Just modified the switch conditionals in input.js file

Thank you, it's push to the production app =)


Add napalm login details to Router edit Form, not configuration.py

With this PR Napalm login details are not put into the configuration.py anymore, they are getting put in the Router form. It works with optional_args, but since I have no device that requires no optional_args for a connection I can't test if it actually works when someone doesn't put anything in the optional_args field. So it would be cool if you could test if that works too.
Any feedback is appreciated.

Coverage remained the same at 83.484% when pulling c8a2dad35a27eea1ac5b4a7520d6ccb06a3347af on smaxx1337:smaxx1337-patch-1 into fd4af9def3d5f7cb4058915c31912792c2b58a23 on respawner:master.

Little bump here. This is needed feature!

I've pushed some of your changes in c3cab43 and adapted some others based on the latest master branch. Thanks for working on this PR, we can close it now.


Support for civil Package (Date, DateTime, civil.Time)

It would be good if a Dataframe can support

civil.Date (ie. 1955-04-30)
civil.DateTime (this is not the same as time.Time)
civil.Time
time.Time (already mentioned in numerous other issues eg https://github.com/kniren/gota/issues/22)

Also the ability to sort
Also on loading, specify a column needs to be interpreted using custom parse which produces a type mentioned above.

Ref: https://godoc.org/cloud.google.com/go/civil

https://github.com/rocketlaunchr/dataframe-go library supports generic datatypes.

Time support is desired, but I would not want to add any dependencies to external packages. I'm closing this issue in favor of #93 and others.


"process is not defined" Error at /files

ReferenceError: process is not defined
    at readRequiredEnvVar

Note that the Web app displays a "500 Internal Error" page but actually the error happened in the frontend, the only HTTP request that happened returned a 200 OK code.

The reason is that directories.ts ends up being imported by frontend code, and the frontend code cannot run is because it calls process which is a NodeJS thing.

I wonder if https://kit.svelte.dev/docs/modules#$env-dynamic-public would be the solution

The frontend shouldn't really have to access these values though.
Here the bug is probably caused by src/routes/files/+layout.svelte importing $lib/directories (I wish SvelteKit could give me this info instead of me having to guess it), but really it could get this info from the data it receives from src/routes/files/+layout.server.ts instead.


Broken link in docs.ockam.io

I think the link to edit docs.ockam.io is broken.
If you are located in any of the pages of docs.ockam.io and you try to click the link "Edit on GitHub" on the right side panel, it will try to take you to the address: https://github.com/build-trust/ockam-documentation/blob/main/examples/README.md which doesn't exist.
This could impact contributors that want to improve the documentation.

Thank you, great catch @andrescaroc

Thanks @andrescaroc, this is fixed now


Edited script so that workflow does not blow up when it reads a unicode files

The previous workflow that I made has an issue whenever it read a unicode file.
This commit fixes this issue by reading the file raw.

Cheers @molangning  - all good!


Cannot enter authentication code.

This is what's happening.

It doesn't work if you enter it there anyway?

No, it just gets stuck there.