Implement stateless function support

This implements stateless function support. A provisional stateless function TCK is included since to my knowledge, the cloudstate tck does not cover stateless functions yet. By default, executing ./extended_tck.sh will build a docker container, install cloudstate python-support into the docker container (including protobuf build), and run the original tck as well as the extended tck against said container.
Some changes to the build have been made to simplify installation, incorporating protobuf compilation into setup.py.

Hi @GratefulTony,
Thank you for your contribution! We really value the time you've taken to put this together.
Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:
https://www.lightbend.com/contribute/cla

Hi @GratefulTony,
Thank you for your contribution! We really value the time you've taken to put this together.
Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:
https://www.lightbend.com/contribute/cla

@GratefulTony thanks a lot for this contribution :)
While reviewing it, we also like to get stateless function support in general in line with the current reference implementation. There are some open questions he project is on for this.

Thanks for the review! I will look into making the requested changes this weekend. Also open to updating things in the future if nomenclature/best practices around stateless functions change.

Current plan is to rename stateless functions to Actions. They can certainly be renamed here later.

@pvlugter Is that the only change you intend to make?

At least one pull request committer is not linked to a user. See https://help.github.com/en/articles/why-are-my-commits-linked-to-the-wrong-user#commits-are-not-linked-to-any-user

At least one pull request committer is not linked to a user. See https://help.github.com/en/articles/why-are-my-commits-linked-to-the-wrong-user#commits-are-not-linked-to-any-user

still have some work to do implementing the requested changes. Will get to it in the coming days. Moving to running unit tests for stateless functions. (can look into renaming to actions) fixed up the tck script to use unique container names, and made the networking more platform agnostic.

At least one pull request committer is not linked to a user. See https://help.github.com/en/articles/why-are-my-commits-linked-to-the-wrong-user#commits-are-not-linked-to-any-user

At least one pull request committer is not linked to a user. See https://help.github.com/en/articles/why-are-my-commits-linked-to-the-wrong-user#commits-are-not-linked-to-any-user

Hi @chomnoue,
Thank you for your contribution! We really value the time you've taken to put this together.
Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:
https://www.lightbend.com/contribute/cla

Hi @chomnoue,
Thank you for your contribution! We really value the time you've taken to put this together.
Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:
https://www.lightbend.com/contribute/cla

Hi @chomnoue,
Thank you for your contribution! We really value the time you've taken to put this together.
Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:
https://www.lightbend.com/contribute/cla

@GratefulTony I see now the typesafe-cla-validator mentioning "chomnoue" for commits you probably pushed. Also there are quite few unrelated commits I think visible in this branch. Could you rebase your changes/additions somehow cleanly to your branch? Regarding the CLA Validator if I remember correctly you got approved its check with your initial commit for this PR, or is this still pending? Thanks :)

Hi @chomnoue,
Thank you for your contribution! We really value the time you've taken to put this together.
Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:
https://www.lightbend.com/contribute/cla

@pvlugter can you imagine why the CLA Validator mentions chomnoue now in this PR? Thanks.

Hi @chomnoue,
Thank you for your contribution! We really value the time you've taken to put this together.
Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:
https://www.lightbend.com/contribute/cla

@GratefulTony I see now the typesafe-cla-validator mentioning "chomnoue" for commits you probably pushed. Also there are quite few unrelated commits I think visible in this branch. Could you rebase your changes/additions somehow cleanly to your branch? Regarding the CLA Validator if I remember correctly you got approved its check with your initial commit for this PR, or is this still pending? Thanks :)

Yeah. I got approved, but had to go back and rewrite some of my earlier commits since I had my email misconfigured in git config on a new dev machine. I'm in the middle of a rebase to try to clean things up. this is my best guess as to why chomnoue is getting flagged.

We discussed the renaming from stateful function to action today at the contributors call and we agreed to: "Python stateless function support can rename to action now or after merge".
So I think after the cleanup and review of this PR we should merge this PR and get the name changed afterwards.

I think I have a good rebase now, CLA validator appears to be happy for now. still a tiny bit of work to do to get the docker/proxy-aware unit tests working.

I think I have a good rebase now, CLA validator appears to be happy for now. still a tiny bit of work to do to get the docker/proxy-aware unit tests working.

Thanks @GratefulTony sounds great. With about 4k lines removed and 1.5k added, can you perhaps summarize shortly what has added, changed (and removed also) in this PR or what you were looking for. I assume that the PRs title "Implement stateless function support" describes not all changes for what I can see.

I think I have a good rebase now, CLA validator appears to be happy for now. still a tiny bit of work to do to get the docker/proxy-aware unit tests working.

Thanks @GratefulTony sounds great. With about 4k lines removed and 1.5k added, can you please summarize shortly what has added, changed (and removed also) in this PR or what you were looking for. I assume that the PRs title "Implement stateless function support" describes not all changes for what I can see.

When I reviewed this PR I saw that it included many formatting and style improvements. But it would be interesting to hear that summary.

yes. the other changes are mainly to do with improving the build. I changed the build to automatically pull and compile the .proto files instead of including copies of the files in the repo, I pull the proto files from scm during the setuptools build. I also removed the generated files from the git repo, as they are now generated when the user pip installs. This is probably the source of most of the removed code. Obviously, the tck script has been changed to run the extended tests. I also ran black, flake8 and isort on the library as there were some minor formatting and style issues.
I also refactored the test script packaging to be able to include the shoppingcart and functiondemo code in unit tests, and implemented the some tests (more for functiondemo).
It looks like a new tck image was released last night, and now in the tck script the proxy isn't able to connect to the tck. I also still need to finally determine how to get discovery to work for the stateless functions without a persistence id. (it works fine with one)

yes. the other changes are mainly to do with improving the build. I changed the build to automatically pull and compile the .proto files, I pull the proto files from scm during the setuptools build. I also removed the generated files from the git repo, as they are now generated when the user pip installs. This is the source of most of the removed code. Obviously, the tck script has been changed to run the extended tests. I also ran black, flake8 and isort on the library as there were some minor formatting and style issues.
I also refactored the test script packaging to be able to include the shoppingcart and functiondemo code in unit tests, and implemented some tests (more for functiondemo).

@GratefulTony thanks for the summary.

It looks like a new tck image was released last night, and now in the tck script the proxy isn't able to connect to the tck. I also still need to finally determine how to get discovery to work for the stateless functions without a persistence id. (it works fine with one)

yeah, it failed for all other language support libraries:
https://observablehq.com/@marcellanz/cloudstate-go-tck-verification
regarding discovery, if the protocol does not define this, it should be noted here on the Draft Spec PR:
https://github.com/cloudstateio/cloudstate/pull/119
and we should discuss why no persistence ID should be used I think.

Without a doubt we need to formalize at Spec. But I believe that stateless functions do not need a persistence id since nothing persists

persistence

CRDTs are also not persisted (yet). And the persistence_id is defined as:
    // The ID to namespace state by. How this is used depends on the type of entity, for example,
    // event sourced entities will prefix this to the persistence id.
    string persistence_id = 3;

But I only mentioned the Spec, because its the container to collect such feedback I think.

Yes. I think that in the case of CRDT's there is an expectation that they will be persistent one day. I don't see that happening to the Stateless case, I don't see much sense. But I asked everyone's opinion at Spec

regarding why the persistence_id was included in the implementation: as I had said, it appears that the service discovery mechanism is using an EntitySpec protocol buffer to participate in service description. The EntitySpec has the entities field (of type Entity) which requires the persistence_id field. In my implementation, I do not use the persistence_id to do service resolution, so as far as I can tell, it is a kind of baggage, but a field which I think needs to be populated on the Entity protocol buffer. I don't see any corresponding analogue for stateless functions in the protobuf specs. I wasn't sure if this was used in any way by cloudstate internals, but I set it to the service name to relate the user function to the namespace concept. In my implementation, I believe it does not actually need to be set to non-default, so I could potentially set this field in Entity protocol buffers to empty string, but this didn't seem to be the right thing to do. As far as I can tell, service discovery can't occur if I don't fill in one of these Entity objects for a stateless function definition.

It seems the proxy doesn't care ATM:
https://github.com/cloudstateio/cloudstate/blob/v0.5.1/proxy/core/src/main/scala/io/cloudstate/proxy/function/StatelessFunctionSupportFactory.scala#L33-L41
just logs the entity.persistenceId  and uses solely the entity.serviceName to instantiate the StatelessFunctionSupport. The spec clearly should state its requirements regarding the stateless function support.

There is clearly a gap between what was defined in the protobuf and what the proxy implements. But I think that to continue with this PR we can maintain the approach used by @GratefulTony  just referring to the persistence id in the discovery stage

@sleipnir I Agree.

@sean-walsh would you like to have an eye on this community PR for the Python support? Thanks.

So it seems we're ok with the "ride along" persistence_id and renaming to Actions later. I think other than that, all of the requested changes have been implemented. Let me know if there are other changes requested, otherwise, pr should be about ready to merge.

Thank you @GratefulTony I will take a look later

I tested the PR locally (on a Mac) and ./extended_tck.sh with cloudstate-function` failed as follows:
Run starting. Expected test count is: 5
ConfiguredCloudStateTCK:
Cloudstate TCK
- must verify that the user function process responds
- must verify that an initial GetShoppingCart request succeeds
- must verify that items can be added to, and removed from, a shopping cart
- must verify that the backend supports the ServerReflection API
- must verify that the HTTP API of ShoppingCart protocol works
[ERROR] [09/23/2020 10:02:03.825] [CloudStateTCK-akka.actor.default-dispatcher-7] [akka://CloudStateTCK/system/pool-master] connection pool for Pool(shared->http://cloudstate-proxy-3hii9jedwx:9000) has shut down unexpectedly
java.lang.IllegalStateException: Pool shutdown unexpectedly
        at akka.http.impl.engine.client.PoolInterface$Logic.postStop(PoolInterface.scala:214)
        at akka.stream.impl.fusing.GraphInterpreter.finalizeStage(GraphInterpreter.scala:599)
        at akka.stream.impl.fusing.GraphInterpreter.finish(GraphInterpreter.scala:324)
        at akka.stream.impl.fusing.GraphInterpreterShell.tryAbort(ActorGraphInterpreter.scala:664)
        at akka.stream.impl.fusing.ActorGraphInterpreter.$anonfun$postStop$1(ActorGraphInterpreter.scala:802)
        at akka.stream.impl.fusing.ActorGraphInterpreter.$anonfun$postStop$1$adapted(ActorGraphInterpreter.scala:802)
        at scala.collection.immutable.Set$Set2.foreach(Set.scala:201)
        at akka.stream.impl.fusing.ActorGraphInterpreter.postStop(ActorGraphInterpreter.scala:802)
        at akka.actor.Actor.aroundPostStop(Actor.scala:554)
        at akka.actor.Actor.aroundPostStop$(Actor.scala:554)
        at akka.stream.impl.fusing.ActorGraphInterpreter.aroundPostStop(ActorGraphInterpreter.scala:691)
        at akka.actor.dungeon.FaultHandling.finishTerminate(FaultHandling.scala:240)
        at akka.actor.dungeon.FaultHandling.terminate(FaultHandling.scala:197)
        at akka.actor.dungeon.FaultHandling.terminate$(FaultHandling.scala:167)
        at akka.actor.ActorCell.terminate(ActorCell.scala:410)
        at akka.actor.ActorCell.invokeAll$1(ActorCell.scala:519)
        at akka.actor.ActorCell.systemInvoke(ActorCell.scala:535)
        at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:295)
        at akka.dispatch.Mailbox.run(Mailbox.scala:230)
        at akka.dispatch.Mailbox.exec(Mailbox.scala:243)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)

Run completed in 8 seconds, 486 milliseconds.
Total number of tests run: 5
Suites: completed 1, aborted 0
Tests: succeeded 5, failed 0, canceled 0, ignored 0, pending 0
All tests passed.
Removing docker containers
cloudstate-proxy-3hII9jEdWX
cloudstate-function-3hII9jEdWX
69f64237cde10d2dd02b37536a3ca0c0489eee12bdf1ab9e6c31df2c35d94925
5406ffa2baeb6804187a996ce37bde0e6b5c306563a6e0669cc17c8dd2059c53
2020-09-23 10:02:26,143 - test_shoppingcart.py - INFO: host: cloudstate-proxy-3hII9jEdWX
2020-09-23 10:02:26,143 - test_shoppingcart.py - INFO: port: 9000
2020-09-23 10:02:26,143 - test_shoppingcart.py - INFO: connecting on cloudstate-proxy-3hII9jEdWX:9000
2020-09-23 10:02:26,423 - test_shoppingcart.py - INFO: resp:
2020-09-23 10:02:26,476 - test_shoppingcart.py - INFO: resp: items {
  product_id: "0"
  name: "beer"
  quantity: 24
}

2020-09-23 10:02:26,477 - test_functiondemo.py - INFO: connecting on cloudstate-proxy-3hII9jEdWX:9000
2020-09-23 10:02:26,477 - test_functiondemo.py - INFO: channel established.
2020-09-23 10:02:26,527 - test_functiondemo.py - INFO: resp: bar: "foo"

2020-09-23 10:02:26,542 - test_functiondemo.py - INFO: resp: bar: "foo!"

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/local/lib/python3.8/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/local/lib/python3.8/site-packages/cloudstate/test/tck_services.py", line 33, in <module>
    evaluate_functiondemo_server(server, server_port)
  File "/usr/local/lib/python3.8/site-packages/cloudstate/test/functiondemo/test_functiondemo.py", line 44, in evaluate_functiondemo_server
    stub2.ReverseString2(request_boom2)
  File "/usr/local/lib/python3.8/site-packages/_pytest/python_api.py", line 744, in __exit__
    fail(self.message)
  File "/usr/local/lib/python3.8/site-packages/_pytest/outcomes.py", line 156, in fail
    raise Failed(msg=msg, pytrace=pytrace)
Failed: DID NOT RAISE <class 'Exception'>
cloudstate-proxy-3hII9jEdWX
cloudstate-function-3hII9jEdWX
tck-network-3hII9jEdWX

thanks @marcellanz The changes to the docker container should be easy. Regarding the TCK, I noticed things weren't working as well when a new version of the TCK container was pushed a few days ago. I will try to get to the bottom of what's going on with the TCK.

thanks @marcellanz The changes to the script should be easy. Regarding the TCK, I noticed things weren't working as well when a new version of the TCK container was pushed a few days ago. I will try to get to the bottom of what's going on with the TCK.

@GratefulTony It would be interesting from where the Pool shutdown unexpectedly is coming; I've seen this error on other occasions with other Support Libraries (might be a proxy issue). But as the shopping cart tests succeeded:
Tests: succeeded 5, failed 0, canceled 0, ignored 0, pending 0
I made my comment more about this one:
Failed: DID NOT RAISE <class 'Exception'>
which seems to come from the new stateless function tests. Thanks for looking into :)

@marcellanz I see. Thanks for pointing that out. Interesting that you don't appear to be using the latest tck image, which iirc, runs 23 tests? I may also need to check that the tck script pulls the latest image version...

@marcellanz I see. Thanks for pointing that out. Interesting that you don't appear to be using the latest tck image, which iirc, runs 23 tests? I may also need to check that the tck script pulls the latest image version...

great point! I think I have still an old image on my box.

I think we can only consider the oldest tck to validate this PR.

I think we can only consider the oldest tck to validate this PR.

@sleipnir Agree. The last few days too much has changed on cloudstate master. We could use cloudstateio/cloudstate-tck:0.5.1.
@GratefulTony the "old" tck script had also the options to specify alternative docker images used:
https://github.com/cloudstateio/python-support/blob/v0.1.1/tck/run_tck.sh#L12

Requested changes made to TCK shell script. Also pinned TCK image version as suggested. TCK passes for me on mac and linux.
I tested on two separate macs with clean clones of the repo and wasn't able to reproduce the failed test case.

I ran on my linux machine and saw no problems.
I approve this PR

@GratefulTony thanks again for your contribution and efforts on this PR :)

Thanks everyone. Excited for the future of this project.

🎉 👍


Update: Rename my-directory and lower font size

Bring font size down to match font size from reports list
Remove > symbol from sidebar until foldering is supported
Rename My Directory to My Data based on feedback from navi users

Do we want to eventually remove all references to directory to have routes named data instead?
data.my-data?


How soon will SOCKS proxies be supported?

Description
SOCKS proxy support recently came out for the Mac version of Proxyman, and it's been great. I wrote up a bunch of documentation for our testers to use it, and that's when I found out that the Windows version of Proxyman doesn't support it. Is there any timeline for bringing SOCKS proxy support to this version?

Hi @roland-ryan-rm We have SOCKS for External Proxy and normal SOCKS Proxy Server. Which one you're referring ? 🤔

Thanks. I will support this feature soon 👍


invalidate() & refresh() throws if used in dispose method of a widget that does not watch that provider.

When using invalidate() or refresh() on a Provider in a StatefullWidget in which its WidgetRef does not register a listener (watch that provider) will throws Looking up a deactivated widget's ancestor is unsafe.
Even if you use a Consumer will still throws. The only way to get this to work if the same WidgetRef instance used to watch a provider calls invalidate only then things work as expected.
Note:
I can not count on autoDispose as at some point during  one  flow the provider will not be watched but at one page, but must be invalidate when the user exit that particular flow completely.
To Reproduce
import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';

final numberProvider = StateNotifierProvider<NumberNotifier, int>((ref) {
  ref.onDispose(() {
    print('disposing');
  });

  return NumberNotifier();
});

class NumberNotifier extends StateNotifier<int> {
  NumberNotifier() : super(0);

  void update() {
    state = state + 1;
  }
}

void main() {
  runApp(const ProviderScope(child: MyApp()));
}

class MyApp extends ConsumerWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context, ref) {
    return const MaterialApp(
      home: MyHomePage(),
    );
  }
}

class MyHomePage extends ConsumerStatefulWidget {
  const MyHomePage({super.key});

  @override
  ConsumerState<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends ConsumerState<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(),
      body: Center(
        child: Text(
          ref.watch(numberProvider).toString(),
          style: Theme.of(context).textTheme.headlineMedium,
        ),
      ),
      floatingActionButton: Row(
        mainAxisAlignment: MainAxisAlignment.end,
        children: [
          FloatingActionButton(
            heroTag: 'Increment',
            onPressed: ref.read(numberProvider.notifier).update,
            child: const Icon(Icons.add),
          ),
          const SizedBox(width: 10),
          FloatingActionButton(
            heroTag: 'go',
            onPressed: () {
              Navigator.of(context)
                  .push(MaterialPageRoute(builder: (_) => const NextPage()));
            },
            child: const Icon(Icons.arrow_forward_ios_outlined),
          ),
        ],
      ),
    );
  }
}

class NextPage extends ConsumerStatefulWidget {
  const NextPage({super.key});

  @override
  ConsumerState<NextPage> createState() => _NextPageState();
}

class _NextPageState extends ConsumerState<NextPage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(),
      body: const Body(),
      floatingActionButton: const BackFab(),
    );
  }
}

class BackFab extends ConsumerStatefulWidget {
  const BackFab({
    super.key,
  });

  @override
  ConsumerState<BackFab> createState() => _BackFabState();
}

class _BackFabState extends ConsumerState<BackFab> {
  // @override
  // void dispose() {
  //   ref.invalidate(numberProvider); // <------------- here
  //   super.dispose();
  // }

  @override
  Widget build(BuildContext context) {
    // ref.watch(numberProvider); // <------------- here
    return FloatingActionButton(
      heroTag: 'back',
      onPressed: () {
        Navigator.of(context).pop();
      },
      child: const Icon(Icons.arrow_back_ios),
    );
  }
}

class Body extends ConsumerStatefulWidget {
  const Body({
    super.key,
  });

  @override
  ConsumerState<Body> createState() => _BodyState();
}

class _BodyState extends ConsumerState<Body> {
  // @override
  // void dispose() {
  //   ref.invalidate(
  //       numberProvider); // <------------- working fine here as there is a listener.
  //   super.dispose();
  // }

  @override
  Widget build(BuildContext context) {
    return Center(
      child: Text(
        '${ref.watch(numberProvider)}', // <-------------  listener.
      ),
    );

    /*
     return Center(
      child: Consumer(builder: (context, r, _) {
        return Text(
          '${r.watch(numberProvider)}', // <-------------  this will also throws. you must the widgetRef
        );
      }),

    */
  }
}

Expected behavior
Should be able to call invalidate or refresh whether there is a listener or not.

Using ref inside onDispose is generally not allowed. Especially ref.invalidate/refresh.
The fact that sometimes you do not get an error is the bug here. It should never work.
I'll make separate issues to:

investigate why sometimes there's no error
improve the error message
document why this is not allowed
add a warning if ref is used inside State.dispose.

@rrousselGit so how can I dispose a provider if I cant use ref in dispose?

@rrousselGit you mean I should invalidate the provider in the onWillPop maybe?
The problem is i saw a lot of issue about this call back not been triggered when the user press the device back button.

onWillPop could be a good place.
But honestly you probably should be using autoDispose

You may also want to do it next to your pop()

@rrousselGit I love autoDispose but the problem is the I have a form of like 6 pages and the user can go forward and backward as he pleased while I should maintain the data he provided.
The only way to use autoDispose is to add a consumer at the first form with nothing but SizedBox.shrink to keep a listener registered during the whole form thing. But I find weird to do this as it looks like a hack.

Not sure why a SizedBox.shrink is necessary here.
Just ref.watch your provider inside a widget that's mounted during the entire form flow.

@rrousselGit silly me, I thought the tree would be rebuilt, but that's not the case if the tree was not showing on the screen.
Thanks for the help.

I never thought of this. it is actually very neat!.  thanks again.


add language at optional configurations

I want to use in Japanese because I'm Japanese.
So I added language option in configuration.
Please check it.

@wataru420 thank you for your PR! I will review this change later when I arrive at work.

@wataru420 looks good! I'll run a regression test later on this pull request and if I like the change I'll make a release! I'll notify you when it's released.

@jvarness Thank you in advance!

@wataru420 I think I might actually enhance the code to include your changes as well as add a command for the user to specify the locale.

@jvarness Thanks to merged it. I was also thinking about that, but I think there is no reason to changing the language in the middle. How do you think?

I thought about it some more, and I think it's probably fine to leave it the way that it is now.

@wataru420 not sure if you saw but this has been released with 0.1.3.
Thank you for your contribution!

Thank you! :smile:


Fails silently if given directory path doesn't exist

When using a serverless.yml like:

plugins:
  - serverless-stack-output

custom:
  output:
    file: .serverless-outputs/stackOutput.json

Then if the given directory .serverless-outputs does not exists, it fails silently. I would expect any given folder that doesn't exist to be created, so we don't need to have a .gitkeep file in our repo.

I believe this repo has been abandoned (last commit was in 2017). There is a fork at @anttiviljami/serverless-stack-output that you might want to look at.


Fix issue 17488: Add trailing slash to POSIX tempDir() to match Windows behaviour

Also updated documentation to match the code.
https://issues.dlang.org/show_bug.cgi?id=17488

@rjframe: if your commit message contains "Fix issue xzy" than the Dlang-Bot will be able to catch it (i.e. the same as your title).
More infos: https://github.com/dlang-bots/dlang-bot

@wilzbach Thanks.
@CyberShadow My apologies; this is done.

Could you add a unittest which verifies that the path ends with the directory separator regardless of the platform?

@CyberShadow done.

Regarding the docs not mentioning getcwd, my fault as I rarely read the docs when submitting PRs, to see if they mention the previous behavior.  Also, I never got notified of Vlad's attempts to tell me about this, as I turned off email notifications on bugzilla and for some strange reason, never got a github notification of his comment on my commit.
This PR LGTM, looks like the last assert just needs to be fixed to use the right type.

This seems to have been stuck here for a while. Any change to get it through?

This looks good to me. I think due to recent CI changes, either the coverage needs to be improved or that check bypassed manually, though. Not sure how easy it is to improve coverage in this situation without mocking the filesystem or environment, though. @wilzbach Do we need to force-merge in situations like these?

CodeCov was never required and on master we even set it to be always green.
However, yeah the bot won't auto-merge if a CI is red, so this needs to be merged manually or rebased.

@CyberShadow @wilzbach it's rebased.

Thanks
Hmm now there's a failure on all OSX machines @ auto-tester:
****** FAIL release64 std.process
core.exception.AssertError@std/process.d(1023): unittest failure
----------------
4   test_runner                         0x0000000101495a0d _d_unittestp + 165
5   test_runner                         0x00000001005ca3f3 void std.process.__unittest_L963_C25() + 1107
6   test_runner                         0x00000001005c763c void std.process.__modtest() + 28
7   test_runner                         0x0000000100152d34 void test_runner.doTest(object.ModuleInfo*, ref core.runtime.UnitTestResult) + 76
8   test_runner                         0x0000000100152c6b core.runtime.UnitTestResult test_runner.testModules() + 259
9   test_runner                         0x0000000100152b3f core.runtime.UnitTestResult test_runner.tester() + 31
10  test_runner                         0x00000001014963e6 runModuleUnitTests + 154
11  test_runner                         0x00000001014aa378 void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() + 36
12  test_runner                         0x00000001014aa303 void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 31
13  test_runner                         0x00000001014aa271 _d_run_main + 485
14  test_runner                         0x00000001001529e3 main + 15
15  test_runner                         0x00000001001529b3 start + 51
16  ???                                 0x0000000000000001 0x0 + 1
make[1]: *** [unittest/std/process.run] Error 1
make[1]: *** Waiting for unfinished jobs....
1.470s PASS release64 std.random


Cross chain

Describe the feature request
Description of the feature request here. I suggest taiko should allow cross chain swaps across other chain, not just bridges.
Spam policy

[X] I verify that this issue is NOT SPAM and understand SPAM issues will be closed and reported to GitHub, resulting in ACCOUNT TERMINATION.

Stop spamming


Add Cross Country Trip example

Add example: Cross Country Trip.

@mbostock Please let me know if you'd like me to wait for a :+1: or something before merging PRs.
I'm not quite sure of the proper etiquette here, so currently I'm merging willy-nilly.


suite: take shorthand repo, user/repo for --suite-repo and --ceph-repo args

Signed-off-by: Sage Weil<EMAIL_ADDRESS>

This doesn't seem to work:
>>> suite.expand_short_repo_name('ceph', 'git://git.ceph.com/ceph.git')
['git:', '', 'git.ceph.com', 'ceph']
>>> suite.expand_short_repo_name('ceph', 'https://github.com/ceph/ceph')
['https:', '', 'github.com', 'ceph', 'ceph']
>>> suite.expand_short_repo_name('ceph', 'https://github.com/ceph/ceph/')
['https:', '', 'github.com', 'ceph', 'ceph', 'ceph']

It should probably have unit tests :)

works for me!  e.g.,
teuthology-suite -s rados --filter upgrade --subset 1/100 -c master -n 5 --ceph-repo ceph  --suite-repo liewegas/ceph -p 50 --suite-branch wip-backoff --dry-run

Working for me!

Why do we care about trailing slashes in particular?

@zmc Seems to me that stripping off the trailing slash is not necessarily wrong. It's sanitizing the user input.
Instead of sanitizing to https://github.com/ceph/ceph (without trailing slash), would it make sense to go all the way to (what I consider to be) canonical format, i.e. https://github.com/ceph/ceph.git ?

@liewegas I took the liberty of pushing a commit into this PR - hope that's OK!
@zmc The commit addresses the trailing slash issue you found and adds a few more unit tests.

jenkins re-test this please


Can be paging navigation.

Most Recent Idea:

Define a function to get article objects to next to older and newer the current article.

Naming is important. I have seen several instances of confusion in navigation due to misuse of words before and after.

Provide no way to render multiple articles on a single page directly/specialized:

Implement a function to assist in iterator cropping (skip and take), so that it is possible to cropping out sections of multiple articles.
Multiple article pages can be realized by preparing a method to perform keyword substitution in HTML.
However, MarkTheRipper does not recommend this method.

[x] older function.
[x] newer function.

These functions are returned the iterator for continuous direction older and newer to end of category entries.
When we need to one or more older/newer entries, try to apply with take function in #24.


feat: Server request handler

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Use the newer TravisCI container based builds

Fix the testing issues showing up in #39, which are likely due to:
https://www.traviscistatus.com/incidents/11hp8bhkrkn7

Thanks @ethanwhite !


[OneWayGriefing] Fix increaseStake() such that funds are taken from msg.sender

@thegostep should this apply to the punish function too?
Currently the punish function looks like this:
function punish(address from, uint256 currentStake, uint256 punishment, bytes memory message) public returns (uint256 cost) {
        // restrict access
        require(isCounterparty(msg.sender) || Operated.isActiveOperator(msg.sender), "only counterparty or active operator");

        // execute griefing
        cost = Griefing._grief(from, _data.staker, currentStake, punishment, message);
    }```

So if we were to change it to use `msg.sender`, it would look like this:

function punish(uint256 currentStake, uint256 punishment, bytes memory message) public returns (uint256 cost) {
// restrict access
require(isCounterparty(msg.sender) || Operated.isActiveOperator(msg.sender), "only counterparty or active operator");
    // execute griefing
    cost = Griefing._grief(msg.sender, _data.staker, currentStake, punishment, message);
}

The stronger assumption of always taking funds from msg.sender is necessary to avoid relying on approval amounts to control access to funds on the contract


Add support for newly supported languages

Spotless 5.2.0 added support for black (python) and clang-format (c, c++, c#, objective-c, protobuf, javascript, and java).  So might want to hook into those VS Code project types as well.

I've added support for the following language types: python, c, cpp, csharp, objective-c, objective-cpp
Released with 1.0.2


Guarantee order of XML rep of hashtables, or, make tests order-independent?

As discovered when implementing #1 the hash table implementation has changed on Racket HEAD. The current tests wrongly assume an order that is not guaranteed.
Should rewrite using e.g. check-match with list-no-order.

I see two ways to resolve this.

Continue to write the xexprs using the in-hash order, which is not guaranteed and in fact changes in Racket HEAD. Fix the tests to do an expected vs. actual equality test independent of the order of elements.  (My first instinct, in my comment above.)

Write the xexprs in a guaranteed order, for example (for/list ([k (in-list (sort (hash-keys ht) symbol<?))]) ..... Adjust the tests' expected output to be sorted like this.

I'm leaning against 1 and toward 2. One reason is that it's a PITA to write such an order-independent comparison for the test. Although that's just my problem, in a similar vein there's a broader problem:
In the real world people sometimes parse XML poorly. They use regular expressions. Or they might parse xexprs using match, expecting a fixed order (much like my original tests). Is that truly the correct way? No, not really. Does it actually happen? All? The? Time? Of course it does. Therefore if someone used this library for a web API, and the XML output order changed with a new version of Racket? The output would be theoretically correct, but practically broken.
So I'm leaning toward 2. As a simple example:
(flexpr->xexpr '(hasheq 'a 1 'c 3 'b 2))

Would now be guaranteed to produce:
'(Response () (a () "1") (b () "2") (c () "3"))

This would be true for old Rackets, Racket on HEAD, and any future Racket implementation of hash tables.

I have a commit, not yet pushed, to do this. Before I do, any feedback @jackfirth ?

Given that flexprs are constrained to only have symbols as keys, I think it would be less of an issue to sort by key than with generic dictionaries. I would recommend not documenting the exact sorting method used, only promising that the output is deterministic and will not change without a corresponding change in the version of this library used.

I should clarify: Sort them, rely on that in tests, document that the keys will always be in the same order unless you change the library used, don't document that the order they come in is sorted.

Thanks for the feedback!

I would recommend not documenting the exact sorting method used, only promising that the output is deterministic and will not change without a corresponding change in the version of this library used (even if different Racket versions are used).

I agree. The important point isn't the method used per se, it's that the output order won't change in the future.

I should clarify: Sort them, rely on that in tests, document that the keys will always be in the same order unless you change the library used, don't document that the order they come in is sorted.

I was pretty sure that's what you meant, but thanks for confirming.


color to infrared pixels projection have offset

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
{ D435 }

Firmware Version
(<IP_ADDRESS>)

Operating System & Version
{Win (10)

Kernel Version (Linux Only)
(e.g. 4.14.13)

Platform
PC

SDK Version
{ 2.0 }

Issue Description
const rs2_intrinsics color_intrin = color_frame.get_profile().as<rs2::video_stream_profile>().get_intrinsics();
const rs2_intrinsics ir_intrin = ir_frame.get_profile().as<rs2::video_stream_profile>().get_intrinsics();
rs2_extrinsics color2ir_extrin = color_frame.get_profile().get_extrinsics_to(ir_frame.get_profile());
float color_face_landmark_point[4][3];
float ir_face_landmark_point[4][3];
float ir_face_landmark_pixel[4][2];
//the face landmark(four point)
float color_face_landmark_pixel[4][2]{ {faces.x, faces.y}, {faces.x, faces.y + faces.height},
    {faces.x + faces.width, faces.y},{ faces.x + faces.width, faces.y + faces.height } };
for (int j = 0; j < 4; j++) {
    rs2_deproject_pixel_to_point(color_face_landmark_point[j], &color_intrin, color_face_landmark_pixel[j], 1);
    rs2_transform_point_to_point(ir_face_landmark_point[j], &color2ir_extrin, color_face_landmark_point[j]);
    rs2_project_point_to_pixel(ir_face_landmark_pixel[j], &ir_intrin, ir_face_landmark_point[j]);
}

I am doing face detection. I use de/project to calculated the corresponding ir and depth pixel coordinate based on color pixel, the corresponding depth pixels coordinate are correct, but the corresponding ir pixels coordinate have offset. And I observed that the farther the distance, the smaller the offset.

Hi @Jiyun-Cui
We will have to look into it and come back with an answer

Hello @Jiyun-Cui,
When deprojecting pixel to 3d coordinate note that you're using a hard-coded value of 1 (meter) which is the (presumed) Z value of the specific pixel in the source frame.

rs2_deproject_pixel_to_point(color_face_landmark_point[j], &color_intrin, color_face_landmark_pixel[j], 1);

When projecting a depth pixel (which has actual Z) onto a 2D frame, the projection work as designed as the Z allows to produce to calculate the exact  [x,y,z] coordinates.
In this case the projection is between RGB frame and ir frame (two 2D sources), and since the RGBframe doesn't have depth data, you're filling the missing Z value in a function call with a "rough" estimate of where the pixel "lies" in the 3D space (1 meter), which produces the error.
If the target IR frame is from the left imager (i.e. has the same origin as depth frame), then
you may run a simple test and check the calculate error will reach minimum for pixels that actually are at  1 meter, and then start growing again.

[Realsense Customer Engineering Team Comment]
hi @Jiyun-Cui,
would like to know if ev-mp's answer works for you?
thanks.

[Realsense Customer Engineering Team Comment]
let me close this ticket here, please feel free to open new ticket if any follow question.


Add another accordion for Configuration identical as we have Script

Add another identical accordion for Configuration as we have Script, with the difference that a file can be imported and the path must be shown, see the docs here
(https://docs.reconness.com/agents/add-agent#agent-configuration)

Bug:
If I open the agent again and go to configuration section, I can see the name of the file, but not its content


'safe.directory' errors running cargo in docker on WSL host

I'm assuming these errors are somehow WSL related, but I haven't boot up my Ubuntu partition yet so technically this is an unconfirmed assumption.
When running docker-compose up --build server I get the following error. (After fixing #2.)
server_1  | [Running 'cargo run']
server_1  | error: failed to get `env_logger` as a dependency of package `server v0.1.0 (/cargo_workspace/server)`
server_1  |
server_1  | Caused by:
server_1  |   failed to initialize index git repository (in "/cargo_workspace/cargo/registry/index/github.com-1ecc6299db9ec823")
server_1  |
server_1  | Caused by:
server_1  |   config value 'safe.directory' was not found; class=Config (7); code=NotFound (-3)

safe.directory is apparently an option added in git 2.35.2 to address a CVE. It was then apparently expanded to support * as an opt-out in git 2.36.
Cargo however appears to not use the command line version git. (The docker image comes with git 2.30.2.) Instead it uses the git2 crate. I haven't tracked down what this version of git this corresponds to for this version of cargo.
Adding RUN git config --system --replace-all safe.directory '*' to Dockerfile yields a different but related error.
server_1  | [Running 'cargo run']
server_1  | error: failed to get `env_logger` as a dependency of package `server v0.1.0 (/cargo_workspace/server)`
server_1  |
server_1  | Caused by:
server_1  |   failed to initialize index git repository (in "/cargo_workspace/cargo/registry/index/github.com-1ecc6299db9ec823")
server_1  |
server_1  | Caused by:
server_1  |   repository path '/cargo_workspace/cargo/registry/index/github.com-1ecc6299db9ec823/' is not owned by current user; class=Config (7); code=Owner (-36)

I'm assuming these errors are somehow WSL related, but I haven't boot up my Ubuntu partition yet so technically this is an unconfirmed assumption.

Works on Ubuntu.


ESP get started page

Hi,
In the docs of v7 there will be sites for manufacturers and platforms.
For ESP it is here: https://docs.littlevgl.com/v7/en/html/get-started/espressif.html
It's similar to a README. A few lines about ESP, some recommended boards, how to get started, some platform-specific info, a super simple example, etc.
I'd like to ask if somebody has time and energy to write about these things.

I would love to do that but I'm pretty busy right now. Have you posted this on the forum?

No problem!

Have you posted this on the forum?
Not yet, I wanted to ask here first.

Thank you anyway! :slightly_smiling_face:


Generate better common property docs

Java: https://github.com/Azure/azure-sdk-for-java/blob/master/azure-eventgrid/src/main/java/com/microsoft/azure/eventgrid/EventGridClient.java#L76
Ruby: https://github.com/Azure/azure-sdk-for-ruby/blob/master/data/azure_event_grid/lib/2018-01-01/generated/azure_event_grid/event_grid_client.rb#L23
Node: https://github.com/Azure/azure-sdk-for-node/blob/master/lib/services/eventgrid/lib/eventGridClient.js#L183

I hope this automatically publishes; otherwise, I'll have to go do it manuall (autorest.common is a pain)

It did publish! Wheee!
https://www.nuget.org/packages/Microsoft.AutoRest.Common/2.4.47


Calkit speaker is getting disabled

Integrated twilio video calling with callkit. After answering an incoming call most of the times speaker is getting disabled in callkit, video is working fine. But, others in the room can't hear the sound from the app and can't hear sound of others in the app too. audio subcribed function not firing too.
TwilioVideo: 2.0.0-beta2'
iOS : 10.3.3
NB: I think this started occurs after using mute functionality. i'm not sure

@hasgar
Are you experiencing this issue in the CallKit sample app or in your own application? Also, can you provide a Room SID so I can research why the audio subscription callbacks are not being fired?

No..in sample app it is working fine..how can i get the room sid?

@hasgar,
After you connect to a room, you can query the sid property on the TVIRoom object.
Ryan

Could you please check details of these three room id details
RMf1cdf039ad90fc3534f0e049e3bce69a
RM8e55681b1373a1fbfa207648932d830c
RMf3bfdf51da3c7c78df450c782aab86b6

@hasgar,
Quick question, I have looked at the traffic for the above rooms and only ever see one participant in the room. Do you have examples where there is another participant in the room that is unable to hear the audio?
Ryan

RM63d26e1ebdee86f42c387163cdd2c8bf - 'identity' is the identity of the app.. in this room audio doesn't work.. but RM94015337412c6c7db94faed197565c8c in this room audio works perfect.. because when call happening in the first room i pressed mute button few times.. i think its all related to that mute function. i used the same function as quick start..and i didn't check the mute functionality in quick start..don't know quick start also have problem.. any thoughts?

@hasgar,
I will take some time today and test muting on the CallKit Quickstart app and see if I can reproduce the issue you are seeing. I will let you know if I am able to reproduce it.
Thanks!
Ryan

I just set AVAudioSession to AVAudioSessionCategoryPlayAndRecord in answering call function..now its working

@hasgar
From your previous comment, it appears that you hav this working and all is well. If you have any further issues, don't hesitate to reach out!
Ryan


ci: Improve how we handle cached vertices

./hack/make engine:dev and ./hack/make engine:test feeding data into the same journal.log resulted in spans that didn't make sense. Some spans would switch to a later group (i.e. engine:test), yet the started & completed timestamps would clearly belong to a former group (i.e. engine:dev).
When we did update the started & completed timestamps, we realised that we were overwriting previous vertices, the uncached ones, with cached timings, which also didn't make sense.
The easiest thing is to only track the first vertex, the uncached version, and ignore the cached ones. This means that once a vertex is solved in i.e. engine:dev, we don't show it again in engine:test, since it's cached and less significant timing-wise (it rounds down to 0 micros).
In order to do this better, we would need to use more than the vertex digest for the map. If we were to add the pipeline and/or the session token, then we would be able to track the first cached vertex too. Since it's not that much of a big win, it's OK to stop here for now, until we have something better than a trace to visualise a pipeline run.

@sipsma can you think of ways that this can come back and bite us? https://github.com/dagger/dagger/pull/4498/commits/6b9b2c81462be49bb28592f281d4c0315ba42760


Top level options for external/exclude/ignore

Is there any technical reason not to expose external/exclude/ignore options in Browserify constructor the same way it has been done for require? Looks a bit inconsistent with CLI.
It would be very convenient to have single "options object" that represents a bundle. E.g.
    var bundleConfig = {
            entries: 'src/index.js',
            ignore: 'jquery',
            external: ['./vendor'],
            debug: true,
            transform: [
                    ['babelify'],
                    ['exposify', { react }]
            ]
    };

and then, for example budo({ browserify: bundleConfig}) while developing and browserify(bundleConfig) in production. It's exactly my use case however I easily could imagine many others

I ended up with loose "wrapper" solution inspired by @mattbrunetti plugin workaround:
function configNorm(config, bundle) {
	if (!bundle) {
		var plugin = [configNorm.bind(null, config)];
		return Object.assign({}, config, {
			plugin: config.plugin ? plugin.concat(config.plugin) :
			                        plugin
		});
	}
	['external', 'exclude', 'ignore'].forEach(function (opt) {
		if (config[opt])
			bundle[opt](config[opt]);
	});
	return bundle;
}

and after then browserify(configNorm(bundleConfig)), budo({ browserify: configNorm(bundleConfig) }), etc
However I think it still will be cool to have this in the core. For consistency at least


Autogen nginx-omero.conf

Replace OMERO.server by OMERO.py
The generated file is used when OMERO.web is installed separately from OMERO.server
cc  @manics

Looks good to me.


Adding a detail about VbStrConv.Wide

As per email thread with support engineer and product group.
Adding a detail about VbStrConv.Wide
the conversion may use Normalization Form C even if an input character is already full-width

Ok, I'll start another PR and do it via my enlistment since it's more involved.


MetadataCleanUp may make the present versions not available

MetadataCleanup will delete the expired delta logs(json and checkpoint.parquet). But if the present version depends on these which will be cleaned up, it cannot replay to the whole commits. For example: we have delta logs from version 0 to version 10 as following: 000.json ~ 009.json, 010.json, 010.checkpoint.parquet.
When Commit 10 is operated, MetadataCleanup works. If we assume the logs before 9 (not contained) should be cleaned up, then the rest files are: 009.json, 010.json, 010.checkpoint.parquet.
In fact, Version 9 is not  available, and only Version 10 is shown by desc history.

@YannByron could you explain a bit what's the behavior you expect? Making desc history show only versions you can time travel to?

@zsxwing
Based on the above example, I expect that in order to ensure the remaining versions are available, the necessary information that should have been cleaned up can be retained. That is, do not delete 000.json ~ 007.json.
If that, desc history still show all versions. So, we can mark those versions that user expects to clean up, adjust the desc history implement so that those are not displayed.
IMO, MetadataCleanup should keep the front checkpoint file (if it exists) closest to the smallest non-deleted version and the delta-log files(json) in between.
So we should 'cleanup as much as possible' and 'guarantee available within expectations'. After all, users don't intend to clean up the Version 8 and 9 as in the above example.

IMO, MetadataCleanup should keep the front checkpoint file (if it exists) closest to the smallest non-deleted version and the delta-log files(json) in between.

Rather that keep those files, making checkpoint for the smallest non-deleted version may be the better solution, so that we don't need to adjust desc history.


[WIP] Missing values

Addresses #137

I'm not clear about is whether we are removing set_missing_positions or not? If we remove it then its not possible to do the caching for nil and Float::NAN and if we do not remove it then, how will we get rid of lazy update which makes Daru slow.

Let set_missing_positions remain for now. This will also involve keeping lazy update, but I really don't see a fast way of updating the missing values cache for now. We'll probably need to port it to C or something funky like that.

We can also do something as follows:
We will store the missing values positions in two variables, one for nil and one for Float::NAN. They will store the positions of the missing data. Whenever an update is made instead of calling set_missing_positions we will set @missing_positions_outdated = false. And whenever in the future we require operation regarding missing value we will check @missing_positions_outdated, if its false, we need not recompute the missing positions and if its true we need to recompute the missing positions and update the appropriate variables.
WDYT about this approach?

We will store the missing values positions in two variables, one for nil and one for Float::NAN.

Why do nil and Float::NAN need to be in separate variables?

Whenever an update is made instead of calling set_missing_positions we will set @missing_positions_outdated = false.

Update to what? The vector or the missing positions cache?

And whenever in the future we require operation regarding missing value we will check @missing_positions_outdated, if its false, we need not recompute the missing positions and if its true we need to recompute the missing positions and update the appropriate variables.

Works! Make sure  you reflect this everywhere in the code, though.

Why do nil and Float::NAN need to be in separate variables?

User might ask for reject_values(nil) or `reject_values(Float::NAN).

Update to what? The vector or the missing positions cache?
I meant update to vector.

I'm deprecating the functions has_missing_data? etc., so they will be working but I'm getting rid of their functionality of working with arbitrary assigned missing values like 1, 2, etc. which are other than nil, Float::NAN. In other words missing_values = [1, 2] would have no effect. This makes it easy for me to remove the lazy_update and set_missing_positions. lazy_update and set_missing_positions have to removed to see the expected speed up. Let me know if its fine. Otherwise keeping the old functionality as well as introducing new one at the same time is getting hard.

Kindly have a look. I've made some radical changes like removed some methods like exist?, missing_values=, etc. to remove the lazy_update, set_missing_positions to speed up Daru. Some common methods like has_missing_data?, only_valid has been kept though. It might cause inconvenience for the next Daru release for methods like missing_values won't be working but I insist keeping them as they will lead to better performance. Now I will carry on caching the missing positions of nil and Float::NAN.

Here are some benchmarks. The performance speed are staggering.
I ran below code for this branch and master branch:
require 'benchmark'

n = 1000
dv = Daru::Vector.new 1..100000

Benchmark.bm do |x|
  x.report { 1000.times { dv[0, 10, 20, 30] = nil } }
end

Result for current branch:
       user     system      total        real
   0.010000   0.000000   0.010000 (  0.004940)

Result for master branch:
       user     system      total        real
  36.160000   0.260000  36.420000 ( 39.420752)

Here are some benchmarks. The performance gains are staggering.

Fascinating! It's a giant leap forward. Now it looks like we can even think about replacing where with normal select :)
Bravo, @lokeshh!

Thanks @zverok.
I have been running benchmarks on implementation with caching of nil's positions and implementation with no caching of nils and surprisingly I'm getting more time with caching. I couldn't figure out whats going on. The code seems correctly. Anyway is there some gem to profile which lines in the method are taking a long time and which not?

It seems to me that its because operations such as #at, #[] are more expensive such that finding missing values in a vector is almost free, therefore caching of nil and Float::NAN is not helping.

Hmmm it's interesting to see that caching isn't really helping much. Can you try with profiling and see what's actually going on? I think you can ruby-prof for this.

I'm looking at this in more detail. Is there some gem to profile which lines in the method are taking a long time and which not?

Yeah, like @v0dro says, ruby-prof is pretty easy to use. You just do something like this:
RubyProf.start
(code you want to profile)
result = RubyProf.stop
printer = RubyProf::GraphHtmlPrinter.new(result)
printer.print(File.open('profile.html', 'w'))

And then that file would have pretty list of what've taken how many time, cross-linked to other methods it uses and stuff.

@zverok In our case, the behavior is not exactly not the same, so I guess I will go with writing different specs. Right?

@lokeshh Yep, while extracting the same behaviors into shared example groups.

@lokeshh Yep, while extracting the same behaviors into shared example specs and then using include_context?
@zverok Do you extracting the same behaviors by using include_context?

Yep.

Alright. Thanks!

The PR is complete. I will start adding documentation. @zverok I will take care of extracting the common behavior later on.
Here's the short summary:
Methods added in Daru::Vector (and category):

reject_values
include_values?
indexes
count_values
replace values

Methods added in Daru::DataFrame:

reject_values
include_values?
replace_values

Here are the benchmarks.
Methods removed in Daru::Vector:

missing_values
missing_values=
update
exists?
set_missing_positions

and other methods have been deprecated.

All done. This is ready to be merged.

Works. Something will probably break in statsample so you might need to fix it.

@v0dro. Done. Modified the Statsample to work with this PR.


GEODE-5109: Handle only IllegalStateException

* This validation should only check for IllegalStateException which is sent as the reply exception.
* Any other exception on the remote member should not stop lucene index creation in the local member.

Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[ ] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[ ] Is your initial contribution a single, squashed commit?

[ ] Does gradlew build run cleanly?

[ ] Have you written or updated unit tests to verify your changes?

[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to<EMAIL_ADDRESS>

@nabarunnag The associated ticket is closed, meanwhile this is still open and has valid requests. Should this be closed since the ticket indicates the work is done?

This was merged to develop but not closed. This was to fix a design issue with the feature implementation with the same geode ticket number. this issue was caught by test failures.


Cannot run kubefwd

When running kubefwd I get the following error
panic: No Auth Provider found for name "gcp"

goroutine 1 [running]:
github.com/txn2/kubefwd/cmd/kubefwd/services.glob..func1(0x17db920, 0xc4202ee440, 0x0, 0x2)
	/Users/cjimti/go/src/github.com/txn2/kubefwd/cmd/kubefwd/services/services.go:74 +0x1545
github.com/txn2/kubefwd/vendor/github.com/spf13/cobra.(*Command).execute(0x17db920, 0xc4202ee420, 0x2, 0x2, 0x17db920, 0xc4202ee420)
	/Users/cjimti/go/src/github.com/txn2/kubefwd/vendor/github.com/spf13/cobra/command.go:766 +0x2c1
github.com/txn2/kubefwd/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4202f2500, 0xc4202f2500, 0xc4202f2780, 0x17db920)
	/Users/cjimti/go/src/github.com/txn2/kubefwd/vendor/github.com/spf13/cobra/command.go:852 +0x30a
github.com/txn2/kubefwd/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4202f2500, 0x1, 0x1)
	/Users/cjimti/go/src/github.com/txn2/kubefwd/vendor/github.com/spf13/cobra/command.go:800 +0x2b
main.main()
	/Users/cjimti/go/src/github.com/txn2/kubefwd/cmd/kubefwd/kubefwd.go:64 +0x67

Seems to have something to do with the client lib I am using not supporting gcp. I don't have anything running on GCP at the moment so I'll have to set up a test soon and try it out.
I assume kubectl works normally for you? Any other info for me to reproduce would be appreciated. Thanks.

Yes kubectl works normally for me. I can port-forward pods individually no problem, but I can't use your utility to port-forward all the pods in a namespace.

https://github.com/txn2/kubefwd/pull/2 should fix this.

@imduffy15 thanks for the pull request! @famani-omny #2 is merged and a new version 1.3.0 should be available. I don't have any easy way to test it at the moment so any feedback would be appreciated.

Worked correctly with no issues.


Update to use latest prom-client

The latest prom-client 13.0.x does not work due to some api changes.   The new prom-client has some substantial enhancements so would be nice to be able to use.
https://github.com/siimon/prom-client/releases
Main impacting change:
metrics server has a line like res.send(register.metrics()), you
should change it to res.send(await register.metrics()).

Created a PR #65


[WFCORE-1928] OperationFailedException for when there is no value par…

…ameter in :validate-operation
https://issues.jboss.org/browse/WFCORE-1928
https://issues.jboss.org/browse/JBEAP-6846

Full integration - Windows Build 2108 outcome was FAILURE using a merge of 182a012afb59cdff297f5aedd3e63ef869a3b7b2
Summary: Tests failed: 3 (3 new), passed: 3525, ignored: 182 Build time: 01:30:27
Failed tests
org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).connectionFactoryFailover: java.lang.AssertionError: expected:<200> but was:<500>
	at org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase.queryCount(StatefulFailoverTestCase.java:317)
	at org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase.failover(StatefulFailoverTestCase.java:195)
	at org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase.connectionFactoryFailover(StatefulFailoverTestCase.java:158)
------- Stdout: -------
11:57:14,019 INFO  [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location C:\BuildAgent\work\5768cf3a0bee5b47\full\testsuite\integration\clustering\target\wildfly-SYNC-tcp-0\standalone\data\content\49\e9212156e8b31dae22707d9078f36686bd9bd7\content
11:57:14,022 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "stateful-failover.war" (runtime-name: "stateful-failover.war")
11:57:14,067 WARN  [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0012: Warning while parsing vfs:/C:/BuildAgent/work/5768cf3a0bee5b47/full/testsuite/integration/clustering/target/workdir/content/stateful-failover.war/WEB-INF/beans.xml:1 cvc-elt.1.a: Cannot find the declaration of element 'beans'.
11:57:14,068 INFO  [org.jboss.as.jpa] (MSC service thread 1-3) WFLYJPA0002: Read persistence.xml for test
11:57:14,091 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 16) WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 'stateful-failover.war#test'
11:57:14,091 INFO  [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 16) HHH000204: Processing PersistenceUnitInfo [
	name: test
	...]
11:57:14,107 INFO  [org.jboss.weld.deployer] (MSC service thread 1-6) WFLYWELD0003: Processing weld deployment stateful-failover.war
11:57:14,116 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-6) WFLYEJB0473: JNDI bindings for session bean named 'TimeoutIncrementorBean' in deployment unit 'deployment "stateful-failover.war"' are as follows:

	java:global/stateful-failover/TimeoutIncrementorBean!org.jboss.as.test.clustering.cluster.ejb.stateful.bean.Incrementor
	java:app/stateful-failover/TimeoutIncrementorBean!org.jboss.as.test.clustering.cluster.ejb.stateful.bean.Incrementor
	java:module/TimeoutIncrementorBean!org.jboss.as.test.clustering.cluster.ejb.stateful.bean.Incrementor
	java:global/stateful-failover/TimeoutIncrementorBean
	java:app/stateful-failover/TimeoutIncrementorBean
	java:module/TimeoutIncrementorBean

11:57:14,116 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-6) WFLYEJB0473: JNDI bindings for session bean named 'SimpleIncrementorBean' in deployment unit 'deployment "stateful-failover.war"' are as follows:

	java:global/stateful-failover/SimpleIncrementorBean!org.jboss.as.test.clustering.cluster.ejb.stateful.bean.Incrementor
	java:app/stateful-failover/SimpleIncrementorBean!org.jboss.as.test.clustering.cluster.ejb.stateful.bean.Incrementor
	java:module/SimpleIncrementorBean!org.jboss.as.test.clustering.cluster.ejb.stateful.bean.Incrementor
	java:global/stateful-failover/SimpleIncrementorBean
	java:app/stateful-failover/SimpleIncrementorBean
	java:module/SimpleIncrementorBean

11:57:14,117 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-6) WFLYEJB0473: JNDI bindings for session bean named 'JDBCResourceManagerConnectionFactoryIncrementorBean' in deployment unit 'deployment "stateful-failover.war"' are as follows:

	java:global/stateful-failover/JDBCResourceManagerConnectionFactoryIncrementorBean!org.jboss.as.test.clustering.cluster.ejb.stateful.bean.Incrementor
	java:app/stateful-failover/JDBCResourceManagerConnectionFactoryIncrementorBean!org.jboss.as.test.clustering.cluster.ejb.stateful.bean.Incrementor
	java:module/JDBCResourceManagerConnectionFactoryIncrementorBean!org.jboss.as.test.clustering.cluster.ejb.stateful.bean.Incrementor
	java:global/stateful-failover/JDBCResourceManagerConnectionFactoryIncrementorBean
	java:app/stateful-failover/JDBCResourceManagerConnectionFactoryIncrementorBean
	java:module/JDBCResourceManagerConnectionFactoryIncrementorBean

11:57:14,117 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-6) WFLYEJB0473: JNDI bindings for session bean named 'TimerIncrementorBean' in deployment unit 'deployment "stateful-failover.war"' are as follows:

	java:global/stateful-failover/TimerIncrementorBean!org.jboss.as.test.clustering.cluster.ejb.stateful.bean.Incrementor
	java:app/stateful-failover/TimerIncrementorBean!org.jboss.as.test.clustering.cluster.ejb.stateful.bean.Incrementor
	java:module/TimerIncrementorBean!org.jboss.as.test.clustering.cluster.ejb.stateful.bean.Incrementor
	java:global/stateful-failover/TimerIncrementorBean
	java:app/stateful-failover/TimerIncrementorBean
	java:module/TimerIncrementorBean

11:57:14,117 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-6) WFLYEJB0473: JNDI bindings for session bean named 'PersistenceIncrementorBean' in deployment unit 'deployment "stateful-failover.war"' are as follows:

org.jboss.as.test.clustering.cluster.web.DistributableTestCase(SYNC-tcp).testGracefulServeOnUndeploy: java.lang.NullPointerException: null
	at org.jboss.as.arquillian.container.ServerSetupObserver.handleAfterUndeploy(ServerSetupObserver.java:155)
	at org.jboss.as.test.clustering.NodeUtil.undeploy(NodeUtil.java:49)
	at org.jboss.as.test.clustering.cluster.ClusterAbstractTestCase.afterTestMethod(ClusterAbstractTestCase.java:101)
------- Stdout: -------
12:05:05,155 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location C:\BuildAgent\work\5768cf3a0bee5b47\full\testsuite\integration\clustering\target\wildfly-SYNC-tcp-0\standalone\data\content\40\2278acf53e32ace7377ed37c3c6de780b3f03f\content
12:05:05,157 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "distributable.war" (runtime-name: "distributable.war")
12:05:05,190 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-7) WFLYSRV0018: Deployment "deployment.distributable.war" is using a private module ("org.wildfly.security.manager:main") which may be changed or removed in future versions without notice.
12:05:05,225 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-1) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:05:05,228 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-1) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:05:05,226 INFO  [org.jboss.as.arquillian] (MSC service thread 1-5) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."distributable.war",unit=distributable.war,tests=[org.jboss.as.test.clustering.cluster.web.DistributableTestCase]]
12:05:05,227 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-8) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:05:05,230 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-8) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:05:05,236 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 19) WFLYCLINF0002: Started routing cache from web container
12:05:05,238 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 31) WFLYCLINF0002: Started distributable.war cache from web container
12:05:05,263 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 31) WFLYUT0021: Registered web context: '/distributable' for server 'default-server'
12:05:05,278 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "distributable.war" (runtime-name : "distributable.war")
12:05:05,296 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location C:\BuildAgent\work\5768cf3a0bee5b47\full\testsuite\integration\clustering\target\wildfly-SYNC-tcp-1\standalone\data\content\40\2278acf53e32ace7377ed37c3c6de780b3f03f\content
12:05:05,299 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "distributable.war" (runtime-name: "distributable.war")
12:05:05,332 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.distributable.war" is using a private module ("org.wildfly.security.manager:main") which may be changed or removed in future versions without notice.
12:05:05,375 INFO  [org.jboss.as.arquillian] (MSC service thread 1-3) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."distributable.war",unit=distributable.war,tests=[org.jboss.as.test.clustering.cluster.web.DistributableTestCase]]
12:05:05,378 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:05:05,379 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:05:05,379 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:05:05,380 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:05:05,381 INFO  [org.infinispan.CLUSTER] (remote-thread--p9-t1) ISPN000310: Starting cluster-wide rebalance for cache routing, topology CacheTopology{id=2, rebalanceId=2, currentCH=ReplicatedConsistentHash{ns = 256, owners = (1)[node-0: 256]}, pendingCH=ReplicatedConsistentHash{ns = 256, owners = (2)[node-0: 122, node-1: 134]}, unionCH=null, actualMembers=[node-0, node-1]}
12:05:05,381 INFO  [org.infinispan.CLUSTER] (remote-thread--p9-t1) [Context=routing][Scope=node-0]ISPN100002: Started local rebalance
12:05:05,396 INFO  [org.infinispan.CLUSTER] (transport-thread--p16-t19) [Context=routing][Scope=node-0]ISPN100003: Finished local rebalance
12:05:05,398 INFO  [org.infinispan.CLUSTER] (remote-thread--p9-t1) ISPN000310: Starting cluster-wide rebalance for cache distributable.war, topology CacheTopology{id=2, rebalanceId=2, currentCH=DefaultConsistentHash{ns=256, owners = (1)[node-0: 256+0]}, pendingCH=DefaultConsistentHash{ns=256, owners = (2)[node-0: 122+134, node-1: 134+122]}, unionCH=null, actualMembers=[node-0, node-1]}
12:05:05,398 INFO  [org.infinispan.CLUSTER] (remote-thread--p9-t1) [Context=distributable.war][Scope=node-0]ISPN100002: Started local rebalance
12:05:05,474 INFO  [org.infinispan.CLUSTER] (transport-thread--p16-t2) [Context=distributable.war][Scope=node-0]ISPN100003: Finished local rebalance
12:05:05,475 INFO  [org.infinispan.CLUSTER] (remote-thread--p9-t2) [Context=routing][Scope=node-1]ISPN100003: Finished local rebalance
12:05:05,476 INFO  [org.infinispan.CLUSTER] (remote-thread--p9-t2) ISPN000336: Finished cluster-wide rebalance for cache routing, topology id = 2
12:05:05,497 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 19) WFLYCLINF0002: Started routing cache from web container
12:05:05,514 INFO  [org.infinispan.CLUSTER] (remote-thread--p9-t1) [Context=distributable.war][Scope=node-1]ISPN100003: Finished local rebalance
12:05:05,515 INFO  [org.infinispan.CLUSTER] (remote-thread--p9-t1) ISPN000336: Finished cluster-wide rebalance for cache distributable.war, topology id = 2
12:05:05,520 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 27) WFLYCLINF0002: Started distributable.war cache from web container
12:05:05,536 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 27) WFLYUT0021: Registered web context: '/distributable' for server 'default-server'
12:05:05,561 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "distributable.war" (runtime-name : "distributable.war")
12:05:05,582 INFO  [io.undertow.servlet] (default task-14) /distributable/simple, value = 1
12:05:05,593 INFO  [io.undertow.servlet] (default task-15) /distributable/simple, value = 2
12:05:06,594 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 19) WFLYUT0022: Unregistered web context: '/distributable' from server 'default-server'
12:05:06,609 INFO  [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 3) ISPN000029: Passivating all entries to disk
12:05:06,612 INFO  [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 3) ISPN000030: Passivated 3 entries in 2 milliseconds
12:05:16,642 WARN  [org.infinispan.transaction.impl.TransactionTable] (ServerService Thread Pool -- 3) ISPN000100: Stopping, but there are 1 local transactions and 0 remote transactions that did not finish in time.
12:05:16,643 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 3) WFLYCLINF0003: Stopped distributable.war cache from web container
12:05:16,660 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0028: Stopped deployment distributable.war (runtime-name: distributable.war) in 10069ms
12:05:16,661 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 31) WFLYCLINF0003: Stopped routing cache from web container
12:05:16,683 INFO  [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0002: Content removed from location C:\BuildAgent\work\5768cf3a0bee5b47\full\testsuite\integration\clustering\target\wildfly-SYNC-tcp-0\standalone\data\content\40\2278acf53e32ace7377ed37c3c6de780b3f03f\content
12:05:16,683 INFO  [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0009: Undeployed "distributable.war" (runtime-name: "distributable.war")
12:05:16,706 WARN  [org.jboss.as.arquillian.container.ArchiveDeployer] (main) Cannot undeploy: distributable.war: org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper$ServerDeploymentException: java.lang.Exception: "WFLYCTL0216: Management resource '[(\"deployment\" => \"distributable.war\")]' not found"

org.jboss.as.test.clustering.cluster.web.DistributableTestCase(SYNC-tcp).testGracefulServeOnShutdown: 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:141)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:121)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:83)
	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:236)
	at org.jboss.as.test.clustering.NodeUtil.deploy(NodeUtil.java:42)
	at org.jboss.as.test.clustering.cluster.ClusterAbstractTestCase.beforeTestMethod(ClusterAbstractTestCase.java:91)
Caused by: java.lang.Exception: "WFLYCTL0212: Duplicate resource [(\"deployment\" => \"distributable.war\")]"
	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)
	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85)
	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
	at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:135)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:121)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:83)
	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:236)
	at org.jboss.as.test.clustering.NodeUtil.deploy(NodeUtil.java:42)
	at org.jboss.as.test.clustering.cluster.ClusterAbstractTestCase.beforeTestMethod(ClusterAbstractTestCase.java:91)
------- Stdout: -------
12:05:16,739 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location C:\BuildAgent\work\5768cf3a0bee5b47\full\testsuite\integration\clustering\target\wildfly-SYNC-tcp-0\standalone\data\content\4f\7ed321b98ca5173ba2b7fe37baea3c62370284\content
12:05:16,742 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "distributable.war" (runtime-name: "distributable.war")
12:05:16,777 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-6) WFLYSRV0018: Deployment "deployment.distributable.war" is using a private module ("org.wildfly.security.manager:main") which may be changed or removed in future versions without notice.
12:05:16,808 INFO  [org.jboss.as.arquillian] (MSC service thread 1-6) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."distributable.war",unit=distributable.war,tests=[org.jboss.as.test.clustering.cluster.web.DistributableTestCase]]
12:05:16,810 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-2) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:05:16,811 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-2) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:05:16,812 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-2) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:05:16,813 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-2) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:05:16,815 INFO  [org.infinispan.CLUSTER] (ServerService Thread Pool -- 31) ISPN000310: Starting cluster-wide rebalance for cache routing, topology CacheTopology{id=5, rebalanceId=3, currentCH=ReplicatedConsistentHash{ns = 256, owners = (1)[node-1: 256]}, pendingCH=ReplicatedConsistentHash{ns = 256, owners = (2)[node-1: 134, node-0: 122]}, unionCH=null, actualMembers=[node-1, node-0]}
12:05:16,815 INFO  [org.infinispan.CLUSTER] (ServerService Thread Pool -- 31) [Context=routing][Scope=node-0]ISPN100002: Started local rebalance
12:05:16,819 INFO  [org.infinispan.CLUSTER] (ServerService Thread Pool -- 3) ISPN000310: Starting cluster-wide rebalance for cache distributable.war, topology CacheTopology{id=5, rebalanceId=3, currentCH=DefaultConsistentHash{ns=256, owners = (1)[node-1: 256+0]}, pendingCH=DefaultConsistentHash{ns=256, owners = (2)[node-1: 134+122, node-0: 122+134]}, unionCH=null, actualMembers=[node-1, node-0]}
12:05:16,820 INFO  [org.infinispan.CLUSTER] (ServerService Thread Pool -- 3) [Context=distributable.war][Scope=node-0]ISPN100002: Started local rebalance
12:05:16,823 INFO  [org.infinispan.CLUSTER] (remote-thread--p9-t1) [Context=routing][Scope=node-1]ISPN100003: Finished local rebalance
12:05:16,827 INFO  [org.infinispan.CLUSTER] (remote-thread--p9-t1) [Context=distributable.war][Scope=node-1]ISPN100003: Finished local rebalance
12:05:16,843 INFO  [org.infinispan.CLUSTER] (transport-thread--p16-t21) [Context=routing][Scope=node-0]ISPN100003: Finished local rebalance
12:05:16,844 INFO  [org.infinispan.CLUSTER] (transport-thread--p16-t21) ISPN000336: Finished cluster-wide rebalance for cache routing, topology id = 5
12:05:16,846 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 31) WFLYCLINF0002: Started routing cache from web container
12:05:16,858 INFO  [org.infinispan.CLUSTER] (transport-thread--p16-t19) [Context=distributable.war][Scope=node-0]ISPN100003: Finished local rebalance
12:05:16,860 INFO  [org.infinispan.CLUSTER] (transport-thread--p16-t19) ISPN000336: Finished cluster-wide rebalance for cache distributable.war, topology id = 5
12:05:16,861 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 3) WFLYCLINF0002: Started distributable.war cache from web container
12:05:16,878 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 3) WFLYUT0021: Registered web context: '/distributable' for server 'default-server'
12:05:16,894 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "distributable.war" (runtime-name : "distributable.war")

I'm closing this one as it will conflict with #1893. I think it should a ParameterValidator too; see #1897.


Sidebar cuts off

The sidebar cuts off, even if I make the window bigger.

Thanks @notAperson535, I'll have a look at that soon.
Is that using the compact mode?

@TheOld No.

@TheOld Seems like this has been fixed. Closing now.


Generating new addresses does not reflect in addresses

Reproduce:

recieve -> generate new address
goto walletSettings->addresses
new addresses do not reflect
restart app and now new addresses reflect.

Fixed! Thanks @mocodesmo


[wip] fix SortedOracles handling of single-element state

Description
A few sentences describing the overall effects and goals of the pull request's commits.
What is the current behavior, and what is the updated/expected behavior with this PR?
Tested
An explanation of how the changes were tested or an explanation as to why they don't need to be.
Other changes
Describe any minor or "drive-by" changes here.
Related issues

Fixes #[issue number here]

Backwards compatibility
Brief explanation of why these changes are/are not backwards compatible.

branch is messed up. creating a new one


🐛 fix : Fixed the button color issue

Fixed the button color issues
Refer #41 for issue

Amazing! Thank you!


KAFKA-16911: Update docs for KIP-862

Add single.store.self.join option for topology.optimization, per KIP-862. Should be cherry-picked to the 3.7 branch.

Thanks for the PR @JimGalasyn -- merged to trunk and cherry-picked to 3.8 branch.


euphoria-core: sort operator

We'd like to:
Sort.named("SORT")
    .of(input)
    .by(e -> Comparable)
    .setPartitioning(new RangePartitioning())
    .output();

Range partitioning by the given .by function and sorting by the same attribute within each partition.

PR https://github.com/seznam/euphoria/pull/99

Resolved in PR #99


Fix the error that evm contract deployment and calling transaction are in the same block

…e in the same block
Description
evm合约部署和调用如果在同一区块中，会导致同步区块执行调用合约时无法读取到合约code
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Brief of your solution
evm合约执行时，如果是区块内交易则从本地区块级别缓存中读取数据
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Codecov Report

Merging #339 (7215a61) into master (191d55e) will decrease coverage by 0.16%.
The diff coverage is 4.54%.

@@            Coverage Diff             @@
##           master     #339      +/-   ##
==========================================
- Coverage   45.65%   45.48%   -0.17%
==========================================
  Files         139      139
  Lines       12346    12362      +16
==========================================
- Hits         5636     5623      -13
- Misses       5557     5585      +28
- Partials     1153     1154       +1

Impacted Files
Coverage Δ

bcs/ledger/xledger/state/tx_verification.go
14.38% <0.00%> (-0.06%)
:arrow_down:

bcs/ledger/xledger/state/xmodel/xmodel_snapshot.go
13.55% <0.00%> (-0.24%)
:arrow_down:

kernel/contract/sandbox/mem_xmodel.go
75.32% <0.00%> (-1.00%)
:arrow_down:

kernel/contract/sandbox/xmcache.go
48.06% <0.00%> (-0.38%)
:arrow_down:

bcs/contract/evm/creator.go
26.00% <5.88%> (-0.99%)
:arrow_down:

bcs/consensus/pow/pow.go
39.54% <0.00%> (-3.43%)
:arrow_down:

bcs/consensus/xpoa/xpoa.go
51.26% <0.00%> (-2.04%)
:arrow_down:

bcs/consensus/tdpos/tdpos.go
47.88% <0.00%> (-0.94%)
:arrow_down:

bcs/consensus/tdpos/schedule.go
42.98% <0.00%> (-0.91%)
:arrow_down:

kernel/consensus/base/driver/chained-bft/smr.go
41.33% <0.00%> (+0.74%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 191d55e...7215a61. Read the comment docs.

Codecov Report

Merging #339 (7215a61) into master (191d55e) will decrease coverage by 0.14%.
The diff coverage is 4.54%.

@@            Coverage Diff             @@
##           master     #339      +/-   ##
==========================================
- Coverage   45.65%   45.50%   -0.15%
==========================================
  Files         139      139
  Lines       12346    12362      +16
==========================================
- Hits         5636     5625      -11
- Misses       5557     5583      +26
- Partials     1153     1154       +1

Impacted Files
Coverage Δ

bcs/ledger/xledger/state/tx_verification.go
14.38% <0.00%> (-0.06%)
:arrow_down:

bcs/ledger/xledger/state/xmodel/xmodel_snapshot.go
13.55% <0.00%> (-0.24%)
:arrow_down:

kernel/contract/sandbox/mem_xmodel.go
75.32% <0.00%> (-1.00%)
:arrow_down:

kernel/contract/sandbox/xmcache.go
48.06% <0.00%> (-0.38%)
:arrow_down:

bcs/contract/evm/creator.go
26.00% <5.88%> (-0.99%)
:arrow_down:

bcs/consensus/pow/pow.go
39.54% <0.00%> (-3.43%)
:arrow_down:

bcs/consensus/xpoa/xpoa.go
51.26% <0.00%> (-2.04%)
:arrow_down:

bcs/consensus/tdpos/schedule.go
42.98% <0.00%> (-0.91%)
:arrow_down:

kernel/consensus/base/driver/chained-bft/smr.go
41.33% <0.00%> (+0.74%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 191d55e...7215a61. Read the comment docs.

Codecov Report

Merging #339 (7d6bc22) into master (facac93) will decrease coverage by 0.13%.
The diff coverage is 4.54%.

@@            Coverage Diff             @@
##           master     #339      +/-   ##
==========================================
- Coverage   45.63%   45.49%   -0.14%
==========================================
  Files         139      139
  Lines       12346    12362      +16
==========================================
- Hits         5634     5624      -10
- Misses       5557     5583      +26
  Partials     1155     1155

Impacted Files
Coverage Δ

bcs/ledger/xledger/state/tx_verification.go
14.38% <0.00%> (-0.06%)
:arrow_down:

bcs/ledger/xledger/state/xmodel/xmodel_snapshot.go
13.55% <0.00%> (-0.24%)
:arrow_down:

kernel/contract/sandbox/mem_xmodel.go
75.32% <0.00%> (-1.00%)
:arrow_down:

kernel/contract/sandbox/xmcache.go
48.06% <0.00%> (-0.38%)
:arrow_down:

bcs/contract/evm/creator.go
26.00% <5.88%> (-0.99%)
:arrow_down:

bcs/consensus/tdpos/common.go
52.17% <0.00%> (-2.90%)
:arrow_down:

bcs/contract/xvm/code_manager.go
63.63% <0.00%> (-2.73%)
:arrow_down:

bcs/consensus/tdpos/tdpos.go
46.94% <0.00%> (-1.88%)
:arrow_down:

bcs/consensus/xpoa/xpoa.go
51.26% <0.00%> (-1.02%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update facac93...7d6bc22. Read the comment docs.

Codecov Report

Merging #339 (7d6bc22) into master (facac93) will decrease coverage by 0.04%.
The diff coverage is 4.54%.

@@            Coverage Diff             @@
##           master     #339      +/-   ##
==========================================
- Coverage   45.63%   45.59%   -0.05%
==========================================
  Files         139      139
  Lines       12346    12362      +16
==========================================
+ Hits         5634     5636       +2
- Misses       5557     5570      +13
- Partials     1155     1156       +1

Impacted Files
Coverage Δ

bcs/ledger/xledger/state/tx_verification.go
14.38% <0.00%> (-0.06%)
:arrow_down:

bcs/ledger/xledger/state/xmodel/xmodel_snapshot.go
13.55% <0.00%> (-0.24%)
:arrow_down:

kernel/contract/sandbox/mem_xmodel.go
75.32% <0.00%> (-1.00%)
:arrow_down:

kernel/contract/sandbox/xmcache.go
48.06% <0.00%> (-0.38%)
:arrow_down:

bcs/contract/evm/creator.go
26.00% <5.88%> (-0.99%)
:arrow_down:

bcs/contract/xvm/code_manager.go
63.63% <0.00%> (-2.73%)
:arrow_down:

bcs/consensus/xpoa/xpoa.go
51.26% <0.00%> (-1.02%)
:arrow_down:

bcs/network/p2pv1/conn.go
61.22% <0.00%> (+6.12%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update facac93...7d6bc22. Read the comment docs.


Extension in CII (implementation)

Further Procedure
Possible solution difficult. CEN validation rules validate over all invoice items and do not differentiate whether an element (ParentID) represents this item as a sub-item. This inevitably leads to an error in the validation. Can neither be adapted by KoSIT nor FeRD, changes only possible via CEN committees.
Update:
To-Do still open

There is a bit of confusion in the CEN TC 434 on breaking the validation rules from the core with an extension.
If there is only a subset of XML available for a business rule in the core of course it will fail in an extension!
For example, we have in one of the XML formats 6 attributes A to F, all containing some number.
The first 5 XML attributes: A, B, C, D, and E  are being added up to the attribute F (like full).
Therefore the schematron validation rule is that A+B+C+D+E = F
But let's assume we just required in the B2G core the attributes A, B and C and the result F.
Therefore, the validation rule for the core would be A+B+C = F (as the attributes D and E are not allowed).
With an extension, we decided now to bring back the attribute E!
Therefore, the validation rule for the extension would be A+B+C+E = F (as the attribute D is still not allowed).
In any document which contains an E that is unequal to 0 the core rule will fail, which is completely correct.
We should keep this in mind!
PS: @larsroelkerdenker it is possible to provide a validation rule for the CII sub-invoice line extensions as Andreas Pelekies confirmed as well. Therefore, I will mark this issue as out-of-scope. Please close if clarified otherwise please ask if you have any further questions!


Memory issues

Describe the bug
Sometimes Hashbrown crashes with no error or with Invalid memory access.
To Reproduce
Steps to reproduce the behavior:

Open random files
Crash

Expected behavior
Hashbrown doesn't crash and displays the hashes of the file.
Environment (please complete the following information):

OS: ArchLinux
Install method: Manually

Additional context
It appears that this doesn't happen (at least not often enough for me to reproduce) on the flatpak version. After some testing I narrowed it down to the run_cmd function. This started happening after adding SHA512 support.
If anyone gathers any kind of logs, feel free to post them below until I find a solution.

If anyone is still experiencing this, feel free to re-open!


Fastnlight: Blacklist<PHONE_NUMBER>0

Fastnlight requests the blacklist of the number<PHONE_NUMBER>0. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Approved by Jeff Schaller in Charcoal HQ


Tool.py Not Working For Win 7

The current code does not appear to be able to be run on Windows. The read me file states its been tested on windows. Any help would be appreciated!

Apologies, I am just seeing this. Do you have a traceback you can share?


assets/AbilityIds

The asset mania continues.

Nice 👍
Soon, we never have to use rawcodes directly ever again!


chore: add version metric

Signed-off-by: Jim Ma<EMAIL_ADDRESS>
Description

Related Issue

Motivation and Context

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation Update (if none of the other choices apply)

Checklist:

[ ] Code compiles correctly.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Codecov Report

Merging #954 (3b0c181) into main (b2c9c87) will increase coverage by 0.13%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #954      +/-   ##
==========================================
+ Coverage   42.43%   42.57%   +0.13%
==========================================
  Files         116      116
  Lines        8761     8761
==========================================
+ Hits         3718     3730      +12
+ Misses       4579     4568      -11
+ Partials      464      463       -1

Flag
Coverage Δ

Object-compatibility-e2etests
?

e2etests
?

unittests
42.57% <ø> (+0.13%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

client/daemon/peer/peertask_stream_callback.go
64.07% <0.00%> (+1.94%)
:arrow_up:

client/daemon/peer/peertask_stream.go
56.69% <0.00%> (+3.11%)
:arrow_up:


Major performance degradation when scrolling past "Why Radix Primitives" on the main website page

Bug report
Current Behavior
When scrolling past "Why Radix Primitives" on the main website page it looks like page rendering FPS drops significantly, from normal to ~5 fps. See attached video
Expected behavior
Scrolling as usual
Reproducible example
https://github.com/radix-ui/website/assets/250118/f309b877-1164-4c2c-8a4f-a71f5905a18d
Suggested solution
Have no idea :)
Additional context
I have a not so powerful notebook but never had scrolling issues before. In MS Edge the scrolling works fine.
Your environment

Software
Name(s)
Version

Browser
Firefox 122.0.1

Assistive tech
no

Operating System
windows 10

Same here.
Any solution?


nbconvert can sometimes not be found, we should install it next to the extension like ipykernel

There haven't been any upvotes nor complaints in this space, hence closing this issue


DNM: Running case to check failure

Description

[!TIP]
Add a TL;DR when the description is longer than 500 words or extremely technical (helps the content, marketing, and DevRel team).
Please also include relevant motivation and context. List any dependencies that are required for this change. Add links to Notion, Figma or any other documents that might be relevant to the PR.

Fixes #Issue Number
or
Fixes Issue URL

[!WARNING]
If no issue exists, please create an issue first, and check with the maintainers if the issue is valid.

Automation
/ok-to-test tags=""
:mag: Cypress test results

[!CAUTION]
If you modify the content in this section, you are likely to disrupt the CI result for your PR.

Communication
Should the DevRel and Marketing teams inform users about this change?

[ ] Yes
[ ] No

Summary by CodeRabbit

Chores

Updated test specification to focus on a new TypeScript test file.

/ci-test-limit-count run_count=5

/ci-test-limit-count run_count=20 runId=12194882553

/ci-test-limit-count run_count=20 runId=12194882553