Finalize suppressSaveBeforeStart API

Added in https://github.com/microsoft/vscode-jupyter/issues/6898
This lets an extension starting a debug session forcibly override the user's setting about saving files before debugging.
The jupyter debug adapter may be trying to debug an untitled notebook. This makes sense for notebooks but doesn't make sense for other debug adapters.
I was looking at how it's used and wondering whether this should actually be a property of the debug adapter. The debugger contribution could declare that it is able to debug unsaved/untitled files.
cc @weinand @isidorn any thoughts about that?

@roblourens let me first try to recapitulate the problem:
In https://github.com/microsoft/vscode-jupyter/issues/6898 we agreed on a new flag DebugSessionOptions.suppressSaveBeforeStart that can be passed to vscode.debug.startDebugging() in order to suppress the "Save unsaved/untitled file" dialog when debugging notebook cells.
The implementation of this API needs the information whether the underlying debugger is actually able to debug unsaved/untitled files or not (as you have pointed out in your proposal). If the debugger:

supports debugging unsaved files the "Save" dialog can be suppressed,
does not support debugging unsaved files the "Save" dialog must be shown.

A consequence of this behavior is that the DebugSessionOptions.suppressSaveBeforeStart API can only be a "hint": the the "Save" dialog can only be suppressed if the debugger supports it. I think that's OK but maybe the naming should reflect this.
More to come...

When you say

and cannot be used for a "dynamic" debug extension that "forwards" debugging generically to some other component, e.g. a debugger in a notebook kernel.

and also

In one of my samples I was implementing a generic notebook debugger in the extension alone that could deal with unsaved/untitled files and the underlying DAs were unaware of this.

you are talking about an extension that calls startDebugging to invoke a debug adapter from a different unrelated extension, right? And I think in your sample, your extension is reading the notebook, writing to some file, and telling the DA to debug that file? So in that case, the DA is not actually debugging the unsaved file, but by default we would trigger a save on it.
That shows what makes this messy - we don't know which files are involved in the new debug session, so we save everything. We also have the question of unsaved changes in the notebook vs in other files. If your notebook imports a local .py file, that file would actually need to be saved to have its changes loaded in the new debug session.
The jupyter debug adapter is single-purpose and always can debug without triggering a save, but probably there are other cases where a simple boolean flag in the contribution is too limited. So then we could have

a string is a command ID that can be used to return a dynamic value for the property...

What context does it get, the rest of the launch config?
Thinking through everything, it seems like the simplest option would be to just keep the debug session option, make it the responsibility of the caller of startDebugging, since we have all this flexibility and it's probably hard to decide what is "supported" by which DA or extension.


Fix  getNetworks method

networkIds are folders in keyDir, not files!
(${this.keyDir}/${networkId})

@azimuth0x28 can you please provide a test for this?


from_tiff convenience function

adds a from_tiff convenience to generate an OME class from a tiff, using tifffile.
Stopped short of adding tifffile to dependencies though (added an extra).  Ideas for extracting XML without tifffile welcome.

I got you fam: https://github.com/labsyspharm/ome-tiff-pyramid-upgrade/blob/master/pyramid_upgrade.py#L36
I wrote that to read, manipulate, and write IFDs in order to upgrade the old legacy OME-TIFF "Faas" pyramids to the new BioFormats 6 format in place, without reading or writing any of the pixel data so it runs in an instant (and doesn't require space for a copy). With a little more work it could be a general purpose IFD reading library (like adding classic TIFF support and the ability to refer to tags by name instead of number) but I could easily extract just enough code to read only the ImageDescription out of the first IFD. It only uses pure Python.

I got you fam

lol... I had to google that :joy:
wow 😱  that looks amazing.  I think I'm all for it if you are!  Though I do want a bit more thorough background on exactly what the difference are.  what the limitations of tifffile are, what motivated you to do this, what potential limitations might be here...
but yeah. this looks crazy

For now, if we just want to extract the ImageDescription it's probably 10-20 lines of code. I can omit all the defensive code (which I needed since I didn't want to corrupt files on write), writing code, and general purpose Tag/TagSet data structures. I'll see what I can scrape together. PR against this branch?
The rest of the code in TiffSurgeon would only be required for a full OME-TIFF read/write library, which is out of scope for ome_types. Or is it...?

PR against this branch?

yeah, I'd like to see what that looks like ... (also feel free to open a new PR if you want)

The rest of the code in TiffSurgeon would only be required for a full OME-TIFF read/write library, which is out of scope for ome_types. Or is it...?

To me, it really doesn't matter if it's in ome-types or some other package that plays nicely with ome-types... but it would be great to have a pure python library with a nice API to write a numpy array to ome.tiff.  Again, I wouldn't want to reinvent any wheels (ala tifffile), but if there are new (bioformats 6?) features that don't have a pure-python library yet, and if you've already got a start on that sort of thing, it would be great to hook it up here (whether directly or indirectly)

Ideas for extracting XML without tifffile welcome.

Here's a small standalone function to read the first ImageDescription tag value (as NULL terminated bytes) from an open TIFF file handle:
def tiff_image_description(fh):
    """Return value of first ImageDescription tag from open TIFF file."""
    from struct import unpack
    offsetsize, offsetformat, tagnosize, tagnoformat, tagsize, codeformat = {
        b'II*\0': (4, '<I', 2, '<H', 12, '<H'),
        b'MM\0*': (4, '>I', 2, '>H', 12, '>H'),
        b'II+\0': (8, '<Q', 8, '<Q', 20, '<H'),
        b'MM\0+': (8, '>Q', 8, '>Q', 20, '>H'),
    }[fh.read(4)]
    fh.read(4 if offsetsize == 8 else 0)
    fh.seek(unpack(offsetformat, fh.read(offsetsize))[0])
    for _ in range(unpack(tagnoformat, fh.read(tagnosize))[0]):
        tagstruct = fh.read(tagsize)
        if unpack(codeformat, tagstruct[:2])[0] == 270:
            size = unpack(offsetformat, tagstruct[4:4+offsetsize])[0]
            if size <= offsetsize:
                return tagstruct[4+offsetsize:4+offsetsize+size]
            fh.seek(unpack(offsetformat, tagstruct[-offsetsize:])[0])
            return fh.read(size)

See also https://docs.openmicroscopy.org/ome-model/6.1.2/ome-tiff/code.html#extracting-a-tiff-comment

Resolves #50

Thanks @cgohlke! That's about what I was envisioning.  :)

Thanks @cgohlke!


Clean up azure config

Merge templates that are used only once into azure-pipelines.yml.

bors r+


Move figma migration guide

We have migration guidance for the new figma library currently inside the latest announcement article.
Completing this issue will move the migration content to a more relevant migration space on the salt internal site.

Needs status update from @bhoppers2008


UI: Propose dialog not properly initialized

When I click on propose for cell value X, fill something in and click OK. Then go to a different cell, click on propose for cell Y, the propose dialog is not initialized, but I can see my previous inputs for cell X!

Not that easy to resolve, @KataBoku will do later.


Feature request: Versioned Transactions

Versioned transactions are used (default settings) by raydium.io exchange. It would be helpful to support it.

https://solana.com/docs/advanced/versions
https://solana-labs.github.io/solana-web3.js/classes/VersionedTransaction.html

Current implementation throw the error on attempt of parsing tx data:
Error: Reader(msg/instructions/0/keys/587): readBytes: Unexpected end of buffer

It seems it is related https://github.com/paulmillr/micro-sol-signer/issues/11


375 Switch to Google OAUth2

Google OpenID has been turned off. Clean out old
associations using Google OpenID, and set up
Google OAuth2.
BEFORE DEPLOYING THIS, make sure a client ID and
secret have been configured.
Fixes #375

Apparently django-social-auth has been deprecated and should be replaced with python-social-auth:
https://github.com/omab/django-social-auth
https://github.com/omab/python-social-auth

Opened #419 to maybe upgrade to python-social-auth some day.

:key:


Fixes

Had a few more issues

Done and added dangling else that just frees if no impl, as I'm adding to others with refactoring

Thanks!


Incomplete translations

New versions of MEW sometimes contains new text in English, which isn't added to the translation files. Eg. new help-section to the right, and info-text at the bottom. Not a critical issue, but would be nice to have a clean page with only one language at a time...

I try not to add to the translation files until I'm happy with the English. I think I've changed all that copy every update for the last 6 updates or so. :/
I can add under a [WIP] header. At least then if you are busy or whatever you will know that its not urgent and may change. 🤔
I'll go top to bottom soon regardless. There are a lot of little things.

Closing this issue. Don't hesitate to reopen if needed.


Modify Collector interface methods

As discussed in #260, we change some of the methods in the Collector interface.
The main motivations are:

Consistency; the method MessageIngested was not consistent with MessageSaved for instance, because in the former, the whole Message struct was passed to the method while in the latter, the struct was deconstructed before the method was called.
Flexibility; as the whole Message struct is now passed to each Collector method, the struct can be further deconstructed to extract more data and record new relevant stats.

ptal

Managed to resolve the building issues.


Refine EnvironmentVariableScope API

Some small tweaks are needed for the new EnvironmentVariableScope-type

it should be an interface, not a type.
it lacks a jsdoc comment
it's not clear why workspaceFolder can be optional?

Will correct it right away 👍

it's not clear why workspaceFolder can be optional?

It's not something we expect all consumers to consider, as many folks may not care about applying env variables to a particular workspace. In future we may introduce other parameters as well, and consumers who don't care about it, can simply omit them:
/**
 * The scope object to which the environment variable collection applies to.
 */
export interface EnvironmentVariableScope {
	/**
	 * Any specific workspace folder to get collection for.
	 */
	workspaceFolder?: WorkspaceFolder;
	/**
	 * Returned env collection will only be applied to these shell paths.
	 */
	shell?: string;
}

A consumer who only cares about shell:
const collection = context.environmentVariableCollection.getScoped({ shell })

cc/ @Tyriar


New version: TextClassification v0.3.2

Registering package: TextClassification
Repository: https://github.com/sadit/TextClassification.jl
Created by: @sadit
Version: v0.3.2
Commit: 2008d8939904c120d608c4abeaf1f1184e08cc63
Reviewed by: @sadit
Reference: https://github.com/sadit/TextClassification.jl/commit/2008d8939904c120d608c4abeaf1f1184e08cc63#commitcomment-46796492

@sadit :point_up:
[noblock]


stderr is piped to stdout

How to replicate error:
This ain file should output connection headers to stderr and print a json to stdout.
[Host]
http://localhost:3000/places

[Headers]
Content-Type: application/json

[Backend]
curl

[BackendOptions]
-sS -D /dev/stderr

But what actually happen is that stderr (the headers) are printed on stdout.
You can check this by running this line and reviewing the content of headers.txt file:
ain the_code_provided.ain 2>headers.txt

Why I consider that this should not be like this?

Because as user I expect to be printed to stderr
Because stderr could be used for logging and will allow to do this with the provided example :

ain the_code_provided.ain | jq

And don't make crash the jq parser.
Thanks in advanced!

Thanks for reporting! I'll have a think of the impact of changing the behaviour (which was a conscious decision to capture all output in the order the backend prints it): https://github.com/jonaslu/ain/blob/main/internal/pkg/call/curl.go#L89
In the meantime, you can work around this by doing:
Host]
http://localhost:3000/places

[Headers]
Content-Type: application/json

[Backend]
curl

[BackendOptions]
-sS -D /proc/${PID}/fd/2

PID=$$ ain the_code_provided.ain
That will print headers to the shells stderr and output to stdout

Hi again!
I agree with this. Output from the backend can even intermingle, so separating them solves that too: https://unix.stackexchange.com/questions/476080/what-prevents-stdout-stderr-from-interleaving
For the deplay: I'm in the middle of a major overhaul of the internals and wanted to see what impact it had, but it looks like doing this won't collide that much so go ahead and do the PR.

Great! Then once I have the code, I will open PR!

Hi Jonas, today I had a bit of time and I did the task as you can see in my fork, however I find that I have introduced a lot of boiler plate on the runAsCmd functions.
What do you think if I create a new function share for all backends to run the command and contain the boiler plate?
Pseudo-code based on my fork (internal/pkg/call/call.go):
func CallBackend(ctx context.Context, callData *data.Call, leaveTmpFile, printCommand bool) (Output, error) {
	backendTimeoutContext := ctx
	if callData.Config.Timeout != data.TimeoutNotSet {
		backendTimeoutContext, _ = context.WithTimeout(ctx, time.Duration(callData.Config.Timeout)*time.Second)
	}

	backend, err := getBackend(callData)
	if err != nil {
		return Output{}, errors.Wrapf(err, "Could not instantiate backend: %s", callData.Backend)
	}

	if printCommand {
		if command, err := backend.getAsString(); err != nil {
			return Output{StdErr: []byte(command)}, err
		} else {
			return Output{StdOut: []byte(command)}, nil
		}
	}

	cmd, err := backend.GetCmd(backendTimeoutContext)
        output, err := runCmd(cmd)

	var removeTmpFileErr error
	if !leaveTmpFile || err != nil {
		if err := backend.cleanUp(); err != nil {
			removeTmpFileErr = errors.Wrap(err, "Could not remove file with [Body] contents")
		}
	}

	if backendTimeoutContext.Err() == context.DeadlineExceeded {
		return output, utils.CascadeErrorMessage(
			errors.Errorf("Backend-call: %s timed out after %d seconds", callData.Backend, callData.Config.Timeout),
			removeTmpFileErr,
		)
	}

	if err != nil {
		return output, utils.CascadeErrorMessage(
			errors.Wrapf(err, "Error running: %s\n%s", callData.Backend, strings.TrimSpace(string(output.StdOut))),
			removeTmpFileErr,
		)
	}

	if removeTmpFileErr != nil {
		return output, errors.Wrapf(removeTmpFileErr, "Error running: %s\n%s", callData.Backend, strings.TrimSpace(string(output.StdOut)))
	}

	return output, nil
}

Hard to tell, better if you do it as a commit on top of your fork and we can look at it then. There's always git reset.

I will give a try this weekend then.

Fixed in commit eb9fa6c, closing this


Configs of other backbone

Hi, this is an excellent piece of work!
Could you please provide the configuration files for using VOV and Swin-B? This would make it more convenient to explore the impact of other backbones on performance.

Okay. I will release these experiments this week. Please stay tuned.

We have updated the configuration files of VOV and Swin-B. If you find TopoMLP is useful in your research or applications, please consider giving us a star.


Setup a telemetry for NuGet Gallery to capture performance and usage data

Nuget services are in a challenging position. They are included by default into Visual Studio, referenced everywhere in .NET ecosystem on Microsoft (and would probably be further used in new Linux tooling).
After all: NuGet is the package manager for the Microsoft development platform including .NET. ... The NuGet Gallery is the central package repository used by all package authors and consumers.
People pay for Visual Studio, MSDN subscriptions, they expect it all to work flawlessly. When something (that they already paid their bloody money for) prevents them from doing their work (and then going home to loved ones), they could be rightfully infuriated. Even if that something is in reality a small separate project, managed by a small team without a lot of resources.
In my experience, this situation could be improved a little bit by:

Being more public about the project challenges, limitations, everyday use patterns (regular blog posts by team members could do the trick, they could also be a great PR campaign to let people understand the situation).
Learning more about how nuget.org is actually used, how it behaves and then improve that!

I would recommend to start addressing the second point by setting up a proper telemetry for the Nuget gallery (here is a brief description of setup that works the best for .NET for me) and capture following data:

Number of requests against different APIs, their latency.
Queue depth for the indexing jobs
Processing delay distribution for indexing jobs
Number of exceptions being thrown across the system.

Once you have the information, you would be able to see the bottlenecks and issues more clearly. Besides, that would also make a great material for the blog post.

@abdullin this is good feedback.
We are tracking most of this information already, and we are going to augment it with app insights this week.
Its probably not a bad idea to look at your other suggestions once we get through the next two waves (S1 & S2) and figure out what else we want to start tracking.
Thanks again for the input

Linking #2478 (internal telemetry via AppInsights)

Done. Augmented the telemertry with AppInsights. Thanks for the advice!


SharpZipLib 0.84 can not open archives created with latest version

Steps to reproduce

Create a ZIP file using the latest version of the library.
Try to open the ZIP file with an older version of the library, e.g. 0.84.

Expected behavior
The ZIP file should be successfully open by the old version of the library.
Actual behavior
An exception is thrown by the old library:
Version required to extract this entry not supported (45)
at ICSharpCode.SharpZipLib.Zip.ZipFile.TestLocalHeader(ZipEntry entry, Boolean fullTest, Boolean extractTest)
at ICSharpCode.SharpZipLib.Zip.ZipFile.CheckLocalHeader(ZipEntry entry)
at ICSharpCode.SharpZipLib.Zip.ZipFile.GetInputStream(Int32 entryIndex)
at ICSharpCode.SharpZipLib.Zip.ZipFile.GetInputStream(ZipEntry entry)
Workaround
Set UseZip64 property to false on ZipOutputStream:
zipOutputStream.UseZip64 = UseZip64.Off;
Version of SharpZipLib
Obtained from (place an x between the brackets for all that apply)

[x] Compiled from source
branch: master
commit: 00c3c91
[ ] Downloaded DLL from GitHub
[ ] Downloaded DLL from SourceForge
[ ] Downloaded DLL from _______
[ ] DLL included as part of
Package installed using:
[ ] NuGet
[ ] MyGet
[ ] Chocolatey

@gabisandor
It would appear that this "incompatibility" is intentional. Here is a brief timeline from the Changes.txt file and git history:

Version 0.84 does not have the capability to handle Zip64 extensions
Version <IP_ADDRESS> Add support for Zip64 handling to both streams and ZipFile classes.
Versions up to <IP_ADDRESS>8 created files by default with UseZip64 useZip64_ = UseZip64.Dynamic;
Version <IP_ADDRESS>9 c38c6f4b1bbfe3ebc1d7b95c301286355449b400 changes ZipOutputStream.cs to

// Default of off is backwards compatible and doesnt dump on
// XP's built in compression which cnat handle it
UseZip64 useZip64_ = UseZip64.Off;

Version <IP_ADDRESS>1 Zip64 handling altered to default to "Zip32" for compatability.
Version <IP_ADDRESS>5 1cdcdf5b9c246193b06fa0fd66543f7b911420e8 changes ZipOutputStream.cs to

/// <remarks>Older archivers may not understand Zip64 extensions.
/// If backwards compatability is an issue be careful when adding <see cref="ZipEntry.Size">entries</see> to an archive.
/// Setting this property to off is workable but less desirable as in those circumstances adding a file
/// larger then 4GB will fail.</remarks>

and
// Default is dynamic which is not backwards compatible and can cause problems
// with XP's built in compression which cant read Zip64 archives.
// However it does avoid the situation were a large file is added and cannot be completed correctly.
// NOTE: Setting the size for entries before they are added is the best solution!
UseZip64 useZip64_ = UseZip64.Dynamic;

Version <IP_ADDRESS>9 "ZipFile now defaults to dynamic use of Zip64."

Your workaround is the correct solution for this issue.
-Neil

Thank you very much @McNeight for your detailed insight into this issue. I will then stick to setting Zip64 to off from now on when i need backwards compatibility. From what I understood, the only problem will come up if i try to zip a file that is larger than 4 GB.


Compatibility with UnityEngine.Animator

Unity import animation clip which handle "Animator control property.", but Skinner do not have compatibility with "Animator control property.". if don't support continuously, this is not good continuously

Perfect skinning implement be had Compatibility with UnityEngine.Animator

Bone transform do not move when Animator.CullingMode is not Always Animate.. need culling setting to Unity System.


Cache type_to_typeref

Before:
compile_edgeql_script: Mean +- std dev: 2.60 ms +- 0.07 ms
compile_edgeql_script_webapp_configure_system: Mean +- std dev: 44.0 ms +- 3.6 ms
compile_edgeql_script_webapp_get_movie: Mean +- std dev: 289 ms +- 55 ms
compile_edgeql_script_webapp_get_person: Mean +- std dev: 316 ms +- 73 ms
compile_edgeql_script_webapp_get_user: Mean +- std dev: 150 ms +- 4 ms
compile_edgeql_script_webapp_insert_movie: Mean +- std dev: 155 ms +- 2 ms
compile_edgeql_script_webapp_insert_person: Mean +- std dev: 59.6 ms +- 2.2 ms
compile_edgeql_script_webapp_insert_review: Mean +- std dev: 91.4 ms +- 1.7 ms

After:
compile_edgeql_script: Mean +- std dev: 2.44 ms +- 0.06 ms (6.2% faster)
compile_edgeql_script_webapp_configure_system: Mean +- std dev: 35.0 ms +- 0.9 ms (21% faster)
compile_edgeql_script_webapp_get_movie: Mean +- std dev: 256 ms +- 63 ms (11.5% faster)
compile_edgeql_script_webapp_get_person: Mean +- std dev: 325 ms +- 83 ms (2.8% SLOWER)
compile_edgeql_script_webapp_get_user: Mean +- std dev: 142 ms +- 3 ms (5.4% faster)
compile_edgeql_script_webapp_insert_movie: Mean +- std dev: 140 ms +- 3 ms (9.7% faster)
compile_edgeql_script_webapp_insert_person: Mean +- std dev: 54.6 ms +- 1.5 ms (8.4% faster)
compile_edgeql_script_webapp_insert_review: Mean +- std dev: 84.6 ms +- 2.0 ms (8.5% faster)

For big queries the jitter is higher due to GC activity as the cache needs to be cleaned out.
Other observations:

only caching in the Environment didn't allow me to cache all places (see two marked spots) and got me thinking that it would be better to have a per-Schema "persistent" in-memory cache for this that would survive between compilation rounds; of course benchmarks would have to clean it up but for Real World use that would make the caches' hit rate much higher;
I looked into why get_person() is actually slower now but have no answers yet;
for benchmarks we want to disable GC when the function is being measured, given that those functions are not long-lived this should help with the jitter a lot;
benchmarking with Wi-Fi off works better for me in terms of minimizing jitter;
there are two failing tests due to the cache now but I'm not entirely sure if those are bugs, please look at them (test_edgeql_ir_scope_tree_19; test_edgeql_ir_scope_tree_24).

I did more measuring and sleuthing on this.
Stats from all unit tests:

799k calls
83.47% hit rate
0.000096% hit rate for types with custom typenames
0.000376% name hint mismatch (see below)
2.7% not cached at all (recursive calls for tuple subtypes)

Conclusion 1
Due to the extremely low hit rate on types with custom typenames, I removed the custom typename from the cache key, making it smaller and thus faster for the common case.
Conclusion 2
The two tests that are failing are failing because:

while the type in question is properly recognized and cached;
the schema changed during compilation (saved a bunch of derived types);
and so the name hint is different.

Since the name hint is only used in annotations, and both name hints properly describe the type anyway, it is an acceptable compromise to allow for the name hints to not be derived types. I added an additional check for now to ensure that the name hints are correct every time. My intuition was that it's not worth it because the name hint mismatch rate is extremely low while the check cost would be paid on all cache hits. But it looks like it doesn't really make the cache perform much worse.
More benchmarks
Before
compile_edgeql_script_simple: Mean +- std dev: 2.60 ms +- 0.07 ms
compile_edgeql_script_webapp_configure_system: Mean +- std dev: 44.0 ms +- 3.6 ms
compile_edgeql_script_webapp_get_movie: Mean +- std dev: 289 ms +- 55 ms
compile_edgeql_script_webapp_get_person: Mean +- std dev: 316 ms +- 73 ms
compile_edgeql_script_webapp_get_user: Mean +- std dev: 150 ms +- 4 ms
compile_edgeql_script_webapp_insert_movie: Mean +- std dev: 155 ms +- 2 ms
compile_edgeql_script_webapp_insert_person: Mean +- std dev: 59.6 ms +- 2.2 ms
compile_edgeql_script_webapp_insert_review: Mean +- std dev: 91.4 ms +- 1.7 ms

After (without name hint correction)
compile_edgeql_script_simple: Mean +- std dev: 2.43 ms +- 0.07 ms (6.54% faster)
compile_edgeql_script_webapp_configure_system: Mean +- std dev: 34.9 ms +- 1.0 ms (20.68% faster)
compile_edgeql_script_webapp_get_movie: Mean +- std dev: 257 ms +- 68 ms (11.07% faster)
compile_edgeql_script_webapp_get_person: Mean +- std dev: 315 ms +- 79 ms (0.32% faster)
compile_edgeql_script_webapp_get_user: Mean +- std dev: 142 ms +- 4 ms (5.33% faster)
compile_edgeql_script_webapp_insert_movie: Mean +- std dev: 143 ms +- 3 ms (7.74% faster)
compile_edgeql_script_webapp_insert_person: Mean +- std dev: 54.3 ms +- 1.1 ms (8.89% faster)
compile_edgeql_script_webapp_insert_review: Mean +- std dev: 83.8 ms +- 1.7 ms (8.32% faster)

After (with name hint correction)
compile_edgeql_script_simple: Mean +- std dev: 2.52 ms +- 0.11 ms (3.08% faster)
compile_edgeql_script_webapp_configure_system: Mean +- std dev: 34.9 ms +- 0.7 ms (20.68% faster)
compile_edgeql_script_webapp_get_movie: Mean +- std dev: 250 ms +- 58 ms (13.49% faster)
compile_edgeql_script_webapp_get_person: Mean +- std dev: 323 ms +- 84 ms (2.22% SLOWER)
compile_edgeql_script_webapp_get_user: Mean +- std dev: 143 ms +- 5 ms (4.67% faster)
compile_edgeql_script_webapp_insert_movie: Mean +- std dev: 143 ms +- 3 ms (7.74% faster)
compile_edgeql_script_webapp_insert_person: Mean +- std dev: 55.2 ms +- 2.1 ms (7.38% faster)
compile_edgeql_script_webapp_insert_review: Mean +- std dev: 85.3 ms +- 2.0 ms (6.67% faster)

This is ready.


doc: include namespace-scope info

Motivation
There doesn't seem to be much information about what the --namespace-scope-mode flag does, or the difference between cluster-scoped and namespace-scoped serving runtimes.
Modifications

As a start, a blurb is included for the --namespace-scope-mode flag in the install-script doc.
Corrects the --help output as well.

Result
Helpful information about the --namespace-scope-mode which is included in the recommended way to use the quick-start install of ModelMesh.

/lgtm


PoS validator consensus key change

Add a tx and update PoS validity predicate to allow validators to change consensus key
NOTE: how do we update this in tendermint? We currently using the key file on disk. The key change on-chain will happen in a future epoch, so we'd need to update the file at the right time.

NOTE: how do we update this in tendermint? We currently using the key file on disk. The key change on-chain will happen in a future epoch, so we'd need to update the file at the right time.

We can most likely use the same approach that is being developed for DKG integration, in which validators can change their PVSS public keys and the node waits for the txs to be applied before updating to the new key.
Additionally, we'll probably need to restart Tendermint after we update the priv_validator_key.json (I'm not sure if restarting it will be necessary with tendermint KMS).


Revert "c++ program to check armstrong number"

Reverts fnplus/interview-techdev-guide#247

User has added two files instead of editing the already existing file.


[bug]: DLL load failed while importing onnx_cpp2py_export

Is there an existing issue for this problem?

[X] I have searched the existing issues

Operating system
Windows
GPU vendor
Nvidia (CUDA)
GPU model
RTX 4080
GPU VRAM
16
Version number
5.2.0rc1
Browser
Firefox
Python dependencies
No response
What happened
I had some dependency issues (newer ones were installed during installation and thus I could not proceed with the installation). The latest version 5.2.0rc1 solved this.
I installed invokeAI the usual way but when I started it I got this error.

Desired action:

Generate images with the browser-based interface
Open the developer console
Command-line help
Q - Quit

To update, download and run the installer from https://github.com/invoke-ai/InvokeAI/releases/latest
Please enter 1-4, Q: [1]
Starting the InvokeAI browser-based UI..
Traceback (most recent call last):
File "C:\Users\T\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 196, in run_module_as_main
return run_code(code, main_globals, None,
File "C:\Users\T\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 86, in run_code
exec(code, run_globals)
File "C:\Users\T\invokeai.venv\Scripts\invokeai-web.exe_main.py", line 7, in
sys.exit(run_app())
File "C:\Users\T\invokeai.venv\lib\site-packages\invokeai\app\run_app.py", line 10, in run_app
from invokeai.app.api_app import invoke_api
File "C:\Users\T\invokeai.venv\lib\site-packages\invokeai\app\api_app.py", line 24, in
from invokeai.app.api.dependencies import ApiDependencies
File "C:\Users\T\invokeai.venv\lib\site-packages\invokeai\app\api\dependencies.py", line 14, in
from invokeai.app.services.download.download_default import DownloadQueueService
File "C:\Users\T\invokeai.venv\lib\site-packages\invokeai\app\services\download_init.py", line 3, in
from invokeai.app.services.download.download_base import (
File "C:\Users\T\invokeai.venv\lib\site-packages\invokeai\app\services\download\download_base.py", line 13, in
from invokeai.backend.model_manager.metadata import RemoteModelFile
File "C:\Users\T\invokeai.venv\lib\site-packages\invokeai\backend\model_manager_init.py", line 16, in
from invokeai.backend.model_manager.load import LoadedModel
File "C:\Users\T\invokeai.venv\lib\site-packages\invokeai\backend\model_manager\load_init_.py", line 9, in
from invokeai.backend.model_manager.load.load_base import LoadedModel, LoadedModelWithoutConfig, ModelLoaderBase
File "C:\Users\T\invokeai.venv\lib\site-packages\invokeai\backend\model_manager\load\load_base.py", line 21, in
from invokeai.backend.model_manager.load.model_cache.model_cache_base import ModelCacheBase, ModelLockerBase
File "C:\Users\T\invokeai.venv\lib\site-packages\invokeai\backend\model_manager\load\model_cache_init_.py", line 4, in
from .model_cache_default import ModelCache  # noqa F401
File "C:\Users\T\invokeai.venv\lib\site-packages\invokeai\backend\model_manager\load\model_cache\model_cache_default.py", line 23, in
from invokeai.backend.model_manager.load.model_util import calc_model_size_by_data
File "C:\Users\T\invokeai.venv\lib\site-packages\invokeai\backend\model_manager\load\model_util.py", line 20, in
from invokeai.backend.onnx.onnx_runtime import IAIOnnxRuntimeModel
File "C:\Users\T\invokeai.venv\lib\site-packages\invokeai\backend\onnx\onnx_runtime.py", line 8, in
import onnx
File "C:\Users\T\invokeai.venv\lib\site-packages\onnx_init_.py", line 77, in
from onnx.onnx_cpp2py_export import ONNX_ML
ImportError: DLL load failed while importing onnx_cpp2py_export: A dynamic link library (DLL) initialization routine failed.

I did the usual fixes like

a fresh install of the Geforce Drivers.
calling the installer again.
I tried to delete the .venv folder in the invoke root folder.
And even  tried to install the dependency manually with no change.

Any idea what I might try next?
What you expected to happen
The application should start as usual.
How to reproduce the problem
No response
Additional context
No response
Discord username
No response

There is currently an issue between ONNX and ONNX runtime on the latest version of InvokeAI.
For some reason when I use the InvokeAI installer, after updating it my InvokeAI installation I realized that it doesn't create all the folder it used to.  I also tried it on a random new folder installation to trigger a full new install, and it did the same thing once again. It just created a .venv folder but none of the models, config, database and so on little folders that it used to make... It just generate or update the .venv folder and it downloads incompatible versions of ONNX and ONNX Runtime.
You're the lucky though as I pieced a solution together after looking into forums  and running some test.

Update the Invoke AI installer
Pick a place to install the InvokeAI app. (it can be new or an old one  that you are updating)
Launch InvokeAI and pick option 2 the "Developer Console"
Now enter this:
pip uninstall onnx onnxruntime

Press (Y) to both time that it ask you if you want to uninstall the respective packages
Then enter this next
pip install onnx==1.16.1 onnxruntime==1.16.3
Let it do its thing and write "exit"

Proceed to choose option 1  - Your InvokeAI should launch no problems now.

TLDR - Uninstall the version of ONNX and ONNX Runtime that you have currently install in your venv and reinstall ONNX 1.16.1 & ONNX Runtime 1.16.3
Note:
- These are the earliest version of ONNX and ONNX Runtime I could run together with my InvokeAI installation. If you try >1.16.2 for ONNX and >1.16.3ONNX Runtime you will constantly run into this error.
- This behavior has been happening to me since the previous update of 5.2.0rc1 and is currently still happening with 5.2.0rc1. I don't know what cause this but ONNX and ONXX runtime gets updated to their latest respective version when updating InvokeAI and both of these versions seem to not be working for InvokeAI.

DLL load failed while importing onnx_cpp2py_export: A dynamic link library (DLL) initialization routine failed.


Why can I start embed milvus after I have started standalone milvus

When I started Milvus stand-alone with docker-compose, I also wanted to try embedded milvus but forget to stop stand-alone milvus.
I can successfully start embed milvus with print ---Milvus Proxy successfully initialized and ready to serve!---, I think it should show an error that port is in use.

Resolved


ImportError: cannot import name settings

Getting the below error when trying to run ./manage.py migrate
ripley@whatmanager:/opt/wm/WhatManager2$ ./manage.py migrate
Traceback (most recent call last):
File "./manage.py", line 10, in
execute_from_command_line(sys.argv)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/init.py", line 354, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python2.7/dist-packages/django/core/management/init.py", line 328, in execute
django.setup()
File "/usr/local/lib/python2.7/dist-packages/django/init.py", line 18, in setup
apps.populate(settings.INSTALLED_APPS)
File "/usr/local/lib/python2.7/dist-packages/django/apps/registry.py", line 108, in populate
app_config.import_models(all_models)
File "/usr/local/lib/python2.7/dist-packages/django/apps/config.py", line 198, in import_models
self.models_module = import_module(models_module_name)
File "/usr/lib/python2.7/importlib/init.py", line 37, in import_module
import(name)
File "/opt/wm/WhatManager2/qobuz2/models.py", line 15, in
from qobuz2 import settings
ImportError: cannot import name settings

Turns out the issue was that in the qobuz2 folder I needed to copy the settings.example.py to settings.py.  This issue can be closed.


work on forntend

Use bootstarp for front end design and make sure it's responsive.

These are the design issues left as of now

[ ] Modify footer of application
[ ] Make height of login box same as sign up box
[ ] Modify design of How to ask and Badges page. Make them visible even when not logged in
[ ] Modify design of activity page
[ ] Modify design of post page
[ ] Modify design of Admin login page
[ ] Center # of threads in all threads page
[ ] Modify design of search page
[ ] Adjust Upvote, dpwnvote and comment icons
[ ] Large default profile icon in Profile page

@ananyo2012 is it hosted somewhere? so that I can check the current version?

Yes there is a version till the current master. Here is the link: http://catforum-ananyo.rhcloud.com/

I will work on the remaining design changes soon.

@sonalkr132 Work on forntend is complete now. This is the summary of the frontend redesign

A complete bootstrap based UI
Fontawesome for glyphicons and commonly used icons
An infinitescrolling threads page with threads organised in blocks
Thread blocks fit optimally leaving least space done with masonry

Closing this one. Open new issues for any design related fixes.


Babel error: "Error: We don't know what to do with this node type. We were previously a Statement but we can't fit in here?"

[x] Review the documentation: https://facebook.github.io/react-native
[x] Search for existing issues: https://github.com/facebook/react-native/issues
[x] Use the latest React Native release: https://github.com/facebook/react-native/releases

Environment
  React Native Environment Info:
    System:
      OS: Linux 4.15 Ubuntu 18.04 LTS (Bionic Beaver)
      CPU: x64 AMD FX(tm)-6300 Six-Core Processor
      Memory: 4.52 GB / 31.32 GB
      Shell: 4.4.19 - /bin/bash
    Binaries:
      Node: 10.4.0 - ~/.nvm/versions/node/v10.4.0/bin/node
      npm: 6.1.0 - ~/.nvm/versions/node/v10.4.0/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      Android SDK:
        Build Tools: 23.0.1, 25.0.0, 25.0.2, 25.0.3, 26.0.1, 26.0.2, 27.0.3
        API Levels: 23, 25, 26, 27
    npmPackages:
      @client/react: ^1.0.13 => 1.0.63
      @client/react-native: ^1.0.13 => 1.0.63
      react-native: ^0.56.0 => 0.56.0

Description
With Webpack, everything works fine. With react-native, it fails, using the same Babel setup except that I use babel-preset-react-native instead of @babel/preset-env. Other Babel config:
Internal preset
presets: [
	['babel-preset-react-native', { decoratorsLegacy: true }]
	// or
	['@babel/preset-env', { target: { browser: /* ... */ } }]
],
plugins: [
	'@babel/plugin-transform-flow-comments',
	'@babel/plugin-transform-react-jsx',
	'@babel/plugin-proposal-object-rest-spread',
	'@babel/plugin-syntax-dynamic-import',
	'babel-plugin-lodash',
	['@babel/plugin-proposal-decorators', { legacy: true }],
	['@babel/plugin-proposal-class-properties', { loose: true}],
]

.babelrc
{
  "presets": [
    [
      "witkit-client",
      {}
    ]
  ],
  "plugins": [
    "transform-inline-environment-variables",
    "babel-plugin-transform-flow-strip-types",
    [
      "module-resolver",
      {
        "root": [
          "/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root"
        ],
        "alias": {
          "fs": "/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/shim/empty",
          "path": "/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/shim/empty",
          "node-localstorage": "/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/shim/empty",
          "stream": "stream-browserify",
          "vm": "/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/shim/empty",
          "modernizr.*$": "@client/modernizr",
          "browsernizr.*$": "@client/modernizr",
          "elk-theme-list": "/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/cache/react-native-theme-list.js",
          "react-addons-shallow-compare": "shallow-compare",
          "react-dom/lib/CSSProperty": "/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/shim/react-dom-css-property",
          "react/lib/ReactPropTypes": "prop-types",
<EMAIL_ADDRESS>"/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/cache/VersionList.native.js"
        }
      }
    ]
  ]
}

Error:
Loading dependency graph, done.
error: bundling failed: Error: We don't know what to do with this node type. We were previously a Statement but we can't fit in here?
    at NodePath.insertBefore (/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/node_modules/@babel/traverse/lib/path/modification.js:55:11)
    at PluginPass.Class (/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/node_modules/@babel/plugin-proposal-class-properties/lib/index.js:257:14)
    at newFn (/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/node_modules/@babel/traverse/lib/visitors.js:237:21)
    at NodePath._call (/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/node_modules/@babel/traverse/lib/path/context.js:65:20)
    at NodePath.call (/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/node_modules/@babel/traverse/lib/path/context.js:40:17)
    at NodePath.visit (/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/node_modules/@babel/traverse/lib/path/context.js:100:12)
    at TraversalContext.visitQueue (/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/node_modules/@babel/traverse/lib/context.js:142:16)
    at TraversalContext.visitSingle (/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/node_modules/@babel/traverse/lib/context.js:102:19)
    at TraversalContext.visit (/mnt/scratch/shared/petter/witkit-devenv/client-react-native-0.56/root/node_modules/@babel/traverse/lib/context.js:182:19)

Unfortunately I do not have a demo and can’t share the (proprietary) source, but any suggestions on how to go about debugging this would be welcome.
It seems likely that this is related to the decorators plugin, but the relevant stuff seems to work fine in Webpack but fail with RN, in spite of using the same config for decorators and class-props plugins, the same version of all the @babel/ packages (pinned to the same 7.0.0-beta.47 as babel-preset-react-native), &c.

(I’m a bit perplexed by this “Old Version” tag the bot applies. I filed this mere hours after 0.56 was released, which doesn’t sound very old to me…)

The preset doesn't have the decorators plugin though:
https://github.com/facebook/metro/blob/master/packages/metro-react-native-babel-preset/package.json

I am experiencing this issue, so I investigated it a bit. I narrowed it down to react-native-modal by adding some logging statements to the Babel code.
This appears to be a Babel 7 issue. I've figured out a minimal repro, and it's quite weird.
export class Bug {

  // To get the same error we're seeing, this static declaration is necessary.
  // However, the error we're seeing is likely hiding another one, because if
  // this declaration is removed, another error occurs.
  static blah = {};

  constructor(props) {
    this.test(props);
  }

  test = (props) => {
    // This is the line that is actaully causing the real error
    const test = props.test;
  }
}

export default Bug;

The original error that appears when the static declaration is left alone is:
error: bundling failed: Error: We don't know what to do with this node type. We were previously a Statement but we can't fit in here?
    at NodePath.insertBefore (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/traverse/lib/path/modification.js:55:11)
    at PluginPass.Class (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/plugin-proposal-class-properties/lib/index.js:257:14)
    at newFn (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/traverse/lib/visitors.js:237:21)
    at NodePath._call (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/traverse/lib/path/context.js:65:20)
    at NodePath.call (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/traverse/lib/path/context.js:40:17)
    at NodePath.visit (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/traverse/lib/path/context.js:100:12)
    at TraversalContext.visitQueue (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/traverse/lib/context.js:142:16)
    at TraversalContext.visitSingle (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/traverse/lib/context.js:102:19)
    at TraversalContext.visit (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/traverse/lib/context.js:182:19)

When the static declaration is removed, the real error is revealed:
error: bundling failed: TypeError: Property body[1] of BlockStatement expected node to be of a type ["Statement"] but instead got "ClassExpression"
    at validate (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/types/lib/definitions/utils.js:130:13)
    at validator (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/types/lib/definitions/utils.js:97:7)
    at Object.validate (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/types/lib/definitions/utils.js:177:7)
    at validate (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/types/lib/validators/validate.js:17:9)
    at builder (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/types/lib/builders/builder.js:46:27)
    at Object.BlockStatement (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/types/lib/builders/generated/index.js:245:31)
    at NodePath.replaceExpressionWithStatements (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/traverse/lib/path/replacement.js:212:57)
    at NodePath.insertBefore (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/traverse/lib/path/modification.js:47:17)
    at NodePath.unshiftContainer (/Users/ashoat/Dropbox/src/rn56babelbug/node_modules/@babel/traverse/lib/path/modification.js:204:15)

I have the same issue and i'm also using react-native-modal

Hi there, I'm the RN modal maintainer.
Thanks @Ashoat for investigating and @Titozzz for reporting the issue.
Unfortunately I'm super busy today so I can't investigate further but if you're willing to submit a PR / proposing a fix I can push a new release ASAP.

Right now the only thing I found is not a fix but a workaround... I transpiled your code to ES5 and replaced it... but it works 😭

The easiest workaround for now is simply to remove the export from the ReactNativeModal declaration.
The bug is with Babel, not react-native-modal. However, given Babel will probably take a while to patch, it’s probably easiest to patch react-native-modal. The export can be redeclared later with export { ReactNativeModal }.

I'm trying your fix right now @Ashoat

I'd like to report the bug to the Babel team, but I'm not sure how to reproduce it outside a React Native environment. I tried to create a minimal repro using babel-preset-react-native, but I can't get the bug to happen.
However, I did get a minimal React Native repro working.
Does anybody who knows more about how Metro uses Babel know what I'm missing in the pure-Babel repro?

I just released a new minor version of react-native-modal with the fix proposed by @Ashoat (submitted by @Titozzz ).
Thank you guys ❤

I'm still experiencing this error after bumping version of react-native-modal to 6.2.0. Probably one of my other dependencies is causing this issue. @Ashoat could you be more specific how did you manage to narrow down this issue to react-native-modal, maybe then I can find what is causing it in my project

I just opened the file in the stacktrace and added console.log statements. There was some variable called parentFile or something like that.

Yep, just released a new version of that one as well!

@mmazzarolo thank you!

@Ashoat and @mmazzarolo thank you very much for treading this path ... I followed in your footsteps with only the effort of googling the right search.  Successfully running RN 0.56 with react-native-modal 6.2.0 and babel 7.
  "devDependencies": {
    "@babel/core": "7.0.0-beta.44",
    "babel-jest": "23.4.0",
    "babel-preset-react-native": "^5",
    "jest": "22.0.4"
  },

Since I haven't been able to repro the issue with raw Babel using babel-preset-react-native, my conclusion is that the issue has something to do with the way Metro consumes Babel. I created an issue in the Metro repro.
Going to close this issue seems we've found a short-term workaround for the issue, and the Metro issue tracks the long-term issue.


Internal: Add Cypress integration tests

First step of adding Cypress integration tests for Gestalt.
Next steps:

Use https://github.com/cypress-io/netlify-plugin-cypress to run these on every netlify build
Add https://www.npmjs.com/package/cypress-axe to enable accessibility integration tests

Test Plan

Cypress runs + passes after the netlify build

Follow up at #1220 to implement these integration tests with GitHub actions instead.


fix: Avoid MMO warning message

from syne_tune.experiments import load_experiment triggers
Multi Objective Optimization dependencies are not imported since dependencies are missing. You can install them with
   pip install 'syne-tune[moo]'
or (for everything)
   pip install 'syne-tune[extra]'

Moving the import will avoid that.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hello Martin,
we have these warnings output all over the place. This is a compromise between (a) being able to import stuff at the top, which seems the clean way to do, and (b) you know what you need to do if you run ST with restricted dependencies and get an exception.
I leave this to Jacek, but I got comments in the past about not including stuff except at the top, and anyway this local including does not always work, for example if it is about classes you want to derive from.

I'm fine addressing it a different way as long as the warning disappears. Are there any alternatives?


mock-env: partially revert d31c47a1f9ac

In d31c47a1f9ac, the Content-Type headers were removed with the
justification that the default of "text/plain" was good enough.
However, the Content-Type is used to determine the language used for
syntax highlighting and so we should keep it for the non-text files.

Current coverage is 97.76%

Merging #207 into master will not affect coverage as of 4be7562

Powered by Codecov. Updated on successful CI builds.


Make the name of the events a pointer to constant.

This avoids undefined behavior when casting the const attribute away. Compiler warnings are also avoided.

Given uC/OS-II's long life span, we try to avoid major changes to the API. I don't see a major issue with the current implementation, and the change may cause compatibility issues for older projects.

Hello forg0ne,
true, this is an API change. But definitely not a major one. Adding a const qualifier to a function-parameter does never has an negative effect to the callee. This means this does not create any compatibility issues in old code.
On its contrary, so far, the const qualifier has been implicitly cast away, which raises compiler warnings or even errors. Compare this simplified example: https://godbolt.org/z/3YfTMqKoW.
In addition, casting away a const-qualifier (regardless if it is done implicitly or explicitly) creates an undefined behavior, which should generally be avoided. (Compare https://blog.regehr.org/archives/213)
With this change, the compiler warnings/errors can be avoided, and in addition no undefined behavior is created anymore.


Implement statistics

This pr adds vm statistics to be used in the zksync-era integration, that includes:

Collecting precompiles round counts
Collect storages reads and writes cycles.
Collect vm number of instructions run (or, as they call it, monotonic counter)
Collect decommit cycles

This implementation is supported by the circuits tracer tests in the zksync-era integration.

Great idea! Two comments:

I haven't checked, so maybe it's already there but not mentioned in the description, both stats for far and near call depths would be useful.
This should probably be gated by a feature flag, since it may add significant overhead.


clear-pr-merge-commit-message should preserve commit message if only a single commit is squashed

We use "Squash & Merge" even for PRs with a single commit, because we require commits to be signed and GitHub does not sign commits when doing "Rebase & Merge". Thus, it would be great, if the commit message box would be pre-filled with the commit message of the first and only commit on the PR branch.

Awesome, thanks for the quick fix!


Documentation request: Oban

Hey Mark! Awesome repo! I'm working on adding this to a project and it all seems pretty straightforward except for Oban.
The Problem
For those who may not be familiar, Oban allows you to do job processing with Postgres as its data store. Normally you configure Oban with something like this in your config/config.exs file:
config :my_app, Oban,
  repo: MyApp.Repo,
  plugins: [Oban.Plugins.Pruner],
  queues: [default: 10]

After installing fly_postgres_elixir, Oban fails to start with the following exception:
** (Mix) Could not start application my_app: MyApp.Application.start(:normal, []) returned an error: shutdown: failed to start child: Oban
    ** (EXIT) an exception was raised:
        ** (ArgumentError) expected :repo to be an Ecto.Repo, got: MyApp.Repo
            (oban 2.10.1) lib/oban/config.ex:193: Oban.Config.validate_opt!/1
            (elixir 1.12.3) lib/enum.ex:930: Enum."-each/2-lists^foreach/1-0-"/2
            (oban 2.10.1) lib/oban/config.ex:55: Oban.Config.new/1
            (oban 2.10.1) lib/oban.ex:151: Oban.start_link/1
            (stdlib 3.15.2) supervisor.erl:414: :supervisor.do_start_child_i/3
            (stdlib 3.15.2) supervisor.erl:400: :supervisor.do_start_child/2
            (stdlib 3.15.2) supervisor.erl:384: anonymous fn/3 in :supervisor.start_children/2
            (stdlib 3.15.2) supervisor.erl:1234: :supervisor.children_map/4
            (stdlib 3.15.2) supervisor.erl:350: :supervisor.init_children/2
            (stdlib 3.15.2) gen_server.erl:423: :gen_server.init_it/2
            (stdlib 3.15.2) gen_server.erl:390: :gen_server.init_it/6
            (stdlib 3.15.2) proc_lib.erl:226: :proc_lib.init_p_do_apply/3

If I change the configuration to point to MyApp.Repo.Local then the application will start up, but if I understand correctly this will cause problems down the line. Oban jobs are inserted into the database using Oban.insert/2 which would then try to insert into the local database which may or may not be a read-only replica.
My Solution
I would love feedback on this solution as I'm sure there might be a better way to do it, but I updated my application module to look like this:
defmodule MyApp.Application do
  use Application

  def start(_type, _args) do
    children = [
      {Fly.RPC, []},
      MyApp.Repo.Local,
      {Fly.Postgres.LSN.Tracker, repo: MyApp.Repo.Local},
      ...
      oban(),
      MyAppWeb.Endpoint
    ]

    opts = [strategy: :one_for_one, name: MyApp.Supervisor]

    children
    |> Enum.reject(&is_nil/1)
    |> Supervisor.start_link(opts)
  end
  ...
  defp oban do
    if Fly.is_primary?() do
      config = Application.fetch_env!(:my_app, Oban)
      {Oban, config}
    end
  end
end

Then I created a new Background module that uses a macro to wrap all the Oban functions so that they will all be called against the primary region every time.
defmodule MyApp.Background do
  @moduledoc """
  This module serves as a wrapper around Oban so that it will work properly
  with `Fly.Repo` instead of an `Ecto.Repo`.
  """

  for {func, arity} <- Oban.__info__(:functions), func not in [:child_spec, :init, :start_link] do
    args = Macro.generate_arguments(arity, __MODULE__)

    @doc """
    See documentation for Oban.#{func}/#{arity}
    """
    def unquote(func)(unquote_splicing(args)) do
      if Fly.is_primary?() do
        Oban.unquote(func)(unquote_splicing(args))
      else
        Fly.RPC.rpc_region(Fly.primary_region(), Oban, unquote(func), unquote(args))
      end
    end
  end
end

Am I overlooking a simpler solution? I was thinking about making a video about how to do this, but I was wondering if it might make sense to have it live in the official documentation to make it easier for others to find. I also considered making the Background module a supervisor and have it determine whether or not to start the Oban process so that everything would be contained within that one module. Then I think it could maybe make sense to release it as a separate library if that would have value to others. I wasn't sure if it made sense to do that considering the relative simplicity of it. But I would love to know others' thoughts.

Oh one more thing in case anyone else finds this: You will want to make sure anywhere you are calling use Oban.Testing, repo: MyApp.Repo is updated to use Oban.Testing, repo: MyApp.Repo.Local as well.

Hey @dnsbty! Thanks for writing this up!
I talked with Parker Selbert about how to best work with Oban in a situation like this. We determined that Oban really assumes it's in close proximity to the writable primary database. So the jobs should only be run from the primary region. He said the queues could be configured to only run on the primary. Here's the approach I took:
https://github.com/fly-apps/hello_elixir/pull/5
Myself, I don't have a lot of personal Oban experience in production. So your extra steps of wrapping the Oban interface seems like a really good idea. I'd have to play with the wrapper a bit to test it out.
Could it be simplified like this?
    def unquote(func)(unquote_splicing(args)) do
      Fly.RPC.rpc_region(Fly.primary_region(), Oban, unquote(func), unquote(args))
    end

The Fly.RPC.rpc_region already executes it locally if it's in the primary region or forwards it on if it's not. Does that change still work for you?
If so, I'd love to document it with the library to help people out.

I think your application setup is cleaner though. I like that.

I had exactly the same error. In my case, our solution was to create another repo for Oban with the database URL for the primary region:
# config/runtime.exs

config :myapp, MyApp.Oban.Repo,
    url: System.fetch_env!("DATABASE_URL"),
    socket_options: [:inet6],
    pool_size: String.to_integer(System.get_env("POOL_SIZE", "10")),
    priv: "priv/repo",
    migration_lock: nil,
    queue_target: 5000

# config/config.exs

config :myapp, Oban,
  repo: MyApp.Oban.Repo, # pass the repo here
  queues: [
    default: 10,
    upload: 3,
    ...
  ],
  plugins: [
    Oban.Plugins.Pruner,
    {
      Oban.Plugins.Cron,
      crontab: [
        # Inserted at midnight every day
        ...
      ]
    }
  ]

# lib/myapp/application.ex

  defp oban_opts do
    if primary_region?() do
      Application.get_env(:brandkit, Oban)
    else
      Application.get_env(:brandkit, Oban)
      |> Keyword.put(:queues, false)
      |> Keyword.put(:plugins, false)
      |> Keyword.put(:notifier, Brandkit.DummyNotifier) # also we have to add a custom notifier to avoid some queries.
    end
  end

 defp primary_region? do
    System.get_env("FLY_REGION") == System.get_env("PRIMARY_REGION")
  end

But this solution you guys show seems simpler! I'll try! :)

@fedeotaran I hope there will be some recommended configs for Oban and fly_postgres coming soon!
BTW, you can use Fly.is_primary?() as a built-in helper to replace the primary_region? function above. It does the same thing, so you were totally right about that. :)

Just an update to report on current progress and to explain that this isn't forgotten.
UPDATE: @sorentwo worked with me to help figure out what was needed for oban support. The fly_postgres was updated following his recommendations. I think there may still be some config and documentation to add here, but it's become more simplified. I think the big change is to disable the oban process from running outside of the primary region.
I also believe a blog post is coming soon from Parker that may help as well.

The getoban.pro app runs in 7 regions, but only the primary has a Postgres instance. A few weeks ago (right around the time this post started) I experimented with a replication based Oban deployment. Here is what I discovered:

Postgres based notifications don’t work. You must switch to a distributed erlang notifier like Oban.Notifiers.PG.
Oban instances running non-primary regions shouldn’t run any plugins, which also prevents them from trying to take leadership of the cluster. The next Oban version has an explicit mechanism to disable leadership for this exact reason.
Oban Web has issues in other regions because it expects some quick write/read cycles and may time out. It also requires the use of a stats plugin, which triggers leadership and gets into the situation in the previous point.

This is all to say that Oban should work perfectly fine with Fly Postgres if you adhere to the following criteria:

Don’t run queues on non-primary nodes
Don’t run plugins on non-primary nodes
Use the PG notifier

That setup will allow non-primary regions to insert and query jobs, but not execute them—which is exactly what you want.
The easiest way to accomplish this is to do a check in your runtime.exs and conditionally disable queues and plugins. That would look something like this (written on a phone, bear with me):
unless System.get_env("FLY_REGION") do
  System.put_env("FLY_REGION", "ord")
end

unless System.get_env("PRIMARY_REGION") do
  System.put_env("PRIMARY_REGION", "ord")
end

primary? = System.get_env("FLY_REGION") == System.get_env("PRIMARY_REGION")

if config_env() == :prod do
  unless primary? do
    config :my_app, Oban,
      queues: false,
      plugins: false
  end
 end

Hope the info is helpful!

Hey,
I found a lot of useful information here, thank you!
I got Oban working with fly_postgres_elixir with a multi instance setup.
When I do a deployment I see a lot of logs like these:
 app[d11a6ec1] ord [info] ** (ArgumentError) no node found running in region "sin"

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (oban_pro 0.13.0) lib/oban/pro/queue/smart_engine.ex:70: anonymous fn/2 in Oban.Pro.Queue.SmartEngine.init/2

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (fly_postgres 0.3.1) lib/fly_postgres.ex:170: Fly.Postgres.rpc_and_wait/4

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (oban 2.14.1) lib/oban/engine.ex:282: anonymous fn/3 in Oban.Engine.with_span/4

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (oban_pro 0.13.0) lib/oban/pro/queue/smart_engine.ex:947: Oban.Pro.Queue.SmartEngine.with_retry/3

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (oban 2.14.1) lib/oban/queue/producer.ex:64: Oban.Queue.Producer.handle_continue/2

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (telemetry 1.2.1) /app/deps/telemetry/src/telemetry.erl:321: :telemetry.span/3

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] Last message: {:continue, {:start, [limit: 50, queue: "google_calendar_sync"]}}

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (stdlib 4.2) gen_server.erl:1123: :gen_server.try_dispatch/4

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] ** (ArgumentError) no node found running in region "sin"

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] 09:37:15.131 [error] GenServer {Oban.Registry, {Oban, {:producer, "events"}}} terminating

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (fly_postgres 0.3.1) lib/fly_postgres.ex:170: Fly.Postgres.rpc_and_wait/4

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (fly_rpc 0.2.0) lib/fly_rpc.ex:110: Fly.RPC.rpc_region/5

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (oban_pro 0.13.0) lib/oban/pro/queue/smart_engine.ex:947: Oban.Pro.Queue.SmartEngine.with_retry/3

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (oban_pro 0.13.0) lib/oban/pro/queue/smart_engine.ex:70: anonymous fn/2 in Oban.Pro.Queue.SmartEngine.init/2

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (telemetry 1.2.1) /app/deps/telemetry/src/telemetry.erl:321: :telemetry.span/3

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (oban 2.14.1) lib/oban/engine.ex:282: anonymous fn/3 in Oban.Engine.with_span/4

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (stdlib 4.2) gen_server.erl:1123: :gen_server.try_dispatch/4

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] (oban 2.14.1) lib/oban/queue/producer.ex:64: Oban.Queue.Producer.handle_continue/2

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] 09:37:15.186 [info] Discovered node :"staging-betafi@fdaa:0:5b60:a7b:80:b278:8af9:2" in region sin

2023-02-08T09:37:15.763 app[d11a6ec1] ord [info] Last message: {:continue, {:start, [limit: 50, queue: "events"]}}

2023-02-08T09:37:15.777 app[d11a6ec1] ord [info] 09:37:15.374 [info] Running BetafiWeb.Endpoint with cowboy 2.9.0 at :::8080 (http)

2023-02-08T09:37:15.777 app[d11a6ec1] ord [info] 09:37:15.749 [error] GenServer {Oban.Registry, {Oban, {:producer, "mailers"}}} terminating

sin is my primary region and ord is the only non-primary for now.
Is this normal or expected?
It lasts for about 30 seconds.
Everything still seems to work.
My Oban setup follows this comment: https://github.com/superfly/fly_postgres_elixir/issues/18#issuecomment-1076388188
I made the changes that are outlined here to the beam_cookie: https://github.com/superfly/fly_postgres_elixir#prevent-temporary-outages-during-deployments
and the changes to the backup regions Everything comes back as expected.
Everything even oban seems to work during redeployment.
Thank you

I am running into another issue now.
 2023-02-09T09:39:42.798 app[55c15931] maa [info] (fly_postgres 0.3.1) lib/fly_postgres.ex:187: Fly.Postgres.rpc_and_wait/4

2023-02-09T09:39:42.798 app[55c15931] maa [info] (oban 2.14.1) lib/oban/stager.ex:138: Oban.Stager.stage_scheduled/2

2023-02-09T09:39:42.798 app[55c15931] maa [info] (oban 2.14.1) lib/oban/stager.ex:115: anonymous fn/2 in Oban.Stager.check_leadership_and_stage/1

2023-02-09T09:39:42.798 app[55c15931] maa [info] (ecto_sql 3.9.2) lib/ecto/adapters/sql.ex:1203: anonymous fn/3 in Ecto.Adapters.SQL.checkout_or_transaction/4

2023-02-09T09:39:42.798 app[55c15931] maa [info] (db_connection 2.4.3) lib/db_connection.ex:1611: DBConnection.run_transaction/4

2023-02-09T09:39:42.798 app[55c15931] maa [info] (oban 2.14.1) lib/oban/stager.ex:86: anonymous fn/2 in Oban.Stager.handle_info/2

2023-02-09T09:39:42.798 app[55c15931] maa [info] (telemetry 1.2.1) /app/deps/telemetry/src/telemetry.erl:321: :telemetry.span/3

2023-02-09T09:39:42.798 app[55c15931] maa [info] (oban 2.14.1) lib/oban/stager.ex:85: Oban.Stager.handle_info/2

2023-02-09T09:39:42.798 app[55c15931] maa [info] Last message: :stage

I see these logs on the non-primary instance constantly.
The config of it is this:
[
  engine: Oban.Pro.Queue.SmartEngine,
  repo: xxxxx.Repo,
  notifier: Oban.Notifiers.PG,
  peer: Oban.Peers.Global,
  plugins: [],
  queues: false
]

Does Oban need the local repo?
I am wondering because it makes inserts etc.
Maybe the config need to change @sorentwo after Oban.Stager is not a plugin anymore?

Hey,
Thanks a lot!
Just to clarify, we still need to use plugins: false?
In the docs it says plugins: []
https://hexdocs.pm/oban/v2-11.html#check-configuration-for-multi-node-setups

Great point! That section describes how to retain job staging without running any plugins. In this case, you want to disable job staging and plugins so that non-primary nodes can only insert jobs.

Hey @sorentwo,
If we have this config, the oban dashboard only works in the primary region.
For example, have an app running in Singapore and US.
If you connect to the instance in Singapore the dashboard works, if you connect to the one in the US it does not.
(this can be circumvented by a vpn but it is inconvenient)
This is problematic for globally distributed teams.
Any idea how can we make the dashboard work from all regions?
Thanks

That updated config will work fine, and is what I would recommend. Some operations like bulk canceling won’t work because they require a db write, but you could disable operations in replica regions using a resolver: https://getoban.pro/docs/web/2.9.6/customizing.html#action-controls


Refactor doc

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.6 out of 7 committers have signed the CLA.:white_check_mark: RyanXLi:white_check_mark: wangruohui:white_check_mark: yhcao6:white_check_mark: xvjiarui:white_check_mark: ZwwWayne:white_check_mark: v-qjqs:x: AemikaChowYou have signed the CLA already but the status is still pending? Let us recheck it.

Hi!
@AemikaChow
First of all, we want to express our gratitude for your significant PR in the OpenMMLab project. Your contribution is highly appreciated, and we are grateful for your efforts in helping improve this open-source project during your personal time. We believe that many developers will benefit from your PR.
We would also like to invite you to join our Special Interest Group (SIG) private channel on Discord, where you can share your experiences, ideas, and build connections with like-minded peers. To join the SIG channel, simply message moderator— OpenMMLab on Discord or briefly share your open-source contributions in the #introductions channel and we will assist you. Look forward to seeing you there! Join us ：https://discord.gg/UjgXkPWNqA
If you have WeChat account，welcome to join our community on WeChat. You can add our assistant ：openmmlabwx. Please add "mmsig + Github ID" as a remark when adding friends：）
Thank you again for your contribution❤


Emacs IDE integration support

As discussed on Gitter, I've completed the initial version of the project template, and also the minor mode for Emacs.
I've also submitted a PR to the MELPA repo for Emacs to allow easy installation of the minor mode.

Thanks a lot for great PR! Could you provide screenshot like this http://docs.platformio.org/en/latest/ide/vim.html#screenshot ? People like pictures :smile:
Happy Holidays and Merry Christmas!

Thanks, Merry Christmas to you as well @ivankravets .
I'll try and get a screenshot up and also fix the test error tonight.

Thanks!

and also fix the test error tonight.

Please edit this file with
.. toctree::
    :maxdepth: 2

    ide/arduino
    ide/atom
    ide/clion
    ide/eclipse
    ide/emacs
    ide/energia
    ide/qtcreator
    ide/sublimetext
    ide/vim
    ide/visualstudio

Wow! PR number 404!

@crushedice2000 :smile:  :smile:  :smile:  NOT FOUND
Do you use Emacs?

@ivankravets: No, I don't use emacs nor vim ;-) however would be great to add support for emacs ;-)

Just got my Emacs package added into MELPA :)
Anything else you see that needs modification on the template side, @ivankravets ?

My congrats ! :)
Could you make a screenshot? See VIM integration in the docs for example.
Thanks.

@ZachMassia Thanks a lot for this PR!!! Will be released with PlatformIO 2.7.0 which is planned on 2015-12-29
See http://docs.platformio.org/en/latest/ide/emacs.html
:christmas_tree: :gift: :christmas_tree: :gift: :christmas_tree: :gift: :christmas_tree: :gift:

Awesome, glad I could help :+1:


Language rename: GAS and Groff

When language renaming becomes possible, I suggest these:
GAS → Unix Assembly
GAS is the GNU implementation of the Unix as assembler.  The .s file extension isn't tied specifically to gas.
Groff → troff
groff is the GNU implementation of the traditional Unix (or even older) typesetting software troff (and nroff).  See https://www.gnu.org/software/groff/manual/html_node/History.html.

Also, for similar reasons:
Bison → Yacc

Groff → troff

While troff is definitely better than Groff (the latter is ridiculous) the language is called roff, as pointed in Wikipedia and in the manpage.
So, instead, it should be:

Groff → roff

/cc @larsbrinkhoff

Before submitting this issue, I read various documents, and it was not clear to me that roff is the obvious name for the language.  For one thing, it's described as a predecessor to troff and `nroff.
But I have nothing against roff, if that's what people want.

@larsbrinkhoff Here are more sources that prove that the language name is roff:

groff(7) manpage — see the title
FreeBSD roff(7) manpage

troff is just one of numerous implementations of roff. There is nroff as well, for example.

Yes, roff is the correct name. See also mandoc’s roff(7) manual and History of UNIX Manpages.

I have to agree. Groff is no more a different language to troff as GhostScript is to PostScript. Furthermore, both implementations share the same roots in roff, which is the original root of the typesetting language. So choosing one over the other doesn't really make sense.

@Alhadis I have never seen it in uppercase. It is just roff.

Yeah, I'm currently developing a language package for Roff for Atom... and after extensive research into the language's history, I can tell you I fully agree. Must've been fooled by the capitalisation of a .TH statement somewhere. =)

Closing in favor of #3278.

@pchaigno Please reopen. The issue is only partially solved, Groff is now troff, which is not more correct than roff.

@yegortimoshenko Wrong. troff is short for "Typesetter roff", pronounced tee-roff. It's the name of an interpreter, not the language.

@Alhadis That's the issue I'm talking about. It's like calling C language gcc. Fortunately, that's not the case. troff should be renamed into roff, the latter of which is the correct name of the format.

 I interpreted that as "we should name this troff, not roff."
Disregard.

That's also the name that we're going with; see #3278.

Sorry, didn't see 673aeb32b9851cc58429c4b598c876292aaf70c7, only 247439b8e2f9285fc2adc2238868ae32048dffad. My soul can finally rest in peace :-)

So can mine. =)


Praise

This isn't an actual issue; I just wanted to say that this is one of the best things I've ever seen!

Thanks very much!


Added js4_6_2.html

Added js4_6_2.html (DOM addEventListener)

Added js4_6_2.html (DOM addEventListener)


You may like this too

https://github.com/winitzki/sofp
I think you will like my approach to FP that I'm following in the book.
Feel free to delete this issue, sorry for being intrusive.

This is awesome. I've looked quickly through the draft and love it so far. Will have deeper dive and will let you know my thoughts.


chore: Add KeyId computation while importing secret in ockam_vault

Merged https://github.com/ockam-network/ockam/pull/1612


Add grishy.dev

This PR is:

[X] Adding a new domain
[ ] Updating existing domain size
[ ] Changing domain name
[ ] Removing existing domain from list
[ ] Website code changes (512kb.club site)
[ ] Other not listed

[X] I used the uncompressed size of the site
[X] I have included a link to the Cloudflare report
[X] This site is not an ultra minimal site
[X] The following information is filled identical to the data file

I confirm that I have read the FAQ section, particularly the two red items around minimal pages and inappropriate content and I attest that this site is neither of these things.

[X] Check to confirm

Cloudflare Report: https://radar.cloudflare.com/scan/55371a1f-c110-4016-8d4e-a991efa5d8b0/summary

Thanks!


"Live Example" not working

The link in README.md seems to be dead.

The link works just fine. Checked with Chrome, and rechecked with Firefox.
http://www.isitdownrightnow.com/ghost.moso.io.html


linux-raspberrypi: devicetree build failing with recent Poky commit

Hello, a recent commit in Poky broke the build of linux-raspberrypi:
make[3]: *** No rule to make target 'arch/arm/boot/dts/dwc2.dtbo'.  Stop.
arch/arm/Makefile:345: recipe for target 'dwc2.dtbo' failed
make[2]: *** [dwc2.dtbo] Error 2
Makefile:146: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
Makefile:24: recipe for target '__sub-make' failed
make: *** [__sub-make] Error 2
ERROR: oe_runmake failed
WARNING: exit code 1 from a shell command.

The commit in Poky:
commit 396e269c5c0e285be9d5ab40b521dda21bd72e19
Author: Paulo Neves<EMAIL_ADDRESS>Date:   Mon Jul 2 17:03:44 2018 +0200

    kernel-devicetree: Corrected normalize_dtb

    The normalize_dtb function was buggy because
    it only converted from .dts suffix to .dtb
    suffix if the user passed a full source path to
    KERNEL_DEVICETREE containing the /dts/ path.
    The problem is that if the user did that there
    would be a warning.

    On the othet hand if user just set the variable
    KERNEL_DEVICETREE="file.dts" the bbclass translation
    to the respective .dtb target did not occur and
    make would fail saying it has no rule to make target
    file.dts

    This patch decouples the logic of having /dts/ in the
    path from the target translation.

    (From OE-Core rev: 2e7f3b2b9318d1e5395ad58131eafb873f614326)

    Signed-off-by: Paulo Neves<EMAIL_ADDRESS>    Signed-off-by: Richard Purdie<EMAIL_ADDRESS>
I will investigate a PR but if someone knows how to fix it quickly, is welcome :)

Looks like the function in meta/classes/kernel-devicetree.bbclas from Poky:
normalize_dtb () {
        DTB="$1"
        if echo ${DTB} | grep -q '/dts/'; then
                bbwarn "${DTB} contains the full path to the the dts file, but only the dtb name should be used."
        fi
        DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
        echo "${DTB}"
}

is stripping the overlays/ path from the overlay names (using basename). For example overlays/dwc2.dtbo becomes dwc2.dtbo.
I'm not sure what is the correct behaviour here. We shouldn't use overlays/dwc2.dtbo in meta-raspberrypi or Poky shouldn't strip the path. Thoughts?

The commit in Poky was reverted now in master-next, soon will be fixed in master: http://git.yoctoproject.org/clean/cgit.cgi/poky/commit/?h=master-next&id=c21347064a0f3faf61b2950def4b7a93846c7a8e


Add version: GoLang.Go.1.17 version 1.17.7

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[ ] Have you tested your manifest locally with winget install --manifest <path>?
[X] Does your manifest conform to the 1.1 schema?


New Command: Get planner tasks

Suggestion to a new command.
Planner is one of popular tool used by most of the organizations to manage their project tasks. I would like to cover the areas in planner. To start with, I suggest to list the tasks of a user in planner.

command planner tasks listtasks --userid <useremail/userid>

userid: Either user email or the user id. Optional, if no values passed, it will list current user tasks.

Graph API docs: https://docs.microsoft.com/en-us/graph/api/planneruser-list-tasks?view=graph-rest-1.0&tabs=cs

Requests to be used: /me/planner/tasks and /users/{id}/planner/tasks

Please validate the new command and assign it to me. I'm ready to start my first contribution to office365-cli.

Hey @JayakumarB. Appreciate your help and taking the initiative! To match the current naming convention:

let's change the command name to graph planner task list. Currently, we're still grouping tasks by the API they use. We're dropping this convention for v2, which is in early preview, but for consistency with the current v1, let's prefix the command with graph
let's define two separate properties for userid and useremail, so the command spec is like graph planner task list --userid [userid] --useremail [useremail]. Both are optional and when neither is specified, the command will retrieve tasks of the current user through the /me/planner/tasks API, right?

Awesome addition and looking forward to your PR! Please don't hesitate to reach out if you have any questions.

@waldekmastykarz  Thank you for accepting the request. I will make sure to follow the naming guidelines as you said.

Hi @waldekmastykarz ,
I'm making progress in the command and referred other commands to clarify my doubts. Which alerts about this commands options. It's better to mention username instead of useremail. Because we need userprincipalname to process this command, not email. In some cases useremail and userprincipalname will be different.
So the command will be planner task list --userid [userid] --username [username]

Makes perfect sense. Thank you for the update.


[stdlib] Update changelog to reflect hasPrefix/hasSuffix change.

What's in this pull request?

Update changelog to reflect hasPrefix/hasSuffix change made in https://github.com/apple/swift/pull/3651

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

Builds the compiler incrementally.
Builds the standard library only for macOS. Simulator standard libraries and
device standard libraries are not built.
lldb is not built.
The test and validation-test targets are run only for macOS. The optimized
version of these tests are not run.

A smoke test on Linux does the following:

Builds the compiler incrementally.
Builds the standard library incrementally.
lldb is built incrementally.
The swift test and validation-test targets are run. The optimized version of these
tests are not run.
lldb is tested.

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

@abl Thank you!


Provide file path manipulations for lilypond and include-files

Because of filters as lilypond and inlcude-files we need path manipulation utilities.
We need the PR from pandoc and another Lua implementation  make_relative function.
The function make_relative could be a pure path computation, no filesystem needed. (no symlinks resolving, its probably not needed in a filter context...)
This implementation should be provided in hslua-system-module with for example a copy-implementation of makeRelativeEx
Lilipond:
replace  realpath and dirname in lilypond with make_relative and [PR](https://github.com/jgm/pandoc/pull/6565
If the working dir is /a/b/c
and the image directory /imagedir
and relativize is enabled, an image /imagedir/img  would  resolve into ../../../imagedir/img.
https://github.com/pandoc/lua-filters/blob/1c553017ecc58914c22bf2372902dca4a456929b/lilypond/lilypond.lua#L109

The next pandoc version, probably either <IP_ADDRESS> or 2.11.5, will ship a new Lua module pandoc.path with the necessary functions. We should think about adding additional functions to that module, like canonicalize, but I'd expect it to be good enough for now.


update recent mint changes

mint now supports certificate verification, so we don't need to force clients to set InsecureSkipVerify.

Codecov Report

Merging #1130 into master will increase coverage by 0.04%.
The diff coverage is 40%.

@@            Coverage Diff             @@
##           master    #1130      +/-   ##
==========================================
+ Coverage   90.77%   90.81%   +0.04%
==========================================
  Files         110      110
  Lines        7517     7515       -2
==========================================
+ Hits         6823     6824       +1
+ Misses        464      462       -2
+ Partials      230      229       -1

Impacted Files
Coverage Δ

mint_utils.go
64.71% <0%> (-1.59%)
:arrow_down:

server_tls.go
78.57% <0%> (+1.83%)
:arrow_up:

client.go
91.36% <66.67%> (+0.87%)
:arrow_up:

h2quic/client.go
86.58% <0%> (-1.34%)
:arrow_down:

packet_packer.go
90.35% <0%> (-0.04%)
:arrow_down:

ackhandler/sent_packet_handler.go
98.39% <0%> (+0.03%)
:arrow_up:

session.go
81.29% <0%> (+0.07%)
:arrow_up:

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 29307c5...1edb6b6. Read the comment docs.


Reorganise repository: Separate projects into individual repositories.

Current state:
This repository currently contains folders for several different projects. While this isn't necessarily wrong, it makes it difficult to showcase each project effectively.
Proposed improvement:
I'd like to reorganize the repository by separating the projects into individual repositories. This will make it easier to manage and present each project independently.
Benefits:

Improved clarity and organization
Easier project discovery and navigation
Potential for individual project version control

I'm open to feedback and suggestions on the best way to approach this reorganization.

I've reorganized the repository by following these steps:

Duplicated the repository.
Deleted unwanted folders in the duplicated repository.
Committed and pushed the changes (if working locally).
You can now find the separated projects in their individualrepositories.


Is NTLM supported on Linux?

I'm running the MusicStore sample app (the 1.0.0-rc2 tag) on Linux and have set the ASPNETCORE_ENV environment variable to NtlmAuthentication to make it use the StartupNtlmAuthentication class.
I then added some console output to check what the ClaimsIdentity is populated with:
var identity = (ClaimsIdentity)context.User.Identity;

Console.WriteLine($@"ClaimsIdentity
    Name: {identity.Name}
    Label: {identity.Label}
    AuthenticationType: {identity.AuthenticationType}
    IsAuthenticated: {identity.IsAuthenticated}
    NameClaimType: {identity.NameClaimType}
    RoleClaimType: {identity.RoleClaimType}
");

This is a sample of the output (notice everything is blank):
ClaimsIdentity
Name:
Label:
AuthenticationType:
IsAuthenticated: False
NameClaimType: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
RoleClaimType: http://schemas.microsoft.com/ws/2008/06/identity/claims/role

I've connected my Linux machine to Active Directory using realmd, and it appears that I am authenticated. However, when I register then try to log in, it appears to fall back to regular ASP.NET Identity, which then fails with the following exception:
System.InvalidOperationException: No authentication handler is configured to handle the scheme: Identity.Application
Could someone confirm whether NTLM + Linux is supported?

It is not supported on Linux

Awesome, thank you much!


TypeScript Improvements

I think there is some room for improvement

clear and peak are essentially "untyped".
Imagine I'm using this library for fetching two resources A and B, A has dependencies as [number, number] and B has dependencies [number, string]. So I need a way to make clear(["foo", "bar"]) not compile.
In other words I need to pass the type of (global) dependencies (which is [number, number] | [number, string] in this case) to the library. So here are the ways to do it...
a. Tell users to pass the types via extending an interface via module augmentation
// @file my-project/src/suspend-react-types.d.ts
import "suspend-react";
declare module "suspend-react" {
  export interface Types {
    dependency: [number, number] | [number, string]
    // should be named as "key" see the suggestion on nomenclature at the end
  }
}

// @file my-project/src/Foo.tsx
import { clear } from "suspend-react";

clear(["foo", "foo"]) // won't compile

If the user doesn't provide the types we'd fallback to unknown[] for dependency.
b. Change the API.
// @file my-project/src/extras.ts
import { createSuspender } from "suspend-react";

const suspender = createSuspender<[number, number] | [number, string]>();
// does nothing special in runtime just exports the functions with proper types
export default suspender;

// @file my-project/src/Foo.tsx;
import { clear } from "./extras";

clear(["foo", "foo"]) // won't compile

c. Add an extra type-safe API.
Same as above except we'd also export the current exports (suspend, clear, etc) along with createSuspender so the folks who don't care about types can directly use suspend, clear, etc without having to use createSuspender
d. Don't bother about it, it's not a problem.
Right now you can kinda achieve type-safety like this...
// @file my-project/src/extras.ts
export type MyDependency = [number, number] | [string, string]

// @file my-project/src/Foo.tsx;
import { clear } from "suspend-react";
import { MyDependency } from "./extras";

clear<MyDependency>(["foo", "foo"]) // won't compile

But now you can pass you can pass whatever type different from the actual dependency, you can forget to pass it, you can pass one type to clear but other type to the second arg of suspend, etc xD
My recommendation would be to go with a or d

suspend signature can be improved
This is not much of a big deal just that right now if you hover over suspend this is what you see...

We can change the type a bit so that the user sees this instead...

Or even this...

Though these both come with a negligible risk, here's what Ryan said about it... (although the issue he's commenting on is different but I think it still applies)

Just an update - T & { } creates a "lower-priority" inference site for T by design. I would move this from the "definitely don't depend on this" column to the "it's probably going to work for the foreseeable future" column.

I think we should keep it as it is I guess there's no much gain for the however small risk incurred, just giving the options anyway :P

Let me know if you like any of these improvements, then I'd send a PR. Or if you're fine as the way things are (no problems in that too ofc) you can close this issue.
Also, I'd suggest to change the nomenclature of "dependencies"/"dependency"/"args" to "key" (singular) as the tuple is the key for the cache, it just happens to be dependencies of the suspend function but other than that it doesn't make sense to name the argument of clear as "dependencies" or "args". And also you'd want to come up with a name for the function that one passes in suspend (right now it says "fn"), maybe "resolver"?
It's important to get the nomenclature right because even though it doesn't get reflect in the API anywhere, it does in the documentation, types, source, etc.

thanks for the input, super apreciated! im going with your instincts, they seem warranted. having this finally infer types is amazing (using use-asset for 1.5 years, but typing was a major pita). i renamed args to keys and documented it accordingly.

I was also thinking that another way of improving type safety is to change the API in a way that enforces creating individual caches, each for a specific pair of Keys and Promise result structures, instead of relying on a global one (which doesn't prevent Keys collisions for different result structures)
@drcmda, I hope you don't mind, but to illustrate what that could look like I created an adapted version of suspend-react based on of your demos.
Basically the adapted api there hoists the loader function and config into a "suspending store" factory:
function createSuspendingStore<Keys extends any[], Value>(
    fn: (...keys: Keys) => Promise<Value>, config?: Config
  ): {
    suspend(keys: Keys): Value,
    preload(keys: Keys): void,
    peek(keys: Keys): Value,
    clear(keys?: Keys): void
  }

const postsStore = createSuspendingStore(fetchPost);

const post = postsStore.suspend([id]);

Alternatively the loader function and config could be moved back to the related methods, but consuming them involves a bit more boilerplate:
function createSuspendingStore<Keys extends any[], Value>(): {
    suspend(fn: (...keys: Keys) => Promise<Value>, keys: Keys, config?: Config): Value,
    preload(fn: (...keys: Keys) => Promise<Value>, keys: Keys, config?: Config): void,
    peek(keys: Keys): Value,
    clear(keys?: Keys): void
  }

const postsStore = createSuspendingStore<[number], HNPost>();

const post = postsStore.suspend(fetchPost, [id]);

What do you think?

@drcmda My pleasure! In that case I'll send a PR implementing 1.a soon (2 is okay to be left as it is as I said)
@miguel-silva Your concern around key collisions is fair, but I think it can be solved easily userland, I opened an issue suggesting how

@miguel-silva key collisions are easy to avoid, ,["pmndrs/suspend-react/functionName"]) or
const uid = new Symbol()
suspend(fn, [key1, key2, uid])

i wanted this library to be as simple as humanly possible. cache store already introduce things that aren't so straight forward.

added a small section in the docs https://github.com/pmndrs/suspend-react#making-cache-keys-unique

Blocked on https://github.com/microsoft/TypeScript/issues/46724, waiting to see if it's a bug. If it is then will wait till it gets fixed, if it's not a bug then will see if we can do some workarounds. In worst case we can write declaration by hand instead of the making the compiler emit wrong ones.


Update README.md

Look like this was copy pasted from another library.

Thank you 🙏🏻 The change was made previously. Sorry for the delay


Hand needs to be way too close to grabbable before hand ray disappears

Overview
The hand ray currently only turns off when the hand is incredibly close to a grabbable, when the hand is ~1cm near a grabbable. The ray should turn off when the hand is ~10cm near a grabbable.
This should be implemented by having a separate radius for turning off the line ray, separate from the radius that is used for doing a query for determining what to grab.
Currently, SpherePointer.IsNearObject contains the following:
return UnityEngine.Physics.CheckSphere(position, SphereCastRadius, ~UnityEngine.Physics.IgnoreRaycastLayer);

Instead of SphereCastRadius (used when determining grab start/edn), we should use a different radius HandRayOffRadius.
Expected Behavior
The ray should turn off when hand is ~10cm near a grabbable

Actual Behavior
Ray is still on, even when hand is very close to grabbable

Steps to reproduce
(Links to sample github project preferred)
Unity Editor Version
Mixed Reality Toolkit Release Version

There was originally a 0.05 buffer between the grab radius and the hand ray disappearing, but it looks like that was removed in https://github.com/microsoft/MixedRealityToolkit-Unity/pull/4974 via https://github.com/microsoft/MixedRealityToolkit-Unity/commit/b8160ca9de48c104f474b9d9141cda71a90a65c6#diff-2be5244793f0a456321d940ebafd4e55.
In addition, the grab radius was reduced to a third of its previous size in https://github.com/microsoft/MixedRealityToolkit-Unity/pull/4898.
Those two combined are likely contributing to this issue.

Should this behavior actually be controlled by grabbables?  So

When line pointer hit is closer than X, the pointer is hidden and interaction disabled. Pointer keeps raycasting though, we want to un-hide when moving further away.
Grabbable distance is a separate issue, should the previous radius of 0.15 be restored? It does sound a little bit excessive and if it was just to hide the line pointer then the 1st point would take care of that.

Should this behavior actually be controlled by grabbables?

I don't fully understand the plan, but it could work, I don't have strong objections. Currently the far pointer is disabled by the mediator.

Assigned this issue to you Lukas in case you can help out, since I've got a bit too many bugs to finish before end of this week.

Grabbable distance is a separate issue, should the previous radius of 0.15 be restored? It does sound a little bit excessive and if it was just to hide the line pointer then the 1st point would take care of that.

The grabbable radius should not go back to 0.15 -- that was too big and caused too much accidental grabbing. The current value is okay.


Tab completion isn't working for wd or nvm plugin

I've installed a fresh copy of zsh and oh-my-zsh on Elementary OS Juno.
ZSH: 5.4.2

and I've enabled the following plugins
plugins=(
  extract
  git
  nvm
  wd
  virtualenvwrapper
)

autocomplete isn't working for wd and nvm. The rest are fine.
Can someone please point me on how to debug this issue?

Try rm ~/.zcompdump* after enabling the plugins and then restart the shell.

@mcornella Thanks.

Thanks, it's really helpful!