[vNext] Proposed Fixes for Singleton

I know this may be an unpopular topic, but personally I feel it's time we discuss the implementation of Singleton in the toolkit.
For those who aren't aware, many classes in the toolkit inherit from Singleton. In programming, Singleton is a pattern used to “ensure that only one instance of the singleton class ever exists” (that’s from Wikipedia). But the Singleton class in HoloToolkit doesn't guarantee only a single instance exists. In fact, it doesn't guarantee that any instance exists at all. What Singleton in the toolkit does is return the last instance to become Awake in the Unity scene hierarchy.
Here are some problems that commonly occur with the current implementation:

If no instance of the behavior is placed anywhere in the scene, Singleton.Instance will return null. No exception is thrown and no error will be presented in the log window.

If more than one instance of the behavior is placed in the scene, there is no guarantee which instance will actually be returned by Singleton.Instance. This is because the internal instance is set on Awake and the order in which Awake is called is random. With the current design of  Singleton.Instance, the last one Awake wins.

Many behaviors currently use the object returned by Singleton.Instance without checking first to see if it's null.  If the user has forgotten to place the behavior in the scene, this results in a non-descriptive NullReferenceException at runtime and the calling GameObject is disabled. This is challenging to debug and very confusing for new Unity developers.

There are currently 271 uses of .Instance in the HoloToolkit. Of those 271, only a tiny fraction (maybe 10 or so) actually check to see if the instance is valid before using it. This opens up a very large possibility of error, and when one does occur it's difficult to solve.
I propose the following changes:

Singleton should be renamed SceneInstance
The .Instance property should be renamed .First
The .First property will log a descriptive error and throw a descriptive exception if no instance is available. Something like "An instance of " + typeof(T).Name + " could not be found in the scene."
A new .FirstOrDefault  property will be added which does not throw an exception. This is for cases where it's OK that a behavior may not exist in the scene.
A log message will be generated and exception thrown if more than one instance of the same behavior is added to the scene.

The .First and .FirstOrDefault  names as well as their proposed implementation both follow the conventions used in System.Linq for IEnumerable.
These proposed changes correct the misuse of 'Singleton', follow a known pattern, and properly notify the user if they accidentally leave a required behavior out of a scene.
I'm open to thoughts and feedback. I'm also willing to implement these changes if others agree they would be beneficial.

I was just thinking more about the way System.Linq handles enumerable. Maybe there shouldn't be an exception if more than one instance is added to the scene. We could support Linq like queries. .First, .FirstOrDefuault, .All, etc.

Thanks for bringing this up Jared.  One of the things I've been mulling over myself but haven't had the time to address. I think you've made a wonderful proposal and would like to see other peoples input as well.
This is probably my biggest concern with the current implementation.

If more than one instance of the behavior is placed in the scene, there is no guarantee which instance will actually be returned by Singleton.Instance. This is because the internal instance is set on Awake and the order in which Awake is called is random. With the current design of Singleton.Instance, the last one Awake wins.

Proposal seems reasonable to me.
@mrbobbybobberson do you have any additional thoughts?

I like the direction of this.  It especially startled me when I found no error messaging in .Instance if you forget to create an instance or if you add more than one instance.  The only thing I shy away from is making a "First" and "FirstOrDefault".  I'd prefer to maintain the idea that this concept is for one-in-a-scene objects, so I'd keep the name as "Instance" or perhaps adopt the name "Single" modeled after Linq.  And perhaps if some code needs to check if there's one available, a "HasInstance" or some other bool could be added.  Thoughts on that?

Thanks for weighing in @mrbobbybobberson. I think we really need to decide how much we want to enforce there being one and only one in the scene. If we really want to enforce exactly one, then I agree that First doesn't make sense. In that case we need to get much more explicit with the log messages and exceptions when one isn't found or when more than one attempts to register itself.
If, instead, the purpose is a lightweight dependency resolution strategy then we might consider relaxing the focus on there being exactly one and shift the focus to finding instance(s) within a scene. In this scenario I feel First does make sense because we would allow more than one.
I had never actually looked at or understood Single in Linq until tonight. That's very interesting and it opens up a third option here: Allow the base class to support multiple instances but let the caller assert when there should be only one:

First returns the first one or throws an exception if zero are found.
FirstOrDefault returns the first one or null if zero are found (no exception).
Single returns the ONLY one and throws an exception <1 or >1 are found.
SingleOrDefault returns the ONLY one if there is one but returns null if there are zero (no exception).
AsEnumerable returns all registered (awake) instances.

This allows the best of all to be supported by the same base class and still allows us framework developers to easily assert when there should be an exact number in the scene.
For something like SpatialMappingManager, we'd probably want to use Single to assert that there should be one and only one. For something like GestureManager SingleOrDefault may be OK (use it if available). For TextToSpeechManager, you might want to do an AsEnumerable to enumerate across all TTS in the scene and stop them mid sentence.
Thoughts?

Oh, I forgot we didn't make TextToSpeechManager inherit from Singleton specifically because we wanted to support there being more than one instance. So my final sample doesn't entirely make sense right now, but it theoretically could. Then again, if there can be more than one instance I could see people starting to get confused about when to and not to inherit from this class.
I was hanging out with some folks in the Holo Academy today and we were talking about this. I was under the impression that this was created as a way of doing lightweight dependency resolution and allowing dependencies to come from the scene tree. Someone suggested that it started to create and keep instances awake across scenes (instead of using DontDestroyOnLoad).
If this is about resolving dependencies, most DI containers don't allow more than one instance and attempting to register more than one results in an exception. That would help clarify when to use this base class.
Honestly I go back on forth on whether the base class should enforce a single instance or whether or not the the caller (or calling convention) should enforce it. The latter is more flexible, but I can see how it would cause confusion about the cases when it should be used.

Personally, I've not found a use case for me when I really wanted say multiple GazeManagers in my scene. So I would say keeping it to one instance would work well for majority of the cases. With the verbiage change, we can avoid some confusion around legacy singleton stuff as well. But basically, it's almost like the Singleton design pattern. For scenarios that don't want to be a solo 'Scene.Instance' would not inherit from it as you mentioned earlier.

Another idea, why not convert these to an actual Singleton instance. This has been done many times in Unity before, and commonly using the DontDestroyOnLoad for keeping it around, and having any new instances destroy themselves if they are created - so we keep in line with the idea of a Singleton. If an Instance isn't set yet, its getter would Debug.LogError (then we get UnityPlayer.Log info for production builds) or the UnityEngine.Assertions to ensure something is caught in dev builds when expected game objects aren't present. The above should give devs enough info to know when they've forgotten a dependency.

Simply wanted to point to this Singleton implementation within Unity since this how I have been dealing with them so far (with few adjustments, like notifying there were originally no instance in the scene, for cases needing inspector-tweaked settings).
The editor glitch prevention (applicationIsQuitting) is good to know too.

Are there any news regarding this issue? Yesterday I ran too into the "Singleton.Instance will return null" problem. Thanks to your posts I realized thats it's a HoloToolkit issue and not a problem within my code. Need to find a solution though..

Another option to renaming singleton to sceneinstance would be to make a SceneInstance class.  Then we can iterate on it without breaking existing folks.
In the RS2 branch we have added a 'SingleInstance' class that behaves like singleton, without needing to remember to call base.Awake() to set the instance.  This allows for .Instance to work in Awake() from other scripts. Its getter logs if the class can't be found in the scene or if the class is found more than once in the scene.  I could add a 'HasInstance' bool that would (return Instance != null);
CarpeTempus, which pattern caused your Singleton.Instance to be null?  It probably is something that you need to correct on your end, either by adding the script with the singleton to the scene or not trying to access a .Instance in an Awake() function.  Most of the discussion above I believe is regarding helping developers identify what they need to correct.

Yeah there's a lot of work to be done to get both branches into compliance...

Reading through the above discussion, I see some interesting points raised which allude to use cases I may not be familiar with. That said, it seems apparent that we're actually covering two related but distinct concepts which ultimately should be split into two separate discussions:
1) Singleton pattern objects: Objects which should have no more than one instance instantiated at any one time across all currently loaded Scenes, and which should be accessible from any Scene. These may or may not be made persistent instances, depending upon the particular use case they are intended to fulfil.
2) Scene-Singleton pattern objects: Objects which should have no more than one instance instantiated within any one Scene, but which may have additional instances which each exist in other Scenes, and which may or may not be accessible from other Scenes.
Personally I have not encountered a use case for a SceneSingleton pattern in Unity, primarily because the Singleton pattern performs almost the same function when used in conjunction with Unity's SceneManagement feature set, for every use case I have personally encountered in production environments. While I can envision a few use cases for this pattern, I also find myself wondering whether there is need for this feature within the MRTK, and invite further discussion from other participants on this point.
The main concern I see with the current implementation of SingleInstance is that it presents itself as being of a Singleton pattern, but is in actuality an implementation of the SceneSingleton pattern exhibiting modified behaviour that is inconsistent with the standard Singleton pattern, and which is also inconsistent with Unity's recommended MonoBehaviour logic flow, for the following reasons:

a) SingleInstance uses lazy instance referencing relying upon Object.FindObjectsOfType<T>() to acquire its first instance from the currently active Scene. This is a flawed approach as it i) does not support finding instances within additively loaded Scenes unless the hosting Scene has previously been marked as active within Unity's SceneManager (See link below for reference), ii) does not warn the user if other instances exist within Scenes which are currently loaded but are not the currently active Scene, and iii) even with these restrictions has a performance described as 'very slow' by Unity Technologies as internally it requires a GameObject.GetComponent<T>() search on every GameObject within a full Scene hierarchy traversal.
It is possible to address this issue by having the component iterate through all currently loaded Scenes to find all instances, however this is an even less performant solution than the current implementation, and I am aware of no more performant approach that does not require an unnecessarily complicated solution.

Unity Documentation, Script reference: Object.FindObjectsOfType<T>
https://docs.unity3d.com/ScriptReference/Object.FindObjectsOfType.html

Proposed fix: Singleton instance references should be checked and set explicitly by the valid instance, using its this property.

b) SingleInstance does not follow Unity's recommended logic flow. The recommended logic flow of MonoBehaviour-derived objects is to initialise themselves within their Awake() method (See link below for reference), within which they do not attempt to access any instances of other Components which cannot be guaranteed to exist at that time. This is when the reference to the Singleton instance should be set. If a MonoBehaviour does need to access other Components which are saved to (and thus, initialised within the same frame as other Components in) the currently loading Scene, they should do so no earlier than within their OnEnable(), or ideally within their Start() methods.

Unity Documentation, MonoBehaviour Event Execution Order:
https://docs.unity3d.com/Manual/ExecutionOrder.html

Proposed fix: Singleton reference should be set in the Component's Awake() method, and derived components should not access other Components until OnEnable() or Start() methods are executed.

c) SingleInstance attempts to address issues in other MRTK components. Implementing the two fixes proposed above exposes several cases of other components exhibiting the behaviour described in point b) above, in which they attempt to naively access one or more SingleInstance components which are either uninitialised or non-existent at time of execution. These issues may or may not be encountered in any individual project, depending upon feature inclusion, hierarchy layout, and loading order of Scenes containing derived components.
Referring to the class summary of the current implementation of SingleInstance, it seems clear that it was intended to address these issues, however it does so inadequately, and also introduces some serious and untenable issues of its own.
Proposed fix: Other components should be refactored as necessary to make their behaviour consistent with the recommended flow of MonoBehaviour components.

d) No support currently exists for raising an event once the Singleton instance has been initialised. In past and current projects, I have found it useful to be able to have external Components subscribe to an event which will be fired once a particular Singleton has successfully initialised.
One notable example from the MRTK is the WorldAnchorManager's asynchronous loading of the stored WorldAnchor collection, the completion of which is in effect a prerequisite to the WorldAnchorManager being completely initialised. The reason for this process being asynchronous is apparent, however the constraint does require that other Components are able to safely track when that initialisation has taken place, and the cleanest way to do this is to allow those Components to subscribe to an OnInitialisationComplete event defined within the WorldAnchorManager. For similar reasons other Singletons may benefit from this functionality, even if is used only to allow them to announce that they now exist and may be accessed, and it seems worthwhile to implement this in the base class.
Proposed fix: Add a method with the signature public static void RaiseOnInitialisedOrNow(Action callback), which raises the injected callback immediately if the instance has been initialised at time of execution, or stores it for later execution within the Singleton's Awake() method once initialisation has completed successfully.

e) With the above changes, the class should be renamed appropriately. This is more of a code clarity concern, and is predicated upon the assumption that the intent of any entity should be apparent and clear from its name alone. Currently this intent is not served by the name of the SingleInstance class.
Proposed fix: The class is a generic extension of MonoBehaviour which implements Singleton functionality, so I propose the name MonoBehaviourSingleton<T> as an alternative.

f) The above changes do not provide support for SceneSingleton functionality. If deemed necessary, to cover the use case of having multiple instances of a component which implements singleton-like functionality, but with the specific constraint of having no more than one instance in any single Scene, and which may allow cross-Scene instance access, another component should be created to provide this functionality.
Proposed fix: Another thread should be created with this topic as its subject matter.

Contraindications:
While the proposed code changes to this class are relatively trivial, from making similar changes to our local (older) copy of the MRTK it has become clear that the effect upon dependant classes is not. In particular, it will expose a number of issues related to the behaviour described above in point c) throughout the MRTK, each of which will likely need to be addressed as separate issues. With that in mind, it is best that this proposal be considered for a later version which includes further modifications to other MRTK components.

@shilohjames thanks for the extensive write-up!
We've already agreed to move away from singletons and develop a Dependency Injection approach with vNEXT.


Add Unleash CRDs

Add the required Unleash CRDs:

Unleash - represents an Unleash instance managed by the operator
RemoteUnleash - represents an external Unleash instance that is not managed by the operator
ApiToken - represents an application API token for some Unleash instance

Vi har tatt Unleash CRDene tilbake til https://github.com/nais/unleasherator for øyeblikket da det blir enklere å bruke kubebuilder for å håndtere operatoren.


VR and steering wheel issues (VR: Oculus Quest 2, wheel: Formular Force GP)

Hi Gustavo
we're having issues when running the DReyeVR program from any possible place (editor, package).
Either the wheel works, or the VR works, but never together:
VR works in "play" mode, and wheel works in "launch" mode
Software:
Windows 10 64x
carla 0.9.13
SteamVR 1.25.6
and the required softare from the guide is all set with the instructed version.
hardware;
Gforce GTX 2080 Ti
ryzen 5 5600x
Oculus Quest 2
wheel: Formular Force GP
when running in the editor, with the "launch", and when opening the output log, it shows this:

and it shows this in the beginning of the errors:

but when opening it in "play", the VR works fine, but the wheel does not do anything, and no errors show up on the screen, as it usually does when looking for wheel input.

my wheel plugin is downloaded, and i have downloaded the driver and GHUB as well

and my SteamVR is active during the whole:

Do you have a good guess of what is going wrong?
Thank you for your patience!

So we always run our VR experiments through the "Play->VR Mode" dropdown in editor, and in package/standalone we run it as CarlaUE4.exe -vr (with the -vr flag). The logitech steering wheel not working during VR mode is interesting and I'm not immediately sure what is wrong.
Can you make sure you are on the latest version of DReyeVR (0.1.2 at time of writing)
Can you enable the logitech logging from the Config file to see some prints.
I'd also suggest you try to run in package mode with -vr and enable the package-mode-logging as we describe here for further debugging.
Also those BP_Spline errors are benign (just issues with Carla's 0.9.13 Town03 Map) so you can ignore those.

Thank you, both wheel and vr works together now!
it worked updating the DReyeVR. :)
We used this guide:

found on the Installation guide to DReyeVR: https://github.com/HARPLab/DReyeVR/blob/main/Docs/Install.md


[FEAT] ARM support

It's supported by bluebuild already
https://github.com/blue-build/cli/pull/191

with apple virtualization on, nothing comes up at boot.
without it (ig it uses qemu then), this comes:
Synchronous Exception at 0x00000001391932C7

(silverblue ARM64 rebased to silverblue-hardened-main)
with apple virtualization on, nothing comes up at boot.
without it (ig it uses qemu then), this comes:
Synchronous Exception at 0x00000001391932C7

arm isnt supported. why did you attempt to rebase?


Primitives aren't included in file output

When using the Verilog backend, the primitives aren't included in the output when writing to a file rather than standard out. This is because the file is truncated when it's opened a second time in the OutputFile::get_write call in VerilogBackend::emit, which overwrites anything that was written by VerilogBackend::link_externs.
I'll fix this, but I'm recording it in an issue since I probably won't get to it immediately.

Thanks @bcarlet! Can you provide an MRE?

Sure, take any file that imports primitives:
import "primitives/compile.futil";

// The component doesn't matter
component main() -> (out: 8) {
  cells { r = std_reg(8); }
  wires { out = r.out; }
  control { invoke r(in=8'd42)(); }
}

If we we compile it to Verilog and send the result to standard out,
calyx -b verilog example.futil > out.sv

then out.sv contains a module std_reg. But if we send the result directly to a file,
calyx -b verilog example.futil -o out.sv

then out.sv does not contain a module std_reg.


split openapi-meta to move specification parser to openapi-helper

This will ensure the reuse of the openapi-help in the light-aws-lambda without any dependency for the Undertow.

 split openapi-meta to move specification parser to openapi-helper light-rest-4j master


[Bug]: /play fails if a playlist containing playlists is added

Describe the bug
For some reason, it's possible to add playlists into another playlist.
The bot does not seem to be able to process this.
To Reproduce
Steps to reproduce the behavior:

Go to Jellyfin
Create playlist "A"
Create playlist "B"
Add playlist "A" to "B"
Play playlist "B" using the bot

Expected behavior
The bot also retrieves the songs inside the second playlist.

Cannot reproduce anymore


chore(deps-dev): update dependencies

:tada: This PR is included in version 6.3.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Match Keyword completion won't work for some cases

Description:
Match keyword completion does not work for the following source
import ballerina/io;

function returnUnionType () returns (boolean|float) {
    return false;
}

function main (string... args) {
    boolean|int testUnionVar = false;
    match t
}

Steps to reproduce:

Should suggest the testUnionVar

Closing the issue since the fix has been merged


Use ObjectID as argument when referred-calling _request_gizmo

Fixes #69827
Explanation of the crash is here: https://github.com/godotengine/godot/issues/69827#issuecomment-1344991143
It's unsafe to use raw object pointer as argument of a deferred call. Because that object might already be gone when the call is executed. There's no way to detect the problem since the pointer becomes a wild pointer.
This PR adds a dedicated _request_gizmo_for_id() for deferred calls.

duplicate of #69465

_request_gizmo is also called from within the undo-redo-mechanic. These calls also suffer from the same problem and should use ObjectID.

#69465 seems to be the more complete of the two?

_request_gizmo is also called from within the undo-redo-mechanic. These calls also suffer from the same problem and should use ObjectID.

IIUIC, do/undo arguments should have been kept alive with UndoRedo::add_{do,undo}_reference(). If the arguments are lost, undo/redo won't work as expected I think.

Thanks!


validation for empty strings

Was the api changed between 1.2.1 to 1.2.0 to set the default of empty to false? And should it default to true? If required defaults to false, is the assumption is that that prop isn't included in the object on creation? Then if it is included in the object on creation but is left blank validation will fail. It isn't a huge deal, I'm curious about your thinking on this issue. Thanks for the help.
https://structure.js.org/docs/validation.html#string-validations

The API was not changed but this is a behavior inherited from Joi that by default does not allow empty strings.
I don't think it should default to true, It really depends on the project you are working on, me for example, I'm working on a project using DynamoDB and it doesn't allow empty so for us it's a good behavior.
But I think a generic way to set configurations like that would be great then I proposed that feature.


New Caledonia countrywide

This is the source listed in https://github.com/openaddresses/openaddresses/issues/2928
The server is a bit unstable, but let's see if the machine can pull everything out.

Grump, “504 Gateway Time-out”.

Re-run this please.

Testing a thing with Machine:
Re-run this, please.

Re-run this, please.

Managed to grab with pyesridump so trying this again...
Re-run this, please.

NUM_GRAF appears to be number (NUMERO) and unit (COMP_NUM) combined, though I may be wrong on this.  In some instances, NUM_GRAF is 0 while NUMERO is non-zero and the same value as in the full address field TXT_RECHERCHE.

Since the source is unreliable, I uploaded the pyesridump to https://s3.amazonaws.com/data.openaddresses.io/cache/uploads/trescube/852a94/new-caledonia.geojson.zip

Just area around capital, but excellent to include :)

On May 2, 2017, at 19:28, OpenAddresses Bot<EMAIL_ADDRESS>wrote:
More: https://results.openaddresses.io/jobs/5a4842c1-d0eb-4659-8f9a-4463ca77749a
―
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Seems to pull fine straight from the website, merging with the original ESRI server as source


Execution timeout option

Since the current interruption interface is not supported by the kernel (see #2) a beneficial feature is an optional cell timeout. The timeout can be configured via an environment variable and specified in the kernel.json like the VM/compiler options. If no timeout is specified then no timeout will occur.
Another beneficial place for this is in the server context of jupyter hub where kernels running infinite loops that are not killed don't run forever in the background if a user leaves the server.

See b86211ae39084d17f715cac05bb3eb5c80f1aa95 for the implementation and 24dab5e11e66fe0b6b2ee6a8de4275df36a71621 for an example photo.


Support TLS listening

With either custom certs of just autogenerated ones by default.

I'm closing this for now because I don't see a clear use case, but anyone with a use case should feel free to reopen it.


correct some typos and mistakes.

According @yeasy 's suggestion, correct some typos and mistakes. #2114

@yeasy can you please confirm the changes? Is there any other feedback that needs to be addressed?

@christo4ferris
Yes, I'm rechecking these days. To help guarantee the quality, I'm also asking other hyperledger guys in China to help the check. I will post my feedback ASAP.
By the way, I saw lots of similar requirements to keep a multi-language version of all docs like spec, usage. While currently it's difficult to keep the quality and the updating interval to maintain these works.
Is it necessary to initiate some i18n workgroup to handle these issues?
Welcome for any feedback, thanks!

@christo4ferris I am all in favor of @yeasy 's suggestion.

LGTM

Thanks, will reply in email.

@yeasy agree that we'll need to consider i18n aspects. I have some ideas.

@yeasy are you satisfied with the latest updates?

@christo4ferris Great! Chris, and what's your ideas?
@srderson LGTM. Let's merge this version first and keep syncing with latest doc content. Thanks!

@yeasy Thanks!


Make chart.search(..) return the search results + add zoomTo method

Returns the search results as a list for further manipulation.
The zoomTo method is functionally the same as clicking on a frame. One use case is to zoom to a search result.
For an example see http://bl.ocks.org/kjellmf/raw/533df0ddfb0a3247275f/ (http://bl.ocks.org/kjellmf/533df0ddfb0a3247275f)

Looks great @kjellmf! Merged it and will try to play with some different styles this weekend. Cheers

Thanks @spiermar and thanks for making d3-flame-graph available. Flame graphs are fun to work with.  I have created a handful of d3-flame-graph examples at http://bl.ocks.org/kjellmf .The get top frames example is probably the most useful one.

Looks awesome. Thinking about creating a wiki page with links to examples.


Feat: update ganache-core to support the Istanbul hardfork

Coverage decreased (-0.03%) to 82.123% when pulling baf9d3727660dbd756bfc83040ce4412ab71b39b on feat/istanbul into c305d20161099a7838e70ca41331cf4e6fa7be9f on develop.

Is it possible to release this version for the web3 1.2.4 and enhanced node 12 support?


Add the beginnings of a Function SDK

Description of your changes

I'm sure this won't be close to the end shape of this SDK, but I want to start somewhere. This is essentially a few utilities I found I wanted when writing https://github.com/crossplane-contrib/function-patch-and-transform
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable to ensure this PR is ready for review.

How has this code been tested

It's used to build https://github.com/crossplane-contrib/function-patch-and-transform. Right now it only passes unit tests for that Function (i.e. it hasn't been tested end-to-end).

@phisco I'm going to just merge this for now to get us started, but nothing in here is set in stone.


Related pickers crashes the app

It seems impossible to bind two pickers together (one changing depending on the value of the other) because in 99% of cases the app crashes. It's a bug somewhere in the RN code which I was not able to workaround. The snippet below should make everything clears.
For now, I was forced to replace the pickers with custom modals.
React Native version:
System:
OS: Linux 4.18 Ubuntu 18.10 (Cosmic Cuttlefish)
CPU: (4) x64 Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz
Memory: 1.91 GB / 3.73 GB
Shell: Unknown - /bin/mksh
Binaries:
Node: 8.11.4 - /usr/bin/node
npm: 6.10.3 - /usr/local/bin/npm
npmPackages:
react: 16.8.6 => 16.8.6
react-native: 0.60.4 => 0.60.4
npmGlobalPackages:
react-native-cli: 2.0.1
react-native-screens: 1.0.0-alpha.23
Steps To Reproduce

Run the code below
Select Bar > BarSub02 then go back to Foo

I expect to find Foo > FooSub01 selected. I get a FATAL EXCEPTION instead.
Following code example is a reproducible test case:
import React, {Component} from "react";
import {
        Picker,
        View
} from "react-native";

export default class PickerTest extends Component {
        constructor(props) {
                super(props);
                this.state = {
                        index_group: 0,
                        index_subgroup: 0,
                        items: [
                                {name:"Foo", subs: [
                                        {ClsSubGrName:"FooSub01"},
                                ]},
                                {name:"Bar", subs: [
                                        {ClsSubGrName:"BarSub01"},
                                        {ClsSubGrName:"BarSub02"}
                                ]}
                        ]
                };
        }

        render() {
                return (
                <View style={{flex:1}}>
                        <Picker
                                selectedValue={this.state.index_group}
                                onValueChange={(v) => this.setState({index_group:v,index_subgroup:0})}>
                                {this.state.items.map((item, i) => (
                                        <Picker.Item key={i} value={i} label={item.name} />
                                ))}
                        </Picker>

                        <Picker
                                selectedValue={this.state.index_subgroup}
                                onValueChange={(v) => this.setState({index_subgroup:v})}>
                                {this.state.items[this.state.index_group].subs.map((item, i) => (
                                        <Picker.Item key={i} value={i} label={item.ClsSubGrName} />
                                ))}
                        </Picker>
                </View>
                )
        }
}

Notice that the issue does not occur if current item is the first in list or if you switch between groups with more than one item (e.g. if you add FooSub02 under Foo the issue should not happen anymore).
Here's an excerpt from my logs:
08-09 13:11:27.589  3658  3658 E unknown:ReactNative: Exception in native call
08-09 13:11:27.589  3658  3658 E unknown:ReactNative: java.lang.ArrayIndexOutOfBoundsException: length=1; index=3
08-09 13:11:27.589  3658  3658 E unknown:ReactNative:   at java.util.Arrays$ArrayList.get(Arrays.java:3854)
[ ...OMISSIS... ]
08-09 13:11:27.594  3658  3658 D AndroidRuntime: Shutting down VM
08-09 13:11:27.595  3658  3658 E AndroidRuntime: FATAL EXCEPTION: main

Please use https://github.com/react-native-community/react-native-picker, and report issues there. Thank you

Please use https://github.com/react-native-community/react-native-picker, and report issues there. Thank you

Sorry, I thought it was a builtin feature. Thanks!

It was but moved out

@clamiax  Looks like its a bug with version 0.60.4.
Workaround - add a key to picker

... picker items

@vyshakh I already solved this way: https://github.com/react-native-community/react-native-picker/issues/14#issuecomment-520366956
Thanks!


Add d2h_slow_copy smoke test

The timing related macros make this pretty hard to read. It may be worth compiling as C++ to use chrono and destructors, e.g.
#include <chrono>

struct timer {
  const char *func;

  using clock_ty = std::chrono::high_resolution_clock;
  std::chrono::time_point<clock_ty> start, end;

  timer(const char *func) : func(func) { start = clock_ty::now(); }

  ~timer() {
    end = clock_ty::now();

    uint64_t t =
        std::chrono::duration_cast<std::chrono::nanoseconds>(end - start)
            .count();

    printf("Call %35s: %lu ns (%lu ms)\n", func, t, t / 1000);
  }
}

{
  timer i("id");
  ...
} // prints here

Thanks for the timer class. It is useful. I had made some modifications to it as scoped timer won't work for some parts.


[GOBBLIN-864] add job error message in job state

Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
@yukuai518   please review
JIRA

[x] My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"

https://issues.apache.org/jira/browse/GOBBLIN-XXX

Description

[x] Here are some details about my PR, including screenshots (if applicable):
this will add job error message in job state, just like we set task error message in task state

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:
trivial changes

Commits

[x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Codecov Report

Merging #2720 into master will increase coverage by 0.91%.
The diff coverage is 44.11%.

@@             Coverage Diff              @@
##             master    #2720      +/-   ##
============================================
+ Coverage     44.13%   45.05%   +0.91%
- Complexity     8576     8741     +165
============================================
  Files          1880     1880
  Lines         70170    70199      +29
  Branches       7700     7705       +5
============================================
+ Hits          30973    31629     +656
+ Misses        36312    35643     -669
- Partials       2885     2927      +42

Impacted Files
Coverage Δ
Complexity Δ

...pache/gobblin/configuration/ConfigurationKeys.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...org/apache/gobblin/runtime/EventMetadataUtils.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...in/java/org/apache/gobblin/runtime/JobContext.java
76.37% <100%> (+2.48%)
50 <0> (+1)
:arrow_up:

...rg/apache/gobblin/runtime/AbstractJobLauncher.java
58.12% <25%> (+0.62%)
31 <0> (+2)
:arrow_up:

.../org/apache/gobblin/runtime/SafeDatasetCommit.java
39.71% <44.44%> (-6.33%)
25 <0> (-3)

...gobblin/cluster/ClusterEventMetadataGenerator.java
87.5% <66.66%> (-12.5%)
4 <0> (ø)

...main/java/org/apache/gobblin/runtime/JobState.java
75.73% <71.42%> (+7.96%)
58 <2> (+10)
:arrow_up:

...a/management/copy/publisher/CopyDataPublisher.java
61.64% <0%> (-4.8%)
22% <0%> (-3%)

...ache/gobblin/couchbase/writer/CouchbaseWriter.java
66.27% <0%> (-2.33%)
11% <0%> (ø)

... and 43 more

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 bd4a09a...bb0002a. Read the comment docs.


Accept, but embargo currently valid keys

Instead of rejecting keys that have started before the instant now, but aren't yet expired, accept those keys and emabargo them until they can no longer be used.
This is done by setting the createdAt time on that key.
There is an invariant here that there can only be one key in this state since we don't allow overlapping intervals and we don't allow keys to start in the future.
/fixes #543

/hold
missed tests in another package

/unhold
/shrug

/approve
/lgtm


Confirm that everything is working with the Admin page

It's very very close to working. I'm currently having migration issues and can't figure out exactly why it's failing. I've spent a long time trying to figure out why, but I haven't had any luck. Gonna take a break and retry tomorrow.
{t:600}

I was able to fix the previous migration issue, but now I'm having the same issue when I need to migrate it again. The fix I used last time isn't working and it's incredibly difficult to work with it since there isn't an error message when it fails. Hopefully ill figure it out tomorrow since that should end up being the final step for completion.
{t:600}

It seems like I may have gone in the wrong direction for the uploading csv feature. I'm not 100% sure, but I'll know soon. If I went in the wrong direction then it's looking like I will need to use Django's ORM.
{t:420}


Default Settings and Inventory Location

When this is installed in a controlled location, it can't create the default settings file or download the inventory.  Create a new default location for these that can be written to.
Options:

Windows: %APPDATA%[Program Name]\
Mac/Linux: $HOME/.[program name]/

Fixed by #95 .


Set welcome note resolved status - 21

[Auto generated]
Number: [#21]

github-gitlab-webhook-server: Closing issue for PR: Set welcome note resolved status.
PR was closed.


When checkout out the repo, use the provided branch

Summary
The patch is made from the checked out branch, but without it the patch is attempted to be applied against main, which will brake.
This way of working with patches was introduced in https://github.com/sigstore/root-signing/pull/784, so it has never been tested for a signing ceremony before.
Closes https://github.com/sigstore/root-signing/issues/968
Release Note
N/A
Documentation
N/A

Thanks @cpanato 💟


feat($injector): ability to load new modules after bootstrapping

Added new method to $injector called loadNewModules.
Added corresponding unit tests for new method.
$injector.loadNewModules can be called any time after bootstrap so that any new angular modules defined after bootstrap can still function correctly.  Please see https://groups.google.com/d/msg/angular/w0ZEBz02l8s/YK3H0eMmlxcJ for a detailed justification and explanation of this simple but powerful change.

Ended up modifying my local copy of angular to have this in place. Why even this was not a default behaviour in a first place?

Why even this was not a default behaviour in a first place?

Because an API like this, unbounded, makes it very easy to create a dependency graph that's difficult to reason about. See #11015

+1

@senthanal - 1.4 is already out the door, we have also got the main goals for 1.5 nailed down. I am tentatively adding this to the 1.6 milestone, which are are yet to start planning.

:+1:
I wonder why this feature is usually mentionned as "advanced" while it is a really common use case, just to comply with good practices about the application loading

I have added this to our next team meeting to discuss...

+1

+1

Any updates on this?

I don't think we discussed it in the end. I'll add to the next meeting...
https://docs.google.com/document/d/1xKEbydyUEOQ_gTbcbxy_k2myctG8EiVbeMgLgXTxIc0/

No rush, it's only 4 years since this was opened ¯\_(ツ)_/¯

@cleyshan if you still want to do this then we have decided that we would be happy to merge this.
Can you rebase and fix the conflicts and also provide documentation?

It has now been a week and no reply from @cleyshan - if anyone else wants to take this on and provide a new PR with docs, that would work for us.

@petebacondarwin Simplified snippets of my old code with this fork:
app.service('AmdLoader', function ($injector, $log) {

    var bundleName = 'office-1';
    var bundleJs = config.bundles[bundleName].js

    getScript(bundleJs).done(function () {
        onJsReady(bundleName);
        $log.info('Script loaded : ' + bundleJs);
    });

    var onReady = function (bundleName, done) {
        var moduleName = bundleName + '.html.bundle';
        $log.debug('AMD >> Loading Angular module [' + moduleName + '] ...');

        if (config.bundles[bundleName].modules) {
            $injector.loadNewModules(config.bundles[bundleName].modules);
            $log.debug('AMD >> Children modules loaded >>>');
            $log.debug(config.bundles[bundleName].modules);
        }

        $injector.loadNewModules([moduleName]);
    };
});

Config:
{
  "bundles": {
    "office-1": {
      "js": "path/to/office-1.js",
      "modules": [
        "ui.mask"
      ]
    }
  }
}

Closing in favour of #16224 - thanks for the example @ViieeS


Add missing message params to set user name and avatar

Add option to set a user icon and a user name for the bot when sending custom messages
e.g. JIRA username and JIRA icon

@alexbrazier thanks for the PR!  Will take a look and get this merged 👍


Failed to build OpenBLAS when trying to build caffe-android-lib

I get the below error
C Compiler (/root/vikas/android-ndk-r11c/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-gcc --sysroot=/root/vikas/android-ndk-r11c/platforms/android-21/arch-arm64) is something wrong.
1 at ./c_check line 24.
make: *** [config.h] Error 13
Makefile.system:165: Makefile.conf: No such file or directory
Makefile.system:906: Makefile.: No such file or directory
make: *** No rule to make target 'Makefile.'.  Stop.

@vikasmarath Could you provide more details? Did you use build_openblas.sh?

I actually had the same error when tried to build from linux and pointed to ndk for windows. After I pointed to ndk for linux it successfully built libopenblas_armv8p-r0.2.18.a
But I'm not sure what are the next steps to include this library in my android project. In caffee demo app I see there are .so files in jniLibs folder. Should I generate so files somehow or just add .a files?
@sh1r0 Can you please help me?

@omga
First, you should use not ndk for windows on linux, as it's a cross-compilation toolchain for android where host machine is windows.
Second, what's your purpose? Would you like to use libopenblas solely? If so, you should ask the usage problem in https://github.com/xianyi/OpenBLAS.
Thanks.

Could be reopened if needed.

I get the same error.
Could you give me a solutioin for this error ?

@ten23 Details?

I've got just the same error
Step to reproduce
$ git clone https://github.com/sh1r0/caffe-android-lib
$ export NDK_ROOT=/home/user/Soft/android-ndk-r12b
$ export ANDROID_ABI="x86_64"
$ ./build.sh
make: *** No rule to make target 'clean'.  Stop.
Failed to build OpenBLAS

@DVEfremov Please refer to README, you should either clone all submodules recursively or use git submodule update to get all submodules up-to-date. Thanks.

Sorry I forgot to clone recursively  all sub modules ...


Problem with first load app.js

Laravel Mix Version:4.1.4

Node Version (node -v): v12.14.1

NPM Version (npm -v): 6.14.5

OS: Windows

Description:
Is there an instruction to optimize app.js size? the first download of a 5.5 MB file takes 10 seconds. which is very long. can someone tell me what to look for?
Maybe it is ok. but i think it is not fast at all.
It is my webpack.mix.js

const mix = require('laravel-mix');
mix.autoload({
    jquery: ['$', 'window.jQuery', "jQuery", "window.$", "jquery", "window.jquery"]
});

mix.webpackConfig({
    output: {
        chunkFilename: 'js/chunk/[name].js'
    }

});

mix.options({ processCssUrls: true })
    .js('resources/js/app.js', 'public/js')
    .sass('resources/sass/app.scss', 'public/css')
    .copyDirectory('resources/layout', 'public/layout')//шаблон
    .copyDirectory('resources/images', 'public/img')
    .copyDirectory('resources/css/template', 'public/css/template')
    .copyDirectory('resources/css/dashboard', 'public/css/dashboard')
    .copyDirectory('resources/css/report', 'public/css/report')
    .copyDirectory('resources/css/arm', 'public/css/arm')
    .copyDirectory('resources/js/dashboard', 'public/js/dashboard')
    .copyDirectory('resources/js/common', 'public/js/common')
    .copyDirectory('resources/js/report', 'public/js/report')
    .copyDirectory('resources/js/arm', 'public/js/arm')
    .copyDirectory('resources/js/module', 'public/js/module')
    .copyDirectory('resources/media', 'public/media')
    .copyDirectory('resources/vendors', 'public/vendors')
    .copyDirectory('resources/instruction', 'public/instruction')

Steps To Reproduce:

did you use --prod for production?

Yes, 5.5 MB is result of production's tests

Seems like you're packing all 3rd party vendor code into the app.js all together, and it can result in a monstrous package size. Usually there're tricks to 1) let the vendor code out, load them separately in your webpage, and 2) spilt the chunk into smaller pieces, and dynamically loading components that are needed in the scope or context.
For example, my vue applications always have this setup in webpack.mix.js:
mix.webpackConfig({
    externals: { "vue": "Vue" },
});

And in my code, I can import "Vue" however I want, though the "Vue" library and its dependencies won't be packed into the build files (production or development). The downside of this approach is that you will have to find a CDN that serves the 3rd party libraries, and update the versions in your webpage scripts on each major upgrades.


java.lang.IllegalArgumentException: : could not be parsed into a proper Uri, missing scheme

I recently encountered a weird bug. My service accepts some URLs from users and makes requests to those.
What I'm doing:
val parsedString = sttp.model.Uri.parse(string).toOption.get
val responsF = sttpBackend.send(basicRequest.get(parsedString).response(asByteArray))

And it worked fine until provided string became "" (empty string) then it failed with:
java.lang.IllegalArgumentException: : could not be parsed into a proper Uri, missing scheme
	at org.asynchttpclient.uri.Uri.create(Uri.java:70)
	at org.asynchttpclient.uri.Uri.create(Uri.java:62)
	at org.asynchttpclient.RequestBuilderBase.setUrl(RequestBuilderBase.java:147)
	at sttp.client3.asynchttpclient.AsyncHttpClientBackend.requestToAsync(AsyncHttpClientBackend.scala:196)
	at sttp.client3.asynchttpclient.AsyncHttpClientBackend.$anonfun$preparedRequest$2(AsyncHttpClientBackend.scala:190)
	at scala.util.Try$.apply(Try.scala:210)

Is it expected behavior? I thought if sttp.model.Uri.parse was successful then it was supposed to execute the request or am I missing something?
(reproducible example)
val parsedUrl = sttp.model.Uri.parse("").toOption.get
val str = parsedUrl.toString() // returns `:`
val uri = org.asynchttpclient.uri.Uri.create(str) // boom

Hm indeed that's weird, but some hint as to why this happens might be that sttp's Uri represents both relative and absolute uris, and probably "" gets parsed into a relative uri somehow. Not sure why there's a : (the port separator) in there then. So maybe that's not it :)


Static file "djdt_vertical.png" problem.

As you can see below a request to /img/djdt_vertical.png is made, but the static file is already loaded from the correct path debug_toolbar/img/djdt_vertical.png
Chrome dev tools says the indicator is toolbar.js:244
https://github.com/jazzband/django-debug-toolbar/blob/master/debug_toolbar/static/debug_toolbar/js/toolbar.js#L244
hide_toolbar	@	toolbar.js:244
init	@	toolbar.js:217

Is it possible that you're loading the toolbar.css resource multiple times, but in different locations? It would need to be loaded at http://localhost:4445/toolbar.css and http://localhost:4445/static/debug_toolbar/toolbar.css in order to produce the effect you're seeing.

Sorry it was some time ago i cannot reproduce it now. Thanks for your input!


MODEL_NAME_FLAG appears unused

In the bash script tensorflow/tools/dist_test/local_test.sh the variable MODEL_NAME_FLAG declared in line 94 appears to be unused.
Variables not used for anything are often associated with bugs.
Could someone take a look at this?

@caisq could you take a look?


fix: refactor the database layer

I think this is good to go... having this refactored like this should help support some initial indexing.


[WIP] Move logical qubit along the Z observable

This pull request adds an example demonstrating the movement of the logical qubit along its Z-observable, which addresses issue #50.
I've found that moving data under the current architecture isn't a straightforward task (or it might be an issue with my implementation). The circuits evolve as data moves, which poses significant challenges in defining the plaquettes.
As of now, the detector slices from the output stim circuits appear to be correct to me. However, I'm wondering if there might be a more concise or elegant way to implement this task. I'm open to suggestions from the team and am prepared to make changes in the near future.
Additionally, I've realized that this example could serve as a valuable starting point for further discussions about the tool's design.

I just read the notebook, ran it and replicated the results, good job! I agree with you that the library should offer more convenience functions / classes to address more complex codes.

Additionally, I've realized that this example could serve as a valuable starting point for further discussions about the tool's design.

This was really the principal goal of the issues #50, #51, #52 and #53: find the friction points that makes the library hard to use, as well as potential bugs.
I have 2 main remarks.
The implementation
I think we can benefit from viewing the generation of a QEC differently: instead of having to think about the whole experiment from the start and define everything accordingly, define each part of the code piece by piece. By that I mean that we could:

Generate the initial and last memory experiments using the exact same code as in logical_qubit_memory_experiment.ipynb.
Generate the extended memory using the exact same code as in logical_qubit_extended_memory_experiment.ipynb.
Generate the "glue" circuits between these three QEC steps.
Assemble each generated circuit.

With the methodology above, the only missing piece that will need to be addressed is how to correctly offset the qubits before merging each circuit in order to have quantum circuits on matching qubits.
Basically, just like the other parts of the code, we define re-usable base situations that will be often encountered in real-codes, and make them easy to generate, only leaving the glue to implement to the user of the library.
In particular, the view above means that we will instanciate several different templates (instances of TemplateOrchestrator). But as long as we can offset the qubits correctly, I do not see any problem with that.
The Plaquette classes
I am not satisfied with the different Plaquette classes in tqec.plaquette.library module. They are quite cumbersome and error-prone to use. What is your opinion on that now that you used them? And if you agree with the above opinion, do you have any idea for improvement?

Thanks for your remarks!

In particular, the view above means that we will instanciate several different templates (instances of TemplateOrchestrator).

I agree with that. Actually, this is what I tried to do at first. However, the implementation complexity heavily came from gluing  different parts of the circuits together and we didn't have the template orchecstrator library(assets) yet, then I chose to implement in the simple brute-force way.

What is your opinion on that now that you used them? And if you agree with the above opinion, do you have any idea for improvement?

The Plaquette classes are indeed heavy to use in the code. However, when I think about the use cases after the frontend is ready, we will hopefully define complicated plaquettes on the web with clicking and dragging. The cumbersome definition of plaquettes should only be done for thoes common plaquettes, which will be tested carefully. As for how to test the circuits associated to the plaquettes, I think we can use something like stim.Circuit.has_flow to verify it does have the desired stabilizer flow.

And here are some problems I came across during the implementation in more detail, followed by the idea to tackle them:

How to define a plaquette with empty circuit when all the qubits of it are idling: add with_empty_circuit() to the Plaquette class, which returns a new plaquette with the same shape but a empty scheduled circuit.
How to easily add more measurement records to a detector gate already defined within the plaquettes, which will happen during the circuit gluing process(Or maybe anywhere else during more complicated logical computation): add something like modify_records() to the DetectorGate. Though this is still cumbersome to specify the measurements to be appended to the detector, it will hopefully be made handy at the frontend side. BTW, I think making detector/observable a cirq.Operation rather than cirq.Gate is more appropriate.
How to easily define the glue part of different standard circuit layers: not aware of a simple solution for this yet since the complex overlapping structure between different circuit layers. However, the work at the frontend side will definitely make this part easier.
How to verify the correctness of the built circuits: the most fundmental test we can/should run is that using stim to verify the validity of the definition of the detectors/observables with methods like stim.Circuit.detector_error_model. The simulation as integration tests should be run to verify it further.

I agree with that. Actually, this is what I tried to do at first. However, the implementation complexity heavily came from gluing different parts of the circuits together and we didn't have the template orchecstrator library(assets) yet, then I chose to implement in the simple brute-force way.

Interesting! I though that this would be simpler.

The Plaquette classes are indeed heavy to use in the code. However, when I think about the use cases after the frontend is ready, we will hopefully define complicated plaquettes on the web with clicking and dragging. The cumbersome definition of plaquettes should only be done for thoes common plaquettes, which will be tested carefully.

I agree with your comment.

As for how to test the circuits associated to the plaquettes, I think we can use something like stim.Circuit.has_flow to verify it does have the desired stabilizer flow.

Seems like a good idea.
I agree with most of your listed points, except for

How to easily add more measurement records to a detector gate already defined within the plaquettes, which will happen during the circuit gluing process(Or maybe anywhere else during more complicated logical computation): add something like modify_records() to the DetectorGate.

for which I do not see why we would like to add measurements after plaquette creation. Do you have an example in mind?
Also, I think we should take a little bit of time to think about the changes that are required in order to simplify this task. They may be quite important, and may also impact already existing code.

Do you have an example in mind?

As an example, at the moment we measure out the data qubits along the path, a square plaquette turned into a rounded plaquette. If we do not change the definition of the plaquette in the glue circuit, we need to accout for the two data qubit measurements in the detector gate of the rounded plaquette. Also note that this will need to be added only for the detector in the glue circuit and the following detectors in the memory block remain unchanged.
This is also what I did with the circuit modifier modify_detector_then_repeat in the notebook.
Is there any better idea to address this problem instead of adding additional measurements to the exsiting plaquettes(Or maybe we can change the definition of the plaquettes themself in the glue layer)?

Or maybe we can change the definition of the plaquettes themself in the glue layer

I was thinking about that yes. Create a specific plaquette for that specific purpose, and use it once, in the needed timeslice.
I will try to implement what I has in mind today to help me understand the limitations you encountered.

As another suggestion, note that I think it is completely okay for
neighboring plaquettes to have gates that are common, meaning you detect
that two identical gates overlap and only put one in the circuit. For
example, in a sea of data qubit measurements, in my mind, it would be
perfectly okay to use plaquettes that have four measurements, one on each
corner, and tile them, meaning neighboring pairs of plaquettes have two
measurements in common, only one of which makes it to the circuit.
On Tue, Jan 30, 2024, 3:13 AM Adrien Suau @.***> wrote:

Or maybe we can change the definition of the plaquettes themself in the
glue layer
I was thinking about that yes. Create a specific plaquette for that
specific purpose, and use it once, in the needed timeslice.
I will try to implement what I has in mind today to help me understand the
limitations you encountered.
—
Reply to this email directly, view it on GitHub
https://github.com/QCHackers/tqec/pull/81#issuecomment-1916287377, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKAXTCPXLWJPTAXOIO5M63YRCTUDAVCNFSM6AAAAABCOHZBUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJWGI4DOMZXG4
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

As another suggestion, note that I think it is completely okay for neighboring plaquettes to have gates that are common, meaning you detect that two identical gates overlap and only put one in the circuit. For example, in a sea of data qubit measurements, in my mind, it would be perfectly okay to use plaquettes that have four measurements, one on each corner, and tile them, meaning neighboring pairs of plaquettes have two measurements in common, only one of which makes it to the circuit.

I had to do that for resets and measurements already. For reference, the merging is done here:
https://github.com/QCHackers/tqec/blob/655c86b85260ded3e6268432d00c983d8b210e99/src/tqec/plaquette/schedule.py#L342-L373
and plaquettes are defined with the mergeable_tag in the plaquette library (example for XXPlaquette, the other plaquettes are similar):
https://github.com/QCHackers/tqec/blob/655c86b85260ded3e6268432d00c983d8b210e99/src/tqec/plaquette/library/xx.py#L46-L62
https://github.com/QCHackers/tqec/blob/655c86b85260ded3e6268432d00c983d8b210e99/src/tqec/plaquette/library/xx.py#L139-L151

I got the time to look at the problem, and though it was a good idea to open another draft PR to discuss about potential ways to simplify the implementation you provided.
I would be fine merging that PR as it is solving #50 and the resulting implementation is working as expected. We can then iteratively improve the tqec library to simplify the QEC creation process showcased in the notebook you wrote.
What do you think @inmzhang ? Also, I am eager for other opinions, either on the code here or about the plan laid above (merging this one and then improving in follow-up PRs).

Great, I think it's fine to merge this PR as a starting point of further iteration. And I'll review #100 in a few hours.


Feature request: Post number more than 100, it is too slow  : (

Description
[Description of the feature]
Hi. I love this repository.
It is so simple and good.
But, i try migration from before blog to jekyll, it is too slow bulild.
Post number is about 400.
GitHub mail to me "Page build timed out. Please try again later."
And in local, it is too slow build too.
How can i solve this problem?

err. I didn't pay much attention about building speed.
I don't know much about your former blog, but Jekyll  itself is not very fast and TeXt by now is a complex theme.
You can build your blog in your computer and push the result files to GitHub. I'll pay more attention about it : )’


Add spec87 hex

With this PR we:

add ISO8583 1987 version with HEX encoding
create ./specs directory for all new specs
in CLI show the list of supported specs

Codecov Report

Merging #92 (c1444ab) into master (368c26f) will decrease coverage by 2.45%.
The diff coverage is 0.00%.

:exclamation: Current head c1444ab differs from pull request most recent head e92d978. Consider uploading reports for the commit e92d978 to get more accurate results

@@            Coverage Diff             @@
##           master      #92      +/-   ##
==========================================
- Coverage   71.19%   68.74%   -2.46%
==========================================
  Files          21       21
  Lines         729      755      +26
==========================================
  Hits          519      519
- Misses        165      191      +26
  Partials       45       45

Impacted Files
Coverage Δ

prefix/hex.go
5.55% <0.00%> (-14.45%)
:arrow_down:

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 368c26f...e92d978. Read the comment docs.

Updated README :)


Matches multiple schemas when only one must validate in launch.json

I am receiving this problem message in my launch.json file, and I am completely unable to use the debugger in vscode. It simply doesn't work. To just run one line of code takes 5 minutes. And functions won't run at all. I don't know if this problem message has any relevancy to the debugger not working, but both issues have occurred at the same time so I'm assuming that this is the case.
I've also tried to uninstall the javascript debugger, and instead installed the overnight addition of the debugger in case their was bug fixes I missed, but the problem still persists.
If anyone can help me with this issue i'd greatly appreciate it, as I can't really code at all until this is resolved.
Thanks.

Could you please shared the affected launch config?
And a screenshot showing the message in context would help too.


cmd/go: "go get" can fail in a confusing way on the module path

I found this weird error while writing a reproducer for https://github.com/golang/go/issues/44961. Using x/tools as an example:
$ go version
go version devel +cf59850466 Wed Mar 10 09:01:05 2021 +0000 linux/amd64
$ cd src/tools
$ git checkout -q 44abc2a71b321b77c0a579d8c5bf2704d648c9e0
$ go get -d golang.org/x/tools
go get golang.org/x/tools: unrecognized import path "golang.org/x": parse https://golang.org/x?go-get=1: no go-import meta tags ()
$ go get -d golang.org/x/tools@latest
go get: can't request version "latest" of the main module (golang.org/x/tools)
$ go get -d golang.org/x/tools@master
go get: can't request version "master" of the main module (golang.org/x/tools)

I'm not sure why the first go get gives that weird error message. I would expect the three commands to error in the same way.

I think the can't request version "latest" of the main module messages are correct.
unrecognized import path "golang.org/x" is weird and confusing. I'm guessing that only comes up if the argument is the main module path? The go command would disqualify that when searching for packages, so it would be as if you typed go get golang.org/x, in which case that would be the correct message.
We should probably treat go get golang.org/x/tools just like go get golang.org/x/tools@upgrade. Technically, you might be looking for a package with the same path as the main module that actually is provided by another module, but it's unlikely.

Technically, you might be looking for a package with the same path as the main module that actually is provided by another module, but it's unlikely.

I think that falls under "noone should ever ever do this", so I don't think the error message should mention a parent module. I don't think we should even try to look for a parent module.

go get -d golang.org/x/tools is requesting that we download the package-or-module golang.org/x/tools. There is no such package, but if golang.org/x/tools itself is the main module, then it is the latest version of itself and arguably the command should succeed without error.
That is, the lack of a corresponding package should cause the path to be interpreted as a module path, and then nothing should change because the main module is already (invariantly) the latest version of itself.

#37700 is closely related.

Issue was incidentally fixed by commit 109c13b64f815230af65af5c21e67cd7baa62a05 which merged dev.cmdgo development.
> gotip version
go version devel go1.18-ee91bb8319 Tue Sep 14 02:53:17 2021 +0000 windows/amd64
>gotip get  -d golang.org/x/tools
go: downloading golang.org/x/tools v0.1.5

It seems that issue can be closed for now.


Generator modules should provide their own entries to the GeneratorFactory

Actually this should probably be part of #33


Update jsoniter-scala-core, ... to 2.13.3

Updates

com.github.plokhotnyuk.jsoniter-scala:jsoniter-scala-core
com.github.plokhotnyuk.jsoniter-scala:jsoniter-scala-macros

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

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

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #358.


Out of heap space - parse one bucket at a time

Current implementation parses all bulk insert buckets into a massive json object which is stored on the heap. Proposed solution prepares a bucket at a time, preferably while elasticsearch is busy indexing.
To work around this issue run with the -Xmx1g parameter, or increase if required.

By parsing the excel files up front it is possible to fail before the import has started.

Done - we still cannot support excel files of arbitrary sizes. Apache POI consumes a LOT of memory.


Grammar fixes, HoYoVerse branding, and slight rephrasing

Kinda picking up where pull request #228 left off...
I'm not a master of English, but this should do the trick.

Thanks for the contribution, please contribute on the Crowdin next time, because its easier to track translation there :)


/bin/sh and sh may not be a Bourne-like shell

It's not clear whether the rust-installer is targeting all POSIX shells or just Bourne shells. /bin/sh is not guaranteed to point to a Bourne-like shell. For example on Ubuntu, /bin/sh is symlinked to /bin/dash, or the Debian Almquist Shell.

@postmodern Do you have pointers about how to do those checks? I'm not familiar.
Sorry it's taken me so long to circle back around to rust-installer. I've been on other things for a while, but starting a big upgrade now.

I normally explicitly check for $BASH_VERSION or $ZSH_VERSION. Not sure how you'd check whether a shell is bourne compatible.

Also, platforms like SmartOS/Solaris have /bin/sh which is POSIX shell and does not have the "local" directive.  The script is not portable assuming /bin/sh in /bin/bash


Production queue after buying a building by faith

If you buy a building with faith, the current construction order is deleted from the production queue. If there are more orders in the queue, they will moved up.
UPDATE: That seems to fall apparently only repair orders.
See following figures:
Before:

After:

Following DLC and Mods are used:

Related to #112


Updated Readme

Information about the new version has been made and the view has been updated.

Updated Readme

Merging seems to be a pain. Anyways I am taking idea from this :D


Task Prioritization

Implement a feature where users can assign priorities to tasks. This could be done using simple labels like 'high', 'medium', or 'low' or numerical values. Users could then sort their tasks based on these priorities.

How should we display this

Different colors.
example

[  ] Clean room HIGH (in red)
etc


tf.exp on GPU behaves differently from CPU and numpy when a complex input overflows

Click to expand!
Issue Type
Bug
Source
source
Tensorflow Version
2.9.2
Custom Code
Yes
OS Platform and Distribution
Colab
Mobile device
No response
Python version
3.7.15
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
11.2.152, 8.1.1
GPU model and memory
No response
Current Behaviour?
When an input of tf.complex64 is too big (say 100.+0.j) and thus causes np.exp to overflow, it returns inf+nanj on GPU, while np.exp and tf.exp on CPU return inf+0.j. This may affect further computation on the result.
Since 100+0.j has zero image part, the overflow should only affect its real part.
Standalone code to reproduce the issue
print("numpy")
input = np.array([100], dtype=np.complex64)
exp = np.exp(input)
abs = np.abs(exp)
print(input, exp, abs)

with tf.device("/cpu:0"):
  print("CPU")
  input = tf.convert_to_tensor([100], tf.complex64)
  exp = tf.exp(input)
  abs = tf.abs(exp)
  print(input, exp, abs)

with tf.device("/gpu:0"):
  print("GPU")
  input = tf.convert_to_tensor([100], tf.complex64)
  exp = tf.exp(input)
  abs = tf.abs(exp)
  print(input, exp, abs)

Relevant log output
numpy
[100.+0.j] [inf+0.j] [inf]
CPU
tf.Tensor([100.+0.j], shape=(1,), dtype=complex64) tf.Tensor([inf+0.j], shape=(1,), dtype=complex64) tf.Tensor([inf], shape=(1,), dtype=float32)
GPU
tf.Tensor([100.+0.j], shape=(1,), dtype=complex64) tf.Tensor([inf+nanj], shape=(1,), dtype=complex64) tf.Tensor([nan], shape=(1,), dtype=float32)
/usr/local/lib/python3.7/dist-packages/ipykernel_launcher.py:3: RuntimeWarning: overflow encountered in exp
  This is separate from the ipykernel package so we can avoid doing imports until

@tilakrayal This is also reproduced on tf nightly.

@sachinprasadhs,
I was able to reproduce the issue on tensorflow-gpu v2.9, v2.10 and nightly. Kindly find the gist of it here.

@tilakrayal Your nightly gist is on CPU only

The C++ standard doesn't seem to specify what happens on complex overflow: std::exp(std::complex).  For real inputs, it does explicitly specify that the output should be inf.
On CPU, we simply call std::exp, which returns inf+0j.  On GPU, we're calling the MLIR implementation, which is returning inf+NaNj.  If I disable MLIR kernels, I get the same result as CPU (because we then revert back to calling std::exp).
As for which one is "correct", given the definition that exp(x + j * y) = exp(x) * cos(y) + j * exp(x) * sin(y), I would actually have expected to get an imaginary component of inf * 0 = NaN.  So IMO, MLIR is correct, and std::exp is technically in the wrong.  Though std::exp is probably trying to conform to the specification for real inputs as much as possible.
I'll forward this to the MLIR team, but as a warning: since the behavior is unspecified for such an input, there's no guarantee we can make implementations conform.

Hi,
Thank you for opening this issue. Since this issue has been open for a long time, the code/debug information for this issue may not be relevant with the current state of the code base.
The Tensorflow team is constantly improving the framework by fixing bugs and adding new features. We suggest you try the latest TensorFlow version with the latest compatible hardware configuration which could potentially resolve the issue. If you are still facing the issue, please create a new GitHub issue with your latest findings, with all the debugging information which could help us investigate.
Please follow the release notes to stay up to date with the latest developments which are happening in the Tensorflow space.


The distributed training example fails to mention batch and LR scaling

Keras.io example: https://keras.io/examples/nlp/data_parallel_training_with_keras_nlp/
Merged PR: https://github.com/keras-team/keras-io/pull/1395
This example is good on the whole but it would be much better with proper batch size and learning rate scaling.
Without this, using two accelerators instead of one will not train any faster.
The usual scaling is:
batch_size = strategy.num_replicas_in_sync * sigle_worker_batch_size
The large global batch is processes on the multiple accelerators in chunks, one chunk per accelerator. Without increasing the batch size, you are sending smaller per-worker batches to the accelerators, potentially under-utilizing them.
lr = strategy.num_replicas_in_sync * single_worker_lr
Bigger batches also means fewer gradient updates per epoch. Without scaling the LR, the model will be learning more slowly on multiple workers. Gradient updates computed on bigger batches need to be allowed to do "more training work", through a higher learning rate.
Of course, these are just rules of thumb. Actual optimal values can only be obtained by careful hyper-parameter tuning, with both raw speed, and time to convergence metrics.

@shivance I believe you authored this guide.

@martin-gorner  @sachinprasadhs  Can I work on this Issue?

@Zekrom-7780 , Thanks for Volunteering, Feel free to create a PR.


projects: add eunomia-bpf as Emerging project

Add eunomia-bpf to eBPF projects page. In terms of requirements for inclusion in the projects page:

[X] The project must be open source. All source code must be licensed under an open source license. Any documentation must be licensed under an open license.

All development activities are open source, the documentations and source code are under MIT license.

[X] The project must be using eBPF as its underlying core technology, in other words, a project would lose its purpose if the eBPF parts are removed.

The project tries to simplifies building, distribute, and run eBPF programs with WebAssembly.

[X] The project must be open to collaboration and have a governance model following open-source best-practices.

CODE_OF_CONDUCT and CONTRIBUTING exists.
Open sourced for 3 weeks and We already have 6 contributors, 8 pull requests.

the logo should be imported in the /applications page and declared in the logo list. And the build should be working after fixes.


Ver 81457 label connection param

Adding label connection parameter. The client, connection-string, and connection-parameters classes need to know about the new label param. It has a default of the empty string, cannot be set via environment variable, and can't be managed client side via parameter status message because we currently have no parameter status handler. I began a new test class for Vertica specific connection parameters.

Resolved conflicts resulting from Jonathan's, Prepared Statements PR. Very small conflict


why use the transpose op on embeddings?

https://github.com/guillaumegenthial/tf_ner/blob/master/models/lstm_crf/main.py#L84

@jdxyw ,
Have a look at the Fused cells. They behave differently compared to regular cells.


Follow up for #2938

Address the missing comments from @anuraaga. 😄

Seems like it contains Linefeed character. Let me change it a little bit.

We had a bug in encoding. 🤣
The spec says that
Implementations MUST NOT add line feeds to base-encoded data unless
the specification referring to this document explicitly directs base
encoders to add line feeds after a specific number of characters.

Let me fix this. 😉

@anuraaga Gentle ping :wink:

How about adding more test cases for invalid inputs by the way?

Could borrow some samples from here: https://github.com/google/guava/blob/master/guava-tests/test/com/google/common/io/BaseEncodingTest.java

Could borrow some samples from here<EMAIL_ADDRESS>
There are not so much stuff to bring because it's mostly about the feature that we don't support such as alternate padding, separators, base32 etc.
So I just brought some strings to test more. 😉

How about adding more test cases for invalid inputs by the way?

Add some cases invalid and I found out that I missed the case where padding is inserted in wrong indices. PTAL. 🙇


Ctrlr-x86_64-5.3.201 crash looping on Access-Virus-TI5.bpanelz

I downloaded Ctrlr-x86_64-5.3.201 for the first time. Access-Virus-TI5.bpanelz but I problems with the correct setup. Once I restarted Ctrlr for another try it crashed and tried to restart just to crash again until I manually killed it. I am attaching the crash-loop, but it is not super useful due to missing debug symbols in the precompiled build.
Ctrlr-x86_64.crash.txt
I also tried to build from git, but run into #73?
make -C Builds/LinuxMakefile/
make: Entering directory '/home/ensonic/projects/audio/ctrlr/Builds/LinuxMakefile'
make: *** No rule to make target '../../JuceLibraryCode/include_juce_audio_plugin_client_VST2.cpp', needed by 'build/intermediate/Debug/include_juce_audio_plugin_client_VST2_dd551e08.o'.  Stop.

After deleting /home/ensonic/Ctrlr - I could start it again. Not sure if it helps but the settings where quite large:
ll /home/ensonic/Ctrlr/
total 3880
drwxr-xr-x   7 ensonic eng    4096 Apr 20 18:52 ./
drwxr-xr-x 146 ensonic eng   12288 Apr 20 16:20 ../
drwxr-xr-x   2 ensonic eng   16384 Apr 20 16:18 83f1aec8407e00c3434581d0ebee4828/
drwxr-xr-x   2 ensonic eng    4096 Apr 20 16:03 8.4QkxlRtUKDK/
drwxr-xr-x   2 ensonic eng    4096 Apr 20 16:43 8.Fst7Urk4aFN/
drwxr-xr-x   2 ensonic eng    4096 Apr 20 15:59 8.I4U4PO.mNLH/
drwxr-xr-x   2 ensonic eng    4096 Apr 20 16:37 8.WM+a0GWdOVH/
-rw-r--r--   1 ensonic eng 3918911 Apr 20 18:34 Ctrlr.settings

What's the solution on the build error? Any comment on the crash?


pkgdev commit: inline array space mangler

Add a simple mangler that works only on simple inline arrays, that are set into a environment variable, to auto add spaces after and before the circled brackets.
Meaning a line like: DOCS=(README.md example.txt)
Will mangle into DOCS=( README.md example.txt )

Note that examples in the bash manual are without spaces:
   Arrays are assigned to using compound assignments of the form
     NAME=(VALUE1 VALUE2 ... )

The bash manual also defines functions as
fname () compound-command [ redirections ]

(with the space between the name and parentheses), in fact the environment file is like that too. Your point?

So if we omit the space in function definitions, then maybe we should omit it in array assignments as well, for consistency? :smile:
But seriously, my point is that there's nothing wrong with omitting the spaces, and all of the following are fine:
DOCS=(README.md example.txt)
DOCS=( README.md example.txt )
DOCS=(
    README.md
    example.txt
)

What would be the point of whitespace micro-management here? Does it improve readability, or what?

all PYTHON_COMPATs have the same space formatting, we also enforce tabs for indentation, how is that not whitespace micromanagement?

For example, we have things like local mycmakeargs=() or DOCS=() for assignment of an empty array all over the place. These would be required to be written with a space then?

maybe this is a good opportunity to actually flesh out an actual style guide?

Yes, that's where to start. Then, maybe pkgcheck should warn. But IMHO a tool like pkgdev should be very conservative about changing the files that are committed.

Just my opinion, if Gentoo wants to continue down the path of mangling various bash constructs then it needs something like a bash style guide (copy from some other existing one?), checking for bash style issues (either in pkgcheck or using something like shellcheck) as part of the standard dev flow, and actually using a bash parser.
Doing this in a hacky fashion using regular expressions or similar with no overarching linting support is ill advised.


Document OIDC with managed k8s

We have looked into OIDC with EKS, GKE, and Azure. So we should document that for users.
Acceptance Criteria:

[ ] #1366
[ ] #1365
[ ] #1364
[x] #1363
[ ] #1367

Hello @joaquimrocha, Is there any chance to add support for OpenShift (Oauth) support for the Headlamp? We did some investigation in the scope of this PR https://github.com/headlamp-k8s/headlamp/issues/1035
While the OpenShift console already has a number of useful features, we believe that offering Headlamp across multiple clusters would further enhance the user experience. Do you think there's a chance of adding specific OAuth support for OpenShift?
Thank you

It would be nice to have a guide for Keycloak + kube-oidc-proxy + oauth2-proxy as well!


feat: edges

This component provides an abstraction of EdgesGeometry from Three.js, <Edges> is specifically designed for rendering visible edges of objects in a scene graph. This enhances the visual quality by highlighting contours and providing a stylized appearance which contributes to the artistic aspect of 3D visualizations.

Easy to set up as it automatically derives geometry from its parent
You can simply wrap it around any Object3D, Mesh, or primitive to automatically apply edge rendering.
You can give to <Edges> a custom material

Local Playground — pnpm run playground
Local Documentation — pnpm run docs:dev

Hey @damienmontastier ,
Are you still working on this?

Hey @andretchen0 !
I can continue on it, like the <Decal>

hey @andretchen0 ! I just put a last modified version! ✌
Previously @JaimeTorrealba had given me feedback regarding documentation here . I think there would be the possibility of improving <Edges> with Line2 or something! But currently the Line2 instance that is returned by a defineExpose returns a null value. Maybe in the future we could have a <Edges2> ?
Also, on the demo, I commented some code, there's currently a bug with events pointer https://github.com/Tresjs/tres/issues/801, so the code isn't functional at the moment.

hey @andretchen0 ! I just put a last modified version! ✌

Great!

But currently the Line2 instance that is returned by a defineExpose returns a null value. Maybe in the future we could have a <Edges2> ?

There's at least one open PR for <Line2>. I will check this out and get back to you.

Also, on the demo, I commented some code here, there's currently a bug with events pointer Tresjs/tres#801, so the code isn't functional at the moment.

We'll have to check that in the future, but it's not up to <Edges> to work around it, so don't worry about it here.
The events issue should be fixed with this PR. I'm not sure when it'll be merged though; it's part of a longer term project to bring portals to Tres core and I'm currently on the road and just working on smaller projects.

But currently the Line2 instance that is returned by a defineExpose returns a null value.

The defineExpose issue will be fixed when this PR is merged: https://github.com/Tresjs/cientos/pull/523 . If you want to test on your branch, in src\core\shapes\Line2.vue, you just need to change :ref to ref here:
<template>
  <primitive
    :ref="lineRef"
    :object="line"
  />
</template>

Thanks @andretchen0  for your feedback!
I'm going to modify Line2 locally tomorrow! And I'll let you know!
Is this PR good for you? And so there will be an <Edges2> ?

Is this PR good for you?

It looks good! Docs demo is on-brand, too! I made a few review comments. Nothing major.

And so there will be an <Edges2> ?

If you want to implement one and there's an advantage over the PR here, I don't think anyone would say no. Though my personal preference at the moment would be to make one, good <Edge /> component for users.
Just FYI though, if you were comparing to Drei, their <Line /> and our <Line2 /> both use THREE.Line2. Drei use of THREE.Line2 here.
I called the Cientos' version <Line2 /> since it wraps THREE.Line2. And to avoid conflict in case we ever wanted to have a Cientos component based on THREE.Line.
Since THREE doesn't have Edges, I'm fine with calling your component here <Edges />, even if you want to use <Line2 /> or THREE.Line2 under the hood.
Maybe @alvarosabu wants to weigh in here.

If you want to implement one and there's an advantage over the PR here, I don't think anyone would say no. Though my personal preference at the moment would be to make one, good <Edge /> component for users.

Ok that's understandable!
I'm talking about a case where the user didn't want to use LineSegments (for which line-width doesn't exist, it's a fixed size). Instead, he wanted to use Line2, which embeds line-width modification. That's why I was talking about <Edges2 />.

Hey @andretchen0 !
I've just pushed the last modifications you asked for in the review.

Hey @andretchen0 !
I've just pushed the last modifications you asked for in the review.

Looks good!

If you want to implement one and there's an advantage over the PR here, I don't think anyone would say no. Though my personal preference at the moment would be to make one, good <Edge /> component for users.

Ok that's understandable!
I'm talking about a case where the user didn't want to use LineSegments (for which line-width doesn't exist, it's a fixed size). Instead, he wanted to use Line2, which embeds line-width modification. That's why I was talking about <Edges2 />.

Ah, gotcha.
Line width would be a useful addition, so if it wouldn't be too much work to use Line2 instead of LineSegments here, that'd be nice.
But I won't block the PR either way. It's good for me. Approved.

Hey @andretchen0 !
Yes, I think it will be simpler to create a <Edges2 /> for the use of Line2 and line-widths. This will avoid making <Edges> more complex.
Perfect! Can't wait for the next release!


Upload symbol definitions so they can be seen in ScholarPhi interface

Recently, Dongyeop and Vivek updated the definition extractor to have higher recall and precision. Since then, the data format expected by the UI got out-of-step with the data uploaded from the definition extractor.
This PR includes changes that upload definitions extracted for both tems and symbols to the database in a format that the ScholarPhi UI expects. As a result, you can see that for papers like 1601.00978, symbol nicknames like x are clickable, their definitions show up, and declutter is supported for terms detected by the definition detector.

@rreas and @dykang I would appreciate if you two take a look! I realize the code is tangled, though it's probably a good thing to have others on the team familiar with this code as we approach alpha. Of particular note is the file entities/definitions/upload.py, where the biggest logical changes were made.
Smaller changes include:

renaming acronym* variables to abbreviation* in definition detector
moving the 'Context' type into the common.types instead of entities.sentences.types

I'm not sure I can provide much of value. I've tried to leave a few forward-looking notes! I don't expect that I'd be much help in catching any real bugs without helping run the end-to-end (which we can certainly do!).

Thanks Russell, this is immensely helpful!

I particularly took a look at codes related to definitions and sentences. Overall, it looks good to me. I put some clarification questions when I don't understand the logic behind them by only looking at code.

Thank you, @dykang! I've added clarifications in my responses, and will integrate a few of them into comments where you asked for them. I'm curious to know if they answer your questions!

@andrewhead Yes, they all answer my questions clearly! Please let me know once you resolve the rest of the other issues!


HTML Syntax Highlighting Bug

VS Code Version:

Version: 1.55.0
Commit: c185983a683d14c396952dd432459097bc7f757f
Date: 2021-03-30T16:02:21.560Z
Electron: 11.3.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.8.0-48-generic

OS Version: Ubuntu 20.04.2 LTS

Steps to Reproduce:

Create a file with these contents in VSCode:

<!DOCTYPE HTML>
<html>
  <head>
    <style>
      @-ms-viewport {
        width: device-width;
      }
    </style>
  </head>
</html>

Notice that everything from (and including) </style> is miscoloured and somehow the end of the style tag is not registered

Does this issue occur when all extensions are disabled?: Yes

We recently moved to a different CSS grammar for providing syntax highlighting. The old one was unmaintained, and the new one has good fixes in it. You can see the full discussion here: https://github.com/Microsoft/vscode/issues/115480
Specifically, see https://github.com/Microsoft/vscode/issues/115480#issuecomment-776376851, which references viewport as a deprecated feature (details https://developer.mozilla.org/en-US/docs/Web/CSS/@viewport). Even though the new grammar is missing ms-viewport, we decided to go with it because the benefits of having a maintained grammar outweighed the negative of missing the deprecated ms-viewport.
If you feel strongly that this is essential for the grammar, I recommend going to https://github.com/atom/language-css/, the repo that we pull our css grammar from, and filing an issue there to ask for ms-viewport to be supported in their textmate grammar.

Thank you for the response Alex, and taking the time to explain the reasoning behind it to me!
It's definitely not the biggest deal for me, but I'll submit an issue upstream either way, and see what happens.
Be well!


金字塔下采样时候的尺寸是不是有问题，不能整除的情况会出现bug吧？还有计算权重时候的矩阵是不是该初始化为全零？

金字塔下采样尺寸已修改为round(s/2)；权重初始化已添加，感谢指正~（另增加了robust norm模块，自适应调整输出结果的亮度对比度）。
The size of each pyramid downscale is set to round(s/2), and weightmap initialization has been added. Thanks for pointing out~ (moreover, robust norm is applied to adjust lightness and contrast adaptively).


Issues/95 - Add Run 2.1i DR1 Object Table tutorial

Adds a tutorial stepping through the Run 2.1i DR1 Object Table.

We (== DM) have SVM (?) code to do a better job of s/g separation.  It's been used trained on HSC data (using HST COSMOS imaging as space truth, although HSC is too deep), and we could probably run in on DESC sims too.
		R

Updates now pushed:

Default to *_tract4850.  This takes ~10 seconds to load.
Added subsampling logic to make easy subsamples when loading full DC2.  Scanning the full set of data files still takes ~5 minutes, but the reduced memory footprint means the JupyterHub node doesn't spend all of its time swapping.
Added Mandelbaum N(mag_i) HSC comparison for galaxies.

Thanks @joezuntz  @sschmidt23 for your reviews.
Even in the absence of formal approval from the reviewers, I'm taking the liberty of merging this to get this Notebook in front of the wider collaboration.


Create a UI Using Freestyle SAPUI5

Tutorials: https://developers.sap.com/tutorials/btp-app-create-ui-freestyle-sapui5.html
Step 5 "If these are of interest to you, you can go on using cds watch and skip the rest of the section." should probably read:

"If these are of /no/ interest to you ...".

Hi @laszloKajan,
Thank you for your feedback. We have updated the tutorial in step 5.
Best regards,
Iwona


Translations pulled from Zanata (0.8.x)

+1 to merge.
(Michael B usually does this for all repositories when performing a build, so unless you have good reason to want to check i18n before a release you don't need do this - word of caution if you do this you should also run the "post fetch" updates such as mvn replacer:replace - some i18n eg French contain single apostrophes which need escaping to double - single apostrophes for GWT....)

@manstis hm thanks, I haven' t done that replacer so maybe we should hold this. The reason why I pulled this is because the number of i18n that we're trying to get verified. Getting the updated content from Zanata helps finding out if it is an issue with translation or code.

There's no problem with you doing it if you need ti check i18n before a release, just be sure to run mvn replacer:replace in the repository root before committing :-) IIRC it's covered in the README in droolsjbpm-build-bootstrap... but real developers don't read that!!! --- me included ;-)

@manstis thanks heaps! got it sorted now and also checked the docs :)

+1 to merge.


Is it possibile to log to the stream that is completely outside of the application environment?

Monolog version 1|2|3?
2 or 3
Intro
Let's say we have tests where some code is executed outside of the tests context, e.g.:

API testing where there is a running server and real http requests are executed against it
console commands executed via shell_exec (or something). Here we could probably check the exit code in tests but some commands are not "all or nothing" commands or are designed to be daemons that don't exit on exceptions (e.g. message consumers).

Unfortunately the app code and the tests are not perfect, developers are also on different levels and many don't follow TDD approach what leads to the following problem.
The problem
The problem is that some tests are green even though the server logs have errors. This is because some errors are silenced and logged (what is fine) or, in case of deamon commands, are only logged. However this s not what the test is testing so these errors are missed.
The need
I would like to have a handler in my application that can log to the console where I'm executing tests. Something like this:
$ vendor/bin/phpunit
# the tests are running, API calls are executed, console commands run on the background

# logs from the API server/console commands are shown here

It could be great if the handler in my application would somehow connect to the shell (and it's stdout/stdin) where the test framework is running. This way a developer could see the errors and react despite of the tests being green.
One idea that I have is whether PHP can write to the file descriptor. A terminal where tests are running has it's own process number so if we somehow got this number in the running application we could log to it's file descriptor no. 1.
P.S. yes, I know developers could open the logs file from the application and follow it but: 1. logs from all the test runs would be three so searching is difficult; 2. unfortunately the devs ignore log file until the tests are not green.

You should be able to use a StreamHandler with php://stdout or php://stderr as URL?

Ah I see.. then IMO the next best thing might be to have a step after phpunit is done that checks the test log file and outputs anything that's in it if present.. There are for sure other options to communicate between processes but that doesn't really seem worth the hassle here to have a custom handler talking to the phpunit process etc.

Yeah I'd empty it in the tests bootstrap, keep it simple.


Re-join user on Video Conference

If someone disconnect in the middle of Video Group Chat, how to invite him again, or can he join using the same room ID ?

This functional (joining an ongoing Audio/Video call)  is available from Enterprise plan only and it additionally requires Multi-party Video server. Please contact Sales team<EMAIL_ADDRESS>to learn more.


Use ruby 2.2.5 for appliance builds.

cc @bdunne @Fryguy
I'm thinking darga should go out with the latest 2.2.x ruby.

cc @simaishi

:+1: LGTM


Revert "Deprecate classic dashboard docs"

Reverts SumoLogic/sumologic-documentation#3438

This is incorporated through the PR https://github.com/SumoLogic/sumologic-documentation/pull/3482.


Use rss stream

Instead of making requests to reddit's api each time, just use the rss steam for a subreddit

Or we could use pushshift


Link directing to malware site?

"Tothetrails.com" appears to be redirecting to a Malware site off the readme.md  -

Thanks. I removed the link from the readme.


Fix the variable name in Example 2

There is no sp1 in the example. It should be sp7 instead.

@ScottHutchinson
Thanks for taking the time to propose a change for the docs. Looking closely at it, I don't see the need for this change. There's no sp2 defined in the second example either, if you're only considering the local context. The article explains how the snippets go together. The snippet in Example 1 declares and defines both sp1 and sp2, which then get used in Example 2.  There's nothing wrong with your updated code, but it seems to be fixing a problem that isn't really a problem. In the interest of not fixing what isn't broken, I'm closing the PR. However, please don't let this discourage you from proposing other fixes, or if you think I'm wrong, for arguing your case here.


[StatusBar:001] More descriptive status message

We should use a FormatString to allow us to show the number of processes we are downloading or similar information. An example message would be "Downloading {0} Media Files" or similar.

Fixed in experimental build v.<IP_ADDRESS>x


Refactoring of MVAU and VVAU

This PR refactors the MVAU/VVAU HLS custom-op in a HW custom-op, HLS custom-op and RTL custom-op.
Depends on
2. Support for packed MV(A)Us: PR #794.
3. Support for multi-packed DSP58s for VVUs: PR #907
WIP

In general, this PR contains a lot of commits that are not relevant for the refactoring of the MVAU in HW abstraction layer and HLS variant. This might cause confusion and merge conflicts if you want to introduce these commits again at a later point in time.

Due to many changes introduced to undo the starting point of the branch, a new branch/PR has been created to maintain a clean history. Please see: https://github.com/Xilinx/finn/pull/971