[DataFactory] RepoConfiguration validation failure

Bug Report

import path of package in question - .../services/datafactory/mgmt/2018-06-01/datafactory
SDK version - 18.0.0
output of go version - go1.10.2 windows/amd64

Trying to create a data factory with a repo configuration produces the following error
accountName := "xxx"
collaborationBranch := "master"
projectName := "dftest"
repositoryName := "dftest"
rootFolder := "/"
tenantID := "xxx"
location := "northeurope"

dataFactory := datafactory.Factory{
	Location: &location,
	FactoryProperties: &datafactory.FactoryProperties{
		RepoConfiguration: datafactory.FactoryVSTSConfiguration{
			AccountName:         &accountName,
			CollaborationBranch: &collaborationBranch,
			ProjectName:         &projectName,
			RepositoryName:      &repositoryName,
			RootFolder:          &rootFolder,
			TenantID:            &tenantID,
		},
	},
}

_, err := client.CreateOrUpdate(ctx, resourceGroup, name, dataFactory, "")
if err != nil {
	return err
}

azurerm_data_factory.data_factory: datafactory.FactoriesClient#CreateOrUpdate: Invalid input: autorest/validation: validation failed: parameter=factory.FactoryProperties.RepoConfiguration constraint=Null value=datafactory.FactoryVSTSConfiguration{ProjectName:(*string)(0xc042078750), TenantID:(*string)(0xc042078780), AccountName:(*string)(0xc042078720), RepositoryName:(*string)(0xc042078760), CollaborationBranch:(*string)(0xc042078730), RootFolder:(*string)(0xc042078770), LastCommitID:(*string)(nil), Type:""} details: field "factory.FactoryProperties.RepoConfiguration" doesn't exist

If I remove the factory.FactoryProperties.RepoConfiguration validation from CreateOrUpdate then the factory is created succesfully

@hbuckle, thanks for filing this. You definitely found a rough edge we should grind down.
By updating your RepoConfiguration to be a pointer as so:
RepoConfiguration: &datafactory.FactoryVSTSConfiguration{

What's tripping things up is that the methods AsFactoryVSTSConfiguration, AsFactoryGitHubConfiguration, and AsFactoryRepoConfiguration  found here, are dangled off of FactoryVSTSConfiguration instead of type *FactoryVSTSConfiguration. This means that our validation checks to see if something non-nil-able is nil, causing this failure.
I'm going to open a generic issue that mentions this problem, and credit you for finding it. But I'll close this issue out since we have a simple work-around.


Enable lock nodes feature

Description
Enable to lock nodes. Each node will have a lock feature at the top right except Start and Finish. It's hidden and if you hover it, it'll show a black circle background. Once clicked, a lock icon is shown. Each locked nodes can't be move or be deleted.
Test

Click on the lock feature.
Try lock nodes, save and close xpipes. Open the xpipes back will still have the locked nodes.
There a lock toolbar button that will lock all non-general nodes connected from Start.

Note: This lock feature doesn't applied to Start and Finish node.

Thanks for catching that error. I didn't refactor it correctly. The way I did it will create & register new command signals every time the xpipes is created. I fix it by changing to its previous state. Thanks again @MFA-X-AI.


Error hidden when source is not available

Reporting a bug

[x] I have tried using the latest released version of Numba (most recent is
visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
[x] I have included below a minimal working reproducer (if you are unsure how
to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Example:
import numpy as np

from numba import njit, typed, typeof
from numba.core import types
from numba.experimental import structref

@structref.register
class ParticleType(types.StructRef):
    pass

class Particle(structref.StructRefProxy):
    def __new__(cls, pos, mass):
        return structref.StructRefProxy.__new__(cls, pos) # <- didn't provide the required mass argument

structref.define_proxy(Particle, ParticleType, ["pos", "mass"])

Particle(pos=1, mass=2)

Because StructRefis building the source code dynamically, the inspect.getsourcelines will fail in https://github.com/numba/numba/blob/a7c121a6631ba576561bcc6e72a4bfe97151fb4d/numba/core/typing/templates.py#L752
It will be nice to fix this to make StructRef error be meaningful

This is what needs fixing:
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Internal error at <numba.core.typeinfer.CallConstraint object at 0x7f9caff486d0>.
could not get source code


The weights on JBox seem to be inaccessible to anyone except university campus

I tried this downloader but it does not work: https://github.com/hebingchang/pyjbox

Still uploading to release on Baidu Drive… (Our network connection is annoying for Google Drive and OneDrive.)

Ok, thank you very much! Baidu works for me, I can upload to Google or Mega after I have it.

That really helps! So kind of you!

Okay I've uploaded the checkpoints on Baidu Drive now! As for the dataset, it is too large to upload. Perhaps you could download from VGGFace2-HQ and modify the file structure according to the directory tree we provide.

Thanks! Uploaded to Google:
https://drive.google.com/drive/folders/19-04v2683KSc14o1ahPh6m4jJJt5X8rt?usp=sharing
and Mega:
https://mega.nz/folder/JUpmGYwa#jaHarRjyqKYQXSP8op3zcQ

A lot of thanks!!!