Add conversions module for Java 8 CompletableFuture

Closes #221
I could not build CancelableFuture -> CompletableFuture because cancelled CancelableFuture is non-terminating, which I cannot react on without something like Task.onCancelRaiseError. I went with Future -> CompletableFuture conversion instead.
There are also APIs I don't think we can support, like obtrudeValue which lets you mutate the result of CompletableFuture even when it is already completed. Luckily, even the doc for obtrudeValue says it guarantees nothing.
Also, a lot of CompletableFuture API allows supplying Executor to run on (and if you don't, it runs on synchronously or on a common ForkJoinPool) - and since Scheduler is an Executor too, I added deferCompletableFutureAction to Task companion.
Btw, although @alexandru said:

Given that Scala 2.12 requires Java 8, this should be added for Scala 2.12 only.

It should be possible to cross-build it for Scala 2.11.x too, since it is a separate module and there might be somebody running 2.11 on Java 8.

We can describe onCancelRaiseError for CancelableFuture as well and we should probably add it:
import monix.execution.atomic.Atomic
import monix.execution.schedulers.TrampolineExecutionContext.immediate

def onCancelRaiseError[A](fa: CancelableFuture[A], e: Throwable)
  (implicit ec: ExecutionContext): CancelableFuture[A] = {

  if (fa.isComplete) fa else
    CancelableFuture.async { cb =>
      val active = Atomic(true)
      val cb2 = new RaiseCancelable(active, cb)
      // Register listener
      fa.underlying.onComplete(cb2)(immediate)
      // Return cancelable
      new RaiseCancelable(active, cb)
    }
}

final class RaiseCallback[A](active: AtomicBoolean, cb: Try[A] => Unit)
  (implicit ec: ExecutionContext) extends (Try[A] => Unit) {

  def apply(value: Try[A]) =
    if (active.getAndSet(false)) {
      cb(value)
    } else value match {
      case Failure(e) => ec.reportFailure(e)
      case _ => ()
    }
}

final class RaiseCancelable[A](active: AtomicBoolean, cb: Try[A] => Unit)
  extends Cancelable {

  def cancel(): Unit = {
    if (active.getAndSet(false))
      cb(Failure(new CancelledException()))
  }
}

The nice thing about onCancelRaiseError is that this kind of synchronization is precisely what would have been needed if the contract would have been for CancelableError to always terminate in error on cancel, but this one is optional, on a by-need basis.

So nice of you to pick this up 😀
Some ideas:

I'd rather have this project named monix-java  with the monix.java namespace, because the current Java is Java 9 and who knows, we might end up with Java 9 conversions when Java 10 is released and I'd rather not have multiple Java-related projects. We'll be conservative and mindful in what we accept too.

I'd rather have its dependencies optional, as we might want to add conversions for monix.reactive as well - so each sub-project gets its own object / module under monix.java:

// For CancelableFuture
import monix.java.execution._

// For Task
import monix.java.eval._

And then in this sub-project's dependencies we can specify them as "provided".  Not entirely sure if this is a good idea, since it can blow up in people's faces with a ClassNotFoundException, but we should include it in the monix package that brings in everything, anyway and "provided" is useful for people that want an a la carte experience.

onCancelRaiseError

That will only work if you call cancel on a result of CancelableFuture.onCancelRaiseError. But since Futures represent a computation that is already running, there's not much utility in this unless it propagates cancelled status downstream. Cancelled monix futures become non-terminating, so they propagate nothing. I cannot turn cancelled monix future into cancelled j.u.c.CompletableFuture.
So it's might be better to leave that as Future -> j.u.c.CompletableFuture that turns non-terminating Futures into non-terminating j.u.c.CompletableFutures - with no support for cancelling.

monix.java namespace

I'm slightly :-1: on that. First, if somebody does import monix._, that will shadow java package. Second, if we do add Java 9 conversions (e.g. to Flow interfaces, #438), it will be harder for users to understand why that ClassNotFoundException happens. I believe different namespaces (monix.java8, monix.java9) would be more convenient, even if it lives in the same module.

Hm, I cannot find a way to conditionally aggregate the subproject if scalaVersion used in build is not included in its crossScalaVersions. Is there a way?

@oleg-py unfortunately you can't pick and choose the Scala versions per sub-project.
When I first wrote that description on the issue, I was thinking of a module inside monix-eval to only be included with Scala 2.12, not in a separate sub-project, but by using a source trick. Like we have for example here: https://github.com/monix/monix/tree/master/monix-execution/shared/src/main/scala_2.12/
This would be another way of approaching the problem. We could make object CancelableFuture extend a trait that's empty for Scala 2.11, but that contains extra utilities for Scala 2.12+.
On the monix.java namespace I agree with you, bad idea.

@alexandru I made it work for Scala 2.11 / Java 8. Seemed easier 😅 (esp. since CI uses that combination for builds too). WDYT?

Merged. Hope it works well.
Thanks.

@alexandru @oleg-py
Hi guys! It may be silly question, but what dependency do I have to add to my project to make monix.java.* package available? I didn't find it in README.md...
monix-java of last version 2.3.3 can't be resolved...

Sorry guys for procrastinating on releasing 3.0.0-M4. The release process is really annoying 😑
It's ready for release though, will do so sometime today.


Remove leading 'x' from repository name

The leading 'x' is kind of arbitrary. Especially now that we can set
topics on the repositories, we don't need a pattern to distinguish what
is a track or not.
The repository itself has already been renamed. GitHub redirects from
the old name to the new name, so we do not have to rush to fix links to
the old repository name, though we should update them for the sake of
clarity.
See exercism/meta#1

I didn't update the xObjectiveCTest references, because I'm not sure how all those pieces fit together.

that is just the name of the test suite.  I think the x stands for Xcode.

Thanks!

Oh! That would make sense :) Thanks 🌻


fork the recipe repo

https://github.com/conda-forge/staged-recipes
and then prepare a PR with recipes for our pkgs.  four kernels:
beakerx-groovy
beakerx-java
beakerx-scala
beakerx-clojure
and our python runtime in beakerx-python
and the UI and widgets in beakerx, a dependency of each of the above.
this is part of https://github.com/twosigma/beakerx/issues/5134

fork is done: https://github.com/twosigma/staged-recipes


Regularized Gaussian extension: ModifiedHalfNormal

Sub PR from #424

Added Modified Half Normal distribution (conjugate distribution to RegularizedGaussian/GMRF)

To-do:

[ ] Add tests

Thanks for the suggestions @nabriis , I have now added a regression test for the sampling, logpdf and gradient.
Currently, due the the logpdf in the ModifiedHalfNormal being unmodified, the logpdf will not match with that of the Gamma. Also, there is no gradient implemented in Gamma currently, so such comparison is currently not possible.


Elasticsearch 7 documented to not work, but docker-amundsen.yml uses it

Expected Behavior
If elasticsearch 7 is supported, which it appears to be as it is used in the [docker compose file here](https://github.com/amundsen-io/amundsen/blob/main/docker-amundsen.yml#L23, the docs should not require Elasticsearch 7.
Current Behavior
Pages such as https://www.amundsen.io/amundsen/databuilder/ say:

Requirements

Python >= 3.6.x
elasticsearch 6.x (currently it doesn’t support 7.x)

which conflicts with the docker-amundsen.yml, which seems to work.
Possible Solution
Update supported elasticsearch versions to include 7.x, if it is indeed supported. If Opensearch is supported as well that would be good to know.
Screenshots (if appropriate)

Thanks for pointing that out @razzius! Indeed the docs would need update, are you willing to submit PR?

docs are up to date now


Upgrading to Angular 8

any update on upgrading to angular 8

Are you planning to support for Angular 8.

This is not at all compatible with Ivy. so if you use angular 9 with Ivy or angular 10 the all thing breaks


BUG: Website not Responsive in Mobile Screen

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
The entire Smart-grid website is not responsive for mobile screens and multiple other screens. The elements are out of the place in the mobile screen.
Screenshots:

Please assign me this issue. I would love to work on it.
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

someone already working on this


tlog client/server hashing issue

possible bug, reported at https://github.com/g8os/blockstor/pull/209#issuecomment-305367738

However in my case it is a valid error, as the full logs give this:
t=2017-05-31T20:53:38-0500 lvl=dbug msg="hash check failed:data hash is incorrect\n" module=global caller=server.go:264
t=2017-05-31T20:53:38-0500 lvl=eror msg="connection from <IP_ADDRESS>:61605 dropped with an error: data hash is incorrect" module=global caller=server.go:107
t=2017-05-31T20:53:38-0500 lvl=dbug msg="abort current sendResp goroutine for vdisk:a" module=global caller=server.go:287
panic: tlog server resulted in error for vdisk a: EOF

So for some reason the hash check failed, will look into it.
EDIT: it's not easy to trigger it, but if you open a couple of shells and run:
for i in {1..100}
do
    GODEBUG=cgocheck=0 go test -timeout 5m -tags 'isal' github.com/g8os/blockstor/nbdserver/ardb
done

From my quick check, i don't think that it is a bug.
It is just the hashing serves it's purpose : detect corrupted data.

Then the bug is the corrupt data, no?

Then the bug is the corrupt data, no?

At that stage, tlogserver hasn't done anything to the data, the possible issues are:

very bad network
the hash function become buggy under high load

Both of which seem bad if we can't catch it now :) Rare bugs like this tend to get very regular, once you have sufficient amount of active users.

For me, the main suspect is the bad network, and it is not a bug.
Bad network is one of the reason we need this hash check.
While bug in hash, no idea how could it happen, maybe need to isolate the hashing part to better reproduce it.

Oh ok I start to see why you think #226 is a bug. Because now the reaction upon corrupt data is fatal for both client and server, and I guess you want to handle this better?

Do you know which test that trigger this issue?

Oh ok I start to see why you think #226 is a bug. Because now the reaction upon corrupt data is fatal for both client and server, and I guess you want to handle this better?

No, the fatal is in nbdserver, i only want to fix tlog on that issue

I think i have fixed this issue in ea2dd1ad648f78fe91d071a0eb5fc75391748baf.
It is because the race in transaction.Content.
With current code, sequence cache and transaction sender share same (pointer of) content.
See https://play.golang.org/p/qLDLUE6QJr for the demo

OK, after running go test with  -race flag many times concurrently (from two terminals), i finally got the race proof, which show the race condition i mentioned above
go test -race -run TestTlogStorageDeadlockWithNondeduped

INFO[06-05|11:26:19] embedded LedisDB Server ready and listening at <IP_ADDRESS>:39985 module=global caller=redis.go:47                                                                                [56/1464]
INFO[06-05|11:26:19] embedded LedisDB Server ready and listening at <IP_ADDRESS>:42389 module=global caller=redis.go:47
INFO[06-05|11:26:19] embedded LedisDB Server ready and listening at <IP_ADDRESS>:38429 module=global caller=redis.go:47
INFO[06-05|11:26:19] Started listening on local address <IP_ADDRESS>:43035 module=global caller=server.go:55
DBUG[06-05|11:26:19] received handshake request from incoming connection module=global caller=server.go:140
DBUG[06-05|11:26:19] incoming connection checks out with version: 1.1.0-alpha module=global caller=server.go:150
DBUG[06-05|11:26:19] create vdisk with expectedSequence:0     module=global caller=vdisk.go:148
INFO[06-05|11:26:19] vdisk a reset first sequence to 0        module=global caller=vdisk.go:221
DBUG[06-05|11:26:19] handshake phase successfully completed   module=global caller=server.go:175
DBUG[06-05|11:26:19] replying handshake with status: OK       module=global caller=server.go:202
DBUG[06-05|11:26:19] vdisk a's tlog server has received force flush message module=global caller=tlog.go:274
DBUG[06-05|11:26:19] vdisk a's tlog server has received force flush message module=global caller=tlog.go:274
DBUG[06-05|11:26:19] vdisk a's tlog server has received force flush message module=global caller=tlog.go:274
DBUG[06-05|11:26:19] vdisk a's tlog server has received force flush message module=global caller=tlog.go:274
DBUG[06-05|11:26:19] vdisk a's tlog server has received force flush message module=global caller=tlog.go:274
DBUG[06-05|11:26:19] vdisk a's tlog server has received force flush message module=global caller=tlog.go:274
DBUG[06-05|11:26:20] vdisk a's tlog server has received force flush message module=global caller=tlog.go:274
DBUG[06-05|11:26:20] vdisk a's tlog server has received force flush message module=global caller=tlog.go:274
==================
WARNING: DATA RACE
Read at 0x00c4233a2900 by goroutine 108:
  runtime.slicecopy()
      /home/ibk/go/src/runtime/slice.go:160 +0x0
  github.com/zero-os/0-Disk/vendor/github.com/minio/blake2b-simd.(*digest).Write()
      /home/ibk/pathgo/src/github.com/zero-os/0-Disk/vendor/github.com/minio/blake2b-simd/blake2b.go:231 +0x1e8
  github.com/zero-os/0-Disk/vendor/github.com/minio/blake2b-simd.Sum256()
      /home/ibk/pathgo/src/github.com/zero-os/0-Disk/vendor/github.com/minio/blake2b-simd/blake2b.go:297 +0xf9
  github.com/zero-os/0-Disk.HashBytes()
      /home/ibk/pathgo/src/github.com/zero-os/0-Disk/hash.go:24 +0x6d
  github.com/zero-os/0-Disk/tlog/tlogclient.(*Client).send()
      /home/ibk/pathgo/src/github.com/zero-os/0-Disk/tlog/tlogclient/client.go:292 +0x6a
  github.com/zero-os/0-Disk/tlog/tlogclient.(*Client).Send()
      /home/ibk/pathgo/src/github.com/zero-os/0-Disk/tlog/tlogclient/client.go:282 +0x11f
  github.com/zero-os/0-Disk/nbdserver/ardb.(*tlogStorage).transactionSender()
      /home/ibk/pathgo/src/github.com/zero-os/0-Disk/nbdserver/ardb/tlog.go:311 +0x21f

Previous write at 0x00c4233a2906 by goroutine 471:
  runtime.slicecopy()
      /home/ibk/go/src/runtime/slice.go:160 +0x0
  github.com/zero-os/0-Disk/nbdserver/ardb.(*tlogStorage).Merge()
      /home/ibk/pathgo/src/github.com/zero-os/0-Disk/nbdserver/ardb/tlog.go:152 +0x17f
  github.com/zero-os/0-Disk/nbdserver/ardb.testBackendStorageDeadlock.func2()
      /home/ibk/pathgo/src/github.com/zero-os/0-Disk/nbdserver/ardb/ardb_test.go:497 +0x37e

Goroutine 108 (running) created at:
  github.com/zero-os/0-Disk/nbdserver/ardb.(*tlogStorage).GoBackground()
      /home/ibk/pathgo/src/github.com/zero-os/0-Disk/nbdserver/ardb/tlog.go:253 +0x25a

Goroutine 471 (finished) created at:
  github.com/zero-os/0-Disk/nbdserver/ardb.testBackendStorageDeadlock()
      /home/ibk/pathgo/src/github.com/zero-os/0-Disk/nbdserver/ardb/ardb_test.go:501 +0x61b
  github.com/zero-os/0-Disk/nbdserver/ardb.testTlogStorageDeadlock()
      /home/ibk/pathgo/src/github.com/zero-os/0-Disk/nbdserver/ardb/tlog_test.go:240 +0x25c
  github.com/zero-os/0-Disk/nbdserver/ardb.TestTlogStorageDeadlockWithNondeduped()
      /home/ibk/pathgo/src/github.com/zero-os/0-Disk/nbdserver/ardb/tlog_test.go:198 +0x25b
  testing.tRunner()
      /home/ibk/go/src/testing/testing.go:657 +0x107
==================

@GlenDC i think we can close this issue?


Tweaking logic based on how evtx is parsed on Cuckoo's side

Waiting for Cuckoo3 to be released
Closes https://cccs.atlassian.net/browse/AL-890

Released! :) https://github.com/cert-ee/cuckoo3

Released! :) https://github.com/cert-ee/cuckoo3

Thanks for letting me know @r0ny123 ! Looks like it is still in development though, so I'll wait until it is production-ready before changing the service code :)

Ah yes. Guess we have to wait a bit more.


Unclear documentation/odd results with return_variance in restricted_mean_survival_time

I have been using restricted_mean_survival_time from a KaplanMeierFitter, and in particular I need the standard error or standard deviation of the restricted mean. So I set return_variance=True in restricted_mean_survival_time. I find very different results in the variances that are returned when I call restricted_mean_survival_time in these two ways:
restricted_mean_survival_time(kmf,  t=max_detected, return_variance=True)
versus
restricted_mean_survival_time(kmf.survival_function_,  t=max_detected, return_variance=True)
Note that before calling this function, I have run:
kmf = KaplanMeierFitter()
kmf.fit_left_censoring(T, E)

I have tested this on a data set which includes upper limits, and have compared the results with the outputs from the survival R package (https://cran.r-project.org/web/packages/survival/survival.pdf). For this example data set, running survfit in R gives a restricted mean that is consistent with both restricted means from lifelines. The standard error from R is 3 times (2.769 times to be precise) smaller than standard error calculated from the first call of restricted_mean_survival_time above (sqrt(variance / number of data points)), but is consistent with the second call.
I believe the difference between these two calls is just that the second one doesn't recalculate the survival function, but why does that cause a factor of 3 difference in the standard deviation, and no significant difference in the mean?  It is particularly confusing that the second result, which agrees with R (which I believe is correct), prints out a message saying

Approximating RMST using the precomputed survival function. You likely will get a more accurate estimate if you provide the fitted Model instead of the survival function.

Is this a bug? Either way, I think an explanation of how these two ways of calling restricted_mean_survival_time would be helpful in the documentation.

Hi @rchwn,
Definitely there is a bug here. I wonder if it has something to do with the left-censored dataset (i.e. RMST is making some right-censoring assumption).
Anyways, the two calls should be identical. I'll have to look into what _expected_value_of_survival_squared_up_to_t is doing...
The warning is fine, and can be ignored. That warning is for the case when a dataframe is provided, but a parametric model is possibly available. In your case, you aren't using a parametric model, so either call is using the same data (the pre-computed survival function).

I did find a bug (fix will be in latest version, see #1278), and I suggest using restricted_mean_survival_time(kmf, t=max_detected, return_variance=True) for best accuracy.

Thanks for the quick replies. I actually found that restricted_mean_survival_time(kmf.survival_function_, t=max_detected, return_variance=True) gave a more accurate variance for my particular application (maybe because I'm using left-censored data?).


Disable UI elements for selecting zero-fee

BitcoinAmountField should allow to set a minimum of 1. Maybe that will be less confusing if anyone tries to use the custom fee amount field. Otherwise selecting 0 gives 1 fee, selecting 1 gives 1 fee, 2=2...
Talking about <widget class="BitcoinAmountField" name="customFee"/>

@rnicoll this needs a rebase

Rebased!

Pushed an incomplete solution to the minimum fee field, for others to look at. Will try fixing it tomorrow (right now it appears the minimum property isn't set correctly)

Minimum field fixed, please test and let me know if there's any issues.

Works for me, ACK


[Feature] Support erasure code

Support erasure code:

The implementation idea of EC client, we refer to https://issues.apache.org/jira/browse/HDFS-7285.
Support for reading EC files.
Supports writing or appending to EC files.
Fix some bugs for functions complete, addBlock and abandonBlock.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 3 committers have signed the CLA.:white_check_mark: M1eyu2018:x: liubingxing:x: tomscutYou have signed the CLA already but the status is still pending? Let us recheck it.


random_color() and random_bright_color() should have a parameter random_seed

As it is always good to reproduce randomness, these two functions should have a parameter seed.
https://docs.manim.community/en/stable/_modules/manim/utils/color.html#random_color
Then it should be possible to just init that seed.
~~https://towardsdatascience.com/stop-using-numpy-random-seed-581a9972805f~~
EDIT: Second link does not apply here.

The link you have posted regarding the numpy random seed doesn't really apply for the random_color function, it doesn't use numpy's random module.

True, sorry!
I got confused, because there is also a choise function in numpy.
Here is the correct one:
https://docs.python.org/3/library/random.html#bookkeeping-functions

@kolibril13 I reviewed PR #1676, it works but I don't think we need if-else code statement, we can do it directly also.
Like rng = random.Random(random_seed).
Some Experiments:
>>> from manim.utils.color import random_color, random_bright_color
>>> random_color()
'#FFEA94'
>>> random_color()
'#00FF00'
>>> random_color(42)
'#ECABC1'
>>> random_color(random_seed=42)
'#ECABC1'
>>> random_color()
'#FFF1B6'
>>> random_bright_color()
<Color #ddd>
>>> random_bright_color()
<Color #fbd0d1>
>>> random_bright_color(42)
<Color #f5d5e0>
>>> random_bright_color(42)
<Color #f5d5e0>

So should I create a new pr?

So should I create a new pr?

Hey, I have reviewed that PR already a while ago, but the fundamental issue noted in https://github.com/ManimCommunity/manim/pull/1676#issuecomment-871298275 has not been discussed or resolved yet. Removing the if-else will also not change that.

I don't think that this behavior is expected, but I also don't really have a good / simple solution for this. I think that essentially, we'd have to check whether a RNG with the given seed has already been initialized, and then use the existing one – or create one.

I don't know if I understood it correctly. What is the expected behavior? Is it if random.Random() is already defined with random_seed then no need to create RNG Object and If not then, we create RNG Object and set it's seed to random_seed.
I looked into it and I don't think its possible with python random module. Random does give us function such getstate() and setstate() which can be used to get info on its current state. getstate() function returns a list of size 624 and I dont think we can extract seed from that.
>>> import random
>>> random.getstate()[1][0]
2147483648
>>> random.seed(42)
>>> random.getstate()[1][0]
2147483648

Though this can be done in Numpy random module as np.random.get_state()[1][0] returns random_seed.
>>> import numpy as np
>>> np.random.get_state()[1][0]
2147483648
>>> np.random.seed(42)
>>> np.random.get_state()[1][0]
42
>>> np.random.randint(0, 100)
51
>>> np.random.randint(0, 100)
92
>>> np.random.randint(0, 100)
14
>>> np.random.get_state()[1][0]
723970371

But it also changes after some tries, so we can't determine the seed. I found something on stackoverflow related to it:

In summary on np.random.seed(s):
- get_state()[1][0] immediately after setting: retrieves s that exactly recreates the state
- get_state()[1][0] after generating numbers: may or may not retrieve s, but it will not recreate the current state (at get_state())
- get_state()[1][0] after generating many numbers: will not retrieve s. This is because pos exhausted its representation.
- get_state() at any point: will exactly recreate that point.  Lastly, behavior may also differ due to get_state()[3:] (and of course [0]).

So, I don't think we can retrieve current Random seed as the seed is used to update the internal state of the random number generator is not directly stored anywhere.
References:

https://stackoverflow.com/questions/12697299/is-there-a-way-to-read-back-the-random-seed-in-python
https://stackoverflow.com/questions/32172054/how-can-i-retrieve-the-current-seed-of-numpys-random-number-generator

Before we get into implementation details, we have to agree on what kind of behavior we should actually expect. Personally, I think that a situation like
>>> random_bright_color(42)
<Color #f5d5e0>
>>> random_bright_color(42)
<Color #f5d5e0>

is not desireable, because setting the seed then is equivalent to hard-coding one specific color. I would expect that repeatedly calling random_color(random_seed=42) continues to give random colors, but in a reproducible way.
You are right that the current seed of an initialized RNG  cannot be retrieved -- but as it is mentioned in the SO answers you've posted, we can still store the seed of the RNG that has been initialized last somewhere. (Maybe in Manim's configuration, maybe "just" in the module; not sure about that.) Then, when random_color is called again, the passed seed can be compared to the stored one, and either the already initialized RNG can be used, or a new one can be initialized.

Yeah, we can store seed in config file and compare it if users provide random_seed.

I would expect that repeatedly calling random_color(random_seed=42) continues to give random colors, but in a reproducible way.

I was thinking maybe we could use getstate() and setstate() functions. Like we could return the state of seed at that with getstate() and later on set it back to its previous state using setstate().
In the meanwhile, I can try working on storing it in config system.

I've had a look through all of the stuff discussed in this issue so far and I'm not sure the solution of globally storing a seed for the random function is ideal because it opens the door for other areas of the code to reference that same seed and then produce inconsistent results if the code is edited. Consider the two following snippets of code:
colour1 = random_color(42)
colour2 = random_color(42)
shape1 = random_shape(42)
shape2 = random_shape(42)

colour1 = random_color(42)
shape1 = random_shape(42)
colour2 = random_color(42)
shape2 = random_shape(42)

These two snippets, although only a trivial reordering of one another, would produce very different results (assuming that random_shape accesses the same seed/RNG) and I don't think it's immediately obvious that either random_color or random_shape should have side effects.
I can think of a few solutions right now, each of course with their own benefits and drawbacks:

Store the seed for random_colour separately so that there's no risk of future code using it and causing issues.
Make random_colour return a seed that can be stored by the end user and fed back into random_colour later on. In this solution, we would use a new instance of a RNG every time random_colour is called.
Introduce a random_colours(n: int, seed: int = None) -> List[Color] function that returns a list of n random colours.

Comments on the above solutions:

Would probably introduce some tech debt and encourage the storage for RNG seeds to become very far out of scope if other areas of the code wanted to do the same thing.
Gives the end user the most control, but is by far the least ergonomic. Having to store 2 values from random_color every time it's run and then pass one of those parameters back into random_color is not ideal.
This solution removes the non-deterministic behavour when reordering code and I think it's probably the best solution right now save for a full rewrite of the way that RNG is handled by Manim as a whole which is a conversation for a separate issue.

Let me know what you think of the above and we can discuss further before I actuallly write any code. Feel free to @ me (Phosphorescent#2786) in the Discord if you'd rather talk there :)

Hi! I noticed that this issue has been open for a while. I'm looking to make my first contribution, so I don't have a lot of experience with the project, but I agree that creating a separate function seems like the best idea. Introducing non-deterministic behavior like that seems like a nightmare. Is anyone else still actively working on this issue, or can I go ahead and start implementing that approach?

just an additional comment: I'd suggest a parameter to exclude either certain colors or at least to optionally automatically exclude the current background color.

That's a good point. I imagine re-rendering something until you get an actually visible color gets more difficult as you work with more colors. Actually, wouldn't the function have to exclude a range of very similar colors to avoid that situation?

That's a good point. I imagine re-rendering something until you get an actually visible color gets more difficult as you work with more colors. Actually, wouldn't the function have to exclude a range of very similar colors to avoid that situation?

I don't think so, since it anyway are not too many different colors from which the random colors are drawn - but It would probably not too difficult to find similar colors to exclude using hue and brightness.

I think that goes beyond the scope of this issue, but it does sound like enough of a concern to deserve its own issue. I'm not too sure though. What do you think?

I think that goes beyond the scope of this issue, but it does sound like enough of a concern to deserve its own issue. I'm not too sure though. What do you think?

I am just thinking that it would be easiest to implement these things at the same time rather than doing surgery on this code several times in a row. And I also think that just excluding the current background is "good enough" - I reverted to random_bright_color() on a dark background, but the contrast between the different shades is very weak.

Sounds good. I'm not experienced enough with Manim to really know how dificult/easy using these functions are

I think that goes beyond the scope of this issue, but it does sound like enough of a concern to deserve its own issue. I'm not too sure though. What do you think?

I am just thinking that it would be easiest to implement these things at the same time rather than doing surgery on this code several times in a row. And I also think that just excluding the current background is "good enough" - I reverted to random_bright_color() on a dark background, but the contrast between the different shades is very weak.

Would you like to clarify what you mean by excluding "background" ? As per the color PR it uses the manim core colors for random colors.

Nvm.
So the current goal of this issue becomes changing the behavior with the seed but I also think that the exclusion of a specific color range shouldn't be done in this. Because in the end it gets more complicated if you want to have a magic function which basically computes legible  colors if you specify a background i actually think that one should be separate if we want to do it right we need to do some research what that actually means.
Because just excluding the exact background color won't really help in that situation even if i see where this comes from. But i think we should just stick to the seed for this ticket, so then yes we have to work on it twice but at least we do it right!

https://www.uxmatters.com/mt/archives/2007/01/applying-color-theory-to-digital-displays.php

I have a suggestion here - I created a small RandomColor object which contains its own instance of a random number generator which can be seeded and functions to pick a random color from a given set of colors, a color with a different hue from a given reference color or saturation/value or saturation/lightness pair.
class RandomColor(object):
    def __init__(self, seed = None) -> None:
        self.generator = np.random.RandomState(seed=seed)
        self.palette = ["#FFFFFF"]
    def setPalette(self, palette : Sequence[ParsableManimColor]):
        self.palette = palette
    def randomPaletteColor(self):
        return self.generator.choice(self.palette)
    def randomHue(self, reference_color:ParsableManimColor = "#FF0000", saturation=None, lightness=None, value=None):
        if saturation != None:
            if lightness != None:
                rgb = colorsys.hls_to_rgb(h=self.generator.uniform(0,1),s=saturation,l=lightness)
            elif value != None:
                rgb = colorsys.hsv_to_rgb(h=self.generator.uniform(0,1),s=saturation,v=value)
            else:
                rgb = colorsys.hsv_to_rgb(h=self.generator.uniform(0,1),s=saturation,v=1)
        else:
            hsv = colorsys.rgb_to_hsv(*color_to_rgb(reference_color))
            rgb = colorsys.hsv_to_rgb(h=self.generator.uniform(0,1),s=hsv[1],v=hsv[2])
        return ManimColor(rgb)

usage:
class randTest(Scene):
    def construct(self):
        rndcol = RandomColor()
        rndcol.setPalette([RED,GREEN,BLUE,YELLOW])
        for i in range(len(rndcol.palette)):
            self.add(Rectangle(width=1, height=0.3, fill_opacity=1, color=rndcol.palette[i]).move_to([-6+i,3.5,0]))
        self.add(Square(side_length=0.6, fill_opacity=1, color=PURE_BLUE).move_to(6.6*LEFT+0*UP))
        self.add(Square(side_length=0.6, fill_opacity=1, color=RED).move_to(6.6*LEFT+1*DOWN))
        self.add(Square(side_length=0.6, fill_opacity=1, color="#4c855b").move_to(6.6*LEFT+2*DOWN))
        self.add(Square(side_length=0.6, fill_opacity=1, color="#e0d9c3").move_to(6.6*LEFT+3*DOWN))

        for x in np.linspace(-6,6.5,20):
            self.add(Dot(x*RIGHT+3*UP, radius=.3, color=rndcol.randomPaletteColor()))

            self.add(Dot(x*RIGHT+0*UP, radius=.3, color=rndcol.randomHue(PURE_BLUE)))
            self.add(Dot(x*RIGHT+1*DOWN, radius=.3, color=rndcol.randomHue(RED)))
            self.add(Dot(x*RIGHT+2*DOWN, radius=.3, color=rndcol.randomHue("#4c855b")))
            self.add(Dot(x*RIGHT+3*DOWN, radius=.3, color=rndcol.randomHue("#e0d9c3")))

Ok I continued to work on it, ready to suggest a pull-request, after some additional polishing. What does everyone/anyone think?

rndcol = RandomColor(seed=42) initializes an instance with its own random number seed
rndcol.randomColor() same as the current plain random_color()
rndcol.setPalette([RED,GREEN,BLUE,YELLOW]) sets an internal color palette for random choice
rndcol.randomPaletteColor(allow_repeat=False) picks a random color from the palette, avoiding immediate repetitions
rndcol.randomContrastColor(PURE_BLUE)) tries to pick contrasting colors with regard to hue, saturation and brightness
rndcol.randomHue(RED)) generates a random color with same saturation and brightness, but random hue

class randTest(Scene):
    def construct(self):
        rndcol = RandomColor(seed=42)
        rndcol.setPalette([RED,GREEN,BLUE,YELLOW])
        for i in range(len(rndcol.palette)):
            self.add(Rectangle(width=1, height=0.3, fill_opacity=1, color=rndcol.palette[i]).move_to([-4+i,3.5,0]))
        self.add(Tex(r"randomPaletteColor()", font_size=22).move_to([-7,3,0],aligned_edge=LEFT))
        self.add(Tex(r"randomColor()", font_size=22).move_to([-7,2.3,0],aligned_edge=LEFT))
        self.add(Rectangle(height=0.6, width=14, fill_opacity=1, color="#e0d9c3").move_to(7*LEFT+1.5*UP, aligned_edge=LEFT))
        self.add(Tex(r"randomContrastColor()", font_size=22,color=BLACK).move_to([-7,1.5,0],aligned_edge=LEFT))
        self.add(Rectangle(height=0.6, width=14, fill_opacity=1, color=PURE_BLUE).move_to(7*LEFT+0.5*UP, aligned_edge=LEFT))
        self.add(Tex(r"randomContrastColor()", font_size=22,color="#768040").move_to([-7,0.5,0],aligned_edge=LEFT))
        self.add(Square(side_length=0.6, fill_opacity=1, color="#FFFF00").move_to(5.5*LEFT+0.5*DOWN))
        self.add(Square(side_length=0.6, fill_opacity=1, color=RED).move_to(5.5*LEFT+1.5*DOWN))
        self.add(Square(side_length=0.6, fill_opacity=1, color="#4c855b").move_to(5.5*LEFT+2.5*DOWN))
        self.add(Square(side_length=0.6, fill_opacity=1, color="#e0d9c3").move_to(5.5*LEFT+3.5*DOWN))
        self.add(Tex(r"randomHue()", font_size=30,color="WHITE").rotate(90*DEGREES).move_to([-6.5,-2,0],aligned_edge=LEFT))

        for x in np.linspace(-4.5,6.5,15):
            self.add(Dot(x*RIGHT+3*UP, radius=.3, color=rndcol.randomPaletteColor()))

            self.add(Dot(x*RIGHT+2.3*UP, radius=.3, color=rndcol.randomColor()))
            self.add(Dot(x*RIGHT+1.5*UP, radius=.25, color=rndcol.randomContrastColor("#e0d9c3")))
            self.add(Dot(x*RIGHT+0.5*UP, radius=.25, color=rndcol.randomContrastColor(PURE_BLUE)))
            self.add(Dot(x*RIGHT+0.5*DOWN, radius=.3, color=rndcol.randomHue("#FFFF00")))
            self.add(Dot(x*RIGHT+1.5*DOWN, radius=.3, color=rndcol.randomHue(RED)))
            self.add(Dot(x*RIGHT+2.5*DOWN, radius=.3, color=rndcol.randomHue("#4c855b")))
            self.add(Dot(x*RIGHT+3.5*DOWN, radius=.3, color=rndcol.randomHue("#e0d9c3")))


docs: update OpenAPI Comparison Chart to reflect OpenAPI 3.0

Description
The OpenAPI Comparison Chart in the docs isn't fully in sync with the OpenAPI 3.0 specification.
This fixes it, by adding and updating the appropriate fixed fields for the Components Object.

/rtm


Pausing moving words

Hi, thank you for releasing this great package!
I wanted to add a feature to pause the animation when the user isn't actively viewing the page.
I was considering implementing a method called pause() inside the main Movinwords class and calling it when the document is hidden. I'm not so sure how to implement this method so that the animation is frozen when the user leaves the page.
Do you have any suggestions for how to proceed?
Thanks!

Hello!
Sorry for the very late reply.
Pausing is not doable at the moment 😞 .
Movinwords uses css-transitions and those cannot be directly paused, as CSS does not provide a specific property or command to pause a running transition.
It could potentially be implemented on the code's side, but this is also tricky, as the code would need to know in advance which transition props to pause/resume based on the "transition" (fadeIn, slideIn, etc) that is provided.

Quick update:
The pause logic has been implemented:
https://github.com/revueltai/movinwords?tab=readme-ov-file#pause


Librispeech trained model for Streaming ASR

Hello,
Are there any pre-trained models like icefall-asr-multidataset-pruned_transducer_stateless7-2023-05-04 (Englis) which are trained on GigaSpeech + LibriSpeech + Common Voice 13.0 for Streaming ASR
Concurrently, which is the best pre-trained model which you have for Streaming ASR

Do you want Chinese or English?

I would like to know about the  English model.

I would like to know about the English model please.

Is there any example of using NeMo model for Streaming ASR as they can be exported as ONNX format?

Is there any example of using NeMo model for Streaming ASR as they can be exported as ONNX format?

Sorry, we don't have any.


dodge_the_creeps game not starting

I am starting to learn Godot as I want to try rust game development.
I am so happy to have a dodge the creeps rust version !
It looks really great but I cannot figure how to make it works:

I can compile the rust .dll (I am using windows 10)
I can launch the Godot project
But when I click on the Start button : the button disapear but nothing else happens ? I put debug log into the rust code fn on_start_button_pressed :
godot_print!("START BUTTON PRESSED");
owner.emit_signal("start_game".into(), &[]);
The godot_print can be seen into the Godot (v3.2.1) console when pressing the button but after nothing happens ?

Is it a known issue ? Am I doing something wrong ?
I tried the scene create example : its works with no problem.
Thanks.

Could you run Godot from a command prompt, preferably with RUST_BACKTRACE=1, and see if anything unusual is printed there?

Sorry, my bad. I cloned the repository again and start from this new one and now it works !
Thanks.


added helper method for COMB UUIDs

Resubmission of #180 with changed name helper (timestampFirstComb())

It's done. I don't really know what else to test, though.

After giving this a lot of thought, I've decided not to merge this pull request. In general, I like your idea of having a convenience method, but since the timestamp first COMB UUID isn't part of the UUID standard, I don't think the convenience method has a place in this library.
Thanks for contributing; keep it up!


ARROW-3584: [Go] Implement Table, Schema and Column

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@227ad0d). Click here to learn what that means.
The diff coverage is 77.87%.

@@           Coverage Diff            @@
##             master      #2   +/-   ##
========================================
  Coverage          ?   63.4%
========================================
  Files             ?      51
  Lines             ?    2481
  Branches          ?       0
========================================
  Hits              ?    1573
  Misses            ?     834
  Partials          ?      74

Impacted Files
Coverage Δ

go/arrow/schema.go
100% <100%> (ø)

go/arrow/datatype_nested.go
94.44% <100%> (ø)

go/arrow/array/table.go
74.5% <47.91%> (ø)

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 227ad0d...a29d0a8. Read the comment docs.


Lexer for FalconPL

(Original issue 401 created by None on 2009-03-24T13:26:25+00:00)
== Lexer for [http://www.falconpl.org/ FalconPL] ==

File: ''./pygments/lexers/_mapping.py''
{{{
'FalconLexer': ('pygments.lexers.agile', 'FalconPL' ('falconpl', 'falcon'), ('.fal', '.ftd'), ('text/x-falconpl', 'application/x-falconpl')),
}}}

File: ''./pygments/lexers/agile.py''
{{{
class FalconLexer(RegexLexer):
"""
For FalconPL <http://www.falconpl.org/>_ source code.
"""
name = 'FalconPL'
aliases = ['falconpl', 'falcon']
filenames = ['.fal', '.ftd']
mimetypes = ['text/x-falconpl', 'application/x-falconpl']
tokens = {
'root': [
(r'\n', Text),
(r'\s+', Text),
# Comments
(r'//(.?)$', Comment.Single),
(r'/\(.?)\/', Comment.Multiline),
# Keywords
(r'(break|continue|dropping|return|launch|from|global|const|self'
r'|catch|raise|case|default|def|directive'
r'|load|export|loop|while|for|function|innerfunc|init|static'
r'|attributes|forfirst|forlast|formiddle|enum|try|class|switch'
r'|select|object|if|elif|else|end)\b', Keyword),
# Items
(r'(nil|false|true)\b', Name.Builtin.Pseudo),  # or Keyword.Pseudo
# Operators
(r'[+^?=/&%$£!=|:-+@#]=?', Operator),
(r'(and|or|not|in|notin|to|provides|as)\b', Operator.Word),
# Numbers
(r'(0|[1-9][0-9_])', Number.Integer),
(r'([0-9][0-9_]*)?\.[0-9_]+([eE][+\-]?[0-9_]+)?', Number.Float),
# [+-][0-9]+(.[0-9]+)?([eE][0-9]+)?
(r'0[xX][a-fA-F0-9_]+', Number.Hex),
(r'0[cC]?[0-7_]+', Number.Oct),
(r'0[Bb][01_]+', Number),  # Binary
# Identifiers
(r'[^0-9_]\w+', Name.Variable),
(r'_\w+', Name.Variable.Instance),  # For module too
# Functions and classes
(r'(all|any|allp|anyp|eval|choice|xmap|iff|lit|cascade|dolist|eq)\b',
Name.Function),
(r'(List)\b'), Name.Class,
# Other
(r'(tracestep)\b', Name.Builtin),
# Exceptions
(r'(SyntaxError|CodeError|RangeError|MathError|IoError|TypeError'
r'|ParamError|ParseError|CloneError|InterruptedError|Error)\b',
Name.Exception),
],
}

}}}
Reported by falconpl

(Original issue was assigned to gbrandl)

(Original comment by thatch on 2009-09-19T00:44:23+00:00)
Still waiting for example files, retargeting.

(Original comment by thatch on 2009-06-21T19:29:58+00:00)
I've never heard of Falcon before, but the lexer looks decent.  Please provide examplefiles that demonstrate a good portion of the language (under a suitable license).  The examples I found didn't work due to parens and square brackets (among others) being error tokens.  ^^ needs to be escaped, btw, or it goes infinite-loop on the first character.

(Original comment by None on 2009-04-14T12:10:28+00:00)
The 'agile.falcon.2.py' file is wrong. Use 'agile.falcon.py'

(Original comment by None on 2009-04-14T11:00:40+00:00)
It has been the files where has been fixed any little issues.

(Original comment by tshatch on 2010-12-22T06:46:04.935787+00:00)
Still needs example files.


fix: admin moderation order by date

Description

currently moderations on /admin/aila/[chatId] a fetched in a non-deterministic order
this PR ensures that they're ordered by date, with the latest at the top

:tada: This PR is included in version 1.8.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


topic list by date

Describe the bug
topic list is not by date

topic_date_upt use
update column at new post - edit post - change query topic list in function (at topic creation auto put by msql)


android can not show PDF

...
...
...

Logs

I connect my phone,and then,I run in android studio。In this way,the apk run well.
but in this way

the pdf does not display.

please follow the instructions to generate release APKs in the README.

I did it as Readme.But it does not work

Okay, let me run some tests. Please post the output of $ flutter doctor, as described in the issue template.

Could it be because I use Java,but you use Kotlin? @devxpy

@devxpy

Still error? Please fix it, it also happened to me

I did some tests, the error happens only in some x64 devices, not all, I have a LG K10 x64 and the method is found and the plugin works fine.


Fix compatibility with Wear More Rings mod.

Hi there. Here's a patch that should fix compatibility with the wear more rings mod.
I'm not sure if Summoning rings are supposed to be put into combined rings, but this patch might add support for that. It makes it so that GetWornRings returns a list of rings that are either worn, or used in crafting combined rings that are being worn.

Hello there!
Firstly, thank you for the PR. Am I mistaken or does this patch remove compatibility with Wear More Rings?
It technically resolves the conflict issue I saw reported, but with this Custom Companions would no longer activate for summoning rings added on non-vanilla slots.

You're mistaken. The way Wear More Rings is implemented nowadays is that it keeps a combined ring in the left ring slot. The non-vanilla slots will simply put their equipped rings inside that combined ring. The new implementation of GetWornRings recurses on the combined rings and pulls out all the normal (vanilla & modded) rings.

Awesome, thank you for clarifying that!
I will have the updated deployed here shortly.


icu-intl: Ubuntu 14LTS build break

We have icu-intl is enabled by default now. ICU-intl impl. uses couple of ICU API those are not available on ICU 52. Although we don't say we officially support any of these, we could simply feature detect and pick API we can use and keep the number of platforms we support.
IMHO we shouldn't break our default build with Ubuntu 14LTS

http://bugs.icu-project.org/apiref/icu4c/ucurr_8h.html#acc9adb69459d712bc18e3e167dc5ec2a
This is stable since 4.2. That is not the issue that was being experienced.

but... I am still highly unconvinced that this is a code issue. I will look into this more on Monday.

As long as ‘default’ ChakraCore build successfully compiles and runs on 14LTS, there is no issue. Otherwise, API or ABI.. we have the tools to fix it.

I was getting link errors after building CC with —embed-icu on Ubuntu 16.04, is this related?

Do you remember what the link errors were? The error being discussed here was one that came up in the office, a compilation error about an undefined reference to ucurr_getPluralName_52

I was getting link errors after building CC with —embed-icu on Ubuntu 16.04, is this related?

Can you be more precise? This is a tested scenario by CI and it doesn't fail on neither 1.8 or master.

I’ll verify later once I pull up my Ubuntu 16 VM.

@obastemur
fatcerberus@pig-cult-vm:~/src/ChakraCore$ ./build.sh -j=8 --embed-icu

But later, attempting to link to the shared library:
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::MessageImpl::appendReducedApostrophes(icu_57::UnicodeString const&, int, int, icu_57::UnicodeString&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::SharedObject::getRefCount() const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::Locale::getDisplayName(icu_57::Locale const&, icu_57::UnicodeString&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::PluralMapBase::toCategory(char const*)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ParsePosition::~ParsePosition()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICULocaleService::registerInstance(icu_57::UObject*, icu_57::Locale const&, int, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICULocaleService::createKey(icu_57::UnicodeString const*, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::CanonicalIterator::CanonicalIterator(icu_57::UnicodeString const&, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `vtable for icu_57::CacheKeyBase'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector32::expandCapacity(int, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::SharedObject::removeRef(signed char) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uset_add_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::LocaleKeyFactory::updateVisibleIDs(icu_57::Hashtable&, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::LocaleKeyFactory::~LocaleKeyFactory()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUResourceBundleFactory::handleCreate(icu_57::Locale const&, int, icu_57::ICUService const*, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUResourceBundleFactory::~ICUResourceBundleFactory()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector32::setElementAt(int, int)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ByteSink::~ByteSink()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::SharedObject::addRef(signed char) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uiter_next32_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector32::setSize(int)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::LocaleBased::getLocaleID(ULocDataLocaleType, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::LocaleBased::getLocale(ULocDataLocaleType, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::LocaleKeyFactory::getDynamicClassID() const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UnicodeSetIterator::UnicodeSetIterator(icu_57::UnicodeSet const&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::MessagePattern::getPluralOffset(int) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UnicodeSet::applyPattern(icu_57::UnicodeString const&, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::LocaleKeyFactory::create(icu_57::ICUServiceKey const&, icu_57::ICUService const*, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector32::UVector32(int, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUService::getKey(icu_57::ICUServiceKey&, icu_57::UnicodeString*, icu_57::ICUServiceFactory const*, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::MessagePattern::operator==(icu_57::MessagePattern const&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `vtable for icu_57::ParsePosition'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector64::UVector64(UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::MessagePattern::~MessagePattern()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UnicodeSetIterator::getString()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UCharsTrie::~UCharsTrie()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUNotifier::removeListener(icu_57::EventListener const*, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ByteSink::Flush()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uset_open_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::CanonicalIterator::next()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector64::removeAllElements()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector64::setElementAt(long, int)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUService::getDisplayName(icu_57::UnicodeString const&, icu_57::UnicodeString&, icu_57::Locale const&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUService::createSimpleFactory(icu_57::UObject*, icu_57::UnicodeString const&, signed char, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uset_close_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UCharsTrieBuilder::~UCharsTrieBuilder()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `typeinfo for icu_57::ICUResourceBundleFactory'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::CanonicalIterator::~CanonicalIterator()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uset_applyPattern_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector64::~UVector64()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UCharsTrie::firstForCodePoint(int)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICULocaleService::registerInstance(icu_57::UObject*, icu_57::Locale const&, int, int, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `typeinfo for icu_57::ByteSink'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uset_getItemCount_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::LocaleKeyFactory::LocaleKeyFactory(int)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UnicodeSetIterator::~UnicodeSetIterator()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICULocaleService::get(icu_57::Locale const&, icu_57::Locale*, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUService::clearCaches()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUService::registerFactory(icu_57::ICUServiceFactory*, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::BreakIterator::createSentenceInstance(icu_57::Locale const&, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICULocaleService::getAvailableLocales() const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::MessagePattern::clear()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uset_getSerializedSet_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::MessagePattern::operator=(icu_57::MessagePattern const&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUService::unregister(void const*, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::CanonicalIterator::reset()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uset_addRange_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector64::insertElementAt(long, int, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector32::operator==(icu_57::UVector32 const&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector32::~UVector32()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUService::notifyListener(icu_57::EventListener&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::LocaleUtility::initNameFromLocale(icu_57::Locale const&, icu_57::UnicodeString&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::LocaleKeyFactory::handleCreate(icu_57::Locale const&, int, icu_57::ICUService const*, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `typeinfo for icu_57::SharedObject'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UnicodeString::toTitle(icu_57::BreakIterator*, icu_57::Locale const&, unsigned int)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UCharsTrie::Iterator::next(UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector64::expandCapacity(int, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector32::insertElementAt(int, int, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector32::assign(icu_57::UVector32 const&, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector32::removeAllElements()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICULocaleService::get(icu_57::Locale const&, int, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UnicodeSetIterator::next()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UVector32::UVector32(UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uset_getItem_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UCharsTrieBuilder::add(icu_57::UnicodeString const&, int, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUResourceBundleFactory::getDynamicClassID() const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `typeinfo for icu_57::CacheKeyBase'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICULocaleService::ICULocaleService(icu_57::UnicodeString const&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uiter_previous32_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uset_getSerializedRangeCount_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uset_size_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UCharsTrieBuilder::UCharsTrieBuilder(UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `vtable for icu_57::ByteSink'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uiter_setUTF8_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `vtable for icu_57::SharedObject'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::MessagePattern::MessagePattern(icu_57::MessagePattern const&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUNotifier::notifyChanged()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UCharsTrieBuilder::buildUnicodeString(UStringTrieBuildOption, icu_57::UnicodeString&, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::MessagePattern::getNumericValue(icu_57::MessagePattern::Part const&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUService::reset()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UCharsTrie::Iterator::Iterator(unsigned short const*, int, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UnifiedCache::getInstance(UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUService::countFactories() const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICULocaleService::registerInstance(icu_57::UObject*, icu_57::Locale const&, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUResourceBundleFactory::ICUResourceBundleFactory(icu_57::UnicodeString const&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::LocaleKeyFactory::handlesKey(icu_57::ICUServiceKey const&, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::CacheKeyBase::~CacheKeyBase()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICULocaleService::registerInstance(icu_57::UObject*, icu_57::UnicodeString const&, signed char, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UnicodeSet::UnicodeSet(icu_57::UnicodeString const&, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUResourceBundleFactory::ICUResourceBundleFactory()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UCharsTrie::nextForCodePoint(int)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::MessagePattern::parsePluralStyle(icu_57::UnicodeString const&, UParseError*, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UCharsTrie::Iterator::~Iterator()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUService::acceptsListener(icu_57::EventListener const&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::SharedObject::deleteIfZeroRefCount() const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uset_clear_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::LocaleKeyFactory::getDisplayName(icu_57::UnicodeString const&, icu_57::Locale const&, icu_57::UnicodeString&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `typeinfo for icu_57::ICULocaleService'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::LocaleUtility::initLocaleFromName(icu_57::UnicodeString const&, icu_57::Locale&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::SharedObject::~SharedObject()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUService::getKey(icu_57::ICUServiceKey&, icu_57::UnicodeString*, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::UnifiedCache::_get(icu_57::CacheKeyBase const&, icu_57::SharedObject const*&, void const*, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUNotifier::addListener(icu_57::EventListener const*, UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUService::reInitializeFactories()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICULocaleService::createKey(icu_57::UnicodeString const*, int, UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICUResourceBundleFactory::getSupportedIDs(UErrorCode&) const'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::PluralMapBase::toCategory(icu_57::UnicodeString const&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::Locale::getAvailableLocales(int&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::ICULocaleService::~ICULocaleService()'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::MessagePattern::MessagePattern(UErrorCode&)'
dep/lib/x86_64/libChakraCore.so: undefined reference to `typeinfo for icu_57::LocaleKeyFactory'
dep/lib/x86_64/libChakraCore.so: undefined reference to `uset_getSerializedRange_57'
dep/lib/x86_64/libChakraCore.so: undefined reference to `icu_57::LocaleBased::setLocaleIDs(char const*, char const*)'
collect2: error: ld returned 1 exit status

Very interesting -- that is all stuff used by ICU internally, not by ChakraCore. There are lots of typeinfo issues, and I remember there were some issues related to RTTI in the past. The classes there also seem to be from all over the place (haven't looked specifically but some of these things look like theyre from both Common and i18n). Super bizarre that this is an issue, though, since this is what our CI tests.

I'm building with --no-icu for now to avoid the issue, but I do wonder how much breakage I've caused by doing so.

But later, attempting to link to the shared library

So you get the error when you use the shared lib?

@obastemur Yes, ./build.sh completes successfully but I get the errors above when I try to actually link to the generated binary.

Can you please share some details on that?

What more do you need to know?  I run build.sh with --embed-icu (no other options), attempt to link miniSphere to the shared library it creates and get a bunch of undefined reference errors for icu symbols (see a few posts above, I posted the complete list of errors).

What more do you need to know?

The scenario you mentioned works on CI (test/native-tests/test-shared-basic).  I'm trying to understand what is actually different with your build (CC linkage)

If it helps at all, here's the relevant part of my makefile:
https://github.com/fatcerberus/minisphere/blob/master/Makefile#L110-L118
Pretty standard stuff, I think.

Also here's everything else I link to if it matters:
https://github.com/fatcerberus/minisphere/blob/master/Makefile#L36-L39

@fatcerberus I got the same errors after building CC on a dirty out folder. Can you please clean build folder for CC and retry?

@obastemur Thanks, just tried that about 5 minutes ago.  I blew away my entire CC directory, cloned fresh from master and rebuilt with ./build.sh -j=8 --embed-icu, but got the exact same errors when linking to the binary. ☹

can you try the following;
cd test/native-tests/
 ./test_native.sh <path for shared ch binary> <build type i.e. Test or Debug ..>

fatcerberus@pig-cult-vm:~/src/ChakraCore/test/native-tests$ ./test_native.sh ~/src/ChakraCore/out/Release/ch Release
Using CC [/usr/bin/clang-3.8]
Using CXX [/usr/bin/clang++-3.8]
ls: option requires an argument -- 'w'
Try 'ls --help' for more information.
Testing test-shared-basic
FATAL ERROR: Unable to load /home/fatcerberus/src/ChakraCore/out/Release/libChakraCore.so GetLastError=0x7e
Makefile:1: *** missing separator.  Stop.
./test_native.sh: line 67: ./sample.o: No such file or directory
test-shared-basic FAILED

FATAL ERROR: Unable to load /home/fatcerberus/src/ChakraCore/out/Release/libChakraCore.so GetLastError=0x7e

Error code 126 means.. (among other things) it can't load libChakraCore.so because of a dependency.
It could be really nice if you may send a full raw log for the script below; (assuming you are under ~/src)
git clone https://github.com/Microsoft/ChakraCore cccc
cd cccc
./build.sh --embed-icu -j
cd test/native-tests/
./test_native.sh ~/src/cccc/out/Release/ch Release

When I do this on various systems, it doesn't fail.

@obastemur Still failing. 😭   Here's the full output running the exact commands you listed:
https://drive.google.com/open?id=1Kkcmr28dqKXuf468JykPHZTcrbKLQH__

Thanks! I will normalize the log you sent and compare to mine / CI.. lets see what’s going on

@fatcerberus most likely there is no ch binary in ~/src/cccc/out/Release/ch ?
If there is;
cd test/native-tests/test-shared-basic/
`~/src/cccc/out/Release/ch Platform.js > Makefile
make

What do you got?

I just checked, the ch binary is there.
fatcerberus@pig-cult-vm:~/src/cccc$ cd test/native-tests/test-shared-basic
fatcerberus@pig-cult-vm:~/src/cccc/test/native-tests/test-shared-basic$ ~/src/cccc/out/Release/ch Platform.js > Makefile
FATAL ERROR: Unable to load /home/fatcerberus/src/cccc/out/Release/libChakraCore.so GetLastError=0x7e
fatcerberus@pig-cult-vm:~/src/cccc/test/native-tests/test-shared-basic$ make
Makefile:1: *** missing separator.  Stop.
fatcerberus@pig-cult-vm:~/src/cccc/test/native-tests/test-shared-basic$

I am going to assume this is resolved; feel free to re-open it in the future if something similar comes up. I am not sure if 14.04 works yet but at this point that should probably be a different issue if someone still wants it, and can probably be worked around with --embed-icu regardless.


Dot-separated field names are converted to object forcedly

I am trying to send request with field name like 'campaign.type'. The name is provided by API and I can't change it. Redux-form automatically converts it to nested object so I can't send it. Is there any possibility to turn off this feature?

Not that I know of, but the submit function provides the values as an object with the name as the key, so it should be possible to name it something else at the field level and then change the name in your submit function.

@tstirrat15 is correct.


v0.50.1 breaks statsd/prometheus metrics collection

Describe the bug
Upgrading to v0.50.1 from v0.40.2 breaks the metric collection in prometheues
To Reproduce
Upgrade with the procedure in the datawire blog

Upgrading to Ambassador 0.50.1
Ambassador relies on Kubernetes deployments for updates. To update Ambassador, change your Kubernetes manifest to point to quay.io/datawire/ambassador:0.50.1 and run kubectl apply on the updated manifest. Kubernetes will apply a rolling update and update to 0.50.1.

Also note that it is not possible to upgrade vial Helm chart as it still points to 0.40.2 and the Chart is used to define the tag of the docker image.
Expected behavior

Metrics are displayed in prometheus
Documentation reflects reality ;)

Versions (please complete the following information):

Ambassador: v0.50.1
Kubernetes environment: AWS via Kops
Version: 1.10.X

There are some hints on the issues and PRs here and there about a change in this regard, it would be nice to know how to get this working

Can you give some more specifics about how "things are broken"? We've tested statistics collection extensively in 0.50 and 0.50.1 and haven't seen any issues. Have you carefully followed the documentation here: https://www.getambassador.io/reference/statistics#exposing-statistics-via-statsd?

Thanks for the link @richarddli  here is what my configuration looks like right now:
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "6"
  creationTimestamp: null
  generation: 1
  labels:
    app: ambassador
    chart: ambassador-0.40.2
    heritage: Tiller
    release: ambassador
  name: ambassador
  selfLink: /apis/apps/v1/namespaces/ambassador/deployments/ambassador
spec:
  progressDeadlineSeconds: 600
  replicas: 3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: ambassador
      release: ambassador
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      annotations:
        prometheus.io/port: "9102"
        prometheus.io/scrape: "true"
      creationTimestamp: null
      labels:
        app: ambassador
        release: ambassador
        service: ambassador
    spec:
      containers:
      - args:
        - -statsd.listen-address=:8125
        - -statsd.mapping-config=/statsd-exporter/mapping-config.yaml
        image: prom/statsd-exporter:v0.6.0
        imagePullPolicy: IfNotPresent
        name: statsd-sink
        ports:
        - containerPort: 9102
          name: metrics
          protocol: TCP
        - containerPort: 8125
          name: listener
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /statsd-exporter/
          name: stats-exporter-mapping-config
          readOnly: true
      - env:
        - name: STATSD_ENABLED
          value: "true"
        - name: AMBASSADOR_ID
          value: production
        - name: AMBASSADOR_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        image: quay.io/datawire/ambassador:0.50.1
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /ambassador/v0/check_alive
            port: admin
            scheme: HTTP
          initialDelaySeconds: 30
          periodSeconds: 3
          successThreshold: 1
          timeoutSeconds: 1
        name: ambassador
        ports:
        - containerPort: 80
          name: http
          protocol: TCP
        - containerPort: 80
          name: https
          protocol: TCP
        - containerPort: 8877
          name: admin
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /ambassador/v0/check_ready
            port: admin
            scheme: HTTP
          initialDelaySeconds: 30
          periodSeconds: 3
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            cpu: 300m
            memory: 256Mi
          requests:
            cpu: 100m
            memory: 128Mi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      serviceAccount: ambassador
      serviceAccountName: ambassador
      terminationGracePeriodSeconds: 30
      volumes:
      - configMap:
          defaultMode: 420
          items:
          - key: exporterConfiguration
            path: mapping-config.yaml
          name: ambassador-config
        name: stats-exporter-mapping-config
status: {}```

However if I port-forward into any of the pods to port 9102 in `/metrics` I don't see any `envoy*` related metrics. This used to work in `v0.40.2`

This are my mappings
```apiVersion: v1
data:
  exporterConfiguration: |
    ---
    mappings:
    - match: 'envoy.cluster.*.upstream_cx_connect_ms'
      name: "envoy_cluster_upstream_cx_connect_time"
      timer_type: 'histogram'
      labels:
        cluster_name: "$1"
    - match: 'envoy.cluster.*.upstream_rq_total'
      name: "envoy_cluster_upstream_rq_total"
      timer_type: 'histogram'
      labels:
        cluster_name: "$1"
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: ambassador-config
  selfLink: /api/v1/namespaces/ambassador/configmaps/ambassador-config```

having a similar issue, here is the issue I am getting
2019-02-11 14:45:44 diagd 0.50.1 [P44TAmbassadorEventWatcher] ERROR: Unable to resolve statsd-sink to IP : [Errno -2] Name does not resolve
2019-02-11 14:45:44 diagd 0.50.1 [P44TAmbassadorEventWatcher] ERROR: Stats will not be exported to statsd-sink

Thanks @tzilist I can confirm this is indeed the problem. It seems that the project is moving away from sidecar containers to a single statsd sink (this from a PR not yet merged of the helm chart) so maybe it was just tested with such a configuration.

@AlexRRR glad to help :)
@richarddli It might be worth having someone run through the docs for setting up monitoring as well as the sections about istio, both seem to be outdated now. Thanks for all of the hard work you guys do though, loving ambassador so far!

@tzilist Thanks. Am I sensing that you're volunteering? :-)

@richarddli Oof, I wish I had time! I will in about 2 weeks, if they haven't been updated, I'll go through them and add some extra things I did to debug and set up ambassador properly :)

Can confirm that STATSD_ENABLED=true and STATSD_HOST=localhost works with the prom exporter :)

An updated ambassador chart was just merged to helm/charts! 🎉 would be great if you could test it :)

@Flydiverny  thank you for getting that in! I'll test it today!

I've updated the docs in #1220, and DaveOps is also working on some additional improvements. I believe that addresses this issue.


Incoming transaction notification

When a new transaction is received, the app will display a notification for the user.
This can be displayed directly to the user when they are in the app, and would look simliar to the transaction sent dialog. If the app is not in the foreground, a notification will also display in the tray. In the settings there will be an option to disable the notification.

verified working in latest build


DragListener blocks touch input on descendants

When using a DragListener on a Node with descendants with other input listeners, the DragListener seems to block touch input on those listeners. Mouse input works fine. I noticed this with a scenery-phet/TimerNode:
    const timerNode = new TimerNode( timeProperty, isRunningProperty );
    timerNode.addInputListener( new DragListener( {
      translateNode: true
    } ) );

TimerNode can be dragged but the buttons cannot be clicked. Saw this on an iPad and on my Windows laptop touchscreen. IF the DragListener is replaced with a SimpleDragHandler, the problem goes away.
Only seen with a scenery-phet/TimerNode so far.

Verified in another spot - scenery-phet's DemoScreenView, I swapped the MovableDragHandler on the ConductivityTesterNode with a DragListener. When this is done, dragging the probe nodes drags the entire ConductivityTesterNode rather than the probes.

TimerNode has a timerNode.dragTarget which drag listeners should be added to just for this reason. Unfortunately we'll need to do similar things for full components with buttons.

Ah, I see, thanks. Just out of curiosity, why does this happen for touch and not mouse?

Ah, I see, thanks. Just out of curiosity, why does this happen for touch and not mouse?

I recall it's related to touch snag, where the drag touch snag activates before the press on the button could happen.

Got it, thanks.
I got it working by copying the example in gas-properties StopwatchNode. The listener is added to the TimerNode.dragTarget, but the targetNode specified on the DragListener is still the TimerNode.
      this.dragTarget.addInputListener( new DragListener( {
        targetNode: this,
        //...
      } ) );


Generate beauty Signatum address via Vanitygen

Hi, all ... There is a question about generating Signatum addresses via vanitygen tool. I was tried to generate some addresses with address version 25 via vanitygen. For example:
Address: BTestyoaWqbPx7PR37waTGUSSFCRFWtqWu                  Privkey: 69kJq3sW3CVSAveV2vGb7LtuGsT2XJPhGPFMEvMzqtVAkmjZQeL
But when i'm trying to import this privkey to signatum-qt wallet via importprivkey it says that the key is invalid. Who can explain why? What the difference between key generation in vanitygen and signatumd? May be i miss something and setting address version 25 is not enought?

Problem is solved. Here is a my fork of vanitygen - https://github.com/DeckerSU/vanitygen with Signatum Coin addresses support.