feat: support for relative paths

With these changes, we can specify relative paths and allow the API to retrieve the full URL using the Referer header.

@all-contributors please add @epavanello for code


Make it work on plain Debian

https://github.com/devcontainers-community/features-llvm/actions/runs/5875312127/job/15931397336

maybe investigate https://github.com/rapidsai/devcontainers/tree/branch-23.10/features/src/llvm ?


[Feature Request] Radio support in Tree Component

Existing Component
是
Component Name
Tree
Description
当前 Tree 组件仅支持CheckBox，希望可以加上对 Radio 的支持，覆盖更多的业务场景

Currently, the Tree Component only support show checkbox, I hope that you can add radio support to this component, which may cover more scenarios.

Sorry, we have no plan to support this.


Milestone 2 Feedback

Marking:
-0.5 Alignment of the table “put the average voting above the voting average by studio, as well as average box value above Financials By Studio, since they are correlated,”
Suggestion:
Great job, I think your group made some great changes to streamline the new design in the new app sketch. I really like the column to the left; it is very clean. A general suggestion for the deployed app, make sure to center each of the graphs within each bordered square. I think it would be clearer if you put the average voting above the voting average by studio, since they are correlated. Maybe best fit line for voting profile dot plot. As you mentioned in your reflection, I believe some next steps could include “the functionality whereby when user clicks on a particular studio on either of the boxplot charts of the top rows, the rest of the un-clicked studios would be greyed out and the lower scatter plot and the table would reflect the chosen studio's information accordingly.” Have a great week!

[ ] Cards realignment: #30

Closing this issue since both the concerns were addressed in #33

cards switched around
clicking on a box in the boxplot now filters the table and the scatter plot


Improve Google API error message parsing

Here there could be a method that would route some known error types to a more meaningful UserExceptions.

Ref.: https://keboola.zendesk.com/agent/tickets/9921

Maybe at least make the JSON pretty printed to improve readability.

Just to add, the current error message is something like this:
[2019-03-01 00:00:24] ex-google-drive.ERROR: Google Drive Error: Client error: `POST
 https://www.googleapis.com/oauth2/v3/token` resulted in a `400 Bad Request` response: { "error":
"invalid_grant", "error_description": "Bad Request" } {"message":"Client error: `POST
https://www.googleapis.com/oauth2/v3/token` resulted in a `400 Bad Request` response:\\n{\\n
\"error\": \"invalid_grant\",\\n \"error_description\": \"Bad Request\"\\n}\\n","reason":"Bad
Request","sheet":
{"id":2,"fileId":"1y_XXXXXXXXXXX","fileTitle":"XXXX","sheetId":"433959412","sheetTitle":"XXXXX",
"outputTable":"table","header":{"rows":1,"columns":[]},"enabled":true}} []

It can be kinda hard for end-users to read and debug themselves. Maybe a  status code of the request, response.error and response.error_description would suffice?


Support reading param.json from stdin

It would be useful to support reading a parameter json file from stdin for various piping scenarios, using the convention of "-" as filename:
cat some.json | envsubst | wsk action invoke my-action -P -

In this example we can leverage envsubst to replace some environment variables in the file. Without being able to read from stdin, one has to push the content into a temporary file, invoke and then delete the temp file again.
From looking at the go cli code, it seems readFile() in util.go could be adapted to leverage ioutil.ReadAll(os.Stdin) in case filename == "-". One probably has to check if that is ok for all other readFile() usages, or if that should be a special option reserved for -P --param-file only.

Provided pull request #2848.
Please have a look, thanks!

Issue moved to apache/incubator-openwhisk-cli #126 via ZenHub


refactor(es6) upgrade ModuleParseError to ES6 class

What kind of change does this PR introduce?
refactor, ES5 => ES6
Did you add tests for your changes?
All existing tests pass
If relevant, link to documentation update:
N/A
Summary
upgrade ModuleParseError to es6
Does this PR introduce a breaking change?
N/A
Other information

Thanks


🌱 Remove unit test container image building Dockerfile

What this PR does / why we need it:
Instead use prow tests and get rid of building extra container image just for unit tests

/test-ubuntu-integration-main

/test unit
/test golangci-lint

/test-ubuntu-integration-main

@smoshiur1237 can you re-lgtm, it was lost after squashing. Thanks!


TLS Error when using https

When i switch to https i'm getting the following TLS Error:
2014/12/29 23:57:23 http: TLS handshake error from <IP_ADDRESS>:43480: tls: first record does not look like a TLS handshake

The https Part in my app.ini looks like:
[server]
PROTOCOL = https
DOMAIN = git.mortik.de
ROOT_URL = https://git.mortik.de
...
CERT_FILE = /home/git/gogs_ssl.crt
KEY_FILE = /home/git/gogs_ssl.key

Thanks your report!
As I did some googling, I haven't got an idea of this error.
Following information maybe helpful:

2014/12/29 23:57:23 http: TLS handshake error from <IP_ADDRESS>:43480: tls: first record does not look like a TLS handshake

Where is this error coming from?

How did you visit your Gogs instance? Directly or via Nginx?

via nginx
i've set gogs protocol settings to http and setup ssl only in nginx.
The remaining Problem is that Chrome and Firefox are showing warnings about that gogs loads some assets via http and not https

The remaining Problem is that Chrome and Firefox are showing warnings about that gogs loads some assets via http and not https

I would say it's true.
So did the original problem solved? Do you have any other questions? :santa:

sorry, yes the problem is solved for me ^^

@mortik cool, happy new year!

@Unknwon happy new year! :)

Hi,
I had the issue today too. Exactly the same error message when I noticed...
In the browser bar address, do not forget to type "https" in the address at the beginning.
This fixed it for me and I have been able to add the security exception (as I am not using "trusted" SSL certificates).
I do write it here in case anybody runs into the issue as, as stupid as it is. It might be the issue. :)
PS: then it seems that if you're in HTTPS mode, if you type the address as an HTTP one, it will do the TLS handshake error: first record does not look like a TLS handshake. I don't know how hard it would be for you, but it might be interesting if when in HTTPS mode it would automatically redirect the "http://blablabla.bla" to "https://blablabla.bla".

@Hayaweh

but it might be interesting if when in HTTPS mode it would automatically redirect the "http://blablabla.bla" to "https://blablabla.bla".

It is nice but you would end up hacking Go source code somehow... but not 100% sure.
Normally we put NGINX front it and redirect HTTP to HTTPS.

@Unknwon
Well. I have absolutely no idea if this is possible or not.
As for putting NGINX in front, currently I am running it from a Windows Server 2012 and have no web-server installed aside of IIS. (I guess that we can do it there too but that would allow not to have a web-server behind it).
As I said, I have no knowledge of Go nor the internal structure of Gogs so.. I don't know. :)

@Hayaweh no worries, but if you Google iis redirect http to https, you should get some helpful info.

@Unknwon
Thanks, I already know how to do it. But I was surprised that Gogs did not handle it. (which explained the error stated above)

@Hayaweh I see :smile:

This is simply not possible with a single port. You have to bind 2 ports, one for http and one for https. In the case of golang you have to run them in go routines because the serve function only returns on error. Redirecting from http to https is absolutly not possible with a single port binding.


Unable to resolve module perf_hooks in react native

Description
error: Error: Unable to resolve module perf_hooks from /Users/develop/ReactNative/Test/node_modules/universal-speedtest/dist/Speedtest.js: perf_hooks could not be found within the project or in these directories: node_modules 2 | Object.defineProperty(exports, "__esModule", { value: true }); 3 | exports.Speedtest = void 0; > 4 | const perf_hooks_1 = require("perf_hooks"); | ^ 5 | const path = require("path"); 6 | const worker_threads_1 = require("worker_threads"); 7 | const UrllibHelper_1 = require("./helpers/UrllibHelper"); at ModuleResolver.resolveDependency (/Users/develop/ReactNative/Test/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js:158:15) at DependencyGraph.resolveDependency (/Users/develop/ReactNative/Test/node_modules/metro/src/node-haste/DependencyGraph.js:231:43) at Object.resolve (/Users/develop/ReactNative/Test/node_modules/metro/src/lib/transformHelpers.js:129:24) at resolve (/Users/develop/ReactNative/Test/node_modules/metro/src/DeltaBundler/traverseDependencies.js:396:33) at /Users/develop/ReactNative/Test/node_modules/metro/src/DeltaBundler/traverseDependencies.js:412:26 at Array.reduce ()enter code here at resolveDependencies (/Users/develop/ReactNative/Test/node_modules/metro/src/DeltaBundler/traverseDependencies.js:411:33) at processModule (/Users/develop/ReactNative/Test/node_modules/metro/src/DeltaBundler/traverseDependencies.js:140:31) at async addDependency (/Users/develop/ReactNative/Test/node_modules/metro/src/DeltaBundler/traverseDependencies.js:230:18) at async Promise.all (index 4)
Version
0.68.2
Output of npx react-native info
system: OS: macOS 12.4 CPU: (4) x64 Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz Memory: 28.34 MB / 8.00 GB Shell: 5.8.1 - /bin/zsh Binaries: Node: 18.1.0 - /usr/local/bin/node Yarn: Not Found npm: 8.8.0 - /usr/local/bin/npm Watchman: 2<IP_ADDRESS> - /usr/local/bin/watchman Managers: CocoaPods: 1.11.3 - /usr/local/bin/pod SDKs: iOS SDK: Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5 Android SDK: Not Found IDEs: Android Studio: Not Found Xcode: 13.4/13F17a - /usr/bin/xcodebuild Languages: Java: Not Found npmPackages: @react-native-community/cli: Not Found react: 17.0.2 => 17.0.2 react-native: 0.68.2 => 0.68.2 react-native-macos: Not Found npmGlobalPackages: react-native: Not Found
Steps to reproduce
npm install --save universal-speedtest
import { UniversalSpeedtest, SpeedUnits } from "universal-speedtest";
const universalSpeedtest = new UniversalSpeedtest({
measureUpload: true,
downloadUnit: SpeedUnits.MBps
});
universalSpeedtest.runSpeedtestNet().then((result) => {
console.log(result);
});
Snack, code example, screenshot, or link to a repository
https://stackoverflow.com/questions/72514123/unable-to-resolve-module-perf-hooks-in-react-native

Closing as:

This involves this other library: https://github.com/karelkryda/universal-speedtest Please open it as an issue over there.
You posted this also on StackOverflow so you might get a more valuable answer there.

did this issue get resolved?


Bad ELF generation on freebsd

Using the freebsd branch I'm working on: https://github.com/zig-lang/zig/tree/freebsd
Have got executables compiling without errors but the generated ELF's appear to use the UNIX System V ABI (type 0).
$ (freebsd) zig build-exe t.zig
$ (freebsd) ./t
ELF binary type "0" not known.

Just to check, I tried rebranding as a GNU elf and using the linux compatibility layer built in to FreeBSD but segfaults, which makes sense. There is a specific FreeBSD OS ABI of type 9, but not really that familiar with how oses want their elf files.
Will have a closer look at some point.

One clue is to have a look at what clang does. We can look at the difference in the LLVM IR generated by clang and by zig. And see if clang generates ELF files that are correct or the same as Zig.

FreeBSD is almost the only OS out there to set this value. Other systems like NetBSD set this to System V ABI.


Font too small/different for Thumbnail view

Expected Behavior
The Thumbnail mode for the Bottom Bar tab content offers the most space-compact view, but the font is absolutely tiny, and is in a monospace font, unlike the rest of the UI. Even smaller than the "current-image-data" area, which is already tiny. And I'm using a 4K 30" monitor zoomed to 110%.
Actual Behavior
For accessibility and legibility, font faces and sizes should be largely uniform across a UI. Otherwise it makes it impossible to adjust the UI so text is legible without other text
Screaming at you in large sizes :)
The font face should especially be consistent. Some situations call for a monospace font, such where where whitespace counting is needed or text needs to line up vertically. That's not really the case here.
Another minor related issue
The thumbnail label currently includes the full path to the file. This is helpful when viewing the Root folder, but when you've already selected that folder on the left, it's just wasted space. Showing paths only as relative to the selected folder under the Root would help alleviate the need to limit the size of the text.
Steps to Reproduce
In the bottom bar, go to Models, LoRAs, Embeddings, etc. Choose Thumbnails mode.
Note the font size of 9.8 pixels, and how this to compares to the larger text on-screen -- the Generate button, top menu, and bottom bar tabs (more than twice as large, 20px). Even the tiny text in the "current image data" area is 12px.
Debug Logs
n/a

Other
I recommend using CSS variables for common things like font sizes and faces, so the CSS across the board is more consistent without having to keep it all aligned manually or through complex cascading. (I just poked through the source and saw that you are using CSS vars)

Thumbnail view was intended for the image browser

Names are long and direct value of the names is low/rare, so them occupying too much space is unwanted.
I'm probably gonna make an even denser image gallery variant in the near future, as currently the image gallery is way too whitespacey for my personal taste.
Maybe for thumbnail view, it could be made a bit more dynamic - shrink if the names are very long, and display normal size if not too long.
... The part you mentioned of subsetting the name to only the part after what folder you're in, is, uh... already working on the image browser. It's indeed missing from the model view tho, so that's a pure and simple bug

Improved line-splitting on browser text
Fix the stray pathnames on model names
Fixed bounding boxes
Applied the dynamic size change for thumbnail names mentioned above


[CPU] Best CPU Build found with MKL config in bazel build BUT with MKL Disabled in script, especially on LSTM, can't undestand why

Please make sure that this is an issue related to performance of TensorFlow.
As per our
GitHub Policy,
we only address code/doc bugs, performance issues, feature requests and
build/installation issues on GitHub. tag:performance_template
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Windows 10
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: -
TensorFlow installed from (source or binary): Build from source
TensorFlow version (use command below): 2.1.0
Python version: 3.8
Bazel version (if compiling from source): 0.27.1
GCC/Compiler version (if compiling from source): msvc2019
CUDA/cuDNN version: -
GPU model and memory: -

You can collect some of this information using our environment capture
script
You can also obtain the TensorFlow version with:

TF 1.0: python -c "import tensorflow as tf; print(tf.GIT_VERSION, tf.VERSION)"
TF 2.0: python -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"

Describe the current behavior
Hello there, I'm trying to find one of the best possible build option config while build tensorflow from source on my computers.
First I thought (as my two coputers are using i7 CPUs) building with MKL was the best option. But tuning correctly intra and inter op thread is hard because it really depends on the model used and the size of data used.
I created a micro benchmark (not really great I admit) but I found some huge discrepencies between build config options AND between Defines while running the script. I'm only benchmarking inference.
All builds were using /arch:AVX2
Here are the results of the microbenchmark with each build config options and define pairs :
Build Command (With MKL) :
bazel --output_base=output_dir build --define=no_tensorflow_py_deps=true --config=v2 --config=mkl --config=opt -c opt --copt="/Ob3" --copt="/fp:fast" --copt="/O2"  //tensorflow/tools/pip_package:build_pip_package

Define Config (MKL Disabled)
os.environ['TF_DISABLE_MKL'] = '1'
os.environ["CUDA_VISIBLE_DEVICES"] = "-1"
os.environ['TF_CPP_MIN_LOG_LEVEL'] = '1'

tf.compat.v1.disable_eager_execution()

Results
Big Dense pass 1 : it took 10.544710159301758 seconds
Big Dense pass 2 : it took 9.63374948501587 seconds
Big Dense pass 3 : it took 9.610066175460815 seconds
Xception pass 1 : it took 5.660003900527954 seconds
Xception pass 2 : it took 5.289057493209839 seconds
Xception pass 3 : it took 5.238063812255859 seconds
LSTM pass 1 : it took 10.222216606140137 seconds
LSTM pass 2 : it took 8.22239375114441 seconds
LSTM pass 3 : it took 8.210553884506226 seconds
LSTM unrolled pass 1 : it took 14.414194822311401 seconds
LSTM unrolled  pass 2 : it took 7.88745903968811 seconds
LSTM unrolled pass 3 : it took 8.34917140007019 seconds
Linear Model pass 1 : it took 1.0033559799194336 seconds
Linear Model pass 2 : it took 0.0069768428802490234 seconds
Linear Model pass 3 : it took 0.010947227478027344 seconds
Linear Model small data pass 1 : it took 1.0467493534088135 seconds
Linear Model small data pass 2 : it took 0.08178114891052246 seconds
Linear Model small data pass 3 : it took 0.15857625007629395 seconds

Build Command (with MKL) :
bazel --output_base=output_dir build --define=no_tensorflow_py_deps=true --config=v2 --config=mkl --config=opt -c opt --copt="/Ob3" --copt="/fp:fast" --copt="/O2"  //tensorflow/tools/pip_package:build_pip_package

Define Config (MKL Enabled)
#os.environ['TF_DISABLE_MKL'] = '1'
os.environ["CUDA_VISIBLE_DEVICES"] = "-1"
os.environ['TF_CPP_MIN_LOG_LEVEL'] = '1'

tf.compat.v1.disable_eager_execution()

Results
Big Dense pass 1 : it took 13.546119928359985 seconds
Big Dense pass 2 : it took 12.425012588500977 seconds
Big Dense pass 3 : it took 12.265166759490967 seconds
Xception pass 1 : it took 16.793854475021362 seconds
Xception pass 2 : it took 15.786102056503296 seconds
Xception pass 3 : it took 15.787992000579834 seconds
LSTM pass 1 : it took 10.035675525665283 seconds
LSTM pass 2 : it took 8.080043315887451 seconds
LSTM pass 3 : it took 7.926990509033203 seconds
LSTM unrolled pass 1 : it took 20.55500102043152 seconds
LSTM unrolled  pass 2 : it took 7.7295191287994385 seconds
LSTM unrolled pass 3 : it took 7.706652879714966 seconds
Linear Model pass 1 : it took 1.0731301307678223 seconds
Linear Model pass 2 : it took 0.007978677749633789 seconds
Linear Model pass 3 : it took 0.01296544075012207 seconds
Linear Model small data pass 1 : it took 1.1389260292053223 seconds
Linear Model small data pass 2 : it took 0.07978606224060059 seconds
Linear Model small data pass 3 : it took 0.1665961742401123 seconds

Build Command (Without MKL)
bazel --output_base=output_dir build --define=no_tensorflow_py_deps=true --config=v2 --config=opt -c opt --copt="/Ob3" --copt="/fp:fast" --copt="/O2"  //tensorflow/tools/pip_package:build_pip_package

Define Config (MKL Disabled/Enabled should not matter as there it is not an MKL build)
os.environ['TF_DISABLE_MKL'] = '1'
os.environ["CUDA_VISIBLE_DEVICES"] = "-1"
os.environ['TF_CPP_MIN_LOG_LEVEL'] = '1'

tf.compat.v1.disable_eager_execution()

Results
Big Dense pass 1 : it took 10.71854853630066 seconds
Big Dense pass 2 : it took 9.549690961837769 seconds
Big Dense pass 3 : it took 9.396085262298584 seconds
Xception pass 1 : it took 5.693288326263428 seconds
Xception pass 2 : it took 5.287402391433716 seconds
Xception pass 3 : it took 5.261985540390015 seconds
LSTM pass 1 : it took 22.114120721817017 seconds
LSTM pass 2 : it took 20.470056772232056 seconds
LSTM pass 3 : it took 20.77280902862549 seconds
LSTM unrolled pass 1 : it took 27.426076889038086 seconds
LSTM unrolled  pass 2 : it took 21.209628105163574 seconds
LSTM unrolled pass 3 : it took 21.19388747215271 seconds
Linear Model pass 1 : it took 1.0153882503509521 seconds
Linear Model pass 2 : it took 0.007978439331054688 seconds
Linear Model pass 3 : it took 0.010976552963256836 seconds
Linear Model small data pass 1 : it took 1.046147108078003 seconds
Linear Model small data pass 2 : it took 0.08078360557556152 seconds
Linear Model small data pass 3 : it took 0.1626284122467041 seconds

What we see is :

on XCeption model, MKL Enabled run is very slow, and any amount of intra/extra threads config didn't manage to put these numbers down
without BUILDING with MKL, LSTM benches are very slow !

Describe the expected behavior
I can't undestand why the best results were obtained with building with MKL enabled in build and then disabling its usage via script.
By the way when installing tensorflow via pip, we observe the same behaviour (bad results on LSTM) and performance is a little bit worse on all other benchmarks (as it is not build with AVX2 and other optimisation flags I guess)
Standalone code to reproduce the issue
Provide a reproducible test case that is the bare minimum necessary to generate
the problem. If possible, please share a link to Colab/Jupyter/any notebook.
The benchmark naive code is attached below :
bench.zip
Other info / logs Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.

@NicolasVidal Do you have any update on this issue? I'm facing the same problem on intel. Official wheels with mkl enabled are very slow for LSTM networks.

Hi @NicolasVidal ,
Could you please try on latest stable version TF 2.6  and let us know if this is still an issue.Thanks!


Write a wiki page on Linux distros

Write a wiki page where you explain what a distro is. Also include information on the following distros:

Red Hat Linux
SuSE Linux
Debian GNU/Linux
Ubuntu
Gentoo Linux
SystemRescueCD
Damn Small Linux
Vyatta
Fedora Core
PC Linux OS

Done please


if-case conversion assists

Related to https://github.com/dart-lang/sdk/issues/52025, notes from @leafpetersen:
1. Turn a null check into an if case:
if (o.f != null)
->
if (o.f case var f?)
2. Turn an instance check on a field into an if case:
if (o.f is Something)
->
if (o.f case Something f)
See: https://dart-review.googlesource.com/c/sdk/+/295502
/fyi @scheglov

@leafpetersen I implemented so far an assist like this, when there is already a variable assigned, and it is checked for null or type. We have quite a lot of code like this in the analyzer and analysis server.
  Future<void> test_notEqNull() async {
    await resolveTestCode('''
void f(A a) {
  var y = a.x;
  if (y != null) {}
}

class A {
  int? x;
}
''');
    await assertHasAssistAt('if', '''
void f(A a) {
  if (a.x case var y?) {}
}

class A {
  int? x;
}
''');
  }

But looking at your examples, it feels that you want something different, e.g. when we already have an expression that is checked for null, but now we want its value, if it is not null. Do I read your intention right?

Ah nice!  I think the fix you describe above is great.  My suggestion was more around places where the user was not already using a local variable:
if (o.x != null) {
   doStuffWith(o.x!);
}

if (o.y is Something) {
  doStuffWith(o.y as Something);
}

I realize that technically rewriting these to an if case with a bound variable isn't 100% semantics preserving, not sure if quick fixes are always intended to be completely semantics preserving or only heuristically so.  In any case, my suggestion was just a brainstorm suggestion, so happy to see it picked up or not.

Unsafe null assert in code?
Nobody writes code like this!
This is what I was going to say, but decided to get some data to prove it.
Unfortunately, we do have such code, in the SDK.

Code analyzer
void main() {
  final collection = AnalysisContextCollection(
    includedPaths: ['/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server'],
  );
  for (final analysisContext in collection.contexts) {
    final analysisSession = analysisContext.currentSession;
    for (final path in analysisContext.contextRoot.analyzedFiles()) {
      final SomeParsedUnitResult parsedResult;
      try {
        parsedResult = analysisSession.getParsedUnit(path);
      } catch (_) {
        continue;
      }
      parsedResult as ParsedUnitResult;
      parsedResult.unit.accept(
        _Visitor(
          path: path,
        ),
      );
    }
  }
}

class _IfNotEqNull {
  final IfStatement ifStatement;
  final String leftCode;
  final List<PostfixExpression> nullAsserts = [];

  _IfNotEqNull({
    required this.ifStatement,
    required this.leftCode,
  });
}

class _Visitor extends RecursiveAstVisitor<void> {
  final String path;
  final List<_IfNotEqNull> _ifNotNullStack = [];

  _Visitor({
    required this.path,
  });

  @override
  void visitIfStatement(IfStatement node) {
    if (_notEqNull(node)) {
      return;
    }

    super.visitIfStatement(node);
  }

  @override
  void visitPostfixExpression(PostfixExpression node) {
    if (node.operator.type == TokenType.BANG) {
      final code = node.operand.toSource();
      for (final ifNotNull in _ifNotNullStack) {
        if (ifNotNull.leftCode == code) {
          ifNotNull.nullAsserts.add(node);
        }
      }
    }

    super.visitPostfixExpression(node);
  }

  bool _notEqNull(IfStatement ifStatement) {
    final expression = ifStatement.expression;
    if (expression is! BinaryExpression) {
      return false;
    }

    if (expression.operator.type != TokenType.BANG_EQ) {
      return false;
    }

    if (expression.rightOperand is! NullLiteral) {
      return false;
    }

    _ifNotNullStack.add(
      _IfNotEqNull(
        ifStatement: ifStatement,
        leftCode: expression.leftOperand.toSource(),
      ),
    );

    ifStatement.thenStatement.accept(this);

    final ifNotNull = _ifNotNullStack.removeLast();
    if (ifNotNull.nullAsserts.isNotEmpty) {
      print(path);
      print('  ${ifNotNull.leftCode}');
      for (final nullAssert in ifNotNull.nullAsserts) {
        print('    $nullAssert');
      }
    }

    ifStatement.elseStatement?.accept(this);
    return true;
  }
}

pkg/analysis_server
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/test/stress/utilities/server.dart
  _analysisFinishedCompleter
    _analysisFinishedCompleter!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/test/src/flutter/flutter_outline_computer_test.dart
  outline.children
    outline.children!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/cider/rename.dart
  element.getter
    element.getter!
    element.getter!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/cider/rename.dart
  element.setter
    element.setter!
    element.setter!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/plugin/plugin_manager.dart
  channel
    channel!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/utilities/extensions/range_factory.dart
  comment
    comment!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/services/correction/dart/extract_local_variable.dart
  simpleIdentifier
    simpleIdentifier!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/services/correction/dart/move_doc_comment_to_library_directive.dart
  commentOnFirstToken
    commentOnFirstToken!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/services/correction/dart/move_annotation_to_library_directive.dart
  commentOnFirstToken
    commentOnFirstToken!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/services/correction/dart/replace_final_with_var.dart
  keyword
    keyword!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/services/correction/fix/data_driven/transform_set_manager.dart
  _sdkCache
    _sdkCache!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/services/completion/dart/keyword_contributor.dart
  element.elseElement
    element.elseElement!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/services/completion/statement/statement_completion.dart
  node.finallyKeyword
    node.finallyKeyword!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/services/refactoring/legacy/extract_method.dart
  _selectionExpression
    _selectionExpression!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/services/refactoring/legacy/extract_method.dart
  _selectionStatements
    _selectionStatements!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/services/refactoring/legacy/inline_method.dart
  _methodExpression
    _methodExpression!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/services/refactoring/legacy/inline_method.dart
  ref._methodStatementsPart
    ref._methodStatementsPart!
    ref._methodStatementsPart!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/services/refactoring/legacy/inline_method.dart
  ref._methodExpressionPart
    ref._methodExpressionPart!
/Users/scheglov/Source/Dart/sdk.git/sdk/pkg/analysis_server/lib/src/services/refactoring/legacy/extract_local.dart
  singleExpression
    singleExpression!

Most of this code is quite old, some of it was written in Java initially, so might be 10+ years old :-)
But we have quite a few references in newer code in front_end and kernel as well.

I started some implementation in https://dart-review.googlesource.com/c/sdk/+/295800
However following the discussion we had today about writing more focused assists, the case of unsafe null asserts might be better covered by Extract Local Variable refactoring first, followed by the already implemented Convert to if-case statement assist.
@bwilkerson


not can capture data for blockbox export in prometheus operator

When I was building prometheus, using blockbox export, I can only capture the data of the blockbox export service itself. I cannot capture the data of other namespaces in the kubernetes cluster. However, when I use prometheus, I can capture other data. Namespace data.
permotheus operator config file is in loads:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app: prometheus-blackbox-exporter
  name: prometheus-blackbox-exporter
  namespace: monitoring
spec:
  endpoints:
  - interval: 30s
    path: /probe
    params:
      moudle: [http_2xx]
    scheme: http
    tlsConfig:
      caFile: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
    kubernetes_sd_configs:
    - role: service
    relabelings:
    # - action: keep
    #   sourceLabels:
    #   - __meta_kubernetes_service_annotation_prometheus_io_scrape
    #   - __meta_kubernetes_service_annotation_prometheus_io_http_probe
    #   regex: true;
    - sourceLabels:
      - __address__
      targetLabel: __param_target
    - targetLabel: __address__
      replacement: prometheus-blackbox-exporter:9115
    - sourceLabels:
      - __param_target
      targetLabel: instance
    - action: labelmap
      regex: __meta_kubernetes_service_label_(.+)
    - sourceLabels:
      - __meta_kubernetes_namespace
      targetLabel: kubernetes_namespace
    - sourceLabels:
      - __meta_kubernetes_service_name
      targetLabel: kubernetes_name
    port: blackbox-port
  jobLabel: app
  namespaceSelector:
    #any: true
    matchNames:
    - monitoring
    - kube-system
  selector:
    matchLabels:
      app: prometheus-blackbox-exporter

prometheus config file is in loads:
cat > prometheus-blackbox-exporter-svc.yaml <<EOF
apiVersion: v1
kind: Service
metadata:
  labels:
    app: prometheus-blackbox-exporter
  name: prometheus-blackbox-exporter
  namespace: monitoring
  annotations:
    prometheus.io/scrape: 'true'
spec:
  #type: NodePort
  selector:
    app: prometheus-blackbox-exporter
  ports:
  - name: blackbox-port
    port: 9115
    targetPort: 9115
    #nodePort: 30009
    protocol: TCP
EOF

I can't find the real cause of this error, so asking this question hopes to help me solve this problem, thank you very much, if you want to communicate further, you can contact me, the email is as follows<EMAIL_ADDRESS>Thanks ALl!

I recommend using the additionalScrapeConfigs feature and use raw Prometheus config for this. We're working on having first class support for Blackbox probes (https://github.com/coreos/prometheus-operator/pull/2832), but until we have that using raw configuration is your best choice.

Probes are now supported in prometheus-operator and we have support for them in kube-prometheus. Please use those :)


Replaced 'brew' installation method

Replaced 'brew' installation method with 'brew cask' as per #172

Thanks so much for the PR! The content looks fine, if you can sign the CLA we can merge.

I have already signed CLA but it appears that this PR doesn't recognise that to be the case.
If you take a look at this previous PR you can see there that the CLA has updated to 'COVERED'.
Shall I just close this and open a new PR to try to fix it?

Close and re-open will retrigger the CLA check :)


Remove incorrect statement from BugPattern index doc

#4248

@cushon I'm unfamiliar with CI/CD of google opensource - do I need to something else for this to be merged or is copybara going to take care of it?

@cushon I'm unfamiliar with CI/CD of google opensource - do I need to something else for this to be merged or is copybara going to take care of it?

There's an internal review process before it's merged. You don't need to do anything else, thanks!


Wallet gets disconnected when switching chains

Hi,
When switching chains wallet gets disconnected, more info describing issue and steps to reproduce on the codebase .
As discussed on discord here is code sample to reproduce the issue.
for some reason I could not create demo on stackblitz or codesandbox using nextJS and cosmosKit. So, here is the github repo you can clone https://github.com/fortytwomoney/cosmoskit-issue-demo.
Thank You

What is the status of this issue?

@MbBrainz I'm working on it

@MbBrainz @vinodhum Please use useChains hook and take a look at the docs and the example.
Docs:  https://docs.cosmoskit.com/hooks/use-chains
Example: https://github.com/cosmology-tech/cosmos-kit/blob/main/packages/example/pages/use-chains.tsx

@twhy Thanx for update, will implement useChains and get back.

@twhy looks like adding chains dynamically is throwing error
ex: adding migaloo to list of chains throws below error
Error: There is no chain info for migaloo-1
const supportedChains = [
    'cosmoshub',
    'osmosis',
    'migaloo',
  ]

 const chainFromQuery = query.fromChain as string

  const walletChains = useMemo(() => {
    if (!!chainFromQuery) {
       supportedChains.push(chainFromQuery)
    }
    return supportedChains
  }, [ chainFromQuery])

  const chains = useChains(walletChains)


[BUG] Using CFLAGS for compiler defines

runtests.py:
We should not use compiler flags for compiler defines. The different compilers have different command line syntaxes. There is a special parameter for this - compiler definitions (distutils.Extension(..., define_macros=...).
To Reproduce
execute runtests.py on OpenVMS
Expected behavior
all tests must be done without errors
Environment (please complete the following information):

OS: OpenVMS
Python version 3.8.2
Cython version 0.29.22

It looks like we've tried to do this right at least once:
https://github.com/cython/cython/blob/217a93e7b139ab49815ea9ca34142b3e2a116a08/runtests.py#L1143
so it's probably a useful change to apply it to the other defines in runtest.py if possible.
I don't know how easy it is to eliminate all custom compiler arguments from runtests.py though

The main difference is that these defines are currently set globally and would then need to be set at a per-module level, i.e. for each test. Probably means passing down the options, but shouldn't be too difficult. PR welcome.


docs: how to opt out of precompiled artefacts

Hi @warmwaffles, I split the Configuration section into two subsections because I'd like to make it clearer that make_force_build is a compile-time option (so that users won't get confused about where they should set it).
But please let me know if you have a better idea of which section I should mention this. :D

That's a good change. I wish there was a way to detect that a variable was modified at runtime that is compile time only and Kernel.warn developers.

That's a good change. I wish there was a way to detect that a variable was modified at runtime that is compile time only and Kernel.warn developers.

Yeah, I wish elixir has this feature as well.


UX

I see my wallet shows as connected in the upper right corner. When I click on my wallet nothing happens. I would like to see a "My Account" somewhere on here but that could just be me. I don't recall off-head if the not larva labs marketplace has this.  Maybe it's not necessary.
There is a button with an O and P (?) next to my wallet address that also does not seem to perform any particular function. What is this for?
The arrow button to the far right has the number 1 on it which tells me I have some sort of message. It wasn't immediately clear what the message was, but I figured it out.  Just seems a bit clunky. That could be me. Only bringing things up as I come across them.
I would think mentioning the notion of 'escrowing' your ethphunk and what this means would be a good thing to have BEFORE you choose to accept an offer or list your phunk.  Again, this is just me.  It's a new concept for most so the more info there is up front, the better imo.

Also, I find it hard to see my activity.  For example, I just cancelled a bid and I do see that my transaction was being processed if I look in the upper right hand corner but I sort of had to hunt around for that.  At first I thought that I needed to cancel it again and was looking for the cancel button again (which wasn't there so that's good!).


Revert "Revert "feat(auth): ensure public auth sets cookie""

Reverts liveblocks/liveblocks#609

@FlowFlorent Can we close this?


Alerting is currently slightly off due to summer time changes.

As a quick fix we're temporarily changing the valid alerting hours by hand to ensure
people only get called when they should be.


Link to documentation

We should link to documentation. It will appear properly here later: https://pkg.go.dev/github.com/dense-analysis/ranges

We already link to documentation in README.md.


Divide by zero in SetTopLine with Minimap

When minimap is visible, SetTopLine does a division by zero when LDisplayLineCount = FVisibleLines
   if FMinimap.Visible and not FMinimap.Dragging then
      FMinimap.TopLine := Max(FTopLine - Abs(Trunc((FMinimap.VisibleLines - FVisibleLines) * (FTopLine / (LDisplayLineCount - FVisibleLines)))), 1);

Fixed.


Chat box info messages

Add in a way for the chat box to display 'info messages'. This will be used for showing when defences are (de)activated, and to give the user some information about the system.

Looks like this


bpf: lift port restriction and allow l4 dnat in ipip

See commit desc.

test-me-please

retest-runtime


update readme files with new build information

This amends https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/pull/20 with updated README files

Resolves https://jira.duraspace.org/browse/FCREPO-1527


Update examples for Repo.one/2

Examples for Repo.one/2 are misleading:
Repo.one(Post)

In the example above, the reader will expect the queryable to return multiple results, but a call to Repo.one/2 will raise an error if it does.
Repo.one(from p in Post, where: p.like_count > 10)

In this other example, we are looking for the posts that have over 10 likes. Again, the reader will expect this will likely return multiple results.
The examples lead the reader to think that Repo.one/2 will actually filter out the first result in case of multiple results.
What I suggest as example:
A query that has a where clause on something unique, like an id. But with a join, otherwise the reader might wonder why not use get/3/get_by/3.
In the example suggested in this PR, a post is retrieved based on its id only if it contains comments. It's not the best example; I think the Repo.one/2 function is used for rather specific cases.
Also note that the documentation for Repo doesn't contain queries with join, assoc, ... and that I introduce that with this PR.

I also considered, more simply:
Repo.one(from p in Post, where: p.id == ^post_id)

better use get/3 in this case, but up to the user to understand that one/2 is more suited when need to pass a query.
or (didn't test it), but this kinda completes my example to make more sense out of it, where we want to fetch a single post by id and preload the comments if any.
Repo.one(from p in Post, left_join: c in assoc(p, :comments), where: p.id == ^post_id, preload: [comments: c])

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:


Add a template for Spin + nuxtjs SSG on Spin Up Hub

To help developers get started with Spin + SSGs, it would be awesome if we had Spin Up Hub content (specifically a template) for nuxtjs.

Hey @rajatjindal, can I work on this issue? because there is currently no associated pull request for this issue.

Yes pls, that would be awesome. Please go ahead 👍

Thank you @VamshiReddy02


USHIFT-915: Add wait flag when creating VMs to make sure they are restarted

Closes USHIFT-915

/lgtm


Parameter to control speed?

Hey there, really nice work on this. Very simple to set-up and use which was fantastic.
I was wondering if you plan on adding two parameters to cursor.move_to().

disable_mouse = default false: This would mean that as the mouse is traveling, moving the physical mouse would not interrupt it until it reaches its destination.
speed = default 1: An offset multiplier. Increasing it by 2 would mean twice the human speed. OR an alternative is time_to_destination (sec) in which case 0.100 would mean the cursor needs to reach its destination in 100 milliseconds.

Ah, I took the time to look at the source code and it already has duration. Blocking mouse is easy enough with another library.
Nice work again!

Hey, thanks for reaching out!
Disabling the physical mouse is a great idea, I will research and probably find a way to implement it.
For the speed of the movement, its a bit complicated. The way the movement gets done, is by small incremental movements which reflect points of the graph curvature generated.
On the SystemCursor, it is already available as a parameter.
On the WebCursor, due to ActionChains Duration not properly working as intended for whatever reason (from my personal testing, let me know if i'm completely wrong), I have fine tweaked every parameter and randomization available, giving you the best result, but also taking your ability of customizing the movement sadly (unless you dig and manually change the parameters of the curve generator to check how each one of them reacts).

Ah fast response! Sorry if I'm constantly editing this issue, I was and am in the middle of modifying and testing the code. As mentioned before I am only interested in system cursor for my use case at the moment. I looked at the source code and noticed you had set it to duration:int so I modified it to be duration:float. I do see drastic changes when I set it to be long like 10 seconds but for some reason, setting it below 1 second into milliseconds yielded no results.
What are your thoughts?

Ah fast response! Sorry if I'm constantly editing this issue, I was and am in the middle of modifying and testing the code. As mentioned before I am only interested in system cursor for my use case at the moment. I looked at the source code and noticed you had set it to duration:int so I modified it to be duration:float. I do see drastic changes when I set it to be long like 10 seconds but for some reason, setting it below 1 second into milliseconds yielded no results.
What are your thoughts?

My thoughts are that, I haven't checked and thought carefully about these details, and suspect that  pyautogui.PAUSE and that small number don't really work nice together. But without getting my hands on and testing myself, I can't give you a definitive answer and solution. Tomorrow I think will give you a response. Be free to comment as many times as you want.

Just updated the package.
Now you should experience better and more fluent movement with your preferred duration. I also added duration to the drag_and_drop method and corrected other small things.
Blocking physical mouse input is not viable as of now for many reasons, but either way with my testing you can't actually interrupt the movement, only distort it a little bit if you actually want to. The cursor will reach the destination and every point it is plotted to.
Have a nice day!

To be clear, duration is from the start of the cursor moving to its final destination right? I don't think I'm observing that behavior.


Implementing this library in Swift 3

hi,
can we implement this in swift?
I tried but could not get to load images from internet.
i added a UIView on storyboard and set its class to LCBannerView.
Then created outlet for the view as
@IBOutlet weak var lgAddBannerView: LCBannerView!
then on viewed load as below:
override func viewDidLoad() {
super.viewDidLoad()
self.lgAddBannerView.imageURLs = ["https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQUSaoTcU7EiRBKlB26__J_YhAXK5WUjffGO9lQZ5bHgJs5Boybzg",
"https://cdn.pixabay.com/photo/2016/05/04/15/52/cats-1371991_960_720.jpg", "http://image5.tuku.cn/wallpaper/Animal Wallpapers/5491_2560x1600.jpg"]
self.lgAddBannerView.currentPageIndicatorTintColor = UIColor.red
self.lgAddBannerView.pageIndicatorTintColor = UIColor.white
self.lgAddBannerView.pageDistance = 20
self.lgAddBannerView.frame = CGRect(x: 0, y:0, : width: screen width, height: 150)
}
But it dod not worked for me.
Is there any way to make it work with Swift 3?
Help would be appreciated.
Thanks

Here I Have A demo Project Which Solve your Issue in Swift
Swift 4 Xcode 9.1
Used This is A normal View and In A collectionView
Link - https://drive.google.com/open?id=0Bz8kF1Gedr7fYmRmVDNQbzFXVWs


question: why are PRs built against their original predecessor

Ditto. I see two conflicting angles here:

a PR has the most chance of getting built against its predecessor (ie the original parent revision)
the Merge pull request action would pull the commits and then merge them, so the consecutive build may produce a vastly different result (when other PRs are merged before)

The thing here is that (2) may fail even if (1) succeeded. It would be really nice to run CI on the "post merge" code, whatever it happens to be at the time. That, however, is a moving target as PRs get merged in parallel...
What is the most meaningful way forward?

We solved this in our team by requiring PR to be rebased with latest master before being merged. This way you are sure that your PR additions are tested against master version.

@teodor-pripoae, sure, both rebase and merge would work. Yet that is a manual step that people must remember (and there is no indication in the GitHub WebUI that any divergence has occurred).

:+1: for the issue.
Currently drone always checkouts refs/pull/%s/head commit, while it looks more natural to check PR as a result of the merge, e.g. refs/pull/%s/merge

closing because drone 0.4 now uses refs/pull/%s/merge per the above suggestion with the ability to change the default configuration to use refs/pull/%s/head


Add Hot Listener Support (#820)

Powered by hot-import: https://www.npmjs.com/package/hot-import

Ah, I'm in a hurry to use this PR with @binsee 's last code.
Please leave comments in issue #820 and let me know any suggestions.


Code added for Minimize the Heights II

Description
Code added for Minimize the Heights II in C++ language under LGMSOC'21.
Fixes #1633
Checklist:

[x] My code follows the style guidelines(Clean Code) of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings

@ravikr126 Kindly review my PR.


Elaborate on step 7 Device login

It may be helpful to elaborate a little on the instructions:
7 Follow the Azure Device Login link and sign into the Azure portal.
I assume this can be done from any device using a web browser? It also asks me to sing-in with a valid Microsoft work or school account. What are the reasons for this?
(admin edit: refresh metadata with latest)

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

ID: d2476abf-7ffa-848b-d279-3b584d5c7537
Version Independent ID: d2476abf-7ffa-848b-d279-3b584d5c7537
Content: Microsoft Connected Cache overview - Windows Deployment
Content Source: windows/deployment/do/waas-microsoft-connected-cache.md
Product: windows-client
Technology: itpro-updates
GitHub Login: @cmknox
Microsoft Alias: carmenf

To make it easier for you to submit feedback on articles on learn.microsoft.com, we're transitioning our feedback system from GitHub Issues to a new experience.
As part of the transition, this GitHub Issue will be moved to a private repository. We're moving Issues to another repository so we can continue working on Issues that were open at the time of the transition. When this Issue is moved, you'll no longer be able to access it.
If you want to provide additional information before this Issue is moved, please update this Issue before December 15th, 2023.
With the new experience, you no longer need to sign in to GitHub to enter and submit your feedback. Instead, you can choose directly on each article's page whether the article was helpful. Then you can then choose one or more reasons for your feedback and optionally provide additional context before you select Submit.
Here's what the new experience looks like.
Note: The new experience is being rolled out across learn.microsoft.com in phases. If you don't see the new experience on an article, please check back later.
First, select whether the article was helpful:

Then, choose at least one reason for your feedback and optionally provide additional details about your feedback:

Article was helpful
Article was unhelpful

Finally, select Submit and you're done!


Add peer info api

Motivation
Closes #4778
Note that this is in a draft state because it needs https://github.com/spacemeshos/api/pull/258 to be merged and I guess a release of the API package, before it can be merged. I plan to remove the replace directive for the api in the mod file when, the api has been released.
Changes
Adds a new streaming API endpoint to the node service to return info about connected peers.
Note this PR changes the PostProviderID field to be exported to allow for config to be easily serialised/deserialised in order to perform a deep copy.
Test Plan
Added a test, the test doesn't check whether tags are since that part would make things a bit trickier. However through manual checking I can see that tags are being assigned.
$ grpc_cli call  localhost:9092 spacemesh.v1.NodeService.PeerInfo ''
connecting to localhost:9092
peers {
  id: "12D3KooWRkZMjGNrQfRyeKQC9U58cUwAfyQMtjNsupixkBFag8AY"
  connections {
    address: "/ip4/<IP_ADDRESS>/tcp/5000"
    uptime: "29.348584085s"
    outbound: true
  }
  tags: "bootnode"
}
Rpc succeeded with OK status

DevOps Notes

[x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources)
[x] This PR does not affect public APIs
[x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.)
[x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)

bors merge


[VL] Use conf to control C2R occupied memory

What changes were proposed in this pull request?
In the current design, the Column2Row operation is completed in one go, which consumes a lot of memory and causes the program OOM. In this commit, I modified the C2R operation into multiple operations, which will greatly reduce the peak memory of the C2R operation. In addition, there should be some performance advantages from memory reuse.
How was this patch tested?
(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)

@XinShuoWang Can you update?

can you fix the UT?

@XinShuoWang can you fix the UT?

@XinShuoWang The UT fails as the default buffer size is 64MB and it's too large when task memory is small. You may can  change the threshold value for these UTs.

@XinShuoWang can you fix the UT? the bug triggered many queries failed in our test.

@XinShuoWang Would you continue to fix the issue? If not we can pickup and fix it. The bug blocked our adoption

Looks like the generator operator already limit the output rowvector size to the one we set.
The OOM isn't caused by C2R, but the R2C after parquet scan, because the struct column is too large. The way to solve OOM is to decrease the batch.
Another operator which may output large batch size is hashjoin. So maybe the PR is still useful.

So maybe the PR is still useful.

I am thinking about using the similar mechanism with the one added in https://github.com/apache/incubator-gluten/pull/6009 as a general solution. So we don't have to add such kind of pre-processors for operators one by one @FelixYBW

So maybe the PR is still useful.

I am thinking about using the similar mechanism with the one added in #6009 as a general solution. So we don't have to add such kind of pre-processors for operators one by one @FelixYBW

And the operator may need to be added in Velox to fit into Velox's task processing. We don't want to break whole-stage transformer by the operator in query plan.

#6009

It should be more efficient to break or combine batches in the next operator, instead of implement a dedicated one. Dedicated operator must have a memcpy.

ay need to be added in Velox to fit into Velox's task processing. We don't want to break whole-stage transformer by the operator in query plan.

Velox should hornor the max batch size always, or limit the batch by memory size.

ow operation is completed in one go, which consumes a lot of memory and causes the program OOM. In this commit, I modified the C2

@XinShuoWang what's your case to have large batch size? My issue can be fixed by reduce spark.gluten.sql.columnar.maxBatchSize and spark.sql.parquet.columnarReaderBatchSize

It's caused by a bug when calculating row size.

OK, it's still the generator operator's issue, I set the batch size to 16, but actually the output row number may be as high as 500.

Another issue is that to some columns, the internalrow format may have >11 memory size than a columnar format. Still investigating

Another issue is that to some columns, the internalrow format may have >11x memory size than a columnar format. Still investigating

The output should be correct. Looks it's a big advantage of columnar format.

Error still occurs at case SPARK-16995: flat mapping on Dataset containing a column created with lit/expr, should investigate.
Stack: [0x00007f9cf43da000,0x00007f9cf44db000],  sp=0x00007f9cf44d89e0,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xb04f5a]  Unsafe_GetLong+0x7a
J 7081  sun.misc.Unsafe.getLong(Ljava/lang/Object;J)J (0 bytes) @ 0x00007f9f6d53728e [0x00007f9f6d5371c0+0xce]
j  org.apache.spark.unsafe.Platform.getLong(Ljava/lang/Object;J)J+5
j  org.apache.spark.unsafe.bitset.BitSetMethods.isSet(Ljava/lang/Object;JI)Z+66
j  org.apache.spark.sql.catalyst.expressions.UnsafeRow.isNullAt(I)Z+14
j  org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificOrdering.compare(Lorg/apache/spark/sql/catalyst/InternalRow;Lorg/apache/spark/sql/catalyst/InternalRow;)I+27
j  org.apache.spark.sql.execution.GroupedIterator.fetchNextGroupIterator()Z+127
j  org.apache.spark.sql.execution.GroupedIterator.hasNext()Z+8
J 8209 C2 scala.collection.Iterator$$anon$11.hasNext()Z (35 bytes) @ 0x00007f9f6e6bf538 [0x00007f9f6e6bf340+0x1f8]
j  org.apache.spark.sql.catalyst.expressions.GeneratedClass$GeneratedIteratorForCodegenStage1.processNext()V+42
j  org.apache.spark.sql.execution.BufferedRowIterator.hasNext()Z+11
j  org.apache.spark.sql.execution.WholeStageCodegenExec$$anon$1.hasNext()Z+4
j  org.apache.spark.sql.execution.SparkPlan.$anonfun$getByteArrayRdd$1(ZILscala/collection/Iterator;)Lscala/collection/Iterator;+207
j  org.apache.spark.sql.execution.SparkPlan$$Lambda$3173.apply(Ljava/lang/Object;)Ljava/lang/Object;+12
j  org.apache.spark.rdd.RDD.$anonfun$mapPartitionsInternal$2(Lscala/Function1;Lorg/apache/spark/TaskContext;ILscala/collection/Iterator;)Lscala/collection/Iterator;+2
j  org.apache.spark.rdd.RDD.$anonfun$mapPartitionsInternal$2$adapted(Lscala/Function1;Lorg/apache/spark/TaskContext;Ljava/lang/Object;Lscala/collection/Iterator;)Lscala/collection/Iterator;+7
j  org.apache.spark.rdd.RDD$$Lambda$2870.apply(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+13
j  org.apache.spark.rdd.MapPartitionsRDD.compute(Lorg/apache/spark/Partition;Lorg/apache/spark/TaskContext;)Lscala/collection/Iterator;+27
j  org.apache.spark.rdd.RDD.computeOrReadCheckpoint(Lorg/apache/spark/Partition;Lorg/apache/spark/TaskContext;)Lscala/collection/Iterator;+24
j  org.apache.spark.rdd.RDD.iterator(Lorg/apache/spark/Partition;Lorg/apache/spark/TaskContext;)Lscala/collection/Iterator;+40
j  org.apache.spark.scheduler.ResultTask.runTask(Lorg/apache/spark/TaskContext;)Ljava/lang/Object;+201
j  org.apache.spark.TaskContext.runTaskWithListeners(Lorg/apache/spark/scheduler/Task;)Ljava/lang/Object;+2
j  org.apache.spark.scheduler.Task.run(JILorg/apache/spark/metrics/MetricsSystem;ILscala/collection/immutable/Map;Lscala/Option;)Ljava/lang/Object;+254
j  org.apache.spark.executor.Executor$TaskRunner.$anonfun$run$3(Lorg/apache/spark/executor/Executor$TaskRunner;Lscala/runtime/BooleanRef;)Ljava/lang/Object;+43
j  org.apache.spark.executor.Executor$TaskRunner$$Lambda$2820.apply()Ljava/lang/Object;+8
j  org.apache.spark.util.Utils$.tryWithSafeFinally(Lscala/Function0;Lscala/Function0;)Ljava/lang/Object;+4
j  org.apache.spark.executor.Executor$TaskRunner.run()V+457
j  java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+95
j  java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub
V  [libjvm.so+0x69fb72]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0xe32
V  [libjvm.so+0x69d183]  JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x263
V  [libjvm.so+0x69d787]  JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0x57
V  [libjvm.so+0x73de8c]  thread_entry(JavaThread*, Thread*)+0x6c
V  [libjvm.so+0xad7b0b]  JavaThread::thread_main_inner()+0xdb
V  [libjvm.so+0xad7dd9]  JavaThread::run()+0x299
V  [libjvm.so+0x9651f2]  java_start(Thread*)+0xe2
C  [libpthread.so.0+0x8609]  start_thread+0xd9

I fixed a bit. Now if the batch is small, we needn't alloate 64M memory, but the accurate memory

Error still occurs at case SPARK-16995: flat mapping on Dataset containing a column created with lit/expr, should investigate.

Is it related? I can't see


Different behavior on Android pre-L and L device

Hi, thanks for great library.
I'm having activity that have Title bar and put SmartTabLayout on fragment, so SmartTabLayout will disappear when I replace the fragment that holds SmartTabLayout. But I having different behavior on pre-L and L device. I already test it on Genymotion and my phone which is L device.

Result on L device

Result on pre-L device
The result I'm expecting is on pre-L device.
Thank you.

problem solved. Apparently I'm using wrong implementation of fragment xml tag.
Thank you.

Can you please explain how?


No connection options were found in any orm configuration files

Hi,
we built fcd and only created the .envrc configuration file. Is the ormconfig.js still needed for anything else?
$ npm start

><EMAIL_ADDRESS>start /opt/terra-fcd
> better-npm-run api-prod

running better-npm-run in /opt/terra-fcd
Executing script: api-prod

to be executed: node --stack_size=4096 --max-old-space-size=4096 -r ts-node/register/transpile-only -r tsconfig-paths/register src/server.ts
05-24 07:56 [ERROR]: No connection options were found in any orm configuration files.
Error: No connection options were found in any orm configuration files.

Thanks,
bert

yes seems ormconfig.js is still needed. Any reason why two different configuration styles are necessary?

@bert2002 We just wanted to leave things for TypeORM as it is. https://github.com/typeorm/typeorm/tree/master/src/connection/options-reader

I am not sure if I understand correctly, because it does not work with only the environment file. .envrc - as I understand you - both should work?

It does work with only the environment file for me.
export TYPEORM_CONNECTION=postgres
export TYPEORM_HOST=localhost
export TYPEORM_USERNAME=terra
export TYPEORM_PASSWORD=abcd
export TYPEORM_DATABASE=fcd
export TYPEORM_PORT=5432
export TYPEORM_SYNCHRONIZE=false
export TYPEORM_LOGGING=false
export TYPEORM_ENTITIES=src/orm/*Entity.ts
export TYPEORM_MIGRATIONS=src/orm/migration/*.ts


use com.optimaize.langdetect for lang detection

https://github.com/vespa-engine/vespa/issues/6403

Please hold merge until I've added a commit to fix the dependencies. The purpose of the enforcer is to prevent adding any dependencies that are not provided at runtime to the maven tree of external plugin developers.

@gjoranv  done

The container-dev module is only a helper pom for plugin development. When developing a searcher plugin, users should add a dependency to the container maven artifact, which includes container-dev. The exclusions are done to "hide" the apis that are not exported runtime from the osgi container, to force users to add them explicitly in their own pom. Otherwise, you could have a working build, but a runtime failure because the classes are not available.
The libraries referred to here will be available for the linguistics module inside the container, but not for code outside the bundle that contains the linguistics code.

@gjoranv  Could you please advise how to fix the failing tests ?

I think I see what the problem is. Our internal pom files generate the wrong test classpath. I will try to get it fixed tonight or tomorrow morning outside this PR.


Revised Component types (children, ref)

Based on recent discussion on #typescript. This change summary is longer than the diff. 🙂

Rename past Component type to ComponentWithChildren ParentComponent.

Motivation: Most components don't actually support children.  This causes a type error upon accidental passing of children / forces you to think about which components support children.
Also, many users on #help/#typescript have asked for how to type such a component.
This is a slight breaking change (users may need to change some instances of Component type to ParentComponent to avoid type errors) so should probably wait for Solid 1.4.

Two-parameter FlowComponent requires children and makes it easy to give a custom type for children, as in many flow control components.

New Component type does not have automatic children property (like React's preferred VoidFunctionalComponent),  offering another natural way to type props.children:
Component<{children: JSX.Element}>

New VoidComponent forces not having children prop, to make it extra clear how to type this.

ParentProps, FlowProps, and VoidProps type helpers for the props argument to ParentComponent, FlowComponent, and VoidComponent.

Sadly none of these are great when you need to parameterize by a generic type, but still good starting points for people typing simple components.

props argument in both Component and ComponentWithChildren automatically cast to readonly (shallow one level only), to avoid accidental assignment to props.foo (usually a getter) while still allowing passing mutables in props. Removed; see below.

Add Props<T> helper for this transformation.
Inspired by this React plan.

Add @LXSMNSYC's Ref<T> type so it's easy to type props.ref:
Component<{ref: Ref<Element>}>

Fixes #778.

An alternative would be to leave Component as is, and rename the new Component type to VoidComponent.  This would preserve backward compatibility and match React. But see this discussion for good arguments why (in React) VoidComponent is better than straight Component. And React 18 is changing the type of FunctionalComponent to what was VoidFunctionalComponent.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 89.281%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1205

Relevant Lines:
1288

💛  - Coveralls

This Playground link shows why this is an issue well: https://playground.solidjs.com/?hash=865026612&version=1.3.9
There are two main problems:

The children are then compiled but never used, remaining in the build output, even after optimization/minification.
It's easy to not realize that the misplaced markup you're writing won't be rendered, the TypeScript compiler doesn't make any mention of it. This is in general against the spirit of TypeScript, since TypeScript should bubble up the underlying outwards facing API details as accurately as possible, in order to increase developer productivity and deliver a smooth user experience.

Based on further discussion on #typescript, I've changed this in two ways:

Removed the shallow Readonly constraint on props
Removed Props helper as it wasn't doing anything anymore.

One motivation for this change is that it would not play well with existing explicitly typed props, for example:
function MyComponent(props: {name: string}): JSX.Element { ... }

This type is not consistent with Component<any>, so in particular would not be a valid argument to lazy, for example, as illustrated in the previous need for this commit.
Another motivation for this change is that props might not be shallow Readonly: via spread props, it's possible to add a setter:
<A {...{ set a(){} }} />

Another motivation for this change is that props might not be shallow Readonly: via spread props, it's possible to add a setter

In my opinion this is a stretch. And while obviously it isn't stoppable I wouldn't give it any consideration or motivation here. 99.999% case shallow readonly is what you want. I can't speak to other implications so if it makes sense not to type that way I'm all for it. But the setter shouldn't be a consideration.

@high1 has proposed removing ComponentWithChildren (and PropsWithChildren) types, instead encouraging people to just list children?: JSX.Element in the argument to Component. The main motivation is that this is simpler, helping learn. Does anyone else have preferences either way?

In my opinion, since children are something that not all components will need (really, the majority of them, mainly wrapper components that apply some styling or have their own local state), it makes more sense to write the names in an additive way, which would mirror the natural usage, such as ComponentWithChildren. The VoidComponent name doesn't seem as immediately obvious, it's not clear from the name what you're taking away from the regular Component type

I still think that component should be the default use case, which includes the composability of having children; like with HTML you get void elements which have no children. So I would prefer to have VoidComponents and VoidProps for this special case.

If Component implicitly adds children?: JSX.Element, then VoidComponent must be allowed to have children (similar to React.VFC), otherwise it is impossible to type components accepting non-JSX.Element children without a third Component type. So they wouldn't be comparable to void elements which have no children (i.e. children?: never). Then, it may be confusing to have Component for components that accept JSX.Element as children, and VoidComponent for components that accept nothing, or non-JSX.Element children if not already familiar with the react types.

... if not already familiar with the react types.

If you know JSX, chances are you are already familiar with the react types. And if not, we're not exactly clashing with preconceived expectations, are we?

FWIW, I know React well, but never used React with TypeScript. I started using TypeScript at roughly the same time I started using Solid. So it's all new to me, and I find React's types pretty confusing (and React seems to regret them). So I'm not convinced "same as React" is the right goal... By contrast, there's a natural notion of Component type that this PR adheres to.
But I also originally proposed adding VoidComponent (or a better name) — see "An alternative" in the PR description — before being convinced that this PR is the right way to go. So I'm not totally opposed to the idea, but I think we'd need a better argument than "same as React". (Perhaps "backwards compatibility is too important"? But it's just potential type errors, not functionality.)

@high1 has proposed removing ComponentWithChildren (and PropsWithChildren) types, instead encouraging people to just list children?: JSX.Element in the argument to Component. The main motivation is that this is simpler, helping learn. Does anyone else have preferences either way?

tbf I've never used the built-in types since I can just define my own props interface. I'm down with the Ref type though

@LXSMNSYC I suppose another option is to just deprecate Component (e.g. discourage it in the documentation). But it's unfortunate that there's no type then for "any component", which is what the existing Solid codebase means where it currently uses Component<any> (incorrectly without this PR).

@edemaine I don't think we should deprecate it. The main question is - should the Component type receive children by default, as a number of people expects, and I would say that's what the main purpose of a Component is, and if that's the case, VoidComponent type makes sense as a type that does not receive children. I don't think that there should be any assumptions which type is used more often. I also see the argument which comes from @otonashixav, that by unifying everything in one Component type which would require the user to be explicit with children declaration, and TBH, I'm starting to be more and more in favor of the latter, but I'm OK with any of these two. I don't have a very strong case against ComponentWithChildren, I just don't like the name and I feel that we would be more in line with what users are expecting by using Component and VoidComponent, favored by @atk, or be more on the edge, and simplify the typings by using one Component type which requires explicit children.

Based on more yet more discussion on #typescript with @atk and @otonashixav, I revised further to this plan:

Component<T> type is just (props: T) => JSX.Element (no implicit children).

All component types below extend this
Component<T> extends Component which is equivalent to Component<{}> (no Component<any> needed).

VoidComponent<T> further asserts that there's no children in the props type. (Not sure this is crucial but it's nice for symmetry.)
ParentComponent<T> is like our old Component, and has an optional children?: JSX.Element
FlowComponent<T, C> has required children: C. This can be useful for building components that require a single-argument callback, for example.
VoidProps, ParentProps, and FlowProps are helpers for typing just the props of such components.

I also tried to clean up some use of types in the code, and add some type exports to server code (I assume this is necessary to repeat here?). I'm not sure I found all places where these types could be used in the code, but I think it's an improvement.

Component<T> extends Component which is equivalent to Component<{}> (no Component<any> needed). [Right? Why is CI failing?]

My bad, when I said that I only quickly tested in solid's playground (not a good place to test typescript) and assumed it would work the same as {}, but that's clearly not the case with function parameters, so Component<any> is still needed if <T>(props: Component<T>) => isn't viable.
function lazy<T>(
  fn: () => Promise<{ default: Component<T> }>
): Component<T> & { preload: () => Promise<{ default: Component<T> }>

should work.

Something just to add that I've seen throughout my React/Typescript years is the need to specify the Type of children. Will something like the FlowComponent cater for a <TabManager> component which does accept optional children, as long as they are of type <Tab>?

Will something like the FlowComponent cater for a <TabManager> component which does accept optional children, as long as they are of type <Tab>?

Yes, that's exactly the intent.

Something just to add that I've seen throughout my React/Typescript years is the need to specify the Type of children. Will something like the FlowComponent cater for a <TabManager> component which does accept optional children, as long as they are of type <Tab>?

When you invoke a component using JSX (<Tab>), the return type is always JSX.Element. See https://github.com/microsoft/TypeScript/issues/21699. As such, it isn't possible to narrow the components allowed as children.
FlowComponent is used where the children can be something other than JSX.Element, for instance <For> and <Show> which accept functions which can benefit from the explicit typing.

@edemaine @otonashixav Is VoidComponent needed at all, then? All components would be void by default - and that seems to deprecate VoidComponent, doesn't it? I see no reason to have it as a separate type.

Is VoidComponent needed at all, then? All components would be void by default - and that seems to deprecate VoidComponent, doesn't it? I see no reason to have it as a separate type.

While you cannot call either directly with children, the former is still allowed to assigned to a type that may accept children, whereas the former cannot since it never accepts children.
let MyComponent!: Component
let MyVoidComponent!: VoidComponent

let A: ParentComponent = MyComponent;
let B: ParentComponent = MyVoidComponent;
/*  ^ Type 'VoidComponent<{}>' is not assignable to type 'ParentComponent<{}>'.
  Types of parameters 'props' and 'props' are incompatible.
    Type '{ children?: Element; }' is not assignable to type '{ children?: undefined; }'.
      Types of property 'children' are incompatible.
        Type 'Element' is not assignable to type 'undefined'.
          Type 'null' is not assignable to type 'undefined'.(2322) */

Practically, this affects functions which accept a component e.g.: https://playground.solidjs.com/?hash=-853165744&version=1.3.13

@otonashixav I've looked at the playground, and it seems weird that the Dynamic accepts children property, when a plain component is referenced. Isn't the problem maybe that Dynamic uses current definitions which have implicit children?

That's probably why that specific example works in solid's playground. See https://tsplay.dev/wOPxpN instead.

The children will not be silently accepted on the Component - if not explicitly defined. I don't see a lot of value in explicitly forbidding them, when they first have to be opt-in. On the other hand, maybe having a convenience type is not bad...

It was meant as a convenience type for library developers to make sure users were not confused by components that don't render children. Since types usually don't influence the bundle size of resulting pages and apps, it shouldn't be an issue to provide them.

@atk @edemaine @otonashixav My main concern here is the user viewpoint - now we have Component  which doesn't have implicit children,  VoidComponent which explicitly forbids them, ParentComponent which brings back implicit children. How should a user type his component which doesn't accept children? Should he type it with Component or a VoidComponent - and is there a real difference in the most prevalent usage case?

We need to document these types (JSDoc; especially VoidComponent and ParentComponent need to be mentioned in Component's description). They could basically build VoidComponent themselves, but using a dedicated type which reuses the pattern of Void Elements in the HTML living standard is much more obvious and simple.

Not explicitly typing children as never only means losing a type error in a single unlikely scenario. For the most common case there isn't a difference.
Users are free to choose whatever suits them. They can define the types themselves without using any of the helpers, use only Component, or use all of the helpers. The extra types are named such that it is clear they are a special subset of components with extra semantic value, so I don't see it being difficult to decide which to choose. That said, if I had to argue for their removal:

Libraries using the types force users to learn what the types do, if the names aren't self-descriptive to the person reading them
VoidComponent may get misinterpreted as a component with a void return if you are not familiar with the definition, since that's what a void function is

I see that React has deprecated VoidFunctionComponent - and while I'm OK with keeping it here, adding these additional types only to the documentation would also serve the purpose, wouldn't it? The user could just copy the definitions for these if he feels he needs them, and we would avoid adding utility types to the core - types which are not used anywhere inside the codebase itself.

As I already remarked, it's a question of DX: if we already provide the type and the documentation, we save the developers some work while at the same time helping to make their types be as sound and useful as possible.
These types don't increase our bundle size noticably and will not even appear in the resulting app bundles, so what's not to like?
I also believe the react type was deprecated, because it lacked sufficient documentation, which led to confusion they sought to clean up by doing so. We can avoid the confusion to begin with, so that shouldn't be an issue.

The reason for deprecation is because it's equivalent with the FunctionComponent. As I said, I don't mind either solution, it's just that I don't see any notable benefit from adding Types which can be easily derived from Component.

From a "compatible naming" perspective, it does bother me a bit that VoidComponent in this PR is different from React's VoidComponent (which should really have been called Component -- and soon it will be).  Given the disagreement, perhaps it's better to remove VoidComponent (easier to add than remove)?  I'm happy to go either way; I'd probably never need to use VoidComponent myself because Component (without a children prop) does the job when defining actual components.

I'm all on the side of adding only what's needed, maybe removing ParentComponent also, and having children optional in FlowComponent would be the best course?

Oops, didn't mean to open the can of worms that far. 😄
I feel like ParentComponent (which is the current Component) is the most used in practice today, so we should at least keep that one. I guess FlowComponent could be merged into it, adding a second parameter for the children type like the current FlowComponent.
On the other hand, I think ParentComponent and FlowComponent are each useful in different ways/contexts, and have very different semantic meaning too. (Whereas Component vs. VoidComponent seems like a less useful distinction.) In particular, forcing the existence of (nonoptional) children for FlowComponent seems useful for avoiding bugs.

I'm all on the side of adding only what's needed, ...

I would agree to this sentiment if we were talking about API surface – however this is about types, which are more documentation than code and in documentation, you should cover everything that is helpful to most people.

Thank you all for all your effort to get this one across the finish line.

I'm quite a bit late on this, but since SolidJS doesn't seem to follow semantic versioning, it's worth noting the change from Component to ParentComponent has broken some of my code and some from libraries I use, as Typescript no longer thinks they accept children.

Yeah TypeScript has been very difficult to keep with semantic versioning. This is partly because I don't think in TS and it takes some time for understanding the use cases in practice. Also TypeScript has been making updates that significantly improve typing story. In general these have been deemed worthwhile because of their impact and we've tried to keep them to minor versions.


bazel: show example removal of bind

This is one approach for how we could eliminate native.bind usage in order to support bzlmod in the future.

pushed almost all of them to see how CI feels. there is a difference we have to fix which is why i didn't do them all. specifically if a random ruleset references //external:foo and we bound "foo" to something it would reference ours. grpc is doing this a ton which also has to go away for bzlmod support, and is generally fixed by bzlmod since we can override the global one with whatever we want. I left all ones that mentioned being related to grpc, but theoretically some changes here could affect that without me knowing still


Libappindicator not provided on openSUSE LEAP 15

Prerequisites
Stretchly 0.17.0 currently installed. Trying to install Stretchly 0.18.0
Description
When attempting to install Stretchly 0.18.0 on openSUSE LEAP 15, I get the following response from the YAST Installer:
nothing provides libappindicator.so.1 needed by libappindicator-12.10.1+bzr20141110-lp150.3.1.noarch
[ ] do not install stretchly-0.18.0-1.x86_64

[ ] break libappindicator-12.10.1+bzr20141110-lp150.3.1.noarch by ignoring some of its dependencies

Operating system:  openSUSE LEAP 15.0
Steps to Reproduce

Download stretchly-0.18.0.x86_64.rpm
Open with "Install/Remove Software"
Go through YAST installation process as normal.

Expected behavior:
Installs normally like Stretchly 0.17.0 did.
Actual behavior:
Yast reports the following:
nothing provides libappindicator.so.1 needed by libappindicator-12.10.1+bzr20141110-lp150.3.1.noarch
[ ] do not install stretchly-0.18.0-1.x86_64

[ ] break libappindicator-12.10.1+bzr20141110-lp150.3.1.noarch by ignoring some of its dependencies

Reproduces how often:
Always.
Additional Information
I have the following libappindicator related software installed on this system:
libappindicator1  12.10.1+bzr20170215-lp150.3.1  88.7 KiB from Vendor openSUSE
libappindicator3-1 12.10.1+bzr20170215-lp150.3.1  88.7 KiB from Vendor openSUSE
The file it is complaining about is present in:   /usr/lib64/libappindicator.so.1

Hi, sorry for that. To be honest, I have no idea why it's like that. It might be problem with electron-builder, which I use to create packages, or might be something else. I did not find any issue in electron-builder related to this.
I've googled around and found https://github.com/Foundry376/Mailspring/issues/459#issuecomment-353335619 and https://github.com/jgraph/drawio-desktop/issues/51 so it seems that more electron-based apps have this problem.
Seems that it is ok to go with "break libappindicator", if you are willing to try.

OK, I will go ahead and break the dependency and see if it works well
enough. I'll let you know if it does. Worst that can happen is that I
revert to 17. Thanks for your response.
On Thu, Oct 25, 2018 at 3:35 AM Jan Hovancik<EMAIL_ADDRESS>wrote:

Hi, sorry for that. To be honest, I have no idea why it's like that. It
might be problem with electron-builder, which I use to create packages, or
might be something else. I did not find any issue in electron-builder
related to this.
I've googled around and found Foundry376/Mailspring#459 (comment)
https://github.com/Foundry376/Mailspring/issues/459#issuecomment-353335619
and jgraph/drawio-desktop#51
https://github.com/jgraph/drawio-desktop/issues/51 so it seems that
more electron-based apps have this problem.
Seems that it is ok to go with "break libappindicator", if you are willing
to try.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hovancik/stretchly/issues/315#issuecomment-433001043,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AqY9khRTOykxn8vGiFoOcu88ZQek1esYks5uoZPsgaJpZM4X5EO5
.

Oh, one more note. After I told it to break the dependency, I got this
message as well:
Error: INVALID:stretchly-0.18.0-1.x86_64 (file-59bfa0bd): Signature
verification failed [6-File is unsigned]
Header SHA1 digest: OK
MD5 digest: OK
Package is not signed!
Might want to check that out.
On Thu, Oct 25, 2018 at 3:35 AM Jan Hovancik<EMAIL_ADDRESS>wrote:

Hi, sorry for that. To be honest, I have no idea why it's like that. It might be problem with electron-builder, which I use to create packages, or might be something else. I did not find any issue in electron-builder related to this.
I've googled around and found Foundry376/Mailspring#459 (comment) and jgraph/drawio-desktop#51 so it seems that more electron-based apps have this problem.
Seems that it is ok to go with "break libappindicator", if you are willing to try.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

OK, it seems to run all right.  It installed a different earlier version of
libappindicator to resolve the dependency issue apparently.
Installing libappindicator-12.10.1+bzr20141110-lp150.3.1.noarch.rpm
(installed size 0 B)
Installing stretchly-0.18.0.x86_64.rpm (installed size 132.99 MiB)
I only had these two libs installed:  libappindicator1
12.10.1+bzr20170215-lp150.3.1 and libappindicator3-1
12.10.1+bzr20170215-lp150.3.1
The other one was available in the repository, but I don't know why it
didn't go ahead and install that one if it needed it the first time. Weird.
On Thu, Oct 25, 2018 at 3:35 AM Jan Hovancik<EMAIL_ADDRESS>wrote:

Hi, sorry for that. To be honest, I have no idea why it's like that. It
might be problem with electron-builder, which I use to create packages, or
might be something else. I did not find any issue in electron-builder
related to this.
I've googled around and found Foundry376/Mailspring#459 (comment)
https://github.com/Foundry376/Mailspring/issues/459#issuecomment-353335619
and jgraph/drawio-desktop#51
https://github.com/jgraph/drawio-desktop/issues/51 so it seems that
more electron-based apps have this problem.
Seems that it is ok to go with "break libappindicator", if you are willing
to try.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hovancik/stretchly/issues/315#issuecomment-433001043,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AqY9khRTOykxn8vGiFoOcu88ZQek1esYks5uoZPsgaJpZM4X5EO5
.

Glad it worked out in the end.
Packages are not signed, not sure if electron-builder supports that. I remember I could sign for Mac OS build but I don't have spare money to spend on some fancy certs ;]
Seems github is not signing atom as well https://github.com/atom/atom/issues/7635


Restructure project and model service

Based on #571

I tested the following work flows:

start a capella t4c session (only issue is that No session token was generated for your session. was displayed but not sure if that is the usual case (never actually paid attention to this in the local dev environment)
created a test mode, linked it to a git lab instance (with integration), and loaded the diagram cache
create a project with a description, added one user during the creation, and added one empty (uninitialised) model during this step


⚠ Bofrost.de has degraded performance

In 18ca25a, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1577 ms

Resolved: Bofrost.de performance has improved in 86844ec.


Web Mock Tests

Utilize mocking for unit tests with the web module. We should be making no external calls when creating tests.

Closing after exploring a bit. This could be reopened in the future but the nature of how beautiful soup and requests are used now it doesn't work well for mocks.


Web browser

First of all, I really like your project.
I appreciate your hard work you did.
A wonderful improvement that I miss would be a regular web browser.
Describe the solution you'd like
Opening several websites tabs.
Bookmark system.
Cards at the top of the program.
Describe alternatives you've considered
All connected services use a web browser.
Allowing free browsing on the next service would do the trick.
Additional context
Similar software with that feature: https://tryshift.com/

We don't want Ferdi to become a normal web browser so we won't be implementing features a normal web browser might have. If you want to have a tab that has an experience more similar to a normal browser, you can use the "Custom Website" service and activate the navigation bar in Ferdi's settings.


Customising the HttpClient does not seem to have any effect

Description
When I try to add my own HttpClient in the Android MainActivity class, the calls to the source do not seem to carry the custom Http Headers that I added.
Steps to Reproduce
In MainActivity.cs
internal static HttpClient? httpClient { get; private set; }

protected async override void OnCreate(Bundle? savedInstanceState)
{
    base.OnCreate(savedInstanceState);
    var ffConfig = new FFImageLoading.Config.Configuration
    {
        HttpClient = await GetAuthHttpClient(),
        HttpHeadersTimeout = 300
    };
    var imageService = ServiceHelper.GetService<IImageService>();
    imageService.Initialize(ffConfig);
    //FFImageLoading.ImageService.Instance.Initialize(ffConfig);
    HttpClient client = await GetAuthHttpClient();
}
private async Task<HttpClient> GetAuthHttpClient()
{
    var settingsService = new APIService();
    var deviceToken = await settingsService.GetDeviceToken();
    httpClient = new HttpClient(new AuthenticatedHttpImageClientHandler(settingsService.GetDeviceToken));
    httpClient.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue(deviceToken);
    return httpClient;
}

Expected Behavior
The calls to the Source as specified in the ffImage should carry the http header but they dont.
Using the Single instance or the ImageService, both dont seem to send the custom HttpHeaders to my API call.
Actual Behavior

Basic Information

Version with issue: 1.1.6

Platform: Maui,Android

Screenshots
Reproduction Link / Code

Fixed in the latest version 1.1.8 https://www.nuget.org/packages/FFImageLoading.Maui/1.1.8
Thanks for reporting. Please help to verify the fix when you are free.

Fixed in the latest version 1.1.8 https://www.nuget.org/packages/FFImageLoading.Maui/1.1.8
Thanks for reporting. Please help to verify the fix when you are free.

I can confirm that this is now working.
Thank you so much for fixing it so promptly.


this report does not support webdriverio v5

webderiver.io is supporting cucumber framework in v5 now but this report does not seem to work with attach screenshot or text in before/after hooks

Please read the docs


[Feat]: List next or develop as tagged version in selectable

Is your feature request related to a problem? Please describe.
It would be awesome to be able to select the latest docs from the select

I want to try the latest release (2.0.0-rc7) but checking the new config or docs is a bit hard...
Describe the solution you'd like
Add next / develop as a select option, like many other projecs do

Describe alternatives you've considered
No response
Additional context
No response

v2.0.0 is now released and docs have been updated.


fixed clicks for single choice tree

Padding bettween checkbox & text dissapeared

@AlbinaMakisheva @mirekys May I please ask for another modification, where the TreeSelect will accept also a prop, that is a function and that will enable to make filtering of all options based on some condition, similar like it is in https://github.com/oarepo/oarepo-vocabularies/blob/bfbd29028d77c623774d06f036897477c2c4a424/oarepo_vocabularies/ui/theme/assets/semantic-ui/js/oarepo_vocabularies_ui/form/components/LocalVocabularySelectField/LocalVocabularySelectField.jsx#L102 filterFunction prop. The reason is that some fields, for example, resource type, we need to have different options depending if they are located in the main form, or in the relatedItems field. Thanks!

@AlbinaMakisheva @mirekys May I please ask for another modification, where the TreeSelect will accept also a prop, that is a function and that will enable to make filtering of all options based on some condition, similar like it is in
https://github.com/oarepo/oarepo-vocabularies/blob/bfbd29028d77c623774d06f036897477c2c4a424/oarepo_vocabularies/ui/theme/assets/semantic-ui/js/oarepo_vocabularies_ui/form/components/LocalVocabularySelectField/LocalVocabularySelectField.jsx#L102
filterFunction prop. The reason is that some fields, for example, resource type, we need to have different options depending if they are located in the main form, or in the relatedItems field. Thanks!

Yes this filterFunction prop is needed also for restoration repo for pre-filtering of options based on object's primary material. E.g. if object is from "sklo", then all the restorationMethods also needs to be prefiltered by that. Isn't the functionality already somewhere there @AlbinaMakisheva ?

Clicking on parent selects nothing: https://github.com/oarepo/oarepo-vocabularies/assets/646743/65e90bde-9e19-4450-b68c-44b20a03f215
Additionally theres no pointer cursor indicating that item is clickable, theres no hover state

Still no pointer cursor to indicate clickability, i get I cursor when hovering over an item

Currently selected value not reflected by modal (it should be highlighted as selected) https://github.com/oarepo/oarepo-vocabularies/assets/646743/85ef41e4-bc97-4f4e-9d7a-c46338915e74

In single-value mode, currently selected value is still not shown/distinguished from others when modal opens


master

Update gradle and lib version.

I squashed the commits, the I don't have rights to resolve merge conflicts here...

Hi @IgorGanapolsky , firstly you create a new branch with the name of the issue/feature etc. My suggestion is to resolve your conflicts locally and then push your branch.
But I want to inform you that TravisCI cannot find the 23.0.1 tools so the tests will fail.