Updates to make interbroker links more stable.

Updates to messageEvictionStrategy to prevent buildup of messages in queue for topics on larger clusters.

This relates to https://tickets.puppetlabs.com/browse/MCO-58

Waiting for CLA signature by @web-flow
@web-flow - We require a Contributor License Agreement (CLA) for people who contribute to Puppet, but we have an easy click-through license with instructions, which is available at https://cla.puppet.com/
Note: if your contribution is trivial and you think it may be exempt from the CLA, please post a short reply to this comment with details. http://docs.puppet.com/community/trivial_patch_exemption.html

This seems to fall under the Trivial Patch Exemption Policy as it "introduce no new functionality."

It should be fine; submitting commits via the web interface doesn't work well with our bot either.

Ya not a problem the biggest part is the addition of a pruning strategy otherwise topics keep an ungodly amount of messages around. This seems to be the cause of some instability. Another recommendation is to upgrade to a full mesh as that helps with intermittent network or link issues.
<messageEvictionStrategy>
  <oldestMessageEvictionStrategy/>
</messageEvictionStrategy>
<pendingMessageLimitStrategy>
  <prefetchRatePendingMessageLimitStrategy
    multiplier="2"
  />
</pendingMessageLimitStrategy>

CLA signed by all contributors.


Use GraalVM JDK shouldn't be mandatory for dockerBuildNative

If a user wants to create a native image inside a docker container it shouldn't be mandatory to use GraalVM JDK for running the command, because the native-image is generated inside the container.
$ java -version
openjdk version "1.8.0_265"
OpenJDK Runtime Environment (build 1.8.0_265-b01)
OpenJDK 64-Bit Server VM (build 25.265-b01, mixed mode)

$ ./gradlew dockerBuildNative
> Task :complete:compileJava FROM-CACHE
> Task :complete:processResources UP-TO-DATE
> Task :complete:classes UP-TO-DATE
> Task :complete:runnerJar
> Task :complete:buildLayers
> Task :complete:dockerfileNative FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':complete:dockerfileNative'.
> A GraalVM SDK is required to build native images

With GraalVM JDK:
$ ./gradlew dockerBuildNative
> Task :complete:compileJava FROM-CACHE
> Task :complete:processResources
> Task :complete:classes
> Task :complete:runnerJar
> Task :complete:buildLayers

> Task :complete:dockerfileNative
Dockerfile written to: /home/ivan/workspaces/micronaut/micronaut-guides/micronaut-creating-first-graal-app/complete/build/docker/DockerfileNative

> Task :complete:dockerBuildNative
Building image using context '/home/ivan/workspaces/micronaut/micronaut-guides/micronaut-creating-first-graal-app/complete'.
Using Dockerfile '/home/ivan/workspaces/micronaut/micronaut-guides/micronaut-creating-first-graal-app/complete/build/docker/DockerfileNative'
Using images 'complete'.
...
...

I understand that for nativeImage task is mandatory to use GraalVM JDK and that both tasks use the dockerfileNative task but maybe the check could moved and only executed in former instead of the latter.
More info
Plugin version: 1.0.3

I disagree, we would have to add all sorts of checks to check whether the use built on an unsupported JDK version such as 12/13/14/15 to the plugin.
The alternative would be to build the project with docker but that means dealing with how to cache dependencies inside the docker build and all sorts of other problems.

I understand this, but from a user point of view we have now less functionality than before.
Without the plugin the users only needed to generate the fatjar and run the docker build script. They didn't need to install GraalVM. Now they do.
I agree that if user builds the fatjar locally with JDK 14, then the native-image generation would fail.

IMO this is a better user experience ensuring that they build with GraalVM rather than leaving it up to chance whether they have a correct version of Java or not that is compatible with native image.
I am ok with making the behaviour configurable but ultimately the previous behaviour of allowing the user to build with an unsupported JDK then failing later was worse.

I think what I will do is limit the JDK to a maximum of 11 when running ./gradlew dockerBuildNative

If the native image is built inside a container, I still don't get why having GraalVM locally matters

because the class files are built locally and copied into the container so if you build with a JDK that is incompatible with native image (JDK 12+) then native image will fail

I understand, but still doesn't make sense. Doesn't make sense to require them build the JAR locally with GraalVM, then use native-image inside a container to build the binary.
If I were to have GraalVM locally, I would just use nativeImage.
The point of dockerBuildNative, IMO, is to be able to build a native image regardless of what I use locally. You could craete a multi-stage Docker image with a build stage that has FROM oracle/graalvm-ce:20.2.0-java8 or FROM oracle/graalvm-ce:20.2.0-java11 and then ./gradlew assemble it.

That is a bad user experience IMO as you have to redownload the gradle dependencies and wrapper on every build unless you figure out some complex way to cache the gradle cache in a docker layer

What if we only check, as @graemerocher already mentioned that they are using a maximum of JDK 11 (no matter which JDK-vendor)?
This way the users can build the application with a non-GraalVM JDK and if "it's valid" (JDK 8 or 11), then we allow to create the native image using it.

That seems reasonable to me

Yes, it is possible, and yes, this was done if you created an application with the graalvm and aws-custom-runtime features.

The downside of this approach is you have to replicate the gradle cache and wrapper in a docker layer which is wasteful imo. I think it would be better just to have a check that the java source target version is set to 11 or below

The docker layer will be cached, so it will only have to download wrapper/dependencies once.
And it shouldn't affect the final image size since that build stage would be removed.

Fixed by https://github.com/micronaut-projects/micronaut-gradle-plugin/pull/58


Add interface on TelemetryClient

I wish TelemetryClient implemented an interface so that it would be easier to switch the client in automated tests

We would typically initialize TelemetryClient with the test channel like this.
Which methods would you prefer to have in interface - high level like TrackException or lower level like Track that accepts ITelemetryChannel. Do you plan to test telemetry or just replace actual client with the one that does nothing?

I have both use cases: replacing the client to avoid a network dependency and verify the telemetry
It looks like StubTelemetryChannel solves both cases. Then I am happy and don't really need the interface.

@ogborstad I'm glad it is working for you. We still thinking what would be the best way to enable easy testing of telemetry client and use it with the DI. Thanks for asking!

@SergeyKanzhelev  Is there any update here? Did the team decide not have an interface at all?
I believe having an Interface can help easily mock (use other advanced  features) that most of the testing frameworks like Moq provide. Creating a StubTelemetryChannel is helpful but I think we can do better

@GiriB for now we will proceed with the mock channel. Since there is no reason TelemetryClient will ever be used as an interface in production code - defining it will cause confusion.

@SergeyKanzhelev what sort of confusion are you referring to? My team would very much benefit from having an interface for TelemetryClient so that we can use Moq to verify we are passing the correct dimensions to a metric. Yes, it is possible to do this today without Moq, but it is much more code than it needs to be.

@SergeyKanzhelev Your example of the stubbed telemetry channel involves using the TelemetryClient's constructor which is marked obsolete. Would be nice to have a mocked instance of TelemetryClient without all the compiler warnings that come with it today.

@SergeyKanzhelev Yes, please reconsider. ^^^
Simply asking that the TelemetryClient implement an ITelemetryClient so we can verify the TrackMetric calls.
That is the right level for us to verify. Our prod code knows nothing whatsoever about ITelemetryChannels, it would be weird if its unit tests had to. Doing so in effect makes the TelemetryClient part of the unit being unit tested, and that is of no interest to us.

Is there any updates on this? It seems to me that ITelemetryClient would be a very straightforward implementation and would simplify many use cases for developers, just like we have ILogger.

@TimothyMothra @cijothomas @lmolkova @SergeyKanzhelev could one of you reopen this issue please?
The TelemetryClient should support an interface to make it nice and easy to mock out.
I never yet wrote a unit test that wanted to cover the App Insights SDK code.

I'll reopen the issue for further consideration.
Unfortunately, there are no work planned in this area in near term, so no guaranteed when or if this will be addressed.
Azure monitor/Application Insights' overall direction is alignment with OpenTelemetry, so this can be discussed more when ApplicationInsights/OpenTelemetry integrations starts shipping ~towards end of 2020

cc: @rajkumar-rangaraj as Raj will be working on ApplicationInsights/OpenTelemetry integrations.

Do you have any update to share about this issue ? has it been shipped in any version (released or preview) ?

Do you have any update to share about this issue ? has it been shipped in any version (released or preview) ?

No update. No work is done on changing this so far.
(This is unlikely to come soon, as the long term plan is to align with OpenTelemetry)

Why is it so difficult to add an interface and make a lot of developers happy?
For me, I just want to test if the method TrackEvent of TelemetryClient is called.
This item is open for almost 5 years and still actual.
Please implement ITelemetryClient.

Can someone at least put a link to StubTelemetryChannel? It would make this a lot easier

https://github.com/microsoft/ApplicationInsights-dotnet/blob/develop/WEB/Src/TestFramework/Shared/StubTelemetryChannel.cs

Hi all,
I've written a small package that acts as an interface for TelemetryClient. It just requires another registration line in your ServiceCollection (services.AddApplicationInsightsTelemetryClientInterfaces())
Then you can inject an ITelemetryClient into your class. Or more specific ones like ITelemetryEventLogger or ITelemetryTraceLogger.
Enjoy.
Github Link:
https://github.com/thomhurst/ApplicationInsights.TelemetryLogger
NuGet:
Install-Package TomLonghurst.ApplicationInsights.TelemetryLogger

Adding yet another comment in support of this. This would be super useful! We just want to be able to verify that the right method from the TelemetryClient is called with the expected parameters. Don't really want to introduce a unofficial third party library to wrap it or need to code a custom wrapper, just for testing. Is this going to be re-considered please?

Found myself again in a position where I simply needed to mock a telemetry client to pass in a dependency to satisfy the constructor when the tests themselves couldn't care about the telemetry itself.
Beating the drum for this long-standing request to be solved officially.

Same here. It can't be that hard to add this Interface. It would make developers live much easier. Do we need wait five more years?

Instead of an interface, here's a complete example using a stub telemetry channel. I've kept everything in one file and eliminated some blank lines, just for exposition purposes.
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.Channel;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using System.Collections.Concurrent;
using Xunit;

namespace TestProject1
{
    public class UnitTest1
    {
        private ConcurrentQueue<ITelemetry> TelemetryItems { get; } = new ConcurrentQueue<ITelemetry>();

        [Fact]
        public void Test1()
        {
            var telemetryClient = CreateMockTelemetryClient();
            var componentUnderTest = new ComponentUnderTest(telemetryClient);

            componentUnderTest.Test();

            Assert.True(TelemetryItems.TryDequeue(out ITelemetry? first));
            Assert.IsType<RequestTelemetry>(first);
            Assert.Equal("ItWorks", ((RequestTelemetry)first!).Name);
        }

        private TelemetryClient CreateMockTelemetryClient()
        {
            var telemetryConfiguration = new TelemetryConfiguration
            {
                ConnectionString = "InstrumentationKey=" + Guid.NewGuid().ToString(),
                TelemetryChannel = new StubTelemetryChannel(TelemetryItems.Enqueue)
            };

            // TODO: Add telemetry initializers and processors if/as necessary.
            return new TelemetryClient(telemetryConfiguration);
        }
    }

    /// <summary>
    /// A telemetry channel that simply calls a delegate.
    /// </summary>
    internal sealed class StubTelemetryChannel : ITelemetryChannel
    {
        private readonly Action<ITelemetry> _onSend;
        public StubTelemetryChannel(Action<ITelemetry> onSend) => _onSend = onSend ?? throw new ArgumentNullException(nameof(onSend));
        public bool? DeveloperMode { get; set; }
        public string EndpointAddress { get; set; } = "";
        public void Dispose() { }
        public void Flush() { }
        public void Send(ITelemetry item) => _onSend(item);
    }

    internal class ComponentUnderTest
    {
        private TelemetryClient _telemetryClient;
        public ComponentUnderTest(TelemetryClient telemetryClient) => _telemetryClient = telemetryClient;
        public void Test()
        {
            using var operation = _telemetryClient.StartOperation<RequestTelemetry>("ItWorks");
            // TODO: Body of test
        }
    }
}

The interesting parts here are:

The StubTelemetryChannel which just invokes a delegate on Send.
Setting up a mock TelemetryClient that uses that stub channel. The delegate enqueues each telemetry item to a ConcurrentQueue that's accessible to the unit test.
Passing that mock TelemetryClient to the component under test. This could also be done via dependency injection if that's more suited to your environment.

Obviously, all of this can be customized as appropriate for your application and testing environment.

FYI There is an excellent pr here:
https://github.com/microsoft/ApplicationInsights-dotnet/pull/2761
Unfortunately there is no (usefull) response why it isn't getting merged.


average energy computation for the Wishart node

I've been looking into the computation of average energy for the Inverse-Wishart node.
So I had a look at the computation of this quantity for Wishart node as well.
It appears to me that the average energy computation for the Wishart node is incorrect, i.e.,
@average_energy Wishart (q_out::Any, q_ν::Any, q_S::Any)
You would normally expect q_out to be Wishart distribution, meaning that we'd need to take the log expectation of q_out, not just logdet(m_q_out) where m_q_out = mean(q_out).
It seems to me that ForneyLab.jl does it properly. Is there something I miss?

I think you might be right. Previously (before @bvdmitri introduced the mean(logdet, x) syntax) this also was incorrect for the Gamma node. It seems that we overlooked this one.

I guess we are missing the mean(inverse, x) function for some distributions.

Indeed it looks like an artefact of the old confusion between unsafeDetLogMean(...) and logdet(mean(...)), which was wrong. We replaced logdet(mean()) with mean(logdet, ...) but overlooked this one. Thanks @albertpod !

Fixed with #149 . Thanks @albertpod !


labels disappear when used in an overlay of image and vectorfield

The problem with the label occurs when img * hv.Vectorfield is used, see example below.
import numpy as np
import holoviews as hv
hv.notebook_extension('matplotlib',width=90)

# image
x,y = np.mgrid[-50:51, -50:51] * 0.05
z = x**2+y**3
bounds = (-2.5, -2.5, 2.5, 2.5)
img = hv.Image(z, bounds=bounds, label='image')

# vectorField
vx,vy = np.gradient(z)

vslice = slice(0, vx.shape[0], 4)
slicy = (vslice,vslice)
xx = x[slicy]
yy = y[slicy]
cmplx = vx[slicy] + 1j * vy[slicy] # complex arrow
mag = np.absolute(cmplx)
angle = np.angle(cmplx)

vector_data = (xx.flat,yy.flat,angle.flat,mag.flat)

#layouts
plot = img # WORKS!
plot = hv.VectorField(vector_data,label='quiver') # WORKS!
plot = img * hv.VectorField(vector_data,label='test1 with vectorField') #  both labels gone
plot = hv.Layout(img * hv.VectorField(vector_data),label='test2') # also both labels gone

plot

The plot with a single img and vectorField have a label above the plot, when chosen. Just comment the rest of the plots.
The latter two plots loose both labels!
In contrast, contour plots don't have that problem, which are in my opinion a similar use case.
%%opts Image (cmap='viridis')
%%opts Contours [show_legend=False colorbar=True width=325] (cmap='fire')
# taken from contours example, slightly altered

x,y = np.mgrid[-50:51, -50:51] * 0.05
img = hv.Image(np.sin(x**2+y**3), label='test label')

z0, z1 = img.range('z')
img * hv.operation.contours(img, levels=np.linspace(z0, z1, 5), overlaid=False)

For multiple curves there is a legend. An option here?

In general, an Overlay (which is what * constructs) will inherit the labels of the items that are being overlaid, but only if all the items overlaid have the same label.  There's a very good reason for that---anything can be overlaid onto anything else, and result isn't one or the other of those things, it's the combination, and there's no obvious way to combine multiple labels unless they are identical to each other.
For convenience, in certain cases where we know that one of the items is not likely to have a useful label (as for annotations) or when we know that what's being overlaid all comes from the same source (as for certain operations), we do show the label of the "main" plot.  But if you want to show a label in any other cases, or want a different label for the combination, you'll need to provide a label for the combined, overlaid object.  Here, just do ``plot.relabel('New label') at the end, with whatever the combined plot should be labeled.

If you'd like to vote that we add a label for the combined plot constructed from the individual labels, please do!  E.g. do people think it would be more useful for the result to have the label "image * quiver"?  That would certainly make sense to other HoloViews users, but I'm not sure whether it's a better default behavior than having no label. Any opinions?

Thanks for your reply and the relabel hint.
I agree that inheriting different labels might be hazardous and cumbersome in an overlay when used excessively, e.g., "image * quiver * contour" (* curve ... or even more?!).
In my case I want to plot some image data and on top some flow pattern with the vectorfield (or contours).
I want to annotate this plot in order to embed it in a layout of similar plots with different physical quantities, so some people might want it.
For me works plot.relabel(label1 + ' ' + label2 ). In my opinion it is not logical that labelling is different for contours, where one gets at least the image label. I think this is a common use case and shouldn't be treated differently.
Maybe there are just some examples missing to showcase such combinations?

If you look at the contours by themselves, you'll see that they have the same label as the original image:

So there's no special case for contours; your vector field will work the same way if you give it the same name as your image.  The only difference is that here the contours automatically inherit the label of the underlying image, because they are constructed from it, whereas you are explicitly giving your VectorField a different label when you construct it.
Maybe instead you want to argue for overlay to ignore an empty/default label on the VectorField object, like we do for annotations?

Yes, that would definetely do it.

I think it might be a sensible policy to ignore empty/default labels in general so when you overlay a labelled thing it doesn't automatically override that label. The distinction between annotation and regular elements isn't very clear cut imo since you can use points to annotate something and generally it shouldn't ignore your label just because you've overlaid it.

I think that might be a less surprising and more useful policy. @jlstevens, any opinion?

I think we might want a backwards compatibility switch but otherwise ignoring empty/default labels might be a more sensible policy.


fix: apply a templ prefix to all variables that templ uses within a template to reduce clashes, fixes #169

Looks good to me. Only thought is maybe would be a degree safer if these vars were generated from a hash of the variable name:
varName("ctx") // templ_ctx_166362
Could be overkill? But might reduce the likelihood of a clash by another big chunk. And since it's a hash there's no git thrashing.


Idea - possibility of creating instances with no printer, but only uStreamer webcams?

So i run a printfarm where i use your script, and i love it!! However i would like to run my webcams on a seperate print, and the process of creating multiple instances of uStreamer seems complicated.
It occured to me that your script can do exactly this with proper serial # detection of the cams(very nice)
However your script will not allow me to create a "blank instance" (where i dont connect any printer but only a webcam). Is it possible to make this an option? Or is there an easy way for me to modify your script to do this?
Again, thanks so much for this genius developement!!

I will consider it, but I generally hate webcams and the support they require, so it might take a lot of motivation for me to get around to it.
Building and installing ustreamer is not hard, and the service files are quite straightforward. That would be the ideal approach. There is a work around if you want run webcams on a separate machine from the printers but still use octoprint_deploy for creating ustreamer service files:
Setup the other machine the same way you would with octoprint_deploy.
Add an instance and use a free printer board or one of your other printers to do the autodetection to make a "fake" instance. It would be best to use one that does not have a serial number in this case, but it doesn't really matter.
Setup the camera for that "fake" instance as you would normally.
Then, you can simply turn off the fake instance so it won't  start on boot: sudo systemctl disable fakeinstancename
You can now do this with all your other cameras, using the same printer board or printer to make fake instances, but with installed cameras. You would then need to edit your other OctoPrint instances to point to the host and port of the machine you have the cameras install on.

Wow, thanks for the quick reply.
I agree that webcams are a hassle! When you mean printer board, you mean basically take a mainboard out of a printer and plug it in? (I have an old ender mainboard at home, im pretty sure those have no serial number)
Would the mainboard require 24v power in order to be detected? Or can i simply utilize the USB connection?

Yes, just a free board. If it would need to be powered likely depends on the board. I suspect since most creality board can be backpowered, you would not need to supply 24V. Most of my old RAMPS-clones I use for testing do not need to be powered either.

Thanks a lot for your help. I'll mark this as closed and attempt this as soon as possible!

I tried this idea and it worked great using a dummy mainboard. Thanks!
However, my logitech C270 webcams apparently have the same serial #, so the symlinks/udev rules cause some issues
I tried to edit the udev rules in order to mimick the mainboard rule, so that the cameras are linked to a physical port - i found the part in "KERNELS==" by running udevadm monitor and unplugging/pluggin each camera"
However it doesnt work still after a reboot - uStreamer shows error "Can't access device: No such file or directory"
Any ideas about how i can fix this?


chore: chore: add msteams destination support

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Program]: Write a Haskell program to convert a string to an integer

Description
Write a Haskell program to convert a string to an integer
Input  : "123"
Output : 123

How to contribute

Save the solution in program/program/convert-a-string-to-an-integer/program/convert_a_string_to_an_integer.hs file

!assign


Prevent potential OOB memory access in secure heap implementation if a custom allocator is used

Prevent allocations of size 0 in sh_init, which are not possible with the default OPENSSL_zalloc, but are possible if the user has installed their own allocator using CRYPTO_set_mem_functions. If the 0-allocations succeeds, the secure heap code will later access (at least) the first byte of that space, which is technically an OOB access. This could lead to problems with some custom allocators that only return a valid pointer for subsequent free()-ing, and do not expect that the pointer is actually dereferenced.
An allocation of 0 is attempted if size is twice the value of minsize, for example:
CRYPTO_secure_malloc_init(4096, 2048)

7f07149 in master and be31d57 in 1.1.0  Thanks!


cli: error when exporting *_VERSION env vars with values service_name+service_version

$ docker-services-cli --version
docker-services-cli, version 0.3.0

Description
When a user exports one of the reserved environment variables to set the selected service version ([ELASTICSEARCH|REDIS|POSTGRESQL]_VERSION) in a string+version format e.g. postgresql7 the execution fails.
Steps to Reproduce
$ export ELASTICSEARCH_VERSION=elasticsearch7
$ docker-services-cli up --search $ELASTICSEARCH_VERSION
Environment variable for version elasticsearch7 not set             or set to a non-compliant format (dot separated numbers).

Expected behavior
$ export ELASTICSEARCH_VERSION=elasticsearch7
$ docker-services-cli up --search $ELASTICSEARCH_VERSION
Environment setup
Creating network "docker_services_cli_default" with the default driver
Creating docker_services_cli_elasticsearch_1 ... done
elasticsearch not ready at 1 retries, waiting 2s
elasticsearch not ready at 2 retries, waiting 4s
elasticsearch not ready at 3 retries, waiting 8s
elasticsearch up and running!
Services up!
$ docker ps | grep -i elasticsearch-oss:7
563d457cbfd6   docker.elastic.co/elasticsearch/elasticsearch-oss:7.9.0   "/tini -- /usr/local…"   51 seconds ago   Up 50 seconds   <IP_ADDRESS>:9200->9200/tcp, <IP_ADDRESS>:9300->9300/tcp   docker_services_cli_elasticsearch_1

It should not fail.
I should boot up the correct Elasticsearch version as if one would execute docker-services-cli up --search elasticsearch7 directly.

Possible solutions

Use the same logic to extract versions from service+version strings inside _load_or_set_env .
Rethink how environment variables are handled inside this module?

Additional context
This has blocked invenio-records-resources builds. See more here.

My understanding was that you had to provide a real version, for example:
$ export ELASTICSEARCH_VERSION=7.2.0

This does not work either. It looks like the code is overriding for some reasons the given version in the function override_default_env.
Before the execution of that function, the env var ELASTICSEARCH_VERSION has correctly the version 7.2.0, but then inside that function it takes the latest value:
                    if (SERVICES_ALL_DEFAULT_VERSIONS.get(
                       env_var_with_version)):
                        os.environ[
                            f"{service_name.upper()}_VERSION"
                        ] = SERVICES_ALL_DEFAULT_VERSIONS.get(
                            env_var_with_version
                        )

See here the code. I don't know what was the intended behaviour, so not sure how to fix it, maybe @ppanero has an idea...

@ntarocco the intended behaviour was to load a "pre-configured" version for e.g. ES 7, meaning not having to worry about minor/patch versions. Many parts of this module were re-written in the last sprint but as a first, I think:

The error message comes from here. Which tries to load the values from the environment.
However, (cc @diegodelemos) no elasticsearch7 value is being exported to the env in here
The conversion from elasticsearch7 to ELASTICSEARCH_7_LATEST_VERSION is done here
However, the call to set_env() happens way before the conversion (here).

I can dig deeper once I'm back but basically, I think it a matter of "when is the var exported" vs "when is the var supposed to be available"... Hope it helps.

Everything is working fine, however, there is an incompatibility between configuring from the environment and configuring from command-line options (see collapsible at the end to know why these two ways coexist). If you follow scenarios 1 and 2 described below you should have no problems with this tool, if you are having problems with the conflict (topic of this ticket) and you can't use the other ways, we can give this issue more priority.

Scenario 1: using just environment variables to configure service versions:

$ export ELASTICSEARCH_VERSION=7.2.0
$ docker-services-cli up --search elasticsearch
Environment setup
docker_services_cli_elasticsearch_1 is up-to-date
elasticsearch not ready at 1 retries, waiting 2s
elasticsearch not ready at 2 retries, waiting 4s
elasticsearch not ready at 3 retries, waiting 8s
elasticsearch up and running!
Services up!
$ docker ps
CONTAINER ID   IMAGE                                                     COMMAND                  CREATED              STATUS              PORTS                                                                                NAMES
b2e4c4be75db   docker.elastic.co/elasticsearch/elasticsearch-oss:7.2.0   "/usr/local/bin/dock…"   About a minute ago   Up About a minute   <IP_ADDRESS>:9200->9200/tcp, <IP_ADDRESS>:9300->9300/tcp                                                                                docker_services_cli_elasticsearch_1

Scneario 2: just using command line options:

$ docker-services-cli up --search elasticsearch7
Environment setup
Creating network "docker_services_cli_default" with the default driver
Creating docker_services_cli_elasticsearch_1 ... done
elasticsearch not ready at 1 retries, waiting 2s
elasticsearch not ready at 2 retries, waiting 4s
elasticsearch not ready at 3 retries, waiting 8s
elasticsearch up and running!
Services up!
$ CONTAINER ID   IMAGE                                                     COMMAND                  CREATED              STATUS              PORTS                                                                                NAMES
2adcbb5b30ab   docker.elastic.co/elasticsearch/elasticsearch-oss:7.9.0   "/tini -- /usr/local…"   About a minute ago   Up About a minute   <IP_ADDRESS>:9200->9200/tcp, <IP_ADDRESS>:9300->9300/tcp                                                                                docker_services_cli_elasticsearch_1

Conflict: there is an incompatibility between Scenario 1 and Scenario 2 and it happens when one uses the reserved environment variable to govern the specific version of a service to pass arguments to the command line options (e.g. --search):

$ export ELASTICSEARCH_VERSION=elasticsearch7
$ docker-services-cli up --search $ELASTICSEARCH_VERSION
Environment variable for version elasticsearch7 not set             or set to a non-compliant format (dot separated numbers).

Background: why is it possible to configure from the environment and configure from command-line options ?

During the Travis to GH Actions sprint we refactored the CI matrix and to do so we opted to provide generic environment variables from the CI file (the matrix) to the script that executes docker-services-cli. Doing this with the previous way was a mess in GH Actions code.
What needs to be done:

Document the new behavior. We didn't have time to do so during the sprint
The old way of providing config was kept for backward compatibility (which I think we didn't achieve in the end due to unexpected changes in the requirements) but still, it is useful if one needs to provide specific minor versions (see the previous example, using Elasticsearch 7.3.0 instead of the default 7.2.0.


fixed profile pic display for facebook, twitter and google-plus registra...

Hi Ben.. I realised that all the profile picture urls for the facebook, twitter and google plus pics include 'picture' so added it to the options.

We need a better test for it. Currently it will match all files containing picture substring which may be wrong for some files. Maybe we can check for domain?


APP-4260 Changed the error handling logic to throw error.

By doing this the titanService detects that there was an error in gremlin and he can try to reconnect to titan.
Please @PedroKinetica, @amhester, @willcj33 review this.

LGTM :+1:

good catch Johny!

thanks guys for the review!


Can't see repositories in portus

I have setup Portus<--->registry<--->LDAP working together. I can push and pull to the registry as an ldap user. I can also login to Portus and registry as an ldap user. However when I enter Portus and don't see any images. Or in other words Portus does not show the images that definitely exist.
I have setup notifications in docker registry like so
notifications:
  endpoints:
    - name: portus
      url: https://portus.corp.acme.com/v2/webhooks/events
      timeout: 500ms
      threshold: 5
      backoff: 1s

Also when looking in the logs I can't see anything exceptional.
except maybe this. Can this be related to my problem?
I, [2016-04-23T11:31:53.975771 #60]  INFO -- : Perform CatalogJob
Exception: SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: unknown protocol
I, [2016-04-23T11:31:53.985223 #60]  INFO -- : Finished CatalogJob in 0.01 seconds

I changed now my registry configuration from
notifications:
  endpoints:
    - name: portus
      url: https://portus.corp.acme.com/v2/webhooks/events
      timeout: 500ms
      threshold: 5
      backoff: 1s

to
notifications:
  endpoints:
    - name: portus
      url: http://portus.corp.acme.com:3000/v2/webhooks/events
      timeout: 500ms
      threshold: 5
      backoff: 1s

And I don't get any CatalogJob  exceptions but Portus still does not display my registry content.

hi , i want to know , did you used the official Setup Script completed?
i can not push images and LDAP Integration of failure.
Thank you very much first.

Hi @Vad1mo, is there any way in which you could setup Portus in debug mode ? (see the last point of https://github.com/SUSE/Portus/blob/master/CONTRIBUTING.md#reporting-issues). This way we would be able to detect what happens to Portus when you push an image to your registry.
Besides that, make sure that you are using proper certificates (we get tons of issues that are similar to this and that were missing some steps or they had wrong certificates). Moreover, this message is particularly weird:
Exception: SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: unknown protocol

This basically means that the server is being "picky" on the version of accepted SSL version. Could you also check that ?
Besides that, could you give me information about the version of Portus, docker and your registry ?


Loading Rule is not thread safe

Describe the bug
A seclang_parser used for loading rules in ModSecurity uses global variables.
Due to that I was able to create a simple test proving that loading rules by different rule sets at the same time with multiple threads causes some random issues
https://github.com/SpiderLabs/ModSecurity/pull/2535/files
Logs and dumps
For trying to load the same rule SecAction "id:900000,phase:1,pass,nolog,setvar:tx.paranoia_level=1" multiple times I get different errors:
Examples:
'Rules error. File: <>. Line: 1. Column: 88. Expecting an action, got:  SecAction "id:900000,phase:1,pass,nolog,setvar:tx.paranoia_level=1"'
'Rules error. File: <>. Line: 1. Column: 27. syntax error, unexpected Phase '
'Rules error. File: <>. Line: 1. Column: 1. syntax error, unexpected "," '
To Reproduce
Steps to reproduce the behavior:
Download the branch from my forked repository: https://github.com/iosetek/ModSecurity/tree/load_rule_multiple_threads
Build the project, enter test directory and run ./unit_tests
The example output looks like this:
Executing thread tests.
Test: 'Test 1 thread' succeeded.
Test: 'Test 3 overlapping load rule threads' failed.
thread [0] returned: ''
thread [1] returned: 'Rules error. File: <<reference missing or not informed>>. Line: 1. Column: 88. Expecting an action, got:  SecAction "id:900000,phase:1,pass,nolog,setvar:tx.paranoia_level=1"'
thread [2] returned: ''
Test: 'Test 3 non overlapping load rule threads (delay between)' succeeded.

Expected behavior
The expected behaviour is for loading rules to be thread safe so the failing test from my fork would work.

@iosetek The bison LALR parser is not thread safe. I don't think it is meant to be thread safe. Why do want to load it with multiple threads/process?

@zimmerle Multiple threads are meant to be spawned in the environment to scan the upcoming requests. I couldn't figure out how to copy an existing ModSecurity::Rules object as it contains multiple raw pointers.

How would you suggest to have a multiple threads where each of them has one ModSecurity::Rules instance.
Is it the only place where ModSecurity is not thread safe? How about parsing multiple requests by a fixed number of threads. Can we use ModSecurity to scan two requests on two different threads at the same time?

@iosetek
The modSecurity life cycle is divided into different stages. The stage that the rules are loaded is not threading safe by design. The rules are meant to be loaded in a serial fashion, one file at a time, line by line. As the order of the rules matter, it is important to load it in the user-specified sequence. Changing the order expressed by the user may lead to a behavior that was not what the user expects. Therefore, as the rules need to be loaded sequentially, parallelism on that process may not add a benefit **. SecRule is a script-ish language, not a pattern match; one may say it is turing complete.
Once the rules are loaded (and pre-compiled?), multiple requests can share the same RulesSet object. Leading to parallelism while addressing different requests in different processes or threads. If the rules are loaded in the main process, before the fork, the physical memory will be shared among the different processes.
In the project source, we have different examples that illustrate some utilization of ModSecurity; you may want to have a look at multiprocess_c, there we treat a use case very similar to the one that you want to address -
https://github.com/SpiderLabs/ModSecurity/blob/4127c1bf52d2b30a5c2c3e641b8085fd9a720f43/examples/multiprocess_c/multi.c#L111-L131
** To a benefit, external downloads could be parallelized and cached. Not related to this particular issue.

@zimmerle Could I reach you on slack or any other chat? I feel it would be quicker to solve this and I could paste the conclusion here.
I am afraid that ModSecurity Rules are not thread safe not only during the process of reading files.
In ModSecurity/src/transaction.cc we can see that there is called m_rules->incrementReferenceCount(); in two places. This method looks like this:
void Rules::incrementReferenceCount(void) {
    this->m_referenceCount++;
}

This is a simple int so I don't think it's thread safe here.
Apart from that in my case I have multiple RuleSet instances. Each thread has its own instance. Even though those are different instances ModSecurity won't allow loading rules by different rule sets at the same time. You can check that in the PR I attached.
I believe we could share one RuleSet instance among all our threads but for now it seems that RuleSet is not thread safe completely (looking at the Transaction example).
Could I reach you on the chat?

@zimmerle Could I reach you on slack or any other chat? I feel it would be quicker to solve this and I could paste the conclusion here.

Sure - http://modsecurity.slack.com/

I am closing this issue. @iosetek has found a workaround by having a critical section on the rules load.
He does have a good and yet exciting use case for rules load. I am going to try to handle it on a new issue.

Hi @zimmerle,
Is this handled inside ModSecurity library?
We have a similar used case where we need to load multiple different rulesets in parallel. This is causing crash inside seclang-scanner.cc while accessing global variables.
Note - We are using ModSecurity library version 3.0.10.
Thanks,
Atul


title abrupt changes

As you can see, the second item shows abrupt changes when switched from it to another item:
https://user-images.githubusercontent.com/3332274/151884180-1f04b016-2a94-45c5-b67f-be7071165c18.mp4

I don't see any fidelity issues here, please re-open if you can provide a concrete comparison with the Salomon spec on Dribble

Reopening: is this the same issue?
Related to https://github.com/lukepighetti/salomon_bottom_bar/issues/26

Let's track this in #26


Fix github link

If we want it there at all, the self-referential github link should at least go someplace valid vs. 404

Dup of a previous commit.


Update hca-scea documentation with specification for cells.txt file

When brokering to the SCEA they like to have cell annotations in a specified format. This ticket is to add to the existing documentation so that wranglers can create this format when they have access to the cell type annotations from the author/contributor.

I have made a start on this section here: https://ebi-ait.github.io/hca-ebi-wrangler-central/SOPs/hca_to_scea_tools_SOP.html#cell-type-annotations
I have linked to relevant scea documentation but would like to get a review from Anja in the new year


Onboarding 6.1: Web analytics

As per https://github.com/PostHog/meta/pull/179
Web analytics is launching, so it needs an email flow in the onboarding emails.
Pretty simple flow to add. If someone performs onboarding product selected and product_key = web analytics then we check if they've ingested 50 events after a 36 hour wait. If yes, we skip them to the next email. If no, they get a help email.
Elsewhere, we'll mention web analytics alongside product analytics. This'll help us extending the flow needlessly and making unsubs more attractive.

Quickly done


How to achieve the effect of default blocking container network packet

When I used Neuvector recently, I found that when the container was switched to protected mode, enforcer would create the corresponding Veth pair and some TC rules for the container, and then I found that it was possible to block the network packets of the container. How did that happen? Is it because of TC rule?
Looking forward to your reply, thank you very much!

take a look at Vswitch

take a look at Vswitch

？？？？

The enforcer will consume the packets, forward the allowed packets and the bad ones are dropped.

The enforcer will consume the packets, forward the allowed packets and the bad ones are dropped.

I know that this part realizes packet dropping and packet releasing through packet Mmap based on vth-Neuv on DP side, but shouldn't packet Mmap technology only deal with cloned packets? What technique does enforcer use to block raw packets by default?

@garyduan  where to find the tc rules ? enforcer pod ?


NIFI-5169 Upgrade to JSONPath 2.4

Thank you for submitting a contribution to Apache NiFi.
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?

[ ] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

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

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

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] 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?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

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.

@joewitt @ottobackwards gave it a +1 and travis likes it. Can you merge?

@mattyb149 @ottobackwards did a review on this one and approved (but isn't a committer). His judgment is usually spot on if you want to sign off.

+1 merged to master


COCOA/cocoa_cat_list

Hello! Thanks for your nice work for amodal instance segmentation.
I have tried to run your code, but it seems that COCOA/cocoa_cat_list is missing so I cannot run it. Where can I find the file?
Also, could you please release you pretrained model on COCOA since it will be very useful to study amodal segmentation in the context of general object categories?
Thanks again!

Thank you for your interest in our work. You can use this script (https://github.com/UARK-AICV/AISFormer/blob/master/tools/get_cocoa_classes.py) to generate the cocoa_cat_list.
Regarding the trained models, I try my best to release it soon, I'll remind you here when it is released.


ENV Variables not being applied on existing TFE deployment - codebuild

Version information
DCE v0.26.0
Describe the bug
I'm deploying DCE via TFE and a manual step to update the shims with the lambdas. In my terraform, I have added the following values to the module, but they're not applying to codebuild to fetch my custom AWS nuke config
  reset_nuke_template_bucket     = aws_s3_bucket.dce.id
  reset_nuke_template_key        = aws_s3_bucket_object.aws-nuke-config.key

To Reproduce

Deploy via TF as a module in another project
Go back and add values to the module, then redeploy TF

  reset_nuke_template_bucket     = aws_s3_bucket.dce.id
  reset_nuke_template_key        = aws_s3_bucket_object.aws-nuke-config.key

Check code build and it's not updated. (also does not update if you delete the codebuild project and redeploy.

Expected behavior
It to add the environment variables to the codebuild project

Hi @JacobWeyer, thank you for bringing this to our attention. The reset codebuild should use your provided key and bucket overrides. Before I spin up an environment to try and reproduce this, could you post your reset codebuild log output here (or a snippet of it if it contains anything sensitive)? If it is not using your provided key and bucket TF vars, then we should see something like Using Default Nuke Configuration: ... in the logs. Also, if you're ok with posting your TF code where you declare the DCE module and your s3 bucket, that would also be helpful - thanks.

Ok so yesterday when I was messing with the code and manually triggering the code build, it was populating as Stub.
Today, after looking at some subsequent re-runs it seems to have populated properly.
Is there something specific that would prevent a manually triggered process that would not fix the issue vs what I'm assuming is something triggered from cloudwatch?
I've had an account in NotReady since yesterday. Looks like it has retried a few times over night and now the newest builds have the env variable properly set.

@JacobWeyer, if you don't provide a reset_nuke_template_bucket and reset_nuke_template_key bucket, then the default values ("STUB") will be used. If you saw the default values appear in the environment variables when you manually created a reset CodeBuild, then it is likely that a terraform apply was run at some point without your reset_nuke_template_bucket and reset_nuke_template_key in place to override those defaults.
Now that the reset is using the correct values, if you go to manually create a reset CodeBuild, does it populate your key and bucket correctly?

I've had an account in NotReady since yesterday. Looks like it has retried a few times over night and now the newest builds have the env variable properly set.

Is it failing with an error? If so, can you provide that error here? Thanks

I got the part that was blocking me figured out. For some reason when I manually tried to trigger the codebuild it didn't re-populate the env variables. I might not have done that right but it has been properly populating each day since from the CloudWatch triggered builds.
I most likely didn't retry it properly so we can probably close this issue. It is trying to fetch my nuke config though.

Excellent news @JacobWeyer. I will close this issue as the ENV variables do seem to be populating. Thank you again for reaching out.


Slow hashrateChallenge and fix unique key errors

This PR slows down the hashRateChallenge slightly and fixes some key prop errors in chapter 3
Preview

Hmm...I can't seem to unlock ch.3 to test.

@ecurrencyhodler that would be due to the VERCEL preview using the feature flag system, which currently says chapter 3 should be disabled. We can either spin up a separate database for our dev environment, or we could add some query parameter that lets you bypass feature flags. I think the latter is less work, but we should create a separate issue for this.

PR for the above here: https://github.com/saving-satoshi/saving-satoshi/pull/601

@afterburn should we just merge this? Or should ben rebase for me to test?

I can rebase it

Okay I think kevin's pr is still open. Can you review it? Then rebase after I merge his?

tack!


HAWCStab2 mode classification

Currently, the amp file is parsed very simple and mode is named after the maxloc of the aritmetic mean of the DOFs. A classification similar to Bladed could be done. Even, if only the very reduced number of DOFs are given as output in the amp file. Tower modes might not be identified as ones, thus.

At least a numbering has been introduced.


column_diffusion_timescale does not work on GPU

As noted in https://github.com/OceanBioME/OceanBioME.jl/pull/138, column_diffusion_timescale does not work on GPU.
This function seems unlikely to ever be needed on GPU since column models would probably never need the performance.
We could rethink how it works so please let us know if you need it!

Can you link to the code? Otherwise, it's hard to follow.

Good idea: https://github.com/OceanBioME/OceanBioME.jl/blob/ac8419a1ce5a06a82be31588583636b212c09598/src/Utils/timestep.jl#L4-L17

What does it do?

I don't recall all of the motivation for it but it was written to work out the diffusion timescale for "column" models with 1 dimension and a diffusivity given by a function. I think we wrote it originally because Oceananigans can't do it for diffusion functions?

I don't think we have implemented automagical support for calculating the diffusion time-scale for a diffusion function --- though such support is not too difficult using FunctionField + field reductions.
But more saliently, we rarely have use for such a function because we use vertically-implicit time-stepping for vertical diffusion which is unconditionally stable. For horizontal diffusion, while it is theoretically possible to violate the diffusive CFL, typical horizontal diffusion models are implemented in an "LES" context, wherein the diffusive limitation is very similar to the advective limitation.
All of that said, it's usually better to implement something in Oceananigans if support is needed --- because if other people need it to, they might improve your implementation.
I think it's unlikely that this function belongs in the source code. It's specific to a certain closure setup and only tests the "first" closure within a tuple, because of the [1] in this line:
         @inbounds Δz2_ν[k] = Δzₖ^2 / model.closure.κ[1](0.0, 0.0, z[k], model.clock.time) # assumes all tracer closures are the same and x/y invariant

Yeah, I agree. I recall someone was using it for reading in a diffusivity to replicate a mixed layer from observations or some analytical function, but it was quite a specific case and I could see a function field being a much easier solution.

Yeah, I agree. I recall someone was using it for reading in a diffusivity to replicate a mixed layer from observations or some analytical function, but it was quite a specific case and I could see a function field being a much easier solution.

Yes, that sounds like user code that accidentally ended up in the source code.

I think this was from Si's column model experiments where kappa is strongly dependent on time.  The issue isn't necessarily numerical stability (if using an implicit solver), but you still don't want the time step to be too large when diffusion is large for the purpose of accuracy.  Anyway, I agree that this is a very specific use case and doesn't need to be in the repo.

It could make sense to add support within
https://github.com/CliMA/Oceananigans.jl/blob/main/src/TurbulenceClosures/turbulence_closure_diagnostics.jl
at some point.


top level this is undefined when file contains imports and module is commonjs

Bug Report

🔎 Search Terms
top level this undefined imports

🕗 Version & Regression Information
4.4.0-dev.20210519
⏯ Playground Link
with imports: https://www.typescriptlang.org/play?module=1&ts=4.4.0-dev.20210519#code/JYWwDg9gTgLgBAcgGYQggUOgxhAdgZ3hQjgF44YALYfOAejuLhrgFdcATAUyWFy46YqNAHT4uMACqguEVvAZcoUaEA
without imports: https://www.typescriptlang.org/play?module=1&ts=4.4.0-dev.20210519#code/MYewdgzgLgBAZiEMC8MoAsCWEYHpcJLZoCeADgKYhwwDmANiAEYCG9AKlhAFDcbYA6CBSjtMAWyoBXKEA
💻 Code

with imports:
import 'foo'

const foo = this //foo is undefined

this.setTimeout //error

without imports:
const foo = this //foo is typeof globalThis

this.setTimeout //no error

🙁 Actual behavior
when the file has no imports, the top level this correctly has the same type as globalThis, but when there are imports, the top level this is of type undefined
🙂 Expected behavior
the top level this has the same type as globalThis, regardless of whether or not the file has imports in it

"this" is intentional: #35882
Used search terms: this undefined in:title

this should only be undefined when it compiles to a module. if the module compiler option is set to "commonjs", the top level this  should be typeof globalThis.
that issue seems to assume that a ts file is an esmodule just because it has imports, which isn't always true because lots of projects just have them compiling to commonjs

TypeScript considers files to be modules when you use export or import, regardless of the module compiler option.

why? seems silly to use such an unreliable method to determine that instead of just checking the compiler option that says whether they are modules or not

Because not every file is automatically a module. You can have global scoped files next to modules.
https://www.typescriptlang.org/docs/handbook/modules.html

In TypeScript, just as in ECMAScript 2015, any file containing a top-level import or export is considered a module. Conversely, a file without any top-level import or export declarations is treated as a script whose contents are available in the global scope (and therefore to modules as well).


aiosysbus==1.1.6 error

Hello,
After updated the last version of the integration, I have an error.
Of course after that I tried with the beta version but same issue....
Unable to install package aiosysbus==1.1.6: ERROR: Cannot install aiosysbus==1.1.6 because these package versions have conflicting dependencies. ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts
Setup failed for custom integration 'livebox': Requirements for livebox not found: ['aiosysbus==1.1.6'].
HA CORE 2023.12.1
HA OS 11.2
Do I need to update HA CORE ?
Thanks for you help.

For me, there is no reason for you to update HA CORE. The aiosysbus component requires very few dependencies, it needs python 3.11 and aiohttp and yarl
We may have a conflict with Yarl who also exists in HA.
I'm looking at this...

Indeed you have to install the HA CORE version because the yarl version is too old
Latest version  , yarl 1.9.4
https://github.com/home-assistant/core/blob/master/requirements.txt
2023.12.1 , yarl 1.9.2
https://github.com/home-assistant/core/blob/2023.12.1/requirements.txt
aiosysbus , yarl 1.9.3 or above

Are you having a problem installing the latest version of HA ? Because I could accept the yarl version 1.9.2 but if we can avoid that would be much better ?

Thanks for the quick reply !
I don't mind updating HA but i'll do that when I'll have time to do it properly (backup / snapshot etc ) just in case :)
I'll keep you posted.

It's working fine but now Melcloud integration is not showing up climate entities with HA 2024.1.6...
Thanks for you help @cyr-ius


Inconsistent results when using eq

Bug report
Describe the bug
I have a query that runs just as expected.
> supabase.table("storage").select('*').ilike('message', 'dude').execute()
{'data': [{'id': 2,
   'inserted_at': '2021-07-27T18:34:27.084558+00:00',
   'updated_at': '2021-07-27T18:34:27.084558+00:00',
   'email'<EMAIL_ADDRESS>   'message': 'dude'},
  {'id': 3,
   'inserted_at': '2021-07-27T18:34:31.482083+00:00',
   'updated_at': '2021-07-27T18:34:31.482083+00:00',
   'email'<EMAIL_ADDRESS>   'message': 'dude'}],
 'status_code': 200}

But notice what happens when I run:
> supabase.table("storage").select('*').like('email', 'example@gmail.com').execute()
{'data': [], 'status_code': 200}

Somehow I cannot query the email like I can the other columns in my table. Is email a protected value?
I am using supabase-py version 0.0.2.

I've been running into the same issue.  When I started playing around with it, it looked like the @ sign is the problem.
For example, when I set an email to test and execute the query with that value, then the row shows up just fine.
This may be because the email is encoded such that the @ shows up as an %40.  Any advice from the supabase team here?

I'm beginning to think this is because they use a . to differentiate between the command and the query itself.  See the URL that .eq("email"<EMAIL_ADDRESS>produces:


Fix SmartLifecycle.stop(Runnable) usage

Also remove redundant stop(Runnable) implementations which repeat
a default one in the SmartLifecycle

Cherry-pick to 2.1.x & 2.0.x

Can't cherry-pick to 2.0.x; SL does not have a default stop(Runnable) in SF 5.0

OK. Let me take care of that then!
Should be as simple as a two classes with callback issue.

Back-ported into 2.0.x as https://github.com/spring-projects/spring-amqp/commit/ff8a5da5fa89aff91eb99bb4159553dcdbe52337


Add Sparkswap to Get Bitcoin section

Consider adding Sparkswap to Get Bitcoin.
From the website:
Sparkswap Desktop is the first cryptocurrency exchange built on the Lightning Network. Buy BTC with USD from your bank account in an instant.
I dug into the GH repo and see that a LTC version of the project has been archived. I have not personally used the service, it popped up on my Twitter feed today.
https://sparkswap.com/
https://twitter.com/sparkswap

Looks like they have litecoin remnants in the code (perhaps because LND has it built in)
Have messaged the founder to find out if this is their long term plan.

I was wrong.
That code was for an old project, sparkswap desktop is bitcoin only.
https://github.com/sparkswap/sparkswap-desktop

Uses 'Anchor' stablecoin on a shitcoin network.


Add value property to HelicsInput

Fixes #39

Codecov Report

Merging #40 (d619999) into main (cf93ab5) will decrease coverage by 0.20%.
The diff coverage is 10.52%.

@@            Coverage Diff             @@
##             main      #40      +/-   ##
==========================================
- Coverage   81.93%   81.72%   -0.21%
==========================================
  Files          19       19
  Lines        6575     6594      +19
==========================================
+ Hits         5387     5389       +2
- Misses       1188     1205      +17

Flag
Coverage Δ

unit
81.72% <10.52%> (-0.21%)
:arrow_down:

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

Impacted Files
Coverage Δ

helics/capi.py
80.99% <10.52%> (-0.40%)
: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 cf93ab5...d619999. Read the comment docs.


Ignore socket.io poll

Hey there awesome dudes,
I LOVE THIS LIBRARY.
I just implemented socket.io on my server, and now I see this log all the stinking time:
Wed, 15 Apr 2015 15:27:14 GMT - GET /socket.io/?EIO=3&transport=polling&t=1429111634816-32&b64=1 responded 404 in 0.177 ms

Is there a way to ignore logs with a url that contains /socket.io? Thanks!

Got it.
skip: function(req, res) { return req.url.indexOf('/socket.io') !== -1 }

Yep, using the skip option certainly works :) Another way is to just use this middleware after the middleware that is responding to those socket.io URLs, as only requests that travel through the middleware will actually get logged.
Edit: I realized that URL is getting a 404, so I guess you can't do that :)


Initial Darjeeling ECDSA Support

This is a PR for adding initial ECDSA support to Darjeeling.
This 89 (!) commits PR is, for most of it, a port from Earlgrey's Earlgrey-PROD-M4-RC0 of the following folders:

sw/otbn/crypto
hw/ip/otbn/doc
hw/ip/otbn/data
hw/ip/otbn/util

There are two commits that are only partly based on Earlgrey's branch:

[sw,silicon_creator,sigverify] Add ECDSA p256 verification support (cda370739efcf0cebbbf0e2c3732af59b8fb8059)
[sw,silicon_creator] Add OTBN boot services (a4cf3b0f11f5eb37fcab925d09fd7096a421667f)

The first one adds the ECDSA p256 to the sigverify API, and is a copy paste of the Earlgrey code. I did not cherry-pick it directly as paths have diverged between the two branches.
The second one adds a reduced OTBN boot services support to Darjeeling. I removed the attestation part for now as the Earlgrey counter part relies on getting seeds from flash. We can not do that with Darjeeling and I thought it would be wiser to keep it out for now.

Wow! In leiu of reviewing the diff line-by-line, I've reviewed the two commits
mentioned (LGTM) and checked out integrated_dev locally and attempted to
replicate the cherry-picks for the rest. Unfortunately, I wasn't really able to
do this cleanly, particularly for documentation changes. I think there's a bit
of a problem with isolation in the codebase and especially the documentation
that causes this to not quite be as easy as we'd like.
From my look at the changes, it appears that some commits have been reordered
with respect to their order on master, and most of them only cherry-pick
changes to the selected specific OTBN directories. But this has some unexpected
consequences, I think: for example, commit b348d949b5f2 ([doc] Fixed links to the getting started section.) on master fixes documentation links throughout
different pages, including one OTBN page, after 7af944ccc moved the "getting
started" content into the main book. But this PR cherry-picks only the change
to the OTBN page from b348d9, not the commit that actually moves the content,
which I think will just break the link.
Here's my suggestion:

Break this into at least two PRs -- one that handles documentation and
hw/ip/otbn/util, which shouldn't depend on much the actual code (exceptions like the commit that makes IMEM 8kB, could be included in the docs/util PR), and one that adds the actual code (maybe even one for P256 and one for P384)
Remove the first three commits in the chain (see below, they cancel each other out)
Remove the [doc] Fixed links to the getting started section. commit, since
as described above it breaks a link
In all the PRs, re-order the cherry-picked commits by their commit date on
master after selecting the commits, which should help them resolve properly.

Sorry to suggest such a big change of approach, but I want to make sure we can
keep things coherent and make future merges easier. Long-term, it would be good
to improve isolation in our documentation so that we don't get so many merge
conflicts.

Here are my longer-form notes if you want the gory details:
I suggest removing the first three commits in the chain:

[reggen] Add CIP_IDs and bump all major versions
Revert "[reggen] Add CIP_IDs and bump all major versions"
[reggen] Add initial support for version and cip_id hjson fields

The second reverts the first, and the third has already been added on
integrated_dev
inhttps://github.com/lowRISC/opentitan/commit/538fdef42807462ff7701400bdb5088b9b5b06a6,
so the sum of the three commits shows no difference when I check it against
integrated_dev, and I think having the reversion and the extra copy of the
third commit is likely to confuse branch history a bit, especially since the
first two don't cleanly cherry-pick from master for me and differ
significantly from their master versions (due presumably to resolved
conflicts with 538fde).
When cherry-picking a9785f ([otbn, rtl] Increase imem size to 8 KiB), I
noticed that hw/ip/otbn/doc/registers.md did not exist on integrated_dev;
looks like it was added in a53d50 ([doc] otbn registers and interfaces now use CMDGEN) and then modified in 963a50 ([doc] Minor tweak to md sanitisation code). Both of those commits are cherry-picked later in the chain for this PR,
out of order compared to master, which means that the modifications from
a9785f (updating OTBN docs to say 8kB IMEM) get lost. I suggest moving the
cherry-picks of a53d50 and 963a50 earlier in the chain to fix this, which is
what I tried.
I had to remove a small block of text from
hw/ip/otbn/doc/theory_of_operation.md when cherry-picking a53d50 that got
removed on the master version but appears to have never existed on
integrated_dev. That was pretty solvable. However, when cherry-picking
963a50, I found a lot of conflicts relating to blocks that now use CMDGEN but
haven't been modified to do so on integrated_dev. Perhaps some more
cherry-picks are needed? Looks like a lot of blocks were moved to use CMDGEN in
https://github.com/lowRISC/opentitan/pull/19432, but the changes aren't totally
straightforward to merge onto integrated_dev because e.g.  paths in
documentation links to DIFs have diverged. For now I just dropped the changes
related to documentation files that didn't exist on integrated_dev.
After this the cherry-pick of a9785f worked automatically, so the duplicated
cherry-pick of this commit later in the chain is no longer needed (I checked).
Looking at the description of b348d949b5f2 I realized that this cherry-pick
does not make sense in isolation, as described up top. Skipped this one.
Had a few small conflicts in documentation links when cherry-picking 1c6ddf,
but they weren't hard to resolve.
Then, comparing to this PR, I realized there were still a lot of differences
compared to the state from the corresponding commits on the PR, because of
commits being re-ordered and changes getting auto-merged differently.
Particularly concerning is a variety of differences in hw/ip/otbn/util, since
that could affect functionality and not just documentation.
At this point I decided it was better to post my preliminary notes and agree on
a strategy than to continue hacking away. My WIP replication is at
https://github.com/jadephilipoom/opentitan/tree/verify-dj-otbn in case that's
useful.

Hey @jadephilipoom

Wow! In leiu of reviewing the diff line-by-line, I've reviewed the two commits mentioned (LGTM)

Thanks!

and checked out integrated_dev locally and attempted to replicate the cherry-picks for the rest. Unfortunately, I wasn't really able to do this cleanly, particularly for documentation changes. I think there's a bit of a problem with isolation in the codebase and especially the documentation that causes this to not quite be as easy as we'd like.

I agree. And FWIW we're also looking at syncing the opentitan tools and lib for roughly the same reasons. There are a lot more commits there, and we'll face the same issues I'm afraid.

From my look at the changes, it appears that some commits have been reordered with respect to their order on master, and most of them only cherry-pick changes to the selected specific OTBN directories. But this has some unexpected consequences, I think: for example, commit b348d94 ([doc] Fixed links to the getting started section.) on master fixes documentation links throughout different pages, including one OTBN page, after 7af944c moved the "getting started" content into the main book. But this PR cherry-picks only the change to the OTBN page from b348d9, not the commit that actually moves the content, which I think will just break the link.
Here's my suggestion:
* Break this into at least two PRs -- one that handles documentation and
  `hw/ip/otbn/util`, which shouldn't depend on much the actual code (exceptions like the commit that makes IMEM 8kB, could be included in the docs/util PR), and one that adds the actual code (maybe even one for P256 and one for P384)

* Remove the first three commits in the chain (see below, they cancel each other out)

* Remove the `[doc] Fixed links to the getting started section.` commit, since
  as described above it breaks a link

* In all the PRs, re-order the cherry-picked commits by their commit date on
  `master` after selecting the commits, which should help them resolve properly.

Sorry to suggest such a big change of approach, but I want to make sure we can keep things coherent and make future merges easier.

Please don't be sorry. I really appreciate the thorough review and the suggestion does make sense.
One comment though: If I split this PR into 2-3 of them, and order all commits chronologically in each of them, the final merge of all 3 PRs will not expose commits as they were chronologically merged in the master branch.
Thanks again for the feedback and suggestions.

At this point I decided it was better to post my preliminary notes and agree on a strategy than to continue hacking away. My WIP replication is at https://github.com/jadephilipoom/opentitan/tree/verify-dj-otbn in case that's useful.

Yes, that makes sense to me as well.

I am closing that PR as it will be split into multiple, smaller ones.
This is tracked through https://github.com/lowRISC/opentitan/issues/23486


test: make E2E tests faster using HAR files

Description
Summary of changes

Add HAR files for every test using advancedRouteFromHAR
Add setBrowserTime function to utils.ts
Add setFakeTime function to BasePage (relying on setBrowserTime utility)
Add getPastDate function to utils.ts which returns a date from the past
Move custom matcher logic seperate function for better code readability

Concerns
HAR files take a lot of space (around 13mb for each one on average), there could be a better solution than the one proposed here, I would love to hear your thoughts
closes #435
closes #454

regarding your concern - I think you're right, the HAR file has too many redundant information. I made this issue, I hope I'll fix it someday:
https://github.com/NoamGaash/playwright-advanced-har/issues/13


[enhancement]: Allow parameter default value to utilize another parameter value

Describe your feature request here
It would be convenient to allow creation of a default parameter value that utilizes the value of another parameter. Something like the following:
parameters:
- name: solutionTarget
  type: string
  default: ''
- name: msBuildArguments
  type: string
  default: -target:${{ parameters.solutionTarget }}
- name: binSourcePath
  type: string
  default: $(Build.SourcesDirectory)/${{ parameters.solutionTarget }}/bin

This would allow a convenient syntax for creating a template where parameters have a default value that stems from a single parameter, but still allows the template user to set a different value.
This request is essentially reiterating the request made in #2737. The suggested workaround by @vtbassmatt  was to use variables to create these values that depend on others. In my case, I would like to create templates that are at the scope of a steplist or step. It is not possible to define variables in these scopes. Instead, I used the workaround suggested by @jtpetty using a task to set variables, which lets me create variables in the context of a steplist or step template:
parameters:
- name: solutionTarget
  type: string
  default: ''
- name: msBuildArguments
  type: string
  default: ''
- name: binSourcePath
  type: string
  default: ''

steps:
- bash: |
    if [ -z "${{ parameters.msBuildArguments }}" ]; then
      echo "##vso[task.setvariable variable=msBuildArgumentsVar]-target:${{ parameters.solutionTarget }}"
    else
      echo "##vso[task.setvariable variable=msBuildArgumentsVar]${{ parameters.msBuildArguments }}"
    fi
    if [ -z "${{ parameters.binSourcePath }}" ]; then
      echo "##vso[task.setvariable variable=binSourcePathVar]$(Build.SourcesDirectory)/${{ parameters.solutionTarget }}/bin"
    else
      echo "##vso[task.setvariable variable=binSourcePathVar]${{ parameters.binSourcePath }}"
    fi

As you can see, the syntax is quite cumbersome and it took a lot of trial and error to actually get it working. The creation of the variables in my solution could possibly be simplified, but I played around using the expression join() and coalesce() functions for an hour with no success. As @jmezach expressed, this seems very complex for such a 'simple' operation. I think something like the syntax in the first block is much easier for pipeline authors to develop/maintain and enhances the value of templates for Azure Pipelines customers.

Hi @dmcmenamin-kt, Thank you for the feedback, unfortunately, since the parameters are in AzDevOps runtime and the agent can't manipulate them, probably you need to write your suggestion on the dev community to add a template expression in the parameters definitions to be able to set default values dynamically.
We understand that expressions might be a little bit tricky, so let me help you with your problem,
probably you better use the format function instead of join to concatenate parameter with a string inside your expression, it might look like this:
parameters:
- name: solutionTarget
  type: string
  default: 'someSolutionTarget'
- name: msBuildArguments
  type: string
  default: ''
- name: binSourcePath
  type: string
  default: ''

variables:
  - name: sourceDir
    value: $(Build.SourcesDirectory)
  - name: msBuildArgumentsVar
    value: ${{ coalesce(parameters.msBuildArguments, format('-target:{0}', parameters.solutionTarget)) }}
  - name: binSourcePath
    value: ${{ coalesce(parameters.binSourcePath, format('{0}/{1}/bin', variables.sourceDir, parameters.solutionTarget )) }}

jobs:
- job: 'Example'
  pool:
    vmImage: 'ubuntu-22.04'
  steps:
  - script: |
      echo "msBuildArgumentsVar: $(msBuildArgumentsVar)"
      echo "binSourcePath: $(binSourcePath)"
      echo "sourceDir: $(sourceDir)"

and the result will be similar to yours

Thanks @DmitriiBobreshev. The tip about the format function is useful, I will use that instead of the bash conditionals I had previously.
Could you clarify what the 'dev community' you mentioned refers to? Does that refer to https://github.com/Azure/dev-community? I had also considered adding this to https://github.com/microsoft/azure-pipelines-yaml but that repo seamed more oriented towards YAML Pipeline documentation and built-in templates.

You're welcome @dmcmenamin-kt, Sorry for the inconvenience, I meant https://developercommunity.visualstudio.com/home, since the functional need to be added in the ADO's server-side code.

Now tracked at https://developercommunity.visualstudio.com/t/Pipelines-Allow-parameter-defaults-to-/10386387


Using custom fonts in react-native project

Looking to add custom fonts to my react-native app -- can't seem to find any documentation on this.

@samuelcouch - same as how you would in a regular iOS app :smile:
Follow steps 1-4 here: http://codewithchris.com/common-mistakes-with-adding-custom-fonts-to-your-ios-app/
Then you can use that font family inside of your styles

Does RN support .woff fonts?

I think it's restricted to what IOS allows.
I've used free TTF's in my react native project.

Any tips on how to use custom fonts in Android?

@satya164 what have you tried? were you able to get anything working?

@ccheever Nope. All examples on the web suggest to extend the default Android TextView. There is also one using reflection which changes the font for the whole app. Though this is acceptable, I would also prefer is to be able to declare font families and use them in styles, so that I can use icon fonts etc.
Here is the link if you you just want to change font family for entire app - http://stackoverflow.com/questions/2711858/is-it-possible-to-set-font-for-entire-application
NOTE: I used sans instead of monospace.

I had custom fonts working in a native Android app. Trying to port it over to RN now and they aren't loading inside of  components :(

@marcshilling can you describe in more detail what you tried? Do you still have .ttf files or similar in an assets/ folder? And how are you trying to use the custom fonts inside of RN? Just using the fontFamily style property on text nodes and referencing the fonts you are including?

@ccheever yes, exactly. I've tried putting the .ttf (and .otf) files in both /assets and /assets/fonts (I had to the do the latter on native). And then I declare text like so:
<Text style={{fontFamily: 'FuturaStd-ExtraBold'}}>Hello World</Text>

And just for the record - I'm using the same exact font files and declaring <Text> the exact same way in an iOS React Native project and they are working.

@marcshilling what do you mean with "I had to the do the latter on native", did you write "Typeface font = Typeface.createFromAsset" in the main activity?

This is how I got custom font working,

Put your font files under assets/fonts
Add the following files

FontsOverride.java*
import java.lang.reflect.Field;
import android.content.Context;
import android.graphics.Typeface;

public final class FontsOverride {
    public static void setDefaultFont(Context context,
                                      String staticTypefaceFieldName, String fontAssetName) {
        final Typeface regular = Typeface.createFromAsset(context.getAssets(),
                fontAssetName);
        replaceFont(staticTypefaceFieldName, regular);
    }

    protected static void replaceFont(String staticTypefaceFieldName,
                                      final Typeface newTypeface) {
        try {
            final Field staticField = Typeface.class
                    .getDeclaredField(staticTypefaceFieldName);
            staticField.setAccessible(true);
            staticField.set(null, newTypeface);
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
    }
}

MyApplication.java
import android.app.Application;

public class MyApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();

        FontsOverride.setDefaultFont(this, "DEFAULT", "fonts/Custom-Font.ttf");
        FontsOverride.setDefaultFont(this, "SANS_SERIF", "fonts/Custom-Font.ttf");
    }
}

res/values/styles.xml
<resources>

    <!--
I'm so happy right now! I will let you know :)
Thank you!
Regards,
Geo
On Sun, Sep 20, 2015 at 4:36 AM, Satyajit Sahoo<EMAIL_ADDRESS>wrote:

This is how I got custom font working,

Put your font files under assets/fonts
Add the following files

FontsOverride.java*
import java.lang.reflect.Field;import android.content.Context;import android.graphics.Typeface;
public final class FontsOverride {
public static void setDefaultFont(Context context,
String staticTypefaceFieldName, String fontAssetName) {
final Typeface regular = Typeface.createFromAsset(context.getAssets(),
fontAssetName);
replaceFont(staticTypefaceFieldName, regular);
}
protected static void replaceFont(String staticTypefaceFieldName,
                                  final Typeface newTypeface) {
    try {
        final Field staticField = Typeface.class
                .getDeclaredField(staticTypefaceFieldName);
        staticField.setAccessible(true);
        staticField.set(null, newTypeface);
    } catch (NoSuchFieldException e) {
        e.printStackTrace();
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    }
}

}
MyApplication.java
import android.app.Application;
public class MyApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
    FontsOverride.setDefaultFont(this, "DEFAULT", "fonts/Custom-Font.ttf");
    FontsOverride.setDefaultFont(this, "SANS_SERIF", "fonts/Custom-Font.ttf");
}

}
res/values/styles.xml

<!-- Base application theme. -->
<style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar">
    <item name="colorPrimary">@color/primary</item>
    <item name="colorPrimaryDark">@color/primary_dark</item>
    <item name="colorAccent">@color/accent</item>
    <item name="android:typeface">sans</item>
</style>

—
Reply to this email directly or view it on GitHub
https://github.com/facebook/react-native/issues/1167#issuecomment-141730183
.

--
Met vriendelijk groet,
Gerald Olivero
+31634771782
geolivero.com

@geolivero No problem, I had left out the part where you have to change the AndroidManifest.xml, added it to the post now.

@satya164 what if I need multiple, different custom fonts in my app? You approach seems to simply replace the default font with a single custom font.

@marcshilling Yeah, that will be immensely useful, e.g. - icon fonts. But I've not managed to figure that out yet.

@satya164 I've just added Android support to react-native-icons so you can use icon fonts.
As for custom fonts in general, CustomStyleSpan.java is where typefaces are currently set in React Native Android. For fontFamily to properly work with a custom font RN would need some way to register a custom font family name with a font file in /assets when setting up the ReactInstanceManager.
Something like:
 mReactInstanceManager = ReactInstanceManager.builder()
  .setApplication(getApplication())
  .setBundleAssetName("index.android.bundle")
  .setJSMainModuleName("index.android")
  .addPackage(new MainReactPackage())

  // Add a font family name associated to a font file in /assets
  .addTypeFace("CustomFont", "Custom-Font.ttf")

  .setUseDeveloperSupport(BuildConfig.DEBUG)
  .setInitialLifecycleState(LifecycleState.RESUMED)
  .build();

@corymsmith Awesome man. Thanks a ton.

.addTypeFace("CustomFont", "Custom-Font.ttf")  ```
Does it work with 0.11.4? For me compiler cannot find this method on Builder instance

@wizardzloy It's just a concept.

@wizardzloy I was merely proposing a way to handle that but it hasn't been implemented

@corymsmith @satya164 Oh, I see. So there is working solution for multiple custom fonts so far?

+1

There is an open PR that aims to solve this problem. Hope it will be merged soon
https://github.com/facebook/react-native/pull/3800

Has anyone else had difficulty using the custom fonts on their device? I'm using a font 'GOUDIAC' for Sanskrit transliteration and while it works fine in the Simulator it doesn't load in the actual device

I just tried a new font using the @satya164 method and some words magically disappeared in my app, it seems that views doesn't calculate the sufficient space to display them. Does anyone have encountered the same problem?

@fxhereng Custom font support has been added in React Native - https://github.com/facebook/react-native/commit/bfeaa6a4f531cfc18c097bc9ffb6a8dbe3ddc702
You can try 0.16.0-rc to use it.

@satya164 I still have a problem using that code..
when I change the font setting on the device, my font got changed too.
Any idea?

@ericchris Did you try 0.16.0-rc?

I can't get it to work, it falls back to default font.

using<EMAIL_ADDRESS>TTF font file in android/app/src/main/assets/fonts/
font file name exactly matches font name (i.e. font name = FontName, font file name = FontName.ttf)
also tried setting font name and font file name to lowercase (fontname and fontname.ttf)
no typeface specified in styles.xml

Anyway to debug if the font file even gets loaded?

@satya164  Can you give a sample code for using the custom fonts ? i'm using 0.16.0-rc and i added the fonts to assets/fonts but i cant get them to work.

@turka50 - the font file name should be the same as the font name and should contain only lowercase letter and underscores, e.g.:
{ fontFamily: 'font_name' }

projectfolder/android/app/src/main/assets/fonts/font_name.ttf

@richarddewit  - This is the folder where my files are : \android\app\src\main\assets\fonts
and the files are :

and markup finaly is :

But the text doesn't get affected at all, any ideas ?

@turka50:

Did you run react-native run-android?
Do you have the latest file projectfolder/android/app/react.gradle and a reference to it in projectfolder/android/app/build.gradle?
Do you have any typeface specified in projectfolder/android/app/src/main/res/values/styles.xml? If so remove them.

@richarddewit  I think the issue is that 0.16.0-rc is not properly installed, I'm getting a weird error saying -

Any ideas ?

@turka50 Check if you have compile "com.facebook.react:react-native:0.16.+" in projectfolder/android/app/build.gradle

@richarddewit  Yes i do.  I'm getting this error also -

@turka50 Delete the folders

projectfolder/android/.gradle
projectfolder/android/app/build

and rebuild your project using react-native run-android
Also your font is not in assets/fonts/

@richarddewit  Tried what you suggested , Still not working. The weird thing is that i deleted that folder and there are not fonts at all but it still shows that error...

@turka50 It seems that it's referencing to main/res/assets instead of `main/assets/. Can you check there?

@richarddewit  Ok that was the error ... moving on to the next error :)

@turka50 Known issue with ES6 imports. The fix should land in 0.16 https://github.com/facebook/react-native/commit/ffea7793aff0961ebc22007d650ce36f7c2e61cb

@corymsmith I've just read your snippet to add a custom font here https://github.com/facebook/react-native/issues/1167#issuecomment-144077138
But how can I have in the new android structure?
public class MainActivity extends ReactActivity {
    /**
     * Returns the name of the main component registered from JavaScript.
     * This is used to schedule rendering of the component.
     */
    @Override
    protected String getMainComponentName() {
        return "App";
    }

    /**
     * Returns whether dev mode should be enabled.
     * This enables e.g. the dev menu.
     */
    @Override
    protected boolean getUseDeveloperSupport() {
        return BuildConfig.DEBUG;
    }

    /**
     * A list of packages used by the app. If the app uses additional views
     * or modules besides the default ones, add more packages here.
     */
    @Override
    protected List<ReactPackage> getPackages() {
        return Arrays.<ReactPackage>asList(
            new MainReactPackage(),
            new VectorIconsPackage(),
        );
    }
}

cc @satya164

@PierBover I don't wanna to replace the default fonts of android, I wanna use a custom one

@sibeliusseraphini<EMAIL_ADDRESS>

@sibeliusseraphini And this answer on SO should help as well: http://stackoverflow.com/a/37413939

@corymsmith in the Medium article it says:

Make sure the fonts are lowercase only and follow this pattern: fontname.ttf, fontname_bold.ttf, fontname_light.ttf, fontname_bold_italic.ttf

But in the SO answer:

The name of the file has to match the fontFamily exactly. For instance, if fontFamily is 'Source Sans Pro', the file must be called Source Sans Pro.ttf (and NOT SourceSansPro.ttf). Any suffixes as mentioned in the following paragraph are automatically removed from the file.

Is there any definitive source on how these file must be named?

@PierBover From my understanding the font name needs to match the file name exactly. Not sure it matters whether its lower case or not, try both and see if one doesn't work :)

@corymsmith Ok... I'll try that. :)
Anyone knows how does the font weight work?
From the SO answer and Medium article it seems you can say myfont_light_italic.tff but how do you specify light in the styles?
The Text component docs say this:

fontWeight enum('normal', 'bold', '100', '200', '300', '400', '500', '600', '700', '800', '900')

If it's like CSS 300 should correspond to  _light in the .ttf file name.
What about the other weights? Do we name files like myfont_200.ttf or myfont_900.ttf?

@PierBover
If you have a peek at this:
https://github.com/facebook/react-native/blob/235b16d93287061a09c4624e612b5dc4f960ce47/ReactAndroid/src/main/java/com/facebook/react/views/text/ReactFontManager.java#L21

For each font family the bold, italic and bold_italic variants are supported. Given a "family" font family the files in the assets/fonts folder need to be family.ttf(.otf) family_bold.ttf(.otf) family_italic.ttf(.otf) and family_bold_italic.ttf(.otf).

So if you need other weights then it would seem like you should include the different font file for that weight and then name the file / use the font name that matches the file name for that weight.

So in the styles I'd use:
fontFamily: ‘myfont_light_italic’

?
I guess that should work.
If I have time I will try to fix this so that you can also specify the weight in the .ttf file like myfont_300_italic.ttf. This makes more sense than using classic names like light,black, etc. Plus, @ericvicenti said here they want to support CSS like font weights instead.

@PierBover thanks for all this links, I hope one of them works

Here is how i get custom font working in four step:
1- Copy TTF file to /projectdir/android/app/src/main/assets/fonts
2- Delete these folders: projectfolder/android/.gradle + projectfolder/android/app/build
3- Apply fontFamily to elements
4- react-native run-android

@tje3d so you didn't have to write any Java code for this?

@kunal95 yes

@tje3d It worked! 😀 Thanks

I used rnpm to fix this. It basically does what @tje3d described.
Im specifying this in my package.json file
"rnpm": {
    "assets": ["Fonts"]
}

I've placed my fonts in the Fonts directory and then just run rnpm link

Thanks @krokofant for your method!
I'm going to describe a bit what happens for the rest.
First it copies the fonts correctly for Android:

They also appear in Xcode in the Resources folder

Finally you use them like this in your StyleSheet:
fontFamily: 'opensans',
fontWeight:'bold'

Success

From looking at the code https://github.com/facebook/react-native/blob/0.34-stable/ReactAndroid/src/main/java/com/facebook/react/views/text/ReactFontManager.java
It doesn't look like react native supports light variants of fonts yet. If I get time I may add a PR for support

Anyone know how to detect when the fonts are fully loaded? I noticed (at least in iOS simulator) that the font changes don't take effect for a few hundred milliseconds.

@JulianKingman u can use this https://gist.github.com/sibelius/e1db241ab225aba2adb84dbd8ae6525b to check if the font name was loaded

@sibelius so then would you recommend just having a setTimeout that refreshes every 10ms or so to check again, in order to update the component?

I think all the fonts are loaded when react starts
everytime u change the font u need to recompile the native code

I have tried everything above and nothing seems to work with Android.

Created assets/fonts and placed the .ttf file.
Updated packages.json with

    "assets": ["assets/fonts"]
}```
3. Ran `rnpm link assets` which says it linked correctly and placed the fonts in their correct directories within Android and iOS.
4. Deleted `projectfolder/android/.gradle` and `projectfolder/android/app/build` for good measure.

iOS works beautifully, Android does not work at all.

Running RN 0.40.0

As @tje3d  said before, I made those 4 steps and also I ran " gradlew clean".
One thing more: my font file is called "Lato-Bold.ttf" so I had to use {fontFamily: 'Lato-Bold'} to make it works instead of {fontFamily: 'lato-bold'} as I read in some pages. So I had to use the fontFamily as it called.
Thank @tje3d !

I'm having some issues getting custom fonts working on Android (however, it works fine on iOS).

I've installed my fonts in ./android/app/src/main/assets/fonts:

My project uses an abstract CustomText wrapper component, to ensure the custom font is applied everywhere. When applying the fontFamily, I follow the <filename>.ttf pattern mentioned by folks above. E.g., since my font file is named opensans.ttf, my fontFamily is opensans for the Android platform.

I ran this (from root of react native project, to clear cached android stuff):

rm -rf ./android/.gradle
rm -rf ./android/app/build
cd android && ./gradlew clean && cd ..

Then ran:
react-native run-android

However, my fonts still don't line up. I have it custom fonts functional on iOS, and you can see the comparison here:

Any ideas as to what could be going wrong? I made sure I killed the packager before deleting the cached android files and re-starting the android simulator.

Same issue as @petermikitsh.
React Native v 0.35
Font I'm trying to load is Gotham Ultra.ttf. I renamed to gotham_ultra.ttf and moved to ./android/app/src/main/assets/fonts
I tried deleting the .gradle folder and re-running the packager and react-native run-android.
I've tried every suggestion on this issue but nothing appears to work.

Mine works now! I was adding the style to a single Input component, expecting the placeholder text to have the new font. However, it did not affect the placeholder text but did affect the actual typed text.

From https://blog.bam.tech/developper-news/add-a-custom-font-to-your-react-native-app

4 - Format the Android font files
In the android/app/src/main/assets/fonts folder where your font was copied, rename the files so that:

the prefix matches your .ttf files names
the suffix is snake_case

In my case:
Intelligent Design - Averta-Bold.otf had to be renamed to Averta_bold.otf (along with 15 other variations).

In my case in Android it worked after setting fontWight: '400' fontWeight: 'bold' caused fallback to System font.

I'm getting it working after removing fontWeight! Apparently, I have only 400 weight font.

Is there a way that android can provide a list of available fonts and its font name?

I was using OTF file font and having errors like font not found, for the fontFamily i was mistaken to use the Full name attribute at the font book, the correct one was PostScript name

I don't understand why iOS uses FONTNAME-some instead of FONT-NAME-some whether the file is FONT-NAME-some.ttf
I've implemented a function in order to use fonts on both platforms.
// utils.js

import { Platform } from 'react-native'

/**
 * Add fonts compatibility across iOS & Android.
 *
 * Examples:
 * + SF-UI-Display-Medium.ttf will:
 *    Android: SF-UI-Display-Medium
 *    iOS: SFUIDisplay-Medium
 * + Roboto-Medium.ttf will:
 *    Android: Roboto-Medium
 *    iOS: Roboto-Medium
 */
export default fontCompat = (fontFamily) => {

  if (Platform.OS === 'ios') {
    return fontFamily.replace(/(.*)-/, (x) => x.replace(/-/g,'')+'-');
  }

  return fontFamily;
}

import { fontCompat } from './utils.js'

const myStyles = {
   one: {
       fontFamily: fontCompat('SF-UI-Display-Medium')
   },
   two: {
       fontFamily: fontCompat('Roboto-Medium')
   },
}

@brunobar79 I think because it uses the font's name, not the font's filename (PostScript name, as @a3diti pointed out)

(@JulianKingman  I think you wanted to reply to @brunocascio instead)

@JulianKingman I got it. Good catch, thanks!


update Google Cloud API client import paths and more

The Google Cloud API client libraries for Go are making some breaking changes:

The import paths are changing from google.golang.org/cloud/... to
cloud.google.com/go/.... For example, if your code imports the BigQuery client
it currently reads
import "google.golang.org/cloud/bigquery"
It should be changed to
import "cloud.google.com/go/bigquery"

Client options are also moving, from google.golang.org/cloud to
google.golang.org/api/option. Two have also been renamed:

WithBaseGRPC is now WithGRPCConn
WithBaseHTTP is now WithHTTPClient

The cloud.WithContext and cloud.NewContext methods are gone, as are the
deprecated pubsub and container functions that required them. Use the Client
methods of these packages instead.

You should make these changes before September 12, 2016, when the packages at
google.golang.org/cloud will go away.

The Google Cloud API client libraries for Go are making some breaking changes:

Thanks for the notification. Is there a reference/announcement for this?
This project uses https://godoc.org/google.golang.org/cloud/datastore, which is still available at the old URL, and has no mention of the new package name.

In addition, https://cloud.google.com/go/apis links to the old google.golang.org/cloud package.
The move sounds plausible, but I literally can't verify it. :-/


ffi: Fix const-correctness for quiche_h3_send_* functions

Hi!
Unless I'm mistaken, these parameters are not mutable in the FFI Rust code and thus can be made const in the C/C++ header.

Merged, thanks @rgacogne!