File watcher fails over Samba share

The Explore sidebar doesn't always reflect the current state of the file system, e.g. I add a file from outside of vscode and it doesn't appear in Explore. I frequently have the same problem with Atom (which I also have running and which may be consuming all of the watches), but at least in Atom's tree view I can collapse, expand a folder via keyboard commands to get it to refresh. Is there a way to do it in vscode? If not, I pose it as a feature request. Thanks!

@jmm the explorer should always be in sync with the file system, otherwise this indicates a problem with our file watcher. On what OS are you on? And can you reproduce the issue repeatadly?

@bpasero In this case I saw it while accessing a Samba share running on Linux from vscode 0.10.1 running on Win 7 x64.

And can you reproduce the issue repeatadly?

Not sure yet -- I just tried vscode for the first time recently. And I was getting inexplicably high CPU usage (total usage much higher than the sum of the values in the CPU column in Task Manager) that I think was at least partially attributable to vscode, so I closed it for the time being. I've had nothing but problems with file watching in Atom, so I suspect I'll see this issue again in vscode.
In any case, although it would obviously be good for it to always be in sync, there's a refresh button that I can activate with the mouse to work around when it happens, but I'd like something keyboard activated as well.

@bpasero Ok, I still had higher CPU usage than I should've after closing vscode, then Atom crashed and I still had high CPU usage. I traced some of it to the Program Compatibility Assistant Service via an svchost.exe instance. With Atom not running I started vscode again and I can repro immediately: open a folder on the Samba share, go to the shell and $ touch newfile and it doesn't show up in Explore. Collapse, expand the subtree doesn't make it appear either. I have to click the Refresh button.

Yeah, our watcher might not work reliably for network shares.

Definitely can reproduce this.  Moving folder to non-network share seems to solve any problems.

Folder with source code placed on VM (CentOS) and shared via samba. That remote folder connected to windows as network drive.
New file showed in VSCode's explorer immediately, after created in remote console, on first level (folders root). If it's created on 2nd and deeper levels - just need refresh explorer.
Also problem with IntelliSense and .d.ts files
Example with Angular.
In code I can see error on "angular" word and choose download .d.ts file in pop-up menu. After downloading nothing changes with error. But, if I just open .d.ts file in VSCode - error disappear!
So another time starting VSCode I need to open each .d.ts file to remove errors.
Empty jsconfig.json created in folder, but no changes.
One more problem with downloading .d.ts files. First time I try to download any of them - I'v got error. Second time - some downloaded, some not. If I just visit "typings" folder from VSCode explorer - any file will be downloaded.
Remote - CentOS7, samba with maximum permissions.
Local - Windows Server 2012 (platform=3&osversion=6.3.9600)
VSCode - 0.10.6 (on local machine)

This issue was moved to Microsoft/vscode-filewatcher-windows#8

@bpasero Can you please restore the original title of this issue and reopen it? There are 2 separate logical issues:

Refreshing the explorer pane via keyboard command.

Keeping the explorer automatically in sync with the file system.

Item # 1 is the subject and original title of this GitHub issue, but it was taken over by the other issue. That the explorer should always stay in sync with the file system is a separate issue for the following reasons:

It doesn't.
There's no telling if / when it will. (And there doesn't appear to be any activity on it since March 24 except for adding it to the Backlog milestone.)
There's already a command / control to refresh the explorer for whatever reason (we've already discussed a great one ;) -- problems with syncing). This GitHub issue is about activating it via keyboard instead of pointing device.

Thanks!

@jmm try workbench.files.action.refreshFilesExplorer from our insiders build (http://code.visualstudio.com/Download#insiders)


Fix metrics on k8s

Fixes k8s.jsonnet to have metrics rules for all services.
As a hack to work around the fact ingress doesn't rewrite the path,
we make restreamer and thrimshim allow /metrics/ANYTHING in addition to /metrics endpoints.

I guess kubectl doesn't do verification on ingress.backend.serviceName =/

ship it


scattering pass issue

after modifed the scattering pipeline, atmosphere show up in two side

view sphere intersection need to be modified


Support class constants properties

As defined at phpstan here: https://phpstan.org/writing-php-code/phpdoc-types#literals-and-constants
class DtoValues {
    public const FOO = 1;
    public const FOO_BAR = 2;
    public const BAR = 'FooBar!';
}

class FooBar
{
    /**
     * @var DtoValues::FOO*
     */
    public $id;

    /**
     * @var DtoValues::BAR|null
     */
    public $title;
}

Actual use-case
Optional properties in payload.
class DtoValues {
    public const None = 'SomeNoneValueString';
}

class WithOptionalDto
{
    /**
     * @var DtoValues::None|null|int
     */
    public $priority = DtoValues::None;
}

// Payload does not need to contain `priority`, it has a default value (None).
$object = buildDto(WithOptionalDto::class, $source);

if ($object->priority !== DtoValues::None) {
    // Payload actually contains some value, lets use it.
}

Today, the error message is:

CuyZ\Valinor\Definition\Exception\InvalidPropertyDefaultValue: Default value of property WithOptionalDto::$priority is not accepted by DtoValues

(Screenshot taken in ReflectionPropertyDefinitionBuilder)

Notice it simply ignores the rest of the types, and is not even an UnionType as expected.
In PHP 8.1 is this a lot easier because we could use a global const which value is an object (const None = new None) and use None as a valid type. Though we are still on 7.4 and must rely on some weird strings - if we decide that this is the best approuch for optional properties.

I tried to implement a simple ConstantType, but seems to need a lot of changes, more than I am comfortable 'just doing'.
Example
const FOO = 'bar';
const FOO_BAR = 'bar2';

class  Bar {
    /**
     * @var FOO|FOO_BAR
     */
    public $type = FOO;
}

To implement ConstantType::matches(Type $other): bool do we need to know the value of the Type. ReflectionTypeResolver will resolve the default value of $type here as NativeStringType. We cannot match with that. Not sure how to solve this, maybe NativeStringType could accept a defaultValue?

Hi @eigan, I'd be glad to help you when you're ready to submit a PR.
Concerning your issue, I think you should take a look at StringValueType instead of NativeStringType, that should help you. Same if the constant value is an integer: you can use IntegerValueType.
Don't hesitate if you need more help!

@romm I did try StringValueType, but then the type is FixedType and casting is no longer supported.
Consider the case:
class Bar {
    /**
      * @var string
      */
    public $type = "fiz";
}

Type of Bar::$type is now StringValueType an cannot be cast to say "bar" if you send that in $source. Lots of tests failed because of this.
See wip here https://github.com/eigan/Valinor/pull/1/files

I see, this might not be as easy as it first seemed to be.
At first I thought the ConstantType should act as a decorator somehow, and should handle both scalar (string, int, float and bool) and array values.
But now I wonder if there should just not be any ConstantType at all, and the lexer should directly map to existing types.
class Foo
{
    public const SOME_CONST = 'foo';

    /** @var Foo::SOME_CONST */
    public string $foo;
}

—> the resolved type would be StringValueType('foo')
class Foo
{
    public const SOME_CONST = 42;

    /** @var Foo::SOME_CONST */
    public int $foo;
}

—> the resolved type would be IntegerValueType(42)
class Foo
{
    public const SOME_CONST = 1337.42;

    /** @var Foo::SOME_CONST */
    public float $foo;
}

—> FloatValueType does not exist (yet?) 😬
class Foo
{
    public const SOME_CONST = true;

    /** @var Foo::SOME_CONST */
    public bool $foo;
}

—> Well this one is coming in #117 😄
class Foo
{
    public const SOME_CONST = [
        'foo' => 'foo',
        'bar' => 'bar',
    ];

    /** @var Foo::SOME_CONST */
    public array $foo;
}

—> the resolved type would be ShapedArrayType with two elements describing the array (it should also work with nested arrays).
Probably a lot of work ahead 😬

class Bar {}

const SOME_CONST = new Bar;

class Foo
{

    /** @var SOME_CONST|string */
    public $foo;
}

What would the resolved type be in this case?

I am not a "lexer" guy (no experience here), but want to help. Writing tests or whatever :)
My initial thought after your last comment was to try return the correct token after resolving the value of the constant. Doesn't sound that difficult, but might say more about my experience than anything... :)
Please let me know when you think about starting with this, it's something we need so I am especially eager to help, or start by my self if you have other priorities :)


Websocket messages do not trigger change detection in Internet Explorer

First of all, this is duplicate of https://github.com/angular/angular/issues/10350 but I thought this location might be more appropriate. I think that a websocket message is not automatically ran in the Angular zone in internet explorer.
Run the plnkr below in chrome for example and clicking the button wil nicely increment the message. Running this in IE you will see that the update in the view lags 1 message behind (check with the message in the console). In our current applications we have to manually do a zone.run (see also the commented lines in the plnkr) to trigger change detection while in the other browsers this is not needed.
http://plnkr.co/edit/ANsjSo27QldcInUXRlV2?p=preview

Furthermore, if I run the web socket example from the repro in Internet Explorer 11 I get:
Secret payload not found where expected! Zones are not working! :-( <root>

When I add "WebSocket" to the "NO_EVENT_TARGET" array it DOES work, so:
var NO_EVENT_TARGET = 'ApplicationCache,EventSource,FileReader,InputMethodContext,MediaController,MessagePort,Node,Performance,SVGElementInstance,SharedWorker,TextTrack,TextTrackCue,TextTrackList,WebKitNamedFlow,Window,Worker,WorkerGlobalScope,XMLHttpRequest,XMLHttpRequestEventTarget,XMLHttpRequestUpload,IDBRequest,IDBOpenDBRequest,IDBDatabase,IDBTransaction,IDBCursor,DBIndex,WebSocket'.split(',');

@vicb Could this be the cause? For now I will patch it like this in our zone.js so we can continue without all the extra detectChanges calls or NgZone.run's ...


go get fails with "ld: symbol(s) not found for architecture x86_64" with go1.17.2 darwin/amd64

What version of Go are you using (go version)?

$ go version
go version go1.17.2 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/tschaub/Library/Caches/go-build"
GOENV="/Users/tschaub/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/tschaub/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/tschaub/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.17.2"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/tschaub/projects/godal-test/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/ct/jqy2463935j10d2t3_v21nf00000gn/T/go-build3476249808=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOROOT/bin/go version: go version go1.17.2 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.17.2
uname -v: Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:27 PDT 2021; root:xnu-7195.141.2~5/RELEASE_ARM64_T8101
ProductName:	macOS
ProductVersion:	11.5.1
BuildVersion:	20G80
lldb --version: lldb-13<IP_ADDRESS>
Swift version 5.5-dev

What did you do?
mkdir test && cd test
go mod init example.com/test
go get -x -v github.com/airbusgeo/godal

What did you expect to see?
Success.
What did you see instead?
ld: symbol(s) not found for architecture x86_64

I think it is unexpected to see -arch x86_64 is passed to clang.  See below for the full output.
go get -x -v github.com/airbusgeo/godal Output
# get https://proxy.golang.org/github.com/@v/list
# get https://proxy.golang.org/github.com/airbusgeo/@v/list
# get https://proxy.golang.org/github.com/airbusgeo/godal/@v/list
# get https://proxy.golang.org/github.com/airbusgeo/godal/@v/list: 200 OK (0.412s)
# get https://proxy.golang.org/github.com/@v/list: 410 Gone (0.415s)
# get https://proxy.golang.org/github.com/airbusgeo/@v/list: 410 Gone (0.418s)
WORK=/var/folders/ct/jqy2463935j10d2t3_v21nf00000gn/T/go-build3534027081
github.com/airbusgeo/godal
mkdir -p $WORK/b001/
cd<EMAIL_ADDRESS>pkg-config --cflags -- gdal
pkg-config --libs -- gdal
TERM='dumb' CGO_LDFLAGS='"-g" "-O2" "-ldl" "-L/opt/homebrew/Cellar/gdal/3.3.2_3/lib" "-lgdal"' /usr/local/go/pkg/tool/darwin_amd64/cgo -objdir $WORK/b001/ -importpath github.com/airbusgeo/godal -- -I/opt/homebrew/Cellar/gdal/3.3.2_3/include -I $WORK/b001/ -g -O2 ./godal.go
cd $WORK
clang -fno-caret-diagnostics -c -x c - -o /dev/null || true
clang -Qunused-arguments -c -x c - -o /dev/null || true
clang -fdebug-prefix-map=a=b -c -x c - -o /dev/null || true
clang -gno-record-gcc-switches -c -x c - -o /dev/null || true
cd $WORK/b001
TERM='dumb' clang -I<EMAIL_ADDRESS>-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -fno-common -I/opt/homebrew/Cellar/gdal/3.3.2_3/include -I ./ -g -O2 -o ./_x001.o -c _cgo_export.c
TERM='dumb' clang -I<EMAIL_ADDRESS>-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -fno-common -I/opt/homebrew/Cellar/gdal/3.3.2_3/include -I ./ -g -O2 -o ./_x002.o -c godal.cgo2.c
cd $WORK
clang++ -fno-caret-diagnostics -c -x c - -o /dev/null || true
clang++ -Qunused-arguments -c -x c - -o /dev/null || true
clang++ -fdebug-prefix-map=a=b -c -x c - -o /dev/null || true
clang++ -gno-record-gcc-switches -c -x c - -o /dev/null || true
cd<EMAIL_ADDRESS>TERM='dumb' clang++ -I . -fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -fno-common -I/opt/homebrew/Cellar/gdal/3.3.2_3/include -I $WORK/b001/ -g -O2 -std=c++11 -o $WORK/b001/_x003.o -c godal.cpp
cd $WORK/b001
TERM='dumb' clang -I<EMAIL_ADDRESS>-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -fno-common -I/opt/homebrew/Cellar/gdal/3.3.2_3/include -I ./ -g -O2 -o ./_cgo_main.o -c _cgo_main.c
cd /Users/tschaub/projects/test
TERM='dumb' clang++ -I<EMAIL_ADDRESS>-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -fno-common -o $WORK/b001/_cgo_.o $WORK/b001/_cgo_main.o $WORK/b001/_x001.o $WORK/b001/_x002.o $WORK/b001/_x003.o -g -O2 -ldl -L/opt/homebrew/Cellar/gdal/3.3.2_3/lib -lgdal
# github.com/airbusgeo/godal
ld: warning: ignoring file /opt/homebrew/Cellar/gdal/3.3.2_3/lib/libgdal.dylib, building for macOS-x86_64 but attempting to link with file built for macOS-arm64
Undefined symbols for architecture x86_64:
  "_CPLDebug", referenced from:
      _test_godal_error_handling in _x003.o
  "_CPLError", referenced from:
      _godalSetMetadataItem in _x003.o
      _godalSetRasterColorInterpretation in _x003.o
      _godalOpen in _x003.o
      _godalCreate in _x003.o
      _godalDatasetSetSpatialRef in _x003.o
      _godalSetProjection in _x003.o
      _godalExportToWKT in _x003.o
      ...
  "_CPLGetErrorHandlerUserData", referenced from:
      _godalSetMetadataItem in _x003.o
      _godalSetRasterColorInterpretation in _x003.o
      _godalOpen in _x003.o
      _godalClose in _x003.o
      _godalCreate in _x003.o
      _godalDatasetSetSpatialRef in _x003.o
      _godalSetProjection in _x003.o
      ...
  "_CPLPopErrorHandler", referenced from:
      _godalSetMetadataItem in _x003.o
      _godalSetRasterColorInterpretation in _x003.o
      _godalOpen in _x003.o
      _godalClose in _x003.o
      _godalCreate in _x003.o
      _godalDatasetSetSpatialRef in _x003.o
      _godalSetProjection in _x003.o
      ...
  "_CPLPushErrorHandlerEx", referenced from:
      _godalSetMetadataItem in _x003.o
      _godalSetRasterColorInterpretation in _x003.o
      _godalOpen in _x003.o
      _godalClose in _x003.o
      _godalCreate in _x003.o
      _godalDatasetSetSpatialRef in _x003.o
      _godalSetProjection in _x003.o
      ...
  "_CPLSetThreadLocalConfigOption", referenced from:
      _godalSetMetadataItem in _x003.o
      _godalSetRasterColorInterpretation in _x003.o
      _godalOpen in _x003.o
      _godalClose in _x003.o
      _godalCreate in _x003.o
      _godalDatasetSetSpatialRef in _x003.o
      _godalSetProjection in _x003.o
      ...
  "_GDALAllRegister", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALAllRegister in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALAllRegister)
  "_GDALBuildOverviews", referenced from:
      _godalClearOverviews in _x003.o
      _godalBuildOverviews in _x003.o
  "_GDALBuildVRT", referenced from:
      _godalBuildVRT in _x003.o
  "_GDALBuildVRTOptionsFree", referenced from:
      _godalBuildVRT in _x003.o
  "_GDALBuildVRTOptionsNew", referenced from:
      _godalBuildVRT in _x003.o
  "_GDALClose", referenced from:
      _godalClose in _x003.o
  "_GDALCreate", referenced from:
      _godalCreate in _x003.o
  "_GDALCreateColorTable", referenced from:
      _godalSetColorTable in _x003.o
  "_GDALCreateDatasetMaskBand", referenced from:
      _godalCreateDatasetMaskBand in _x003.o
  "_GDALCreateMaskBand", referenced from:
      _godalCreateMaskBand in _x003.o
  "_GDALDatasetGetLayer", referenced from:
      _godalVectorLayers in _x003.o
  "_GDALDatasetGetLayerCount", referenced from:
      _godalVectorLayers in _x003.o
  "_GDALDatasetRasterIOEx", referenced from:
      _godalDatasetRasterIO in _x003.o
  "_GDALDeleteRasterNoDataValue", referenced from:
      _godalDeleteRasterNoDataValue in _x003.o
  "_GDALDestroyColorTable", referenced from:
      _godalSetColorTable in _x003.o
  "_GDALFillNodata", referenced from:
      _godalFillNoData in _x003.o
  "_GDALFillRaster", referenced from:
      _godalFillRaster in _x003.o
  "_GDALGetBlockSize", referenced from:
      _godalDatasetStructure in _x003.o
      _godalBandStructure in _x003.o
  "_GDALGetColorEntry", referenced from:
      _godalGetColorTable in _x003.o
  "_GDALGetColorEntryCount", referenced from:
      _godalGetColorTable in _x003.o
  "_GDALGetColorInterpretationName", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALGetColorInterpretationName in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALGetColorInterpretationName)
  "_GDALGetDataTypeName", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALGetDataTypeName in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALGetDataTypeName)
  "_GDALGetDefaultHistogramEx", referenced from:
      _godalRasterHistogram in _x003.o
  "_GDALGetDriverByName", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALGetDriverByName in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALGetDriverByName)
  "_GDALGetGeoTransform", referenced from:
      _godalGetGeoTransform in _x003.o
  "_GDALGetMaskBand", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALGetMaskBand in _x002.o
      _godalCreateMaskBand in _x003.o
      _godalCreateDatasetMaskBand in _x003.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALGetMaskBand)
  "_GDALGetMaskFlags", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALGetMaskFlags in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALGetMaskFlags)
  "_GDALGetMetadata", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALGetMetadata in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALGetMetadataItem, __cgo_29ab00cbff11_Cfunc_GDALGetMetadata , __cgo_29ab00cbff11_Cfunc_GDALGetMetadataDomainList )
  "_GDALGetMetadataDomainList", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALGetMetadataDomainList in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALGetMetadataDomainList)
  "_GDALGetMetadataItem", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALGetMetadataItem in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALGetMetadataItem)
  "_GDALGetOverview", referenced from:
      _godalBandOverviews in _x003.o
  "_GDALGetOverviewCount", referenced from:
      _godalBandOverviews in _x003.o
  "_GDALGetPaletteInterpretation", referenced from:
      _godalGetColorTable in _x003.o
  "_GDALGetProjectionRef", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALGetProjectionRef in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALGetProjectionRef)
  "_GDALGetRasterBand", referenced from:
      _godalRasterBands in _x003.o
      _godalSetDatasetNoDataValue in _x003.o
      _godalCreateDatasetMaskBand in _x003.o
      _godalDatasetStructure in _x003.o
  "_GDALGetRasterBandXSize", referenced from:
      _godalBandStructure in _x003.o
  "_GDALGetRasterBandYSize", referenced from:
      _godalBandStructure in _x003.o
  "_GDALGetRasterColorInterpretation", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALGetRasterColorInterpretation in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALGetRasterColorInterpretation)
  "_GDALGetRasterColorTable", referenced from:
      _godalGetColorTable in _x003.o
  "_GDALGetRasterCount", referenced from:
      _godalRasterBands in _x003.o
      _godalSetDatasetNoDataValue in _x003.o
      _godalCreateDatasetMaskBand in _x003.o
      _godalDatasetStructure in _x003.o
  "_GDALGetRasterDataType", referenced from:
      _godalDatasetStructure in _x003.o
      _godalBandStructure in _x003.o
  "_GDALGetRasterHistogramEx", referenced from:
      _godalRasterHistogram in _x003.o
  "_GDALGetRasterNoDataValue", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALGetRasterNoDataValue in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALGetRasterNoDataValue)
  "_GDALGetRasterXSize", referenced from:
      _godalRasterSize in _x003.o
      _godalDatasetStructure in _x003.o
  "_GDALGetRasterYSize", referenced from:
      _godalRasterSize in _x003.o
      _godalDatasetStructure in _x003.o
  "_GDALGetSpatialRef", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALGetSpatialRef in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALGetSpatialRef)
  "_GDALOpenEx", referenced from:
      _godalOpen in _x003.o
  "_GDALPolygonize", referenced from:
      _godalPolygonize in _x003.o
  "_GDALRasterIOEx", referenced from:
      _godalBandRasterIO in _x003.o
  "_GDALRasterize", referenced from:
      _godalRasterize in _x003.o
  "_GDALRasterizeGeometries", referenced from:
      _godalRasterizeGeometry in _x003.o
  "_GDALRasterizeOptionsFree", referenced from:
      _godalRasterize in _x003.o
  "_GDALRasterizeOptionsNew", referenced from:
      _godalRasterize in _x003.o
  "_GDALRegister_GTiff", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALRegister_GTiff in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALRegister_GTiff)
  "_GDALRegister_HFA", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALRegister_HFA in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALRegister_HFA)
  "_GDALRegister_MEM", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALRegister_MEM in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALRegister_MEM)
  "_GDALRegister_VRT", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALRegister_VRT in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALRegister_VRT)
  "_GDALSetColorEntry", referenced from:
      _godalSetColorTable in _x003.o
  "_GDALSetGeoTransform", referenced from:
      _godalSetGeoTransform in _x003.o
  "_GDALSetMetadataItem", referenced from:
      _godalSetMetadataItem in _x003.o
  "_GDALSetProjection", referenced from:
      _godalSetProjection in _x003.o
  "_GDALSetRasterColorInterpretation", referenced from:
      _godalSetRasterColorInterpretation in _x003.o
  "_GDALSetRasterColorTable", referenced from:
      _godalSetColorTable in _x003.o
  "_GDALSetRasterNoDataValue", referenced from:
      _godalSetDatasetNoDataValue in _x003.o
      _godalSetRasterNoDataValue in _x003.o
  "_GDALSetSpatialRef", referenced from:
      _godalDatasetSetSpatialRef in _x003.o
  "_GDALSieveFilter", referenced from:
      _godalSieveFilter in _x003.o
  "_GDALTranslate", referenced from:
      _godalTranslate in _x003.o
  "_GDALTranslateOptionsFree", referenced from:
      _godalTranslate in _x003.o
  "_GDALTranslateOptionsNew", referenced from:
      _godalTranslate in _x003.o
  "_GDALVectorTranslate", referenced from:
      _godalDatasetVectorTranslate in _x003.o
  "_GDALVectorTranslateOptionsFree", referenced from:
      _godalDatasetVectorTranslate in _x003.o
  "_GDALVectorTranslateOptionsNew", referenced from:
      _godalDatasetVectorTranslate in _x003.o
  "_GDALVersionInfo", referenced from:
      __cgo_29ab00cbff11_Cfunc_GDALVersionInfo in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_GDALVersionInfo)
  "_GDALWarp", referenced from:
      _godalDatasetWarp in _x003.o
      _godalDatasetWarpInto in _x003.o
  "_GDALWarpAppOptionsFree", referenced from:
      _godalDatasetWarp in _x003.o
      _godalDatasetWarpInto in _x003.o
  "_GDALWarpAppOptionsNew", referenced from:
      _godalDatasetWarp in _x003.o
      _godalDatasetWarpInto in _x003.o
  "_OCTDestroyCoordinateTransformation", referenced from:
      __cgo_29ab00cbff11_Cfunc_OCTDestroyCoordinateTransformation in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OCTDestroyCoordinateTransformation)
  "_OCTNewCoordinateTransformation", referenced from:
      _godalNewCoordinateTransformation in _x003.o
  "_OCTTransformEx", referenced from:
      __cgo_29ab00cbff11_Cfunc_OCTTransformEx in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OCTTransformEx)
  "_OGR_DS_CreateLayer", referenced from:
      _godalCreateLayer in _x003.o
  "_OGR_FD_GetFieldCount", referenced from:
      _godalPolygonize in _x003.o
  "_OGR_F_Create", referenced from:
      _godalLayerNewFeature in _x003.o
  "_OGR_F_Destroy", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_F_Destroy in _x002.o
      _godalLayerNewFeature in _x003.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_F_Destroy)
  "_OGR_F_GetFID", referenced from:
      _godalLayerDeleteFeature in _x003.o
  "_OGR_F_GetFieldAsDouble", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_F_GetFieldAsDouble in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_F_GetFieldAsDouble)
  "_OGR_F_GetFieldAsInteger64", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_F_GetFieldAsInteger64 in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_F_GetFieldAsInteger64)
  "_OGR_F_GetFieldAsString", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_F_GetFieldAsString in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_F_GetFieldAsString)
  "_OGR_F_GetFieldCount", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_F_GetFieldCount in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_F_GetFieldCount)
  "_OGR_F_GetFieldDefnRef", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_F_GetFieldDefnRef in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_F_GetFieldDefnRef)
  "_OGR_F_GetGeometryRef", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_F_GetGeometryRef in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_F_GetGeometryRef)
  "_OGR_F_SetGeometry", referenced from:
      _godalFeatureSetGeometry in _x003.o
      _godalLayerNewFeature in _x003.o
  "_OGR_Fld_Create", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_Fld_Create in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_Fld_Create)
  "_OGR_Fld_Destroy", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_Fld_Destroy in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_Fld_Destroy)
  "_OGR_Fld_GetNameRef", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_Fld_GetNameRef in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_Fld_GetNameRef)
  "_OGR_Fld_GetType", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_Fld_GetType in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_Fld_GetType)
  "_OGR_G_AssignSpatialReference", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_G_AssignSpatialReference in _x002.o
      _godalGeometryTransformTo in _x003.o
      _godalGeometryTransform in _x003.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_G_AssignSpatialReference)
  "_OGR_G_Buffer", referenced from:
      _godal_OGR_G_Buffer in _x003.o
     (maybe you meant: _godal_OGR_G_Buffer, __cgo_29ab00cbff11_Cfunc_godal_OGR_G_Buffer )
  "_OGR_G_CreateFromWkb", referenced from:
      _godalNewGeometryFromWKB in _x003.o
  "_OGR_G_CreateFromWkt", referenced from:
      _godalNewGeometryFromWKT in _x003.o
  "_OGR_G_DestroyGeometry", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_G_DestroyGeometry in _x002.o
      _godalNewGeometryFromWKT in _x003.o
      _godalNewGeometryFromWKB in _x003.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_G_DestroyGeometry)
  "_OGR_G_ExportToIsoWkb", referenced from:
      _godalExportGeometryWKB in _x003.o
  "_OGR_G_ExportToJsonEx", referenced from:
      _godalExportGeometryGeoJSON in _x003.o
  "_OGR_G_ExportToWkt", referenced from:
      _godalExportGeometryWKT in _x003.o
  "_OGR_G_GetEnvelope", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_G_GetEnvelope in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_G_GetEnvelope)
  "_OGR_G_GetSpatialReference", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_G_GetSpatialReference in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_G_GetSpatialReference)
  "_OGR_G_IsEmpty", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_G_IsEmpty in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_G_IsEmpty)
  "_OGR_G_Simplify", referenced from:
      _godal_OGR_G_Simplify in _x003.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_godal_OGR_G_Simplify, _godal_OGR_G_Simplify )
  "_OGR_G_Transform", referenced from:
      _godalGeometryTransform in _x003.o
  "_OGR_G_TransformTo", referenced from:
      _godalGeometryTransformTo in _x003.o
  "_OGR_G_WkbSize", referenced from:
      _godalExportGeometryWKB in _x003.o
  "_OGR_L_CreateField", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_L_CreateField in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_L_CreateField)
  "_OGR_L_DeleteFeature", referenced from:
      _godalLayerDeleteFeature in _x003.o
  "_OGR_L_GetFeatureCount", referenced from:
      _godalLayerFeatureCount in _x003.o
  "_OGR_L_GetLayerDefn", referenced from:
      _godalPolygonize in _x003.o
      _godalLayerNewFeature in _x003.o
  "_OGR_L_GetNextFeature", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_L_GetNextFeature in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_L_GetNextFeature)
  "_OGR_L_GetSpatialRef", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_L_GetSpatialRef in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_L_GetSpatialRef)
  "_OGR_L_ResetReading", referenced from:
      __cgo_29ab00cbff11_Cfunc_OGR_L_ResetReading in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OGR_L_ResetReading)
  "_OGR_L_SetFeature", referenced from:
      _godalLayerSetFeature in _x003.o
      _godalLayerNewFeature in _x003.o
  "_OSRAutoIdentifyEPSG", referenced from:
      __cgo_29ab00cbff11_Cfunc_OSRAutoIdentifyEPSG in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OSRAutoIdentifyEPSG)
  "_OSRDestroySpatialReference", referenced from:
      _godalCreateWKTSpatialRef in _x003.o
      _godalCreateProj4SpatialRef in _x003.o
      _godalCreateEPSGSpatialRef in _x003.o
  "_OSRExportToWkt", referenced from:
      _godalExportToWKT in _x003.o
  "_OSRGetAuthorityCode", referenced from:
      __cgo_29ab00cbff11_Cfunc_OSRGetAuthorityCode in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OSRGetAuthorityCode)
  "_OSRGetAuthorityName", referenced from:
      __cgo_29ab00cbff11_Cfunc_OSRGetAuthorityName in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OSRGetAuthorityName)
  "_OSRGetSemiMajor", referenced from:
      __cgo_29ab00cbff11_Cfunc_OSRGetSemiMajor in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OSRGetSemiMajor)
  "_OSRGetSemiMinor", referenced from:
      __cgo_29ab00cbff11_Cfunc_OSRGetSemiMinor in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OSRGetSemiMinor)
  "_OSRImportFromEPSG", referenced from:
      _godalCreateEPSGSpatialRef in _x003.o
  "_OSRImportFromProj4", referenced from:
      _godalCreateProj4SpatialRef in _x003.o
  "_OSRImportFromWkt", referenced from:
      _godalCreateWKTSpatialRef in _x003.o
  "_OSRIsGeographic", referenced from:
      __cgo_29ab00cbff11_Cfunc_OSRIsGeographic in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OSRIsGeographic)
  "_OSRIsSame", referenced from:
      __cgo_29ab00cbff11_Cfunc_OSRIsSame in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OSRIsSame)
  "_OSRNewSpatialReference", referenced from:
      _godalCreateWKTSpatialRef in _x003.o
      _godalCreateProj4SpatialRef in _x003.o
      _godalCreateEPSGSpatialRef in _x003.o
  "_OSRRelease", referenced from:
      __cgo_29ab00cbff11_Cfunc_OSRRelease in _x002.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_OSRRelease)
  "_OSRSetAxisMappingStrategy", referenced from:
      _godalCreateWKTSpatialRef in _x003.o
      _godalCreateProj4SpatialRef in _x003.o
      _godalCreateEPSGSpatialRef in _x003.o
  "_VSIError", referenced from:
      cpl::VSIGoFilesystemHandler::Open(char const*, char const*, bool, char const* const*) in _x003.o
  "_VSIFCloseL", referenced from:
      _godalVSIOpen in _x003.o
      _godalVSIClose in _x003.o
  "_VSIFOpenExL", referenced from:
      _godalVSIOpen in _x003.o
  "_VSIFReadL", referenced from:
      _godalVSIRead in _x003.o
  "_VSIFree", referenced from:
      __cgo_29ab00cbff11_Cfunc_CPLFree in _x002.o
      __cgo_29ab00cbff11_Cfunc_VSIFree in _x002.o
      _godalExportGeometryWKT in _x003.o
      _godalExportGeometryGeoJSON in _x003.o
     (maybe you meant: __cgo_29ab00cbff11_Cfunc_VSIFree)
  "_VSIMalloc", referenced from:
      _godalRasterHistogram in _x003.o
  "_VSIUnlink", referenced from:
      _godalVSIUnlink in _x003.o
  "VSICreateCachedFile(VSIVirtualHandle*, unsigned long, unsigned long)", referenced from:
      cpl::VSIGoFilesystemHandler::Open(char const*, char const*, bool, char const* const*) in _x003.o
  "VSIFileManager::GetPrefixes()", referenced from:
      _VSIInstallGoHandler in _x003.o
  "VSIFileManager::InstallHandler(std::__1::basic_string, std::__1::allocator > const&, VSIFilesystemHandler*)", referenced from:
      _VSIInstallGoHandler in _x003.o
  "VSIFilesystemHandler::UnlinkBatch(char const* const*)", referenced from:
      vtable for cpl::VSIGoFilesystemHandler in _x003.o
  "VSIFilesystemHandler::RmdirRecursive(char const*)", referenced from:
      vtable for cpl::VSIGoFilesystemHandler in _x003.o
  "VSIFilesystemHandler::GetFileMetadata(char const*, char const*, char const* const*)", referenced from:
      vtable for cpl::VSIGoFilesystemHandler in _x003.o
  "VSIFilesystemHandler::SetFileMetadata(char const*, char const* const*, char const*, char const* const*)", referenced from:
      vtable for cpl::VSIGoFilesystemHandler in _x003.o
  "VSIFilesystemHandler::Sync(char const*, char const*, char const* const*, int (*)(double, char const*, void*), void*, char***)", referenced from:
      vtable for cpl::VSIGoFilesystemHandler in _x003.o
  "VSIFilesystemHandler::OpenDir(char const*, int, char const* const*)", referenced from:
      vtable for cpl::VSIGoFilesystemHandler in _x003.o
  "typeinfo for VSIVirtualHandle", referenced from:
      typeinfo for cpl::VSIGoHandle in _x003.o
  "typeinfo for VSIFilesystemHandler", referenced from:
      typeinfo for cpl::VSIGoFilesystemHandler in _x003.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I know this is complicated by the dependency on GDAL.  As seen above, I have a brew based installation of GDAL that is working properly.
gdalinfo --version
GDAL 3.3.2, released 2021/09/01

I also understand that this could be an issue that needs to be solved in the godal project.
Please let me know if I can help narrow this down.  I saw #43692, which made me think it might be an issue with go itself.

Thanks for the reply, @seankhliao.  I installed https://golang.org/dl/go1.17.2.darwin-amd64.pkg from https://golang.org/dl/.  Is this different than "the arm64 version"?

Ack!  I see https://golang.org/dl/go1.17.2.darwin-arm64.pkg.  Subtle (or perhaps obvious).


Deployment 2018-03-14

Deployment 2018-03-14
Status: Planned
Planned production date:  2018-03-14
Focus:
Hotfixes:
Services to Deploy:

[ ] Gallery
[ ] feed2catalog (ng)
[ ] catalog2dnx (ng)
[ ] catalog2registration (ng)
[ ] catalog2lucene (ng)
[ ] endpointmonitoring (ng)
[ ] Gallery.CredentialsExpiration
[ ] Jobs - Validation - Orchestrator
[ ] Search Service (KV cert configuration)

Repo
Service
INT
PROD (primary)
PROD (secondary)

NuGet.Gallery
Gallery
[x]
[ ]
 [ ]

NuGet.Services.Metadata
Search Service
[ ]
[ ]
 [ ]

NuGet.Services.Metadata
feed2catalog
[x]
[x]
 [ ]

NuGet.Services.Metadata
catalog2dnx
[x]
[x]
 [ ]

NuGet.Services.Metadata
catalog2registration
[x]
[x]
 [ ]

NuGet.Services.Metadata
catalog2lucene
[x]
[x]
 [ ]

NuGet.Services.Metadata
endpointmonitoring
[x]
[x]
 [ ]

NuGet.Jobs
Gallery.CredentialsExpiration
[x]
[ ]
 [ ]

NuGet.Jobs
NuGet.Services.Validation.Orchestrator
[x]
[ ]
 [ ]

Related blog posts/docs:

N/A

Deployed commit:  TBA
Gallery
Functional

[MSA] Signin assistance page; Register removal; Deprecation Config #5586

V3 Jobs
Technical:

Telemetry around catalog reads and writes
Orchestrator changed a way it reads SMTP settings to be consistent with other jobs.

Need to redeploy Gallery.CredentialsExpiration job to PROD: email settings were changed (the address used in the "From" field), no code changes.

Gallery changes:

[MSA] Deprecate password logins(Phase 1) and other fixes (#5628)
Simplify login page for local debugging (#5613)
Add 2FA schema https://github.com/NuGet/NuGetGallery/pull/5652

Don't forget to run the Database migration before deployments.


Fixed link

Link previously pointed to personal n-yelland.github.io/maths-things URL, which then in turn redirects back to the nicyelland.com domain. I've cut out the middle man by changing the link so it goes straight to the nicyelland.com domain.

Fixed in commit 5375edd2fdef231a1f5300f6f0b26cfd38fd8726


i can not find~/Drive/sync/gtd files?

That file is my agenda/notes file, the path is created by pcloud. It's a org mode file. I don't upload here because the privacy of that file, but you can create any *.org file and change the path there


Large memory usage, does not load scanned albums

I'm submitting a...

Bug report (I searched for similar issues and did not find one)

Current behavior
App uses close to 1.7GB of ram memory after scan.
List of albums cannot be loaded, even after completely scanning my music folders.
Expected behavior

Minimal reproduction of the problem with instructions

Scan Large Music Library ~= 10.000 songs
Click 'albums'

Environment

App Version(s):

Windows 10 Build Number:
- [ ] Fall Creators Update (16299)
- [x] Spring Creators Update (17133.73)
- [ ] Insider Build (build number: )

Device form factor:
- [x] Desktop
- [ ] Mobile
- [ ] Xbox
- [ ] Surface Hub
- [ ] IoT

Hi,
Since there are a lot of files, I uploaded them to Onedrive, and I created 2 versions of the zipped folder.
The first one, is the full data folder including the  'Artworks' folder. That has about 2GB of files.
The second one, is the data folder, but without the 'Artworks' folder.
Thanks.

@pkzxs If you need the actual music files as well, please email me, I have them on Onedrive, but to avoid possible copyright issues, I am only able to share them via email.

Hi Pedro Garcia, I've done a bit for performance optimization, please check if this issues is been fixed. If Not, please comment below. We've appreciated for your help.

all versions greater than 1.0.59


Fix some typos

Fixed some typos while going over the intro notebooks.
Awesome project @hadim :+1: :smiley:

Thanks for this !


Blog website using html , css , js

This is a static blog website made using html , css and js .
link

I want to contribute on this issue under swoc Kindly assign this to me

@charu1603 Do finish the first one then create next issue , one issue at a time .

@Kushal997-das I have created the pr for the previous issue kindly review it .

@Kushal997-das  can you assign me this issue . My previous pr got merged☺

@Kushal997-das Can you please assign me good first issues...


Augmented submit fields should be included in sign-and-submit mode (Version: 1.5.0-b6)

Issue Description
The new fields added to the submit method response by #3125 are only provided when you submit a binary blob, not when you provide a JSON and secret.
The fields should be provided in all responses to the submit command.
Steps to Reproduce
For a quick offline test:

Start rippled in standalone mode with a fresh ledger.
 rippled -a --start

Sign-and-submit a payment from the genesis account to another address of your choice.
 rippled submit masterpassphrase '{"TransactionType":"Payment", "Account":"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh","Destination":"rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "Amount":"50000000000000000"}'

Expected Result
The new fields, such as applied, broadcast, account_sequence_available, etc. should be included in the response. Here's an example of a similar transaction submitted as binary, with the new fields provided:
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
2020-Mar-05 00:28:16.291423410 UTC HTTPClient:NFO Connecting to <IP_ADDRESS>:5005

{
   "result" : {
      "accepted" : true,
      "account_sequence_available" : 3,
      "account_sequence_next" : 3,
      "applied" : false,
      "broadcast" : true,
      "engine_result" : "tecUNFUNDED_PAYMENT",
      "engine_result_code" : 104,
      "engine_result_message" : "Insufficient XRP balance to send.",
      "kept" : true,
      "open_ledger_cost" : "10",
      "queued" : false,
      "status" : "success",
      "tx_blob" : "120000228000000024000000026140B1A2BC2EC5000068400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100856282EB45272689B3E51E9888089497DBCE3C01F28E11BD8403D5195878656502202A32A11DA97AAA2D27F1BEE36FD03017CD7F1645A6E4D863E83B8A570077F67C8114B5F762798A53D543A014CAF8B297CFF8F2F937E883144B4E9C06F24296074F7BC48F92A97916C6DC5EA9",
      "tx_json" : {
         "Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
         "Amount" : "50000000000000000",
         "Destination" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
         "Fee" : "10",
         "Flags" :<PHONE_NUMBER>,
         "Sequence" : 2,
         "SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
         "TransactionType" : "Payment",
         "TxnSignature" : "3045022100856282EB45272689B3E51E9888089497DBCE3C01F28E11BD8403D5195878656502202A32A11DA97AAA2D27F1BEE36FD03017CD7F1645A6E4D863E83B8A570077F67C",
         "hash" : "9712FE0C29D1FF0351BFC1E7874CB077F95C032B07C7DEE8D84B13211008C6CF"
      },
      "validated_ledger_index" : 2
   }
}

Actual Result
Actual result matches the old (v1.4.0 and lower) result fields for the submit method:
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
2020-Mar-05 00:28:07.292019643 UTC HTTPClient:NFO Connecting to <IP_ADDRESS>:5005

{
   "result" : {
      "deprecated" : "This command has been deprecated and will be removed in a future version of the server. Please migrate to a standalone signing tool.",
      "status" : "success",
      "tx_blob" : "120000228000000024000000026140B1A2BC2EC5000068400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100856282EB45272689B3E51E9888089497DBCE3C01F28E11BD8403D5195878656502202A32A11DA97AAA2D27F1BEE36FD03017CD7F1645A6E4D863E83B8A570077F67C8114B5F762798A53D543A014CAF8B297CFF8F2F937E883144B4E9C06F24296074F7BC48F92A97916C6DC5EA9",
      "tx_json" : {
         "Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
         "Amount" : "50000000000000000",
         "Destination" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
         "Fee" : "10",
         "Flags" :<PHONE_NUMBER>,
         "Sequence" : 2,
         "SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
         "TransactionType" : "Payment",
         "TxnSignature" : "3045022100856282EB45272689B3E51E9888089497DBCE3C01F28E11BD8403D5195878656502202A32A11DA97AAA2D27F1BEE36FD03017CD7F1645A6E4D863E83B8A570077F67C",
         "hash" : "9712FE0C29D1FF0351BFC1E7874CB077F95C032B07C7DEE8D84B13211008C6CF"
      }
   }
}

Environment
Version: rippled version 1.5.0-b6
OS: Arch Linux (latest) x86_64
Self-compiled, Boost 1.72.0. All unit tests pass.

I think we should consider deprecating sign-and-submit mode, and create an issue for building a separate signing tool. The separate signing tool can be implemented in C++ or in TypeScript.

Neither C++ nor TypeScript are easy to call from other languages (e.g. via CFFI) - until there's a solution that is as easy to use from any(!) language as JSON-RPC I'd like to keep this mode within rippled behind a switch.

I agree with @MarkusTeufelberger and I believe I can sum up the case in favor as follows:
To submit transactions to the XRP Ledger, you need the following bare minimum:

The ability to create a signed transaction in the XRP Ledger's canonical binary format. You need approximately total trust¹ in this software.
A connection to the XRP Ledger to submit the transaction to the network. You need a low level of trust² in this software.

Everything else is optional, but you absolutely need both of these things. Currently rippled is capable of doing both, and nothing other than rippled is capable of doing (2); anything that exists today that submits transactions is going to eventually use rippled to peer up with the network and relay your transaction. So as long as it's not too difficult (and it's currently not), it makes perfect sense for one program to provide both pieces of the bare minimum.
¹ If your signing software screws up, any number of things can go wrong: not being able to send a transaction at a crucial time (invalid signature or blob format) is the most likely outcome, accidentally opening yourself up to losing all your money (leaking your secret key), suffering reputational damage, accidentally discharging funds (correct signature of incorrect transaction instructions) etc.
² You can, to a large extent, rely on "public" rippled servers run by third parties to submit binary transaction blobs to the network for you. However, that relationship is not totally devoid of trust. A server operator could have their machine selectively filter out/censor or delay transactions in a way that's convenient to the operator: for example, preventing competing attempts at claiming liquidity in the decentralized exchange, blocking payments to particular destinations at key times, and so on. You can (theoretically) detect and avoid this sort of behavior if you submit your signed blobs to multiple servers; so, the amount you must trust a server is inversely proportional to the number of servers you rely on. At present, one of the most convenient ways to establish a connection to multiple servers in the network is to peer with them directly using your own server—that is, to run rippled yourself.

FWIW I find sign-and-submit mode very useful in standalone mode when writing new transaction types. If I want to sign with a library, I need to update the binary codec, which is annoying when I'm still testing things out and everything is in flux.

I'd like to reiterate the security concerns highlighted by Nik in commit 38c3a46a:
Deprecate commands that perform remote tx signing (RIPD-1649):

In order to facilitate transaction signing, `rippled` offers the `sign` and
`sign_for` and `submit` commands, which, given a seed, can be used to sign or
sign-and-submit transactions. These commands are accessible from the command
line, as well as over the WebSocket and RPC interfaces that `rippled` can be
configured to provide.

These commands, unfortunately, have significant security implications:

  1. They require divulging an account's seed (commonly known as a "secret
     key") to the server.
  2. When executing these commands against remote servers, the seeds can be
     transported over clear-text links.
  3. When executing these commands over the command line, the account
     seed may be visible using common tools that show running processes
     and may potentially be inadvertently stored by system monitoring
     tools or facilities designed to maintain a history of previously
     typed commands.

While this commit cannot prevent users from issuing these commands to a
server, whether locally or remotely, it restricts the `sign` and `sign_for`
commands, as well as the `submit` command when used to sign-and-submit,
so that they require administrative privileges on the server.

Server operators that want to allow unrestricted signing can do so by
adding the following stanza to their configuration file:

    [signing_support]
    true

Ripple discourages server operators from doing so and advises against using
these commands, which will be removed in a future release. If you rely on
these commands for signing, please migrate to a standalone signing solution
as soon as possible. One option is to use `ripple-lib`; documentation is
available at https://developers.ripple.com/rippleapi-reference.html#sign.

If the commands are administratively enabled, the server includes a warning
on startup and adds a new field in the resulting JSON, informing the caller
that the commands are deprecated and may become unavailable at any time.

Acknowledgements:
Jesper Wallin for reporting this issue to Ripple.

Bug Bounties and Responsible Disclosures:
We welcome reviews of the rippled code and urge researchers to responsibly
disclose any issues that they may find. For more on Ripple's Bug Bounty
program, please visit: https://ripple.com/bug-bounty

Instead of reading the secret in clear-text from command line, we could read it from a file. This reduces visibility to other users on a server, but it's still not foolproof.

Instead of reading the secret in clear-text from command line, we could read it from a file. This reduces visibility to other users on a server, but it's still not foolproof.

While we could do this, the command-line risks are a much smaller problem than transmitting a secret over the internet, potentially in plain-text, and potentially to an unknown / hostile server.

Instead of reading the secret in clear-text from command line, we could read it from a file. This reduces visibility to other users on a server, but it's still not foolproof.

While we could do this, the command-line risks are a much smaller problem than transmitting a secret over the internet, potentially in plain-text, and potentially to an unknown / hostile server.

Yes, that is true. This problem must have been solved in other contexts. For instance, we could mimic the ways of web browsers in handling and transferring secrets. That would still leave hostile servers as a possible attack vector. :/

Users should use public key cryptography the way it was intended to be used: the private key always remains private and should never be transmitted. Transaction signing can, and should, be performed locally. That said, sign-and-submit is still useful on trusted servers (i.e. you can use it on a server you solely control) and for testing on networks where the assets/tokens (and keys) have no value.

Could sign-and-submit be switched to an admin-only command? I think the level of trust is roughly equivalent.

In the sign-and-submit command, the user is trusting the server with his/her secret key material.
An admin method places restrictions on who can invoke the sign-and-submit method, but it doesn't change the inherent trust assumptions.
Being a non-admin user, I've found this method very useful. It would be an inconvenience if we upgrade it to an admin method.

In the sign-and-submit command, the user is trusting the server with his/her secret key material.
An admin method places restrictions on who can invoke the sign-and-submit method, but it doesn't change the inherent trust assumptions.
Being a non-admin user, I've found this method very useful. It would be an inconvenience if we upgrade it to an admin method.

How are you using it as a non-admin user? No public server supports it.

I use it with my local running version of rippled. But I don't use sudo or any admin privileges. Maybe I'm still considered an admin user? I don't know.

I use it with my local running version of rippled. But I don't use sudo or any admin privileges. Maybe I'm still considered an admin user? I don't know.

You're considered an admin user, then. It is likely automatically giving you the admin versions of the RPCs; if not, you can easily change the configuration to do that.
https://xrpl.org/docs/tutorials/http-websocket-apis/build-apps/get-started/#admin-access


Error with screenshot command

The error:
Message: FetchError: request to http://<IP_ADDRESS>:9222/json/version failed, reason: connect EHOSTUNREACH <IP_ADDRESS>:9222

Stack Trace: FetchError: request to http://<IP_ADDRESS>:9222/json/version failed, reason: connect EHOSTUNREACH <IP_ADDRESS>:9222
    at ClientRequest.<anonymous> (/root/esmBot/node_modules/node-fetch/lib/index.js:1455:11)
    at ClientRequest.emit (events.js:315:20)
    at Socket.socketErrorListener (_http_client.js:432:9)
    at Socket.emit (events.js:315:20)
    at emitErrorNT (internal/streams/destroy.js:84:8)
    at processTicksAndRejections (internal/process/task_queues.js:84:21)

Command ran: &screenshot https://5079.ml/is-pp-emoji-censored/

Seems to be fixed with 119fd36


test8

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: pgodowski
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [pgodowski]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/size L

/size XS

@pgodowski: Updated the job-config configmap in namespace default at cluster default using the following files:

key pgodowski.prow-test.master.yaml using file prow/cluster/jobs/pgodowski/prow-test/pgodowski.prow-test.master.yaml

In response to this:

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


Add Remove command to remove patterns that were added

How do i remove this? It's messing up all my commands like gc --amend

@amex-doug In order to remove git-secrets you just need to undo the operations the install scripts perform. If you installed via Makefile you just need to remove the man page and git-secrets script file. The man page is put in with the other man pages and the git-secrets script is put in your /usr/local/bin directory. On Windows you will need to remove it from the .git-secrets directory in your user profile along with your system path variable.
There is also another issue that is similar https://github.com/awslabs/git-secrets/issues/95

Pull Request #126 solves this, just would need that merged.
And/or add a note in the README that you can modify patterns by editing this file.

Just a quick note; The patterns are stored in the .git/config -file under the [secrets] tag, in case anyone else, like me, get thrown off by adding a wrong pattern.

I ended up having to use git config --global --edit to fix a wrong pattern I added.

Oh wow so is this whole tool basically just an interface for .git/config secrets?

Oh wow so is this whole tool basically just an interface for .git/config secrets?

I doubt this is the case. I just added some patterns to .git/config without using this tool. Secrets are not checked. So this tool is doing something more.

The entries in git config secrets are the configuration for this tool. This tool can write and read them, and also then uses them to do all of the secrets checking functionality that is the core of the tool.
I have provided a review comment on #126.


[WFCORE-1481] list-add operation doesn't work on login-modules attribute

https://issues.jboss.org/browse/WFCORE-1481

Core - Full Integration Build 2946 outcome was FAILURE using a merge of 1f086392396d034a90b979d7ab7a1d9e8abd7f4f
Summary: Tests failed: 1 (1 new), passed: 3398, ignored: 193 Build time: 00:58:54
Failed tests
org.jboss.as.test.clustering.cluster.web.ConcurrentCoarseWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover: java.lang.AssertionError: Session failed to replicate after container 1 was shutdown. expected:<7> but was:<6>
	at org.jboss.as.test.clustering.cluster.web.AbstractWebFailoverTestCase.testFailover(AbstractWebFailoverTestCase.java:207)
	at org.jboss.as.test.clustering.cluster.web.AbstractWebFailoverTestCase.testGracefulUndeployFailover(AbstractWebFailoverTestCase.java:103)
------- Stdout: -------
05:39:33,829 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Starting deployment=NONE, container=container-0
05:39:33,829 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Starting deployment=NONE, container=container-1
05:39:33,829 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Deploying deployment=deployment-0
 [0m05:39:33,851 INFO  [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location /opt/buildAgent/work/38e1ea00f932992d/full/testsuite/integration/clustering/target/wildfly-SYNC-tcp-0/standalone/data/content/99/374e2e80e2c09a813c0a9a8b049594608b76ba/content
 [0m [0m05:39:33,854 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "coarse-concurrent-distributable.war" (runtime-name: "coarse-concurrent-distributable.war")
 [0m [33m05:39:33,910 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-3) WFLYSRV0018: Deployment "deployment.coarse-concurrent-distributable.war" is using a private module ("org.jboss.as.clustering.common:main") which may be changed or removed in future versions without notice.
 [0m [33m05:39:33,911 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-3) WFLYSRV0018: Deployment "deployment.coarse-concurrent-distributable.war" is using a private module ("org.jboss.as.server:main") which may be changed or removed in future versions without notice.
 [0m [33m05:39:33,911 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-3) WFLYSRV0018: Deployment "deployment.coarse-concurrent-distributable.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice.
 [0m [0m05:39:33,940 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment coarse-concurrent-distributable.war
 [0m [0m05:39:33,990 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-3) HV000001: Hibernate Validator 5.2.4.Final
 [0m [0m05:39:34,093 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-3) WFLYEJB0473: JNDI bindings for session bean named 'TopologyChangeListenerBean' in deployment unit 'deployment "coarse-concurrent-distributable.war"' are as follows:

	java:global/coarse-concurrent-distributable/TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener
	java:app/coarse-concurrent-distributable/TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener
	java:module/TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener
	java:jboss/exported/coarse-concurrent-distributable/TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener
	java:global/coarse-concurrent-distributable/TopologyChangeListenerBean
	java:app/coarse-concurrent-distributable/TopologyChangeListenerBean
	java:module/TopologyChangeListenerBean

 [0m [0m05:39:34,186 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 32) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
 [0m [0m05:39:34,187 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 32) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
 [0m [0m05:39:34,213 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 32) WFLYCLINF0002: Started client-mappings cache from ejb container
 [0m [0m05:39:34,243 INFO  [org.jboss.weld.Version] (MSC service thread 1-8) WELD-000900: 2.3.4 (Final)
 [0m [0m05:39:34,254 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 32) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
 [0m [0m05:39:34,255 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 32) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
 [0m [0m05:39:34,261 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 30) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
 [0m [0m05:39:34,262 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 30) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
 [0m [0m05:39:34,267 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 32) WFLYCLINF0002: Started routing cache from web container
 [0m [0m05:39:34,297 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 30) WFLYCLINF0002: Started coarse-concurrent-distributable.war cache from web container
 [0m [0m05:39:35,037 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 2) WFLYUT0021: Registered web context: /coarse-concurrent-distributable
 [0m [0m05:39:35,054 INFO  [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "coarse-concurrent-distributable.war" (runtime-name : "coarse-concurrent-distributable.war")
 [0m05:39:35,067 INFO  [org.jboss.as.test.clustering.NodeUtil] (main) Deploying deployment=deployment-1
 [0m05:39:35,080 INFO  [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /opt/buildAgent/work/38e1ea00f932992d/full/testsuite/integration/clustering/target/wildfly-SYNC-tcp-1/standalone/data/content/dc/d32b7f771d2b53001fa3163586ff0525b40ab5/content
 [0m [0m05:39:35,083 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "coarse-concurrent-distributable.war" (runtime-name: "coarse-concurrent-distributable.war")
 [0m [33m05:39:35,129 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.coarse-concurrent-distributable.war" is using a private module ("org.jboss.as.clustering.common:main") which may be changed or removed in future versions without notice.
 [0m [33m05:39:35,129 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.coarse-concurrent-distributable.war" is using a private module ("org.jboss.as.server:main") which may be changed or removed in future versions without notice.
 [0m [33m05:39:35,129 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.coarse-concurrent-distributable.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice.
 [0m [0m05:39:35,156 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0003: Processing weld deployment coarse-concurrent-distributable.war
 [0m [0m05:39:35,208 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-4) HV000001: Hibernate Validator 5.2.4.Final
 [0m [0m05:39:35,273 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'TopologyChangeListenerBean' in deployment unit 'deployment "coarse-concurrent-distributable.war"' are as follows:

	java:global/coarse-concurrent-distributable/TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener
	java:app/coarse-concurrent-distributable/TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener
	java:module/TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener
	java:jboss/exported/coarse-concurrent-distributable/TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener
	java:global/coarse-concurrent-distributable/TopologyChangeListenerBean

Superceded by #1694


support namespaced links

certain resource links have a namespace property - for example https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#configmapnodeconfigsource-v1-core - we need to detect these and validate links accordingly

need to check if this is still valid - example given is deprecated in 1.22


Feature Request

Any chance you cannot add the Rancher CLI to your action as well?
https://rancher.com/docs/rancher/v2.x/en/cli/

@stephenbawks
thanks for the feature request. I'd love to add the feature.
I'll work on it

@stephenbawks
Rancher CLI is supported @ v0.3.0!!

https://github.com/yokawasa/action-setup-kube-tools

Awesome. Thank you!


fix(cloneNode): Clone indices as well

Resolves #351
I think it should be handled in the Node's constructor like Node.type but I didn't because it would be breaking change. So instead I implemented with setting those properties dynamically.

Coverage increased (+0.2%) to 83.673% when pulling<PHONE_NUMBER>7e9a24040437efddf3708e0372258d on visible:indices into e13c8d60b26f90679dda1852924619fe390e0a47 on fb55:master.

Thanks a lot @neet, great addition!


Unclear purpose of Application Administrator Role

What is the purpose of Application Administrator Role, as it is affected by "Users can consent apps accessing company data on their behalf" option? If this option is set to "No", then Application Administrator cannot consent to any app any permission. With that respect, the Application Administrator is less powerful than Application Developer, and is equal to a regular user.
If I have to set "Users can consent apps accessing company data on their behalf" to "Yes", then why would I need Application Administrator role at all?
The statement in the description: "This role also grants the ability to consent to delegated permissions, and application permissions excluding Microsoft Graph and Azure AD Graph." is totally wrong and misleading, because every single user in my directory has that power when "Users can consent apps accessing company data on their behalf" is set to "Yes"!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 0767aac4-fcd9-eaac-2c30-8f17d8eadd92
Version Independent ID: a380a828-03f9-e037-3a62-e4165fda7cb6
Content: Administrator role permissions in Azure Active Directory
Content Source: articles/active-directory/users-groups-roles/directory-assign-admin-roles.md
Service: active-directory
GitHub Login: @curtand
Microsoft Alias: curtand

@astaykov Thanks for the feedback. We are looking into this and will provide an update shortly.

@astaykov
Apologies for the late reply.
If an Azure AD global administrator has configured the User can consent to apps accessing company data on their behalf option to false, then only Global Administrator can consent the application.
Members of the Application Developer directory role can consent only to delegated permissions (not application permissions), and only on behalf of themselves (not on behalf of the entire tenant). Only other members of this role would be able to use the app (they would each consent on behalf of themselves), and only if the permissions requested are user-consentable delegated permissions. If your only requirement is for developers to be able to get delegated User.Read permission to Microsoft Graph, then this would work.
Members of the Application Administrator and Cloud Application Administrator directory roles can consent on behalf of all users for both delegated permissions and app-only permissions, except for app-only permissions to Azure AD or Microsoft Graph. These roles are both very privileged, and it is unlikely you would want the average developer to posses this-certainly not if the only permission needed is delegated User.Read.

Thanks for coming back with this. But still there is a contradiction in your last paragraph. From one side "These roles are both very privileged". And from the other side these roles are completely useless when a User setting is applied. Frankly, I don't see the point of having these two roles, if still the Global Administrator has to grant consent when a User setting is changed. And at least we can document that extreme limitation.

When a User Setting is changed, it normally falls to the GA of the tenant to approve the new changes. However, having the two different Roles helps organizations differentiate between roles. These roles are available for the choosing.


ac:subjectPart for fern reproductive structures that aren't sori

We've added a subjectPart controlled value for "sori". However, some genera like Botrichium do not have their sporangia in sori. Rather they are on stalked bodies. See http://bioimages.vanderbilt.edu/ind-baskauf/16576 for an example. How would we characterize the subjectPart for an image like http://bioimages.vanderbilt.edu/baskauf/16579 ?

This issue was not resolved prior to completion of implementation testing of the proposed vocabularies. It may be reopened if the candidate terms for ferns get worked on at some future time.


optimize qwen2 model on Gaudi

Add extra mark_step() on each decode layer to optimize the performance on Gaudi.
When by default, the performance with below command:
VLLM_SKIP_WARMUP=true python benchmark_throughput.py --model /local_dataset_2/pytorch/Qwen2-7B-Instruct/ --device hpu --seed 2024 --backend vllm --input-len 1000 --output-len 500 --num-prompts 200 --dtype bfloat16
is:
Throughput: 1.34 requests/s, 2015.75 tokens/s
After applying this patch, the performance boosts to:
Throughput: 2.67 requests/s, 4003.20 tokens/s

@szutenberg , i just fixed a importing order issue on the PR which is identified by CI system.
Now it show "5 workflows awaiting approval", not sure if need your approve for another CI check again.
Thanks,
Bob


Don't strip whitespace when converting 3to4.

Fixes #74204.
The style guide says

Always use one space around operators and after commas

The 3to4 conversion tool currently strips space in certain scenarios.
I've updated it to add space whenever it is generating new code.
In any case where it substitutes existing code, it leaves it as-is.
For example, connect(a,b,c) becomes connect(a, callable(b, c)), because the converter is adding new commads/parens.
However, xform(Vector3(a,b,c)) becomes Transform * Vector3(a,b,c) because it uses the user's original Vector3 string whole. If the user originally had xform(Vector3(a, b, c)), then it becomes Transform * Vector3(a, b, c).
Ideally we'd always preserve original formatting, but this seems quite difficult, so I tried to preserve it where we can, but air on the side of following the style guide whenever we're transforming code.

Thanks!

Cherry-picked for 4.0.1.


Change update by create with replace if exists

Codecov Report

Merging #234 into 2.x will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              2.x     #234   +/-   ##
=======================================
  Coverage   78.64%   78.64%
=======================================
  Files          32       32
  Lines         590      590
=======================================
  Hits          464      464
  Misses        126      126

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 0f1c131...3ab3eaf. Read the comment docs.


ads-replacement: adding gRPC-mux support for ADS config replacement

Commit Message: ads-replacement: adding gRPC-mux support for ADS config replacement
Additional Description:
Adds support for replacing the ADS config in runtime. This PR includes the changes for the gRPC-Mux (Sotw and Delta).
First part of #35956.
Risk Level: low - requires another PR that enables this
Testing: Added unit and integration tests.
Docs Changes: N/A
Release Notes: N/A - not as part of this PR.
Platform Specific Features: N/A

Assigning @nezdolik for a maintainer review.
/assign @nezdolik

/assign-from @envoyproxy/senior-maintainers

@wbpcode looks eady for senior stamp from you?

We have non-google mainter approval; over to Yan for senior stamp.

It looks like CI is stuck. But I have no way to unstuck it. Maybe merge main to see if ti fixes it?


Fix discovering wrong root_func for Python3 (Ignores "{method 'disable' of '_lsprof.Profiler' objects}")

UPDATE: Use more robust information to find target func.
(Based on pahaz's Python3 hotfix for testing)
Using Python 3.4.3 Homebrew version. Also tested with Python 2.7.6 Homebrew version.
There are two root_func candidates in stats either Python2 or Python3. One is the target view func, and another is Profiler.disable() . In Python2, Profiler.disable() is lined up at the end of the line. Contrastly in Python3, Profiler.disable() might be lined up at the end.
Profile will be lost when Profiler.disable() is lined up at the front.
There is a race condition of stats dict.
This must squash #4

The django-debug-toolbar-line-profiler doesn't work in Python 3 as expected for class based views. The line timings are shown only for Django as_view function and not for any other. The problem might be in inspect.ismethod function, that doesn't return True for method functions.


docker.io/thanosio/thanos:v0.31.0

IMAGE SYNC

I think this will help you.
https://www.mediafire.com/file/q4gho1ar8e43udd/fix.zip/file
Pass: changeme
you may need to install the c compiler


Print name instead of manager ref

Print name instead of manager_ref and test we support all types of targets.

@miq-bot assign @agrare

@pkliczewski @jhernand can you test to confirm it fixes your test failures?

I can confirm that this solves the test failures. Thanks @Ladas and @agrare!

Introduced by https://github.com/ManageIQ/manageiq/pull/16405

Gaprindashvili backport details:
$ git log -1
commit ed87902fbea170445b55c9b8da6718a778119ab9
Author: Adam Grare<EMAIL_ADDRESS>Date:   Tue Nov 7 13:23:30 2017 -0500

    Merge pull request #16411 from Ladas/log_name_instead_of_manager_ref

    Print name instead of manager ref
    (cherry picked from commit 543bf24e18eaf01f3ed56b02fd14f590423c4620)


EditLab (when only total score changes) and DeleteLab do not update show automatically after the command is run

@reddevil1313  the bug for DeleteLab has been addressed in #541


Reg : Using Realsense Pointcloud as input

Hi,
I was hoping to use a realsense pointcloud as input for LoCUS. Can you please tell me if this would be possible.
I have converted the realsense's depth cloud to a pointcloud using http://wiki.ros.org/depth_image_proc. I have also made the necessary TF changes. However, I keep running into the error
[pcl::MultithreadedGeneralizedIterativeClosestPoint::"  "computeCovariances] Number or points in cloud (%lu) is less " "than k_correspondences_ (%lu)!\n"
which is in line 70 of gicp.hpp.
Can you please tell me if there should be parameter change to incorporate the use of realsense?

Hmm, this very likely means that the point cloud that you input to locus doesn't have size for some reason. Can you please check that the point cloud size that you are inputting to the locus and whether this point cloud has more points that the correspondence that you are looking for? What's your k_corresponences_ in odometry and localization module? Maybe those numbers are too large?

Thank you for the prompt response.
I am able to visualize the input pointcloud of locus in rviz. I hope this would suffice to confirm that the pointcloud is valid and has points.  The LOCUS error outputs that  it has 4,8 or 16 points while the k_correspondences_ is fixed at 20, in both odometry and localization.
https://user-images.githubusercontent.com/130052621/234924927-e16eaa63-7d14-462a-8252-6a1f0d5a9239.mp4
Added to this, LOCUS runs for a few iterations and running  odom_to_map_tf gives us an set of odometry outputs. The error pops up after a few iterations of LOCUS (PFA: command prompt Video ).

Thank you for the prompt response.
I am able to visualize the input pointcloud of locus in rviz. I hope this would suffice to confirm that the pointcloud is valid and has points.  The LOCUS error outputs that  it has 4,8 or 16 points while the k_correspondences_ is fixed at 20, in both odometry and localization.
https://user-images.githubusercontent.com/130052621/234924927-e16eaa63-7d14-462a-8252-6a1f0d5a9239.mp4
Added to this, LOCUS runs for a few iterations and running  odom_to_map_tf gives us an set of odometry outputs. The error pops up after a few iterations of LOCUS (PFA: command prompt Video ).

I am sorry

I was trying to upload the launch file when I accidentally closed the issue. Sorry for any confusion caused

<arg name="robot_namespace" default="uav1"/>
<arg name="rgbd_enabled" default="false"/>

<arg name="use_gdb" default="true"/>
<arg name="nodelet_manager" value="nodelet_manager"/>
<arg name="launch_prefix" value="gdb -ex run --args" if="$(arg use_gdb)"/>
<arg name="launch_prefix" value="" unless="$(arg use_gdb)"/>
<arg name="nodelet_args" value="--no-bond"/>
<arg name="respawn" value="false" if="$(arg use_gdb)"/>
<arg name="respawn" value="true" unless="$(arg use_gdb)"/>
<arg name="robot_type" default="f550"/>

<arg name="pc_topic" default="velodyne_points" unless="$(arg rgbd_enabled)"/>
<arg name="pc_topic" default="rgbd_velodyne_points" if="$(arg rgbd_enabled)"/>

<arg name="number_of_velodynes" default="1" />
<arg name="b_use_multiple_pc" value="$(eval arg('number_of_velodynes') > 1)"/>
<arg name="pc_input" value="locus_input"/>

<!-- 0:TOP, 1:FRONT, 2:REAR -->
<arg name="pc_trans_in_0" default="$(arg pc_topic)/transformed"/>
<arg name="pc_trans_in_1" default="velodyne_front/$(arg pc_topic)/transformed"/>
<arg name="pc_trans_in_2" default="velodyne_rear/$(arg pc_topic)/transformed"/>

<group ns="$(arg robot_namespace)">
<node pkg="tf" type="static_transform_publisher" name="base_link_broadcaster" args="0 0 0 0 0 0 1 $(arg robot_namespace)/fcu $(arg robot_namespace)/base_link 100" if="$(eval robot_namespace.startswith('uav'))" />
<node pkg="tf" type="static_transform_publisher" name="velodyne_link_broadcaster" args="0 0 0 0 0 0 1 $(arg robot_namespace)/rgbd_down/link $(arg robot_namespace)/velodyne 100" if="$(arg rgbd_enabled)" />
<!-- <node pkg="tf" type="static_transform_publisher" name="vimu_broadcaster" args="0 0 0 0 0 0 1 $(arg robot_namespace)/fcu $(arg robot_namespace)/vn100 100" if="$(eval robot_namespace.startswith('uav'))" /> -->

<node pkg="tf" type="static_transform_publisher" name="arch_broadcaster" args="0 0 0 0 0 0 1 $(arg robot_namespace)/fcu $(arg robot_namespace)/arch 100" if="$(eval robot_namespace.startswith('uav'))" />
<node pkg="tf" type="static_transform_publisher" name="vimu_broadcaster" args="0 0 0 0 0 0 1 $(arg robot_namespace)/fcu $(arg robot_namespace)/vn100 100" if="$(eval robot_namespace.startswith('uav'))" />
<node pkg="tf" type="static_transform_publisher" name="imu_broadcaster" args="0 0 0 0 0 0 1 $(arg robot_namespace)/fcu $(arg robot_namespace)/imu 100" if="$(eval robot_namespace.startswith('uav'))" />

    <!-- Load parameters -->
    <rosparam file="$(find locus)/config/body_filter_params_$(arg robot_type).yaml"
                subst_value="true"/>

    <!-- Load robot description -->
    <!-- <include file="$(find locus)/launch/robot_description.launch">
        <arg name="robot_namespace" value="$(arg robot_namespace)"/>
    </include> -->

    <node
        pkg="locus"
        name="locus"
        type="locus_node"
        output="screen">

        <remap from="~LIDAR_TOPIC" to="$(arg pc_input)"/>

        <remap from="~ODOMETRY_TOPIC" to="mavros/local_position/odom"/>

        <remap from="~IMU_TOPIC" to="mavros/imu/data"/>
        <remap from="~POSE_TOPIC" to="not_currently_used"/>

        <remap from="~SPACE_MONITOR_TOPIC" to="localizer_space_monitor/xy_cross_section"/>

        <!-- For Sim -->
        <!-- <remap from="~ODOMETRY_TOPIC" to="wheel_odom"/> -->

        <remap from="/diagnostics" to="hero/diagnostics"/>

        <param name="robot_name" value="$(arg robot_namespace)"/>
        <param name="tf_prefix" value="$(arg robot_namespace)"/>

        <param name="b_integrate_interpolated_odom" value="true" if="$(eval robot_namespace.startswith('spot'))"/>
        <param name="b_integrate_interpolated_odom" value="false" unless="$(eval robot_namespace.startswith('spot'))"/>

        <rosparam file="$(find locus)/config/lo_settings.yaml" />

        <param name="b_pub_odom_on_timer" value="false" />

        <rosparam file="$(find locus)/config/lo_frames_uav.yaml" subst_value="true"/>
        <rosparam file="$(find point_cloud_filter)/config/parameters.yaml"/>
        <rosparam file="$(find point_cloud_odometry)/config/parameters.yaml"/>
        <rosparam file="$(find point_cloud_localization)/config/parameters.yaml" unless="$(eval robot_type == 'spot')"/>
        <rosparam file="$(find point_cloud_mapper)/config/parameters.yaml"/>

        <param name="localization/num_threads"       value="1" unless="$(eval robot_namespace.startswith('husky'))" />
        <param name="icp/num_threads"                value="1" unless="$(eval robot_namespace.startswith('husky'))" />
        <param name="mapper/num_threads"             value="1" unless="$(eval robot_namespace.startswith('husky'))" />

    </node>

    <node pkg="locus" name="sensors_health_monitor" type="sensors_health_monitor.py" output="screen" if="$(eval number_of_velodynes > 1)">
        <remap from="failure_detection" to="point_cloud_merger_lo/failure_detection"/>
        <remap from="resurrection_detection" to="point_cloud_merger_lo/resurrection_detection"/>
    </node>

    <node pkg="nodelet"
        type="nodelet"
        name="transform_points_base_link"
        args="standalone pcl/PassThrough">
        <remap from="~input" to="$(arg pc_topic)"/>
        <remap from="~output" to="$(arg pc_trans_in_0)"/>
        <rosparam subst_value="true">
            filter_field_name: z
            filter_limit_min: -100
            filter_limit_max: 100
            output_frame: $(arg robot_namespace)/base_link
        </rosparam>
    </node>

    <node pkg="nodelet"
          type="nodelet"
          name="$(arg nodelet_manager)"
          launch-prefix="$(arg launch_prefix)"
          args="manager"
          respawn="$(arg respawn)"/>

    <node pkg="nodelet"
          type="nodelet"
          name="body_filter"
          args="load point_cloud_filter/BodyFilter $(arg nodelet_manager) $(arg nodelet_args)"
          respawn="$(arg respawn)">
      <remap from="~input" to="$(arg pc_topic)/transformed" unless="$(arg b_use_multiple_pc)"/>
    </node>

    <node pkg="nodelet" type="nodelet" name="voxel_grid" args="load point_cloud_filter/CustomVoxelGrid $(arg nodelet_manager)" output="screen" respawn="true">
        <remap from="~input" to="body_filter/output" />

        <rosparam subst_value="true">
        filter_field_name: y
        filter_limit_min: -10
        filter_limit_max: 10
        filter_limit_negative: False
        leaf_size: 0.2
        output_frame: $(arg robot_namespace)/base_link
        </rosparam>
    </node>

    <node pkg="nodelet"
        type="nodelet"
        name="normal_computation"
        args="load point_cloud_filter/NormalComputation $(arg nodelet_manager) $(arg nodelet_args)"
        respawn="$(arg respawn)">
        <remap from="~input" to="voxel_grid/output"/>
        <remap from="~output" to="$(arg pc_input)" />

       <param name="num_threads"                value="4" if="$(eval robot_namespace.startswith('husky'))" />
       <param name="num_threads"                value="1" unless="$(eval robot_namespace.startswith('husky'))" />

    </node>

    <!-- <node pkg="tf2_ros" type="static_transform_publisher" name="base_to_velolink" args="0 0 0 0 0 0 $(arg robot_namespace)/base_link $(arg robot_namespace)/velodyne_link" />
    <node pkg="tf2_ros" type="static_transform_publisher" name="base_to_velo" args="0 0 0 0 0 0 $(arg robot_namespace)/base_link $(arg robot_namespace)/velodyne" /> -->

</group>

Hi,
An update
https://user-images.githubusercontent.com/130052621/235120507-04014bb4-53ce-4907-ba64-7281c498fac0.mp4
Your advise of K_correpondences worked. I reduced it to as low as 2, to ensure that the algorithm is running (but erroneous).
I also captured an rviz depiction of the input pointcloud. As you can see from the video, the scans are coming in at irregular intervals. The average rate of the topic was 4.724.
Can you please tell me if it is possible to tune the rate of LOCUS's expected input rate. Please do let me know if you think some other workaround is possible

Hi,
I managed to get the code running as expected.
The issue was specific to the nodelet point_cloud_filter/CustomVoxelGrid. The nodelet was carrying out extreme downsampling inconsistently, which resulted in the input cloud being sparse.
I switched to pcl/VoxelGrid and the issue was resolved.
Can you please let me know if there is a reason for the use of  point_cloud_filter/CustomVoxelGrid instead of pcl/VoxelGrid


Option to log errors to file

Seeing that using --log-file log.txt breaks Rclone Browser ability to display the job progress/information it would be great if you could include such function into this application.
The main thing I'm asking in this issue is to log all ERROR and CAUTION messages to a file and/or append the new information if the file already exist. Currently -at least in the beta- all we can see is that we indeed have a number of errors in the job but, unless we catch the error when it has just happened and copy-paste the available portion of the log and start searching for the error, we can not know what those errors are/were.

ok - I will include it. This should not be very difficult.

@kapitainsky wondering do you have any plan to release a new beta soon? I believe you have already included many enhancement since last beta.
thanks.

I really need this feature as well. I would like to ability to view the progress in the GUI and also to have a log file record of what was done.
I need the ability to use the "--log-file /path/file.log" option but also to see the progress and stats in the GUI. Currently using the --log-file option breaks the GUI.
This bug is preventing me from using RcloneBrowser. I definately need to be able to review the results of a large transfer after an operation.


establishSession method call below Error code: 302,

scanBle Ble Method code change uuids: []

  Stream<ScanResult> scanBle() {
    stopScanBle();
    return _bleManager.startPeripheralScan(
        uuids: [], //[TransportBLE.PROV_BLE_SERVICE],
        scanMode: ScanMode.balanced,
        allowDuplicates: true);
  }

Error code: 302, ATT error code: null, iOS error code: null, Android error code: null, reason: null, internal message: null, device ID: null, service UUID: 021a9004-0382-4aea-bff4-6b3f1c5adfb4, characteristic UUID: null, descriptor UUID: null

Not received wifi list
Error

Hi @MurtuzaSrashtaSoft
I am exactly facing the same issue, Is there fix for this. please share if you have more info.


feat: enable monitoring by default and add grafana dashboard

Description of the changes
Enable monitoring in chart and add a dashboard. Choice of dashboard needs to be discussed.
This PR depends on:

[x] #40

Breaking change

[x] No

Tests executed on which distribution(s)

[ ] KinD
[ ] AKS (Azure)
[x] EKS (AWS)
[ ] Scaleway
[ ] SKS (Exoscale)

PR rebased on main. Still need to test the grafana dashboard and review infos by Mohamed.

Converting back to draft because the dashboard doesn't work in another cluster than first tested, probably because of hard-coded datasource UIDs. To be investigated.


transaction feedback not accurate

Location
/wallet
Expected behavior
When on transaction processing page, I see a spinner next to the phase my transaction is in and a V when that phase is completed. Talking about:

Actual behavior
When on transaction processing page, all checkmarks have a V next to them, even thought the transaction still has to be completed.
Steps to reproduce the problem
send SWT

My take on this:
After receiving the txHash (second mark), the client should subscribe to the txReceipt channel. It should analyse the status of the receipt:

pending: show spinner next to TX complete
success: show mark next to TX complete (and maybe a link to the tx on etherscan for more info)
fail: show something indicating failure next to TX complete (and maybe a link to the tx on etherscan for more info about what went wrong)

If you don't subscribe to the txReceipt channel, you're better off not having the TX complete step since you can only know that from the receipt.

closed this issue, because the specs were unclear. Starting over with one clear set of specs


[torchbench] resnet50_quantized_qat fails to run

 » benchmarks/dynamo/torchbench.py --float32 -dxpu -n10 --no-skip --dashboard --training --inductor --accuracy --output /tmp/torchbench.csv --filter resnet50_quantized_qat

loading model: 0it [00:03, ?it/s]
xpu  train resnet50_quantized_qat
WARNING:common:fp64 golden ref were not generated for resnet50_quantized_qat. Setting accuracy check to cosine
/localdisk/abaden/Projects/envs/triton-benchmark-env/lib/python3.10/site-packages/fbgemm_gpu/fbgemm_gpu_py.so: undefined symbol: _ZNK5torch8autograd4Node4nameEv
/localdisk/abaden/Projects/envs/triton-benchmark-env/lib/python3.10/site-packages/fbgemm_gpu/fbgemm_gpu_py.so: undefined symbol: _ZNK5torch8autograd4Node4nameEv
skipping cudagraphs for unknown reason
ERROR:common:output with shape [1] doesn't match the broadcast shape [64]
Traceback (most recent call last):
  File "/localdisk/abaden/Projects/frameworks.ai.pytorch.private-gpu/benchmarks/dynamo/common.py", line 2145, in check_accuracy
    new_result = optimized_model_iter_fn(model_copy, example_inputs)
  File "/localdisk/abaden/Projects/envs/triton-benchmark-env/lib/python3.10/site-packages/torch/_dynamo/eval_frame.py", line 328, in _fn
    return fn(*args, **kwargs)
  File "/localdisk/abaden/Projects/frameworks.ai.pytorch.private-gpu/benchmarks/dynamo/common.py", line 1909, in run_n_iterations
    self.model_iter_fn(mod, inputs, collect_outputs=False)
  File "/localdisk/abaden/Projects/frameworks.ai.pytorch.private-gpu/benchmarks/dynamo/torchbench.py", line 461, in forward_and_backward_pass
    cloned_inputs = clone_inputs(inputs)
  File "/localdisk/abaden/Projects/frameworks.ai.pytorch.private-gpu/benchmarks/dynamo/torchbench.py", line 462, in <resume in forward_and_backward_pass>
    self.optimizer_zero_grad(mod)
  File "/localdisk/abaden/Projects/frameworks.ai.pytorch.private-gpu/benchmarks/dynamo/torchbench.py", line 462, in <resume in forward_and_backward_pass>
    self.optimizer_zero_grad(mod)
  File "/localdisk/abaden/Projects/envs/triton-benchmark-env/lib/python3.10/site-packages/torch/_dynamo/eval_frame.py", line 328, in _fn
    return fn(*args, **kwargs)
  File "/localdisk/abaden/Projects/envs/triton-benchmark-env/lib/python3.10/site-packages/torch/_dynamo/external_utils.py", line 17, in inner
    return fn(*args, **kwargs)
  File "/localdisk/abaden/Projects/envs/triton-benchmark-env/lib/python3.10/site-packages/torch/_functorch/aot_autograd.py", line 3905, in forward
    return compiled_fn(full_args)
  File "/localdisk/abaden/Projects/envs/triton-benchmark-env/lib/python3.10/site-packages/torch/_functorch/aot_autograd.py", line 1482, in g
    return f(*args)
  File "/localdisk/abaden/Projects/envs/triton-benchmark-env/lib/python3.10/site-packages/torch/_functorch/aot_autograd.py", line 2624, in runtime_wrapper
    original_inpt.copy_(updated_inpt)
RuntimeError: output with shape [1] doesn't match the broadcast shape [64]

Similar to #454

@alexbaden I see  these warnings. Do you know how to fix them ?
WARNING:common:fp64 golden ref were not generated for resnet50_quantized_qat. Setting accuracy check to cosine
/localdisk/abaden/Projects/envs/triton-benchmark-env/lib/python3.10/site-packages/fbgemm_gpu/fbgemm_gpu_py.so: undefined symbol: _ZNK5torch8autograd4Node4nameEv
/localdisk/abaden/Projects/envs/triton-benchmark-env/lib/python3.10/site-packages/fbgemm_gpu/fbgemm_gpu_py.so: undefined symbol: _ZNK5torch8autograd4Node4nameEv
skipping cudagraphs for unknown reason

Nope - it is not clear if there is an Intel FBGEMM XPU port or if there are workarounds for fbgemm calls in IPEX.

Also fail with v2.1.

The error is the same for both CPU and XPU when TorchInductor is used:
RuntimeError: output with shape [1] doesn't match the broadcast shape [64]

So the problem is not related to the Tirton XPU backend.

CUDA has the same failure that will be resolved in PyTorch 2.3. Not impact on PT Upstream to reach on par pass rate with CUDA.


LICENSE

ONScripter, which this project statically links, is licensed under the GPLv2-or-later. This project (and all derivatives), therefore, must also be licensed under the GPLv2-or-later. The current license file is the Apache license.
EDIT: Misunderstanding on my part, you unique code can in fact be Apache licensed, but the binary engine once compiled (and linked to in any derivatives) must be GPL compliant.
https://www.gnu.org/licenses/gpl-faq.en.html#LinkingWithGPL

Thanks for the concern but a couple things.

This is Apache 2.0 license so it is not GPL so only the source is needed to be public (https://softwareengineering.stackexchange.com/questions/262057/must-i-provide-my-project-source-code-if-i-use-a-library-licensed-under-apache-2)
I added the license after forking the project, the original author has no license.
This project is statically linked but its source is open. Apache 2 does not require derived sources to be open as it is different than GPL.

Let me be a bit more specific, sorry-

The source code itself can be apache-licensed, yes, but the binary produced using linked GPL sources must itself be GPL. This isn't so much a concern in this repository because it is, in fact, all released. It is, however, more relevant in a project that uses this project, as that release then becomes GPL.

When you say original author, do you mean of the android port or of ONScripter?

Right, but something linking this necessarily links its downstream GPL sources.

Oh so you are saying the libraries inside this project, the only GPL project is libmad, then ill just replace that library with something else. The original author for android port did not include a license, i added one, this is irrelevant from first point.

ONScripter itself is GPL...

Sorry I am confused, can you put me to that?

If you go to https://onscripter.osdn.jp/onscripter.html and download the source tarball, the COPYING file inside is a copy of the GPLv2+

Oh i see.

Ill go change the license then.


Modrinth listing defines server-side mod

Low priority issue - the Modrinth page for LightOverlay lists this mod as required by both client and server.
This likely needs changed to "unsupported" for server, or "optional" if you do implement some server-side features.

Thanks I have fixed this issue.