Enhanced properties retrieval

Based on the current undocumented (and for me personally hard to get) retrieval of properties (see #162) the mechanism has been rewritten drastically. The changes include:

hiding of URLs. Guice and other properties consumers want Properties, so method should return such.
.properties files shouldn't be searched in the current directory or in the source root. Therefore default properties are now maintained in an application resource and can be overwritten by both files and resources on classpath if the corresponding system property is set (see Javadoc of OrienteerModule). There's a fallback so that Properties are always retrieved. A .properties file can be put in ~/.orienteer/orienteer.properties and is used if no system property is specified.
The default properties are maintained in the newly created project orienteer-resources.

A test for OrienteerModule has been created. The orienteer-archetype-war project has been adjusted to match the changes listed above.
The reason for the change was that I could never build Orienteer due to issue in intransparent properties loading.

Coverage increased (+0.01%) to 66.34% when pulling 61a5ae526427c87749512191383d7d562e439e40 on krichter722:properties1 into ed9e557c292ec1cebce82a9224561182da1830ba on PhantomYdn:master.

Thank you! But lets discuss: I see few things that contradict with my understanding how it should be organized.

I do agree that passing of Properties instead of URL is better.
Could you please describe what was your initial problem? What kind of symptoms did you have?
The idea of "default properties" has been used for the following feature: there is standalone Orienteer (single jar with all dependencies) and I thought that it will be cool if by just double click you can run Orienteer. So no writing properties, no application servers: just single file - run it and Orienteer is running.
From my point of view: orienteer.properties is not an resources. That's configration: so might be seprate config directory will be good, but I don't see any reason to have dedicated maven module.

So: I agree that changes required, but I think that a) no additional module for that stuff required b) lookup of file by scanning up is good(at least I've already use that my zoo of Orienteer's:) ).

Btw, I updated wiki https://github.com/PhantomYdn/Orienteer/wiki/How-to-run-Orienteer to reflected currently existing ways to start Orienteer.

Could you please describe what was your initial problem? What kind of symptoms did you have?

Properties were not found and Guice failed to initialize (I guess the exact exception doesn't matter because it was definitely due to missing properties).

The idea of "default properties" has been used for the following feature: there is standalone Orienteer (single jar with all dependencies) and I thought that it will be cool if by just double click you can run Orienteer. So no writing properties, no application servers: just single file - run it and Orienteer is running.

But that's the case now (in my changes Properties are always returned), not before (where there must have been a case where null as Properties (or URL in that case) was returned).

From my point of view: orienteer.properties is not an resources. That's configration: so might be seprate config directory will be good, but I don't see any reason to have dedicated maven module.

Some folks might want to specify configuration packaged with their modules on the classpath and don't bother with local file system access. It's no obligatory in my changes (you can specify a config file, a resource on classpath, put a file in ~/.orienteer/orienteer.properties or nothing of that and let properties fallback to built-in defaults.
I don't care where we put the default properties (own module, in orienteer-core or hard code it into the source), adding a separate module to the war would be no problem, though and one-file war deployment would still be guaranteed (that's the purpose of a war file and it'd take a lot more to break that concept ;)).

I see what are you saying... If you don't mind I will slightly modify your realization in a separate branch and then commit into master. I need to support my current infrastructure of Orienteer:)

Of course, it was an undiscussed change, take what you can use and modify at will :) I'll see if properties are still missing at start of Orienteer/initialization of guice and open an issue if issues persist.

The issue didn't occur during build, but during deployment on Glassfish 4.1. I'm getting the error
Information:   ERROR - WicketFilter               - The initialization of an application with name 'wicket.orienteer' has failed.
com.google.inject.CreationException: Guice creation errors:
1) Properties files was not found
2) No implementation for org.apache.wicket.protocol.http.WebApplication was bound.
  at org.orienteer.services.OrienteerModule.getLocalizer(OrienteerModule.java:120)
3) No implementation for org.apache.wicket.protocol.http.WebApplication was bound.
  at org.orienteer.services.OrienteerModule.getOServer(OrienteerModule.java:113)
3 errors
    at com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:435)
    at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:154)
    at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:106)
    at com.google.inject.Guice.createInjector(Guice.java:95)
    at com.google.inject.Guice.createInjector(Guice.java:72)
    at com.google.inject.Guice.createInjector(Guice.java:62)
    at org.apache.wicket.guice.GuiceWebApplicationFactory.createApplication(GuiceWebApplicationFactory.java:171)
    at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:385)
    at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:351)
    at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
    at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:131)
    at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:5329)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:5943)
    at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
    at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
    at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
    at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
    at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
    at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
    at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
    at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:360)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:360)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
    at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
    at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
    at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
    at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
    at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
    at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
    at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
    at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
    at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
    at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
    at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
    at java.lang.Thread.run(Thread.java:745)
Schwerwiegend:   WebModule[/orienteer-war]Exception starting filter wicket.orienteer
java.lang.InstantiationException
    at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:135)
    at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:5329)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:5943)
    at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
    at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
    at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
    at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
    at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
    at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
    at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
    at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:360)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:360)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
    at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
    at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
    at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
    at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
    at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
    at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
    at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
    at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
    at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
    at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
    at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
    at java.lang.Thread.run(Thread.java:745)
Caused by: javax.servlet.ServletException: com.google.inject.CreationException: Guice creation errors:
1) Properties files was not found
2) No implementation for org.apache.wicket.protocol.http.WebApplication was bound.
  at org.orienteer.services.OrienteerModule.getLocalizer(OrienteerModule.java:120)
3) No implementation for org.apache.wicket.protocol.http.WebApplication was bound.
  at org.orienteer.services.OrienteerModule.getOServer(OrienteerModule.java:113)
3 errors
    at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:450)
    at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:351)
    at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
    at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:131)
    ... 51 more
Caused by: com.google.inject.CreationException: Guice creation errors:
1) Properties files was not found
2) No implementation for org.apache.wicket.protocol.http.WebApplication was bound.
  at org.orienteer.services.OrienteerModule.getLocalizer(OrienteerModule.java:120)
3) No implementation for org.apache.wicket.protocol.http.WebApplication was bound.
  at org.orienteer.services.OrienteerModule.getOServer(OrienteerModule.java:113)
3 errors
    at com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:435)
    at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:154)
    at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:106)
    at com.google.inject.Guice.createInjector(Guice.java:95)
    at com.google.inject.Guice.createInjector(Guice.java:72)
    at com.google.inject.Guice.createInjector(Guice.java:62)
    at org.apache.wicket.guice.GuiceWebApplicationFactory.createApplication(GuiceWebApplicationFactory.java:171)
    at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:385)
    ... 54 more

during start of the application on the server. I'm using the default "Debug" command after opening the project in NetBeans 8.0.2 (I can research the exact command set if necessary).

I'm working right now on that:) A couple of minutes and I will commit update.

Coverage increased (+0.0%) to 66.33% when pulling 06125478cc996df89e8f4c9241a7579aee7319ab on krichter722:properties1 into ed9e557c292ec1cebce82a9224561182da1830ba on PhantomYdn:master.

Commited! Please check updated version.


Fix #570

@camilonova could you please approve a new release with this fix. https://github.com/jazzband/django-constance/releases/tag/4.0.1
I think this is crucial.


Server side gtm script loading option

Request / Idea
I see that @gtm-support/core hav option to set source for server side gtm script but @gtm-support/vue2-gtm doesn't  allow to set source option
...
Additional Context
tried
 Vue.use(VueGtm, {       source: "https://insight.blabla.com/gtm.js",       id: "123",     });
but it still load script from  @default https://www.googletagmanager.com/gtm.js
...

Yeah, I would need to update the Vue 2 branch to newest state.
After Vue 3 now switched from next to stable, I didn't updated it anymore.
So of you want to, I need to merge stuff from main branch into vue2 branch and make a specific release for that version.
I do not use VueDemi because this would load unnecessary stuff for Vue 3. They cannot be handled with just simple if-else statements.
I'm currently in vacation, but maybe I can do it today or next few days. Just need to find a free timeslot for that.

@Shinigami92
Is there a workaround to make source working until that merge ?

I'm not totally sure. Maybe you could just add a script Tag source dynamically or update the one that is inserted by this library. But I'm not sure how it would behave.

Looks like this worked fine for me
import VueGtm from "@gtm-support/vue2-gtm";
import { loadScript } from "@gtm-support/core"; // latest ver installed explicitly

loadScript(<GTM_ID>, {
  source: "https://insight.blabla.com/gtm.js",
});

Vue.use(VueGtm, {
  id: <GTM_ID>,
  vueRouter: router,
  loadScript: false,
});

I will add some features and such at once, so I don't need to create several versions in a row.
But that means that I assume that this will take until upcoming weekend.
Hope you are okay with that.

Should be working now with 1.3.0 in vue2
Let me know that everything works
Reopen this issue if not

It works now, thanks allot


Use Quickcheck for property based testing.

I'm not tied to this change at all and feel free to reject anything you don't like.
Prior to this commit a variety of property based tests existed and used
a manual approach, consisting of filling vectors with random data and
choosing random configs using the rand crate. This moves to using
quickcheck to handle a lot of the grunt work that was previously done
manually. In addition to the simpler code quickcheck also provides
"shrinking" of input data to reduce test cases when possible. This can
make troubleshooting test failures much simpler.
In the process of refactoring the tests it became clear that there
exists a lot of redundancy. I took the liberty of removing a variety of
test cases that entirely overlapped with an already existing case. I
believe the end result is net gain in terms of readability and
maintenance of the test cases without any loss of code coverage.

Thanks; will take a look. I'm sure there are duplicate tests. They've accreted somewhat haphazardly and could use some pruning.

I incorporated this in #108; thanks for laying the groundwork. I didn't remove some of the tests, though, as they were originally written to test certain thresholds (when we go from a slow loop to a fast loop, etc) and I'm not completely sure that they're covered elsewhere. Since they're not causing a maintenance headache (yet), I left them in.


feat: 🎸 Ghost button closes #73

feat: 🎸 Ghost button closes #73

:tada: This PR is included in version<EMAIL_ADDRESS>:tada:
The release is available on:

npm package (@beta dist-tag) :package::rocket:
GitHub release :package::rocket:

:tada: This PR is included in version<EMAIL_ADDRESS>:tada:
The release is available on:

npm package (@beta dist-tag) :package::rocket:
GitHub release :package::rocket:

:tada: This PR is included in version<EMAIL_ADDRESS>:tada:
The release is available on:

npm package (@beta dist-tag) :package::rocket:
GitHub release :package::rocket:

:tada: This PR is included in version<EMAIL_ADDRESS>:tada:
The release is available on:

npm package (@beta dist-tag) :package::rocket:
GitHub release :package::rocket:


Development: Update version of Micrometer Prometheus package

Checklist
General

[x] I tested all changes and their related features on the Staging server.
[x] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
[x] I chose a title conforming to the naming conventions for pull requests.

Motivation and Context
Some time ago, there were problems with the update of the io.micrometer:micrometer-registry-prometheus package.
These problems were probably caused by some incompatibility with Spring. As they are resolved now, we can update the micrometer-registry-prometheus package.
Description
Updates the version of the io.micrometer:micrometer-registry-prometheus package.
Steps for Testing

Deploy to Staging (if not deployed yet).
Open the Artemis Statistics for Staging Local CI in Grafana: https://grafana.gchq.ase.in.tum.de/d/d9vRDInMa/artemis-statistics
Check that the monitoring panels look reasonable and that there is no panel with No data.

Review Progress
Code Review

[ ] Code Review 1
[ ] Code Review 2

Manual Tests

[ ] Test 1
[ ] Test 2

Summary by CodeRabbit

Chores

Updated the Micrometer Prometheus registry dependency to the latest version, ensuring improved performance and potential new features for metrics integration.

@iyannsch You cannot deploy to Staging using GitHub Actions, but must use Bamboo instead.
The URL is: https://artemis-staging-localci.artemis.cit.tum.de/


support w3c annotations using  instead of

Hello everyone,
I am currently playing around with the annotorious openseadragon plugin, and I noticed that chrome couldn't set the fill opacity for the loaded annotations. I then realized that my w3c annotations use  instead of  and so the base css for annotations in annotorious wasn't applied.
This PR fixes the issue where w3c annotations using the SvgSelector with  elements instead of  are not drawn with transparent fill-color.
Cheers,
Andreas 😃

Ah - yes, that's very useful. Many thanks!


LIST and MAP types not properly preserved in read after write

See the following code that writes, then reads, a parquet file. The schema doesn't seem to preserve the LIST and MAP types:
package main

import (
	"github.com/parquet-go/parquet-go"
	"log"
	"os"
)

func main() {
	fileName := "schema-issue.parquet"

	var root parquet.Node = parquet.Group{
		"aaa": parquet.Uint(32),
		"bbb": parquet.List(
			parquet.List(
				parquet.String(),
			),
		),
		"ccc": parquet.Group{
			"ddd": parquet.Leaf(parquet.ByteArrayType),
			"eee": parquet.Leaf(parquet.BooleanType),
		},
		"fff": parquet.Map(
			parquet.Int(32),
			parquet.Group{
				"ggg": parquet.Date(),
			},
		),
	}
	writtenSchema := parquet.NewSchema("mySchema", root)

	writtenFile, _ := os.Create(fileName)
	writer := parquet.NewGenericWriter[any](writtenFile, writtenSchema)
	writer.Close()

	openedFile, _ := os.Open(fileName)
	reader := parquet.NewReader(openedFile)

	log.Printf("Written schema: %s", writtenSchema.String())
	log.Printf("Opened schema: %s", reader.Schema().String())
}

Here's the output:
Written schema: message mySchema {
        required int32 aaa (INT(32,false));
        required group bbb (LIST) {
                repeated group list {
                        required group element (LIST) {
                                repeated group list {
                                        required binary element (STRING);
                                }
                        }
                }
        }
        required group ccc {
                required binary ddd;
                required boolean eee;
        }
        required group fff (MAP) {
                repeated group key_value {
                        required int32 key (INT(32,true));
                        required group value {
                                required int32 ggg (DATE);
                        }
                }
        }
}

Opened schema: message mySchema {
        required int32 aaa (INT(32,false));
        required group bbb {
                repeated group list {
                        required group element {
                                repeated group list {
                                        required binary element (STRING);
                                }
                        }
                }
        }
        required group ccc {
                required binary ddd;
                required boolean eee;
        }
        required group fff {
                repeated group key_value {
                        required int32 key (INT(32,true));
                        required group value {
                                required int32 ggg (DATE);
                        }
                }
        }
}

See how the LIST and MAP types are missing in the read schema:

Is that a bug or am I maybe missing something?

FWIW it does seem like the LIST/MAP logical types are preserved in the written file.
≻ parquet meta schema-issue.parquet

File path:  schema-issue.parquet
Created by: github.com/parquet-go/parquet-go
Properties: (none)
Schema:
message mySchema {
  required int32 aaa (INTEGER(32,false));
  required group bbb (LIST) {
    repeated group list {
      required group element (LIST) {
        repeated group list {
          required binary element (STRING);
        }
      }
    }
  }
  required group ccc {
    required binary ddd;
    required boolean eee;
  }
  required group fff (MAP) {
    repeated group key_value {
      required int32 key (INTEGER(32,true));
      required group value {
        required int32 ggg (DATE);
      }
    }
  }
}

From the look of it, you see different output here because the Reader doesn't check for list / map types when parsing the file metadata into a schema, and just converts them to a "group" type. There's a pretty easy way to fix this - just check for these logical types when building the schema, but it breaks a test (TestOpenFile/testdata/list_columns.parquet) - it contains a "LIST" entry with an element path int64_list.list.item (rather than the correct int64_list.list.element) and this causes the parser to fail. It's actually possible that the current behavior is a workaround to allow parquet-go to parse less-than-perfect files - at least, it seems to have that effect in practice.


updated

added title.js , dev.js , vip.js , clearall
also added vip , dev , flag and title display in /profile

remove that customcolors.js  :/


Add ShadowWorksStockalikeSLSandMore.netkan

This netkan is currently broken on the current version of the mod, awaiting new version from author.

Passes local, no way (afaik) to force a rebuild from jenkins. Merging.

Refer KSP-CKAN/NetKAN-bot#1273

In this instance jenkins worked adequately.
When I submitted the PR it should have, and did, pass jenkins. The mod/netkan broke with a mod update after jenkins' tests, and then the 3rd update to the mod fixed it.


NODE_ENV value of 'production' did not match any deployment config file names.

WARNING: NODE_ENV value of 'production' did not match any deployment config file names.
user_api    | WARNING: See https://github.com/lorenwest/node-config/wiki/Strict-Mode

@JimBarrows Have you got any solution to the issue? I'm also facing the same problem.


[Feature Request] All In One Releases

Currently it seems that users of this lsp have two options when installing/updating: cloning the repo and compiling from source, or cloning the repo and placing the corresponding binaries from github actions in the bin/<platform>/ folder. Would it be possible to remove the cloning step from this process entirely and either ship the required files alongside the binary in github actions or post releases on the github releases page with the corresponding version of the required files included?
This would make the installation/updating process significantly simpler as one can just download a zip, extract, and run. Thanks for considering.

That is certainly possible in principle, but the issue is that there is no release workflow currently -- the binaries are purely a by-product of the CI testing.
I'm sure a PR adding such a release workflow would be appreciated!

@actboy168 help!

Basically, a release workflow should

compile the binary on the corresponding platform
create a build subdirectory
create bin/<platform> subdirectories under build
copy lua-language-server and main.lua from bin/<platform> to build/bin/<platform>
copy (recursively) main.lua, debugger.lua,  locale, meta, and script to build
zip the build directory
create a release and upload the archive.


MRG: In Report, allow to add multiple figure or image elements to the same content block ("section")

This allows for the following:
# %%
import matplotlib.pyplot as plt
import mne

r = mne.Report(title='Test')

captions = ['Cap 1', 'Cap 2']
titles = ['Title 1', 'Title 2']
tags = ['tag1', 'tag2']

for title, caption, tag in zip(titles, captions, tags):
    fig, ax = plt.subplots()
    ax.plot([1, 2, 3])
    r.add_figure(fig=fig, title=title, caption=caption,
                 section='Common Section', tags=tag)

r.save('/tmp/test.html', overwrite=True)

Which then produces:

Each figure can now be individually collapsed. Previously, such "grouping" was only possible by means of a slider, which would sometimes make it hard to discover content.
The "parent" section inherits all tags of its children.
This is also a serious refactoring, as you can see by looking at the number of changed lines … The idea was to avoid having to pass around DOM IDs and rendered HTML content so much. Previously, the _render_*() methods would return HTML content, and the calling method would then have to add the content to the report. Now, most _render_*() methods have been renamed to _add_*(), and add the content themselves. This reduces flexibility a bit, but we never made use of it anyway. The only exception is BEM rendering, where we need to group 2 sliders in a row. For this reason, _render_slider() remains.
This code lays a foundation for eventually allowing us to add a section kwarg to all add_*() methods, should we wish to do so.
I've also taken the opportunity to make use of inheritance in our Jinja templates, and get rid of a few we don't need anymore.

Rendered tutorial looks good:
https://output.circle-artifacts.com/output/job/b4a85fd7-6e60-4b0f-a3b1-9241ae45e9ef/artifacts/0/dev/auto_tutorials/intro/70_report.html#sphx-glr-auto-tutorials-intro-70-report-py
Here's a demo of the new feature:
https://output.circle-artifacts.com/output/job/b4a85fd7-6e60-4b0f-a3b1-9241ae45e9ef/artifacts/0/dev/auto_tutorials/intro/70_report.html#adding-custom-figures

and you deleted more lines than you added 👏

Aaaand many of the added lines are just because I've decided to spread out method parameters across lines (one per line), otherwise the diff would've been even more in favor of removal ;)

Since this one doesn't really change behavior, and is mostly a refactoring plus a small feature addition, I'm going a head with merging now

🙏 👏 @hoechenberger


Prevent TypeLoadExcpetion

Fixes #48
As I mentioned in the issue notes, I don't know if this is the right solution for this project, but here's a pull request that causes the TPL data flow assembly to be copied to the bin folder.

Hi @david-mitchell, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

Oops…I meant #49. I will close this and reopen another.


add category navigation

main navigation for the site
link in posts

Added in https://github.com/escowles/recipes/commit/4f9cc550acc66e18017a53533bf5fe404ad87b3a


First batch of xref link fixes (#3682)

First batch of xref fixes for #3682.
I took extra precautions in keeping the style formatting the same, but some styling might not be the one that was intended. Please point them out for me and I'll update them as soon as possible (or feel free to update them yourself!).
Updated files:

docs/framework/data/adonet/ef/sql-generation.md
docs/framework/unmanaged-api/diagnostics/isymunmanagedbinder-getreaderfromstream-method.md
docs/framework/unmanaged-api/diagnostics/isymunmanagedbinder-interface.md
docs/framework/wcf/feature-details/using-contracts-in-workflow.md
docs/framework/wcf/feature-details/using-the-discovery-client-channel.md
docs/framework/wcf/samples/binding-extensibility.md
docs/framework/windows-workflow-foundation/samples/overloadgroups.md
docs/framework/windows-workflow-foundation/samples/using-the-invokemethod-activity.md
docs/standard/io/how-to-convert-between-dotnet-streams-and-winrt-streams.md

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: RutgerM sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@mairaw Files have been updated according to your reviews.

@mairaw Your requested changes have been committed. Thanks for all the help!

Resolved some merge conflicts. I'll review it again as soon as build finishes. Thanks @RutgerM!


BAEL-791 Liquibase rollback

added the sample liquibase rollback scripts

closing since the build is failing due to the db connection


Fixed typo in URL for role permissions matrix

Fixed typo in URL for role permissions matrix

Closing as this problem has been fixed with PR https://github.com/CenturyLinkCloud/PublicKB/pull/1524


reduce build size by mounting cache

when #17 switched to uninstalling torch then reinstalling prerelease torch, it added cached wheels to the final image. by mounting the pip cache, we speed up builds and reduce final image size

How about just:
  python_packages:
    - "numpy<2"
    - "einops==0.8.0"
    - "fire >= 0.6.0"
    - "huggingface-hub==0.24.3"
    - "safetensors==0.4.3"
    - "sentencepiece==0.2.0"
    - "transformers==4.43.3"
    - "tokenizers==0.19.1"
    - "protobuf==5.27.2"
    - "diffusers==0.29.2"
    - "loguru==0.7.2"
    - "pybase64==1.4.0"
    - "pydash==8.0.3"
    - https://download.pytorch.org/whl/nightly/cu124/torch-2.6.0.dev20240918%2Bcu124-cp311-cp311-linux_x86_64.whl
    - https://download.pytorch.org/whl/nightly/cu124/torchaudio-2.5.0.dev20240918%2Bcu124-cp311-cp311-linux_x86_64.whl
    - https://download.pytorch.org/whl/nightly/cu124/torchvision-0.20.0.dev20240918%2Bcu124-cp311-cp311-linux_x86_64.whl
    - https://download.pytorch.org/whl/nightly/pytorch_triton-3.1.0%2B5fe38ffd73-cp311-cp311-linux_x86_64.whl

good stuff, I was hastily installing nightlies here and made some incorrect assumptions about how we deal with base images. @yorickvP think that's a lot cleaner; let's test that and merge if all looks good.

------
 > [stage-0 5/7] RUN --mount=type=cache,target=/root/.cache/pip pip install -r /tmp/requirements.txt:
0.721 Looking in indexes: https://pypi.org/simple, https://download.pytorch.org/whl/cu124
0.730 Collecting torch==2.6.0.dev20240918+cu124 (from -r /tmp/requirements.txt (line 16))
0.823   Downloading https://download.pytorch.org/whl/nightly/cu124/torch-2.6.0.dev20240918%2Bcu124-cp311-cp311-linux_x86_64.whl (1127.7 MB)
10.51      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.1/1.1 GB 3.5 MB/s eta 0:00:00
11.35 Collecting torchaudio==2.5.0.dev20240918+cu124 (from -r /tmp/requirements.txt (line 17))
11.36   Downloading https://download.pytorch.org/whl/nightly/cu124/torchaudio-2.5.0.dev20240918%2Bcu124-cp311-cp311-linux_x86_64.whl (3.4 MB)
11.81      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.4/3.4 MB 7.6 MB/s eta 0:00:00
11.82 Collecting torchvision==0.20.0.dev20240918+cu124 (from -r /tmp/requirements.txt (line 18))
11.82   Downloading https://download.pytorch.org/whl/nightly/cu124/torchvision-0.20.0.dev20240918%2Bcu124-cp311-cp311-linux_x86_64.whl (7.4 MB)
11.91      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 7.4/7.4 MB 90.2 MB/s eta 0:00:00
11.92 Collecting pytorch-triton==3.1.0+5fe38ffd73 (from -r /tmp/requirements.txt (line 19))
11.92   Downloading https://download.pytorch.org/whl/nightly/pytorch_triton-3.1.0%2B5fe38ffd73-cp311-cp311-linux_x86_64.whl (239.7 MB)
13.85      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 239.7/239.7 MB 15.4 MB/s eta 0:00:00
14.26 Collecting numpy<2 (from -r /tmp/requirements.txt (line 2))
14.30   Downloading numpy-1.26.4-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (61 kB)
14.31      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.0/61.0 kB 3.7 MB/s eta 0:00:00
14.32 Requirement already satisfied: torch==2.4.1 in /root/.pyenv/versions/3.11.10/lib/python3.11/site-packages (from -r /tmp/requirements.txt (line 3)) (2.4.1+cu124)
14.37 Collecting einops==0.8.0 (from -r /tmp/requirements.txt (line 4))
14.38   Downloading einops-0.8.0-py3-none-any.whl.metadata (12 kB)
14.44 Collecting fire==0.6.0 (from -r /tmp/requirements.txt (line 5))
14.44   Downloading fire-0.6.0.tar.gz (88 kB)
14.45      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 88.4/88.4 kB 7.6 MB/s eta 0:00:00
14.47   Preparing metadata (setup.py): started
14.86   Preparing metadata (setup.py): finished with status 'done'
14.94 Collecting huggingface-hub==0.24.3 (from -r /tmp/requirements.txt (line 6))
14.95   Downloading huggingface_hub-0.24.3-py3-none-any.whl.metadata (13 kB)
15.11 Collecting safetensors==0.4.3 (from -r /tmp/requirements.txt (line 7))
15.12   Downloading safetensors-0.4.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (3.8 kB)
15.29 Collecting sentencepiece==0.2.0 (from -r /tmp/requirements.txt (line 8))
15.29   Downloading sentencepiece-0.2.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (7.7 kB)
15.44 Collecting transformers==4.43.3 (from -r /tmp/requirements.txt (line 9))
15.45   Downloading transformers-4.43.3-py3-none-any.whl.metadata (43 kB)
15.46      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 43.7/43.7 kB 5.1 MB/s eta 0:00:00
15.71 Collecting tokenizers==0.19.1 (from -r /tmp/requirements.txt (line 10))
15.72   Downloading tokenizers-0.19.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (6.7 kB)
15.90 Collecting protobuf==5.27.2 (from -r /tmp/requirements.txt (line 11))
15.91   Downloading protobuf-5.27.2-cp38-abi3-manylinux2014_x86_64.whl.metadata (592 bytes)
16.03 Collecting diffusers==0.29.2 (from -r /tmp/requirements.txt (line 12))
16.03   Downloading diffusers-0.29.2-py3-none-any.whl.metadata (19 kB)
16.10 Collecting loguru==0.7.2 (from -r /tmp/requirements.txt (line 13))
16.10   Downloading loguru-0.7.2-py3-none-any.whl.metadata (23 kB)
16.24 Collecting pybase64==1.4.0 (from -r /tmp/requirements.txt (line 14))
16.24   Downloading pybase64-1.4.0-cp311-cp311-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (8.1 kB)
16.31 Collecting pydash==8.0.3 (from -r /tmp/requirements.txt (line 15))
16.31   Downloading pydash-8.0.3-py3-none-any.whl.metadata (4.5 kB)
16.32 ERROR: Cannot install torch 2.6.0.dev20240918+cu124 (from https://download.pytorch.org/whl/nightly/cu124/torch-2.6.0.dev20240918%2Bcu124-cp311-cp311-linux_x86_64.whl) and torch==2.4.1 because these package versions have conflicting dependencies.
16.32
16.32 The conflict is caused by:
16.32     The user requested torch==2.4.1
16.32     The user requested torch 2.6.0.dev20240918+cu124 (from https://download.pytorch.org/whl/nightly/cu124/torch-2.6.0.dev20240918%2Bcu124-cp311-cp311-linux_x86_64.whl)
16.32
16.32 To fix this you could try to:
16.32 1. loosen the range of package versions you've specified
16.32 2. remove package versions to allow pip attempt to solve the dependency conflict
16.32
16.32 ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts
16.41
16.41 [notice] A new release of pip is available: 24.0 -> 24.3.1
16.41 [notice] To update, run: pip install --upgrade pip
------
Dockerfile:9
--------------------
   7 |     COPY .cog/tmp/build20241029145437.2852801802109067/requirements.txt /tmp/requirements.txt
   8 |     ENV CFLAGS="-O3 -funroll-loops -fno-strict-aliasing -flto -S"
   9 | >>> RUN --mount=type=cache,target=/root/.cache/pip pip install -r /tmp/requirements.txt
  10 |     ENV CFLAGS=
  11 |     RUN curl -o /usr/local/bin/pget -L "https://github.com/replicate/pget/releases/download/v0.8.2/pget_linux_x86_64" && chmod +x /usr/local/bin/pget
--------------------
ERROR: failed to solve: process "/bin/sh -c pip install -r /tmp/requirements.txt" did not complete successfully: exit code: 1
ⅹ Failed to build Docker image: exit status 1

looks like removing the torch==2.4.1 fixes it, I'll open a PR


host header

is there a way to pass a host-header ?

Ghostunnel is a TCP/TLS proxy, it doesn't have any specific features for HTTP or other application protocols. But it will happily pass on any data you send over the connection including HTTP requests with Host headers. There's currently no way to inject additional data into connections but it might support it in the future via plugins (see issue #132 for a discussion on that).


Updating Docker output and curl for sticky sessions

Description
This PR is updating the Docker Swarm documentation with examples created with latest version of Docker. It also updates the section describing the access via sticky session by using curl command only instead of requiring to amend the /etc/hosts file and perform the test via web browser.

Note: it's the documentation for Docker Swarm mode not for Docker Swarm.


add kcc mainnet and testnet rpc

@mhxw, Thank you for your contribution. However in #78 we decided to drop the rpc list because it is very difficult to maintain and easily gets outdated. So I'll close this PR.


process is undefined on v3.3.1

There are occations where process is still undefined when using a non-webpack app. we need a solution that doesn't rely on a webpack plugin

related to #274

@lukeocodes seems you already fixed the issue with https://github.com/deepgram/deepgram-js-sdk/commit/bd51da7ce06c59b3dea55e4a915e802bd43a3754 :)


Getting Error While initialization react native app in ubuntu

Description
when i am initialization the new project in react native in Ubuntu 22.04.3 LTS. i am getting error of "Template is not getting Download" ---> "✖ Downloading template". while i perform the same on windows it's executed perfectly but the issue i am facing in ubuntu
Steps to reproduce
1.Setup the environment as described in the react native documentation
2. command for initialization a new project
React Native Version
0.73.0
Affected Platforms
Build - Linux
Output of npx react-native info
Downloading templateerror Cannot parse yarn version:
⠴ Downloading templateerror Cannot parse yarn version:
error Cannot parse yarn version:
⠹ Downloading templateerror Installing pods failed. This doesn't affect project initialization and you can safely proceed.
However, you will need to install pods manually when running iOS, follow additional steps in "Run instructions for iOS" section.

✖ Downloading template

  Run instructions for Android:
    • Have an Android emulator running (quickest way to get started), or a device connected.
    • cd "/home/whited3vil/myNewProject12" && npx react-native run-android

Stacktrace or Logs
Downloading templateerror Cannot parse yarn version:
⠴ Downloading templateerror Cannot parse yarn version:
error Cannot parse yarn version:
⠹ Downloading templateerror Installing pods failed. This doesn't affect project initialization and you can safely proceed.
However, you will need to install pods manually when running iOS, follow additional steps in "Run instructions for iOS" section.

✖ Downloading template

  Run instructions for Android:
    • Have an Android emulator running (quickest way to get started), or a device connected.
    • cd "/home/whited3vil/myNewProject12" && npx react-native run-android

Reproducer
NA
Screenshots and Videos

Hi,
Thanks for reporting this issue.
It seems like this issue is actually unrelated to React Native core. Please open this issue against this other repository:
https://github.com/react-native-community/cli/issues
I'll be closing this but feel free to reopen if the other repo points back to us as a issue in the core of React Native.

Same error

@luizricardo-co  please try this :
npm install -g yarn
yarn global add react-native-cli
react-native init sample
yarn run android
yarn start


[all OS versions] Android NDK is updated to r22.

Breaking changes
Default Android NDK was updated to r22.
Target date
Images deployment starts January, 11 and will take 3-4 days.
The motivation for the changes
We provide only the latest NDK by default due to space concerns
Possible impact
If your workflow uses features that were removed from r22 — your build will be broken. Please, refer to NDR r22 changelog for more information.
Virtual environments affected

[x] Ubuntu 16.04
[x] Ubuntu 18.04
[x] Ubuntu 20.04
[x] macOS 10.13
[x] macOS 10.14
[x] macOS 10.15
[x] macOS 11.0
[x] Windows Server 2016 R2
[x] Windows Server 2019

Mitigation ways

Ubuntu: sudo ${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;<exact_version>"
macOS: ${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;<exact_version>"
Windows: $env:ANDROID_HOME/tools/bin/sdkmanager --install "ndk;<exact_version>"

If the time is critical for you, consider using actions/cache to win some installation time.

Hello there! We use Azure DevOps pipelines with the macOS 10.15 image to build our Android apps.
Yesterday we wanted to build releases of our apps, but we got gradle errors back that the NDK version was not available. We googled and found this issue :). We then tried out your specified mitigation way, but that unfortunately did not work.
We tried out all of these commands, but they all failed:
sudo ${ANDROID_HOME}/tools/bin/sdkmanager --sdk_root=${ANDROID_HOME} --install "ndk;22.0.7026061"

sudo ${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;22.0.7026061"

export JAVA_OPTS='-XX:+IgnoreUnrecognizedVMOptions --add-modules java.se.ee'
sudo ${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;22.0.7026061"

Error:
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema
	at com.android.repository.api.SchemaModule$SchemaModuleVersion.<init>(SchemaModule.java:156)
	at com.android.repository.api.SchemaModule.<init>(SchemaModule.java:75)
	at com.android.sdklib.repository.AndroidSdkHandler.<clinit>(AndroidSdkHandler.java:81)
	at com.android.sdklib.tool.sdkmanager.SdkManagerCli.main(SdkManagerCli.java:73)
	at com.android.sdklib.tool.sdkmanager.SdkManagerCli.main(SdkManagerCli.java:48)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.annotation.XmlSchema
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 5 more

Could you please tell us when the migration will be finished, or how we can mitigate the issue? Seems like today is the last day of migration, but the rollout progress is only at 25%. Thanks in advance!

Hello there! We use Azure DevOps pipelines with the macOS 10.15 image to build our Android apps.
Yesterday we wanted to build releases of our apps, but we got gradle errors back that the NDK version was not available. We googled and found this issue :). We then tried out your specified mitigation way, but that unfortunately did not work.
We tried out all of these commands, but they all failed:
sudo ${ANDROID_HOME}/tools/bin/sdkmanager --sdk_root=${ANDROID_HOME} --install "ndk;22.0.7026061"

sudo ${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;22.0.7026061"

export JAVA_OPTS='-XX:+IgnoreUnrecognizedVMOptions --add-modules java.se.ee'
sudo ${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;22.0.7026061"

Error:
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema
	at com.android.repository.api.SchemaModule$SchemaModuleVersion.<init>(SchemaModule.java:156)
	at com.android.repository.api.SchemaModule.<init>(SchemaModule.java:75)
	at com.android.sdklib.repository.AndroidSdkHandler.<clinit>(AndroidSdkHandler.java:81)
	at com.android.sdklib.tool.sdkmanager.SdkManagerCli.main(SdkManagerCli.java:73)
	at com.android.sdklib.tool.sdkmanager.SdkManagerCli.main(SdkManagerCli.java:48)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.annotation.XmlSchema
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 5 more

Could you please tell us when the migration will be finished, or how we can mitigate the issue? Seems like today is the last day of migration, but the rollout progress is only at 25%. Thanks in advance!

Hello @carstenhag, Could you please provide image version from your last successful build and first failed build? (Image version can be found in the logs of first step of build).
What exact version of NDK do you need to use in your build?
The previous image version (20201212.1) contained NDK 21.3.6528147. The new image version (20210110.1) contains NDK 22.0.7026061.
If your build started to fail after image upgrade, I guess you need to install NDK 21.3.6528147 in runtime, not 22.0.7026061 (if I understand you correctly)

Hello @carstenhag, Could you please provide image version from your last successful build and first failed build? (Image version can be found in the logs of first step of build).
What exact version of NDK do you need to use in your build?
The previous image version (20201212.1) contained NDK 21.3.6528147. The new image version (20210110.1) contains NDK 22.0.7026061.
If your build started to fail after image upgrade, I guess you need to install NDK 21.3.6528147 in runtime, not 22.0.7026061 (if I understand you correctly)

ndk-bundle now don't contain directory called : platforms. We faced issue with gradle:
Configure project :app
NDK is missing a "platforms" directory.
If you are using NDK, verify the ndk.dir is set to a valid NDK directory. It is currently set to /usr/local/lib/android/sdk/ndk-bundle.
If you are not using NDK, unset the NDK variable from ANDROID_NDK_HOME or local.properties to remove this warning.
Issue happened first time yesterday afternoon and continues today. Can you please support ?

ndk-bundle now don't contain directory called : platforms. We faced issue with gradle:
Configure project :app
NDK is missing a "platforms" directory.
If you are using NDK, verify the ndk.dir is set to a valid NDK directory. It is currently set to /usr/local/lib/android/sdk/ndk-bundle.
If you are not using NDK, unset the NDK variable from ANDROID_NDK_HOME or local.properties to remove this warning.
Issue happened first time yesterday afternoon and continues today. Can you please support ?

Hello there! We have been using 21.3.6528147 for some months now. Our builds failed with that (because we got a new image), the logs said that we should use 22.0.7026061, so we did so and we committed that.
But now we seem to always get old images again which don't have 22.0.7026061 so I wanted to manually install it :D

Hello there! We have been using 21.3.6528147 for some months now. Our builds failed with that (because we got a new image), the logs said that we should use 22.0.7026061, so we did so and we committed that.
But now we seem to always get old images again which don't have 22.0.7026061 so I wanted to manually install it :D

We just hit the NDK mismatch on our CI, and while I understand you have to keep them updated, is there any way to announce it through some other channels?

We just hit the NDK mismatch on our CI, and while I understand you have to keep them updated, is there any way to announce it through some other channels?

Same here. I know that Azure DevOps does announce brownouts of image and have seen those before. Would have been very good to announce this as well.

Same here. I know that Azure DevOps does announce brownouts of image and have seen those before. Would have been very good to announce this as well.

@ystefinko, could you please try mitigation step above? Adding sudo ${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;21.3.6528147" as a first step of your build?
@carstenhag , sorry for inconvenience, deployment should be finished on Monday.
I think you have two options:

reverting your app to NDK 21.3.6528147 and use mitigation step sudo ${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;21.3.6528147"
leave on 22.0.7026061 and manually install 22.0.7026061. As soon as new image is fully deployed, installation time will be reduced to zero since NDK will be already available.

@ystefinko, could you please try mitigation step above? Adding sudo ${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;21.3.6528147" as a first step of your build?
@carstenhag , sorry for inconvenience, deployment should be finished on Monday.
I think you have two options:

reverting your app to NDK 21.3.6528147 and use mitigation step sudo ${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;21.3.6528147"
leave on 22.0.7026061 and manually install 22.0.7026061. As soon as new image is fully deployed, installation time will be reduced to zero since NDK will be already available.

@maxim-lobanov unfortunately the suggested line does not work (I had posted the errors we got at https://github.com/actions/virtual-environments/issues/2420#issuecomment-760767063).

@maxim-lobanov unfortunately the suggested line does not work (I had posted the errors we got at https://github.com/actions/virtual-environments/issues/2420#issuecomment-760767063).

@maxim-lobanov unfortunately the suggested line does not work (I had posted the errors we got at https://github.com/actions/virtual-environments/issues/2420#issuecomment-760767063).

@maxim-lobanov unfortunately the suggested line does not work (I had posted the errors we got at https://github.com/actions/virtual-environments/issues/2420#issuecomment-760767063).

@dentuzhik , have you tried to subscribe to releases?

Regular Weekly Rhythm can be followed by watching Releases. Pre-release is created when deployment is started. As soon as deployment is finished, it is converted to release.

@carstenhag , sorry for inconvenience. Usually deployment of macOS takes less 2 days but this week we have stuck with multiple environment issues.

@dentuzhik , have you tried to subscribe to releases?

Regular Weekly Rhythm can be followed by watching Releases. Pre-release is created when deployment is started. As soon as deployment is finished, it is converted to release.

@carstenhag , sorry for inconvenience. Usually deployment of macOS takes less 2 days but this week we have stuck with multiple environment issues.

Maybe we are talking past eachother, I will try to be more specific :). It is not a problem that the rollout takes some time.
For us it is a problem, that the mitigation does not work. We would have been happy if the mitigation would have installed the ndk version.

Maybe we are talking past eachother, I will try to be more specific :). It is not a problem that the rollout takes some time.
For us it is a problem, that the mitigation does not work. We would have been happy if the mitigation would have installed the ndk version.

For us root cause was in bug with Android gradle plugin - https://issuetracker.google.com/issues/144111441
With 4.1.1 version it's possible to completely remove hardcoded ndkVersion and let plugin to resolve it automatically

For us root cause was in bug with Android gradle plugin - https://issuetracker.google.com/issues/144111441
With 4.1.1 version it's possible to completely remove hardcoded ndkVersion and let plugin to resolve it automatically

@carstenhag , oh, just realized an issue.
Try without sudo ${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;21.3.6528147". sudo is needed only for Ubuntu images. Will fix the first post.

@carstenhag , oh, just realized an issue.
Try without sudo ${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;21.3.6528147". sudo is needed only for Ubuntu images. Will fix the first post.

Thanks, that did work (I used ${ANDROID_HOME}/tools/bin/sdkmanager --sdk_root=${ANDROID_HOME} --install "ndk;22.0.7026061" to be precise, but I guess --sdk_root can be omitted)

Thanks, that did work (I used ${ANDROID_HOME}/tools/bin/sdkmanager --sdk_root=${ANDROID_HOME} --install "ndk;22.0.7026061" to be precise, but I guess --sdk_root can be omitted)

I have logged bug for an issue with sudo: https://github.com/actions/virtual-environments/issues/2454
sdkmanager refers incorrect Java version via sudo. It is reason why initial command fails on macOS.

I have logged bug for an issue with sudo: https://github.com/actions/virtual-environments/issues/2454
sdkmanager refers incorrect Java version via sudo. It is reason why initial command fails on macOS.

This behavior is by design for sudo:
-E' The -E (preserve environment) option indicates to the security policy that the user wishes to preserve their existing environment variables. The security policy may return an error if the -E option is specified and the user does not have permission to preserve the environment.
you should use flag -E to pass env variables, because JAVA_HOME is missing:
Mac-1610725225646:~ runner$ sudo java -version
openjdk version "14.0.2" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 14.0.2+12)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 14.0.2+12, mixed mode, sharing)

Mac-1610725225646:~ runner$ sudo -E java -version
openjdk version "1.8.0_275"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_275-b01)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.275-b01, mixed mode)

unset JAVA_HOME:
Mac-1610725225646:~ runner$ unset JAVA_HOME
Mac-1610725225646:~ runner$ java -version
openjdk version "14.0.2" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 14.0.2+12)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 14.0.2+12, mixed mode, sharing)

This behavior is by design for sudo:
-E' The -E (preserve environment) option indicates to the security policy that the user wishes to preserve their existing environment variables. The security policy may return an error if the -E option is specified and the user does not have permission to preserve the environment.
you should use flag -E to pass env variables, because JAVA_HOME is missing:
Mac-1610725225646:~ runner$ sudo java -version
openjdk version "14.0.2" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 14.0.2+12)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 14.0.2+12, mixed mode, sharing)

Mac-1610725225646:~ runner$ sudo -E java -version
openjdk version "1.8.0_275"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_275-b01)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.275-b01, mixed mode)

unset JAVA_HOME:
Mac-1610725225646:~ runner$ unset JAVA_HOME
Mac-1610725225646:~ runner$ java -version
openjdk version "14.0.2" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 14.0.2+12)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 14.0.2+12, mixed mode, sharing)

@maxim-lobanov
I tried out all of these commands, but they all failed:
sudo ${ANDROID_HOME}/tools/bin/sdkmanager --sdk_root=${ANDROID_HOME} --install "ndk;22.0.7026061"
sudo ${ANDROID_HOME}/tools/bin/sdkmanager --sdk_root=${ANDROID_HOME} --install "ndk;21.3.6528147"
unset ANDROID_NDK_HOME
Gradle 5.1.1, Android gradle plugin 3.4.0(tried 3.4.3).
Our android example app still not compiling: https://dev.azure.com/heremaps/here-data-sdk/_build?definitionId=3&_a=summary
We need urgent support , as our development became blocked by changes on your side.

@maxim-lobanov
I tried out all of these commands, but they all failed:
sudo ${ANDROID_HOME}/tools/bin/sdkmanager --sdk_root=${ANDROID_HOME} --install "ndk;22.0.7026061"
sudo ${ANDROID_HOME}/tools/bin/sdkmanager --sdk_root=${ANDROID_HOME} --install "ndk;21.3.6528147"
unset ANDROID_NDK_HOME
Gradle 5.1.1, Android gradle plugin 3.4.0(tried 3.4.3).
Our android example app still not compiling: https://dev.azure.com/heremaps/here-data-sdk/_build?definitionId=3&_a=summary
We need urgent support , as our development became blocked by changes on your side.

@ystefinko As maxim wrote at https://github.com/actions/virtual-environments/issues/2420#issuecomment-760998986, leave out the sudo, then it works. I also confirmed that this works some comments ago...
${ANDROID_HOME}/tools/bin/sdkmanager --sdk_root=${ANDROID_HOME} --install "ndk;22.0.7026061 will install the ndk version 22.0.7026061. If you need any other version, specify that in its place.

@ystefinko As maxim wrote at https://github.com/actions/virtual-environments/issues/2420#issuecomment-760998986, leave out the sudo, then it works. I also confirmed that this works some comments ago...
${ANDROID_HOME}/tools/bin/sdkmanager --sdk_root=${ANDROID_HOME} --install "ndk;22.0.7026061 will install the ndk version 22.0.7026061. If you need any other version, specify that in its place.

@carstenhag and @maxim-lobanov issue still exist. I ran it without sudo too.

@carstenhag and @maxim-lobanov issue still exist. I ran it without sudo too.

Hello @ystefinko. As a solution you can try

setup build gradle to the 4.1.0 : classpath 'com.android.tools.build:gradle:4.1.0'
update gradle version to 6.5.1: distributionUrl=https\://services.gradle.org/distributions/gradle-6.5.1-all.zip
Update build.sh part to this:

${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;21.3.6528147" --sdk_root=${ANDROID_HOME} > /dev/null
export ANDROID_NDK_HOME=$ANDROID_HOME/ndk/21.3.6528147

mkdir -p build && cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE="$ANDROID_HOME/ndk/21.3.6528147/build/cmake/android.toolchain.cmake" \
	-DANDROID_PLATFORM=android-28 \
	-DANDROID_NDK="$ANDROID_HOME/ndk/21.3.6528147" \
	-DANDROID_ABI=arm64-v8a \
	-DOLP_SDK_ENABLE_TESTING=NO \
	-DOLP_SDK_BUILD_EXAMPLES=ON

Hello @ystefinko. As a solution you can try

setup build gradle to the 4.1.0 : classpath 'com.android.tools.build:gradle:4.1.0'
update gradle version to 6.5.1: distributionUrl=https\://services.gradle.org/distributions/gradle-6.5.1-all.zip
Update build.sh part to this:

${ANDROID_HOME}/tools/bin/sdkmanager --install "ndk;21.3.6528147" --sdk_root=${ANDROID_HOME} > /dev/null
export ANDROID_NDK_HOME=$ANDROID_HOME/ndk/21.3.6528147

mkdir -p build && cd build
cmake ..
Thanks for advice!
All your suggestions helped. Build passed.
Minor issues detected:

Gradle detected incorrect version of NDK -
> Configure project :app
2021-01-19T11:16:48.6826915Z Checking the license for package NDK (Side by side) 21.1.6352462 in /usr/local/lib/android/sdk/licenses
2021-01-19T11:16:48.6827494Z License for package NDK (Side by side) 21.1.6352462 accepted.
2021-01-19T11:16:48.6828028Z Preparing "Install NDK (Side by side) 21.1.6352462 (revision: 21.1.6352462)".
2021-01-19T11:18:09.0800388Z "Install NDK (Side by side) 21.1.6352462 (revision: 21.1.6352462)" ready.
2021-01-19T11:18:09.0801346Z Installing NDK (Side by side) 21.1.6352462 in /usr/local/lib/android/sdk/ndk/21.1.6352462
2021-01-19T11:18:09.0801881Z "Install NDK (Side by side) 21.1.6352462 (revision: 21.1.6352462)" complete.
2021-01-19T11:18:09.3817717Z "Install NDK (Side by side) 21.1.6352462 (revision: 21.1.6352462)" finished.

$GRADLE_HOME variable is available but I can't use it. Seems like PATH is incorrect, because we can't access any file there. This is minor as we are sill using gradlew.

@dmitry-shibanov hello!
Thanks for advice!
All your suggestions helped. Build passed.
Minor issues detected:

Gradle detected incorrect version of NDK -
> Configure project :app
2021-01-19T11:16:48.6826915Z Checking the license for package NDK (Side by side) 21.1.6352462 in /usr/local/lib/android/sdk/licenses
2021-01-19T11:16:48.6827494Z License for package NDK (Side by side) 21.1.6352462 accepted.
2021-01-19T11:16:48.6828028Z Preparing "Install NDK (Side by side) 21.1.6352462 (revision: 21.1.6352462)".
2021-01-19T11:18:09.0800388Z "Install NDK (Side by side) 21.1.6352462 (revision: 21.1.6352462)" ready.
2021-01-19T11:18:09.0801346Z Installing NDK (Side by side) 21.1.6352462 in /usr/local/lib/android/sdk/ndk/21.1.6352462
2021-01-19T11:18:09.0801881Z "Install NDK (Side by side) 21.1.6352462 (revision: 21.1.6352462)" complete.
2021-01-19T11:18:09.3817717Z "Install NDK (Side by side) 21.1.6352462 (revision: 21.1.6352462)" finished.

$GRADLE_HOME variable is available but I can't use it. Seems like PATH is incorrect, because we can't access any file there. This is minor as we are sill using gradlew.

This broke our CI as well - would love for there to be an announcement channel for stuff like this. Quick note that the docs here for the macos-10.15 installed software (and probably in the lists for other images) don't show this as updated, noticed when I went googling for a solution.

This broke our CI as well - would love for there to be an announcement channel for stuff like this. Quick note that the docs here for the macos-10.15 installed software (and probably in the lists for other images) don't show this as updated, noticed when I went googling for a solution.

Hi all,
we are started working on rolling back the image due to huge impact. It can take 1-2 days.
We will revisit strategy of NDK support, and will rollout image with the fix next week.
Sorry for inconveniences and thank you for your patience.

Hi all,
we are started working on rolling back the image due to huge impact. It can take 1-2 days.
We will revisit strategy of NDK support, and will rollout image with the fix next week.
Sorry for inconveniences and thank you for your patience.

@sashaweiss About the readme being out of date: The readmes only get updated after the rollout is 100% through. No clue where I saw it, but a contributor mentioned this

@sashaweiss About the readme being out of date: The readmes only get updated after the rollout is 100% through. No clue where I saw it, but a contributor mentioned this

@carstenhag @sashaweiss the proper link to the readme can be found in the set up job step

@carstenhag @sashaweiss the proper link to the readme can be found in the set up job step

@miketimofeev thanks for the tip! I'll use that next time, that'll be handy.

@miketimofeev thanks for the tip! I'll use that next time, that'll be handy.

Earlier in the week I bumped to 22.x and a few actions have run fine.
This morning...

No version of NDK matched the requested version 22.0.7026061. Versions available locally: 21.3.6528147

Was this rolled back in ubuntu-latest?

Earlier in the week I bumped to 22.x and a few actions have run fine.
This morning...

No version of NDK matched the requested version 22.0.7026061. Versions available locally: 21.3.6528147

Was this rolled back in ubuntu-latest?

Unfortunately, yes. We have got a lot of reports from customers about breaking builds with NDK 22.x. Also we have got feedback from Xamarin.Android team - NDK 22 is not supported ye. We have to roll images back and freeze NDK 21 on images for a while. A bit more context in https://github.com/actions/virtual-environments/issues/2481#issuecomment-763700114

Unfortunately, yes. We have got a lot of reports from customers about breaking builds with NDK 22.x. Also we have got feedback from Xamarin.Android team - NDK 22 is not supported ye. We have to roll images back and freeze NDK 21 on images for a while. A bit more context in https://github.com/actions/virtual-environments/issues/2481#issuecomment-763700114

Closing this issue, because we reverted image with r22 and will deploy this week with default to r21.

Closing this issue, because we reverted image with r22 and will deploy this week with default to r21.

Here we go again https://github.com/actions/virtual-environments/issues/4144


feat(instructor): introduce ANTHROPIC_JSON mode

:rocket: This PR description was created by Ellipsis for commit d4a3fdb2076274296afffce0a094361f138094e0.

Summary:
This PR introduces a new ANTHROPIC_JSON mode in the instructor package, updates relevant files, documentation, and tests, removes some files, updates the GitHub workflow, and renames some test files.
Key points:

Introduced a new ANTHROPIC_JSON mode in instructor/mode.py.
Updated instructor/function_calls.py and instructor/process_response.py to handle the new mode.
Updated documentation in docs/blog/posts/anthropic.md and docs/concepts/patching.md.
Updated tests in tests/anthropic/test_simple.py.
Removed examples/classification/test_run.py and tests/anthropic/test_anthropic.py.
Updated .github/workflows/test.yml to install dependencies with new mode and run tests excluding a different keyword.
Renamed test files and updated imports due to renaming.

Generated with :heart: by ellipsis.dev

why not just use MD_JSON vs adding a new mode

why not just use MD_JSON vs adding a new mode

i dont have polyglot,
so i have to handle system message, and getting the text out


Fix country picker rhn issue

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/23852
PROPOSAL: https://github.com/Expensify/App/issues/23852#issuecomment-1656723924
Tests

Go to Settings -> Profile -> Personal details -> Home address -> Country
Click on backdrop
Notice whole RHN closes

[x] Verify that no errors appear in the JS console

Offline tests

Same as tests
QA Steps

Same as tests

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://github.com/Expensify/App/assets/65986357/35bea930-fe49-4445-950b-2d94f6c5a65c

Mobile Web - Chrome
https://github.com/Expensify/App/assets/65986357/f89863c2-916a-4401-967a-54e4b1e549cf

Mobile Web - Safari
https://github.com/Expensify/App/assets/65986357/747b6c45-6263-4f81-b8b5-29243a03d7ee

Desktop
https://github.com/Expensify/App/assets/65986357/4c66e710-bc8d-402a-9b5f-6a9888a87eed

iOS
https://github.com/Expensify/App/assets/65986357/d8a208ab-d09f-4a0d-96c4-03ed160cbf2f

Android
https://github.com/Expensify/App/assets/65986357/ea628170-407f-49b3-b2ad-aac4c50d7c7c

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

Just realized Andrew is OOO. Going ahead and assigning @ygshbht. Let's do it 💪🏾

@puneetlath said @AndrewGable is OOO so maybe @puneetlath could do the final review

Hmmm, now that I'm seeing the PR, I'm not sure that I love this solution. I know I agreed to it before, but I'm having second thoughts about handling it this way instead of making it a page. I don't love that we have to have platform-specific logic and also it's not a global solution (the problem still exists on the State picker).
I commented here to learn more about why making the picker it's own page would be a problem.

@puneetlath
I understand to a great extent why you might not be fond of platform-specific logic. I'd like to mention, there are times when it's more reasonable to use such an approach, which is why these functions already exist.
To clarify more, the onModalClose function behaves differently depending on the platform: it's activated by clicking the modal backdrop on desktop web and macOS app, and by hitting the device back button on native devices. On native devices, you just want to go back to previous screen as opposed to dismissing the modal. Instead of creating a new file with nearly identical logic, it seemed more efficient to use existing functions for this purpose.
I'm open to your thoughts, as you have the final review

Ok after the discussion in this issue, we're going to go the new page route. So I'm going to go ahead and close out this issue.
But we'll still pay you for the time @ygshbht since we did hire you to do the work and you've already spent the time doing it.


fix: put Nat.primeCounting in a narrower scope

Without this, it is not possible to mix ! notation for factorial and π notation for Real.pi.
More precisely; while the following works in Mathlib/Analysis/SpecialFunctions/Stirling.lean
lemma factorial_isEquivalent_stirling :
    (fun n ↦ n ! : ℕ → ℝ) ~[atTop] fun n ↦ Real.sqrt (2 * n * π) * (n / exp 1) ^ n := by

it produces an error about ambiguous syntax in a standalone file with import Mathlib:
import Mathlib

open scoped Real Nat Asymptotics
open Real

lemma factorial_isEquivalent_stirling :
    (fun n ↦ n ! : ℕ → ℝ) ~[atTop] fun n ↦ Real.sqrt (2 * n * π) * (n / exp 1) ^ n := by

Follows on from #13473

Thanks!
bors merge


[BUG] Currently can't use the package with "@chakra-ui/react": "^2.9.3"

Description
When i pulled the latest release, i am unable to run the react project managed with vite, i get this error
Could not resolve "@chakra-ui/form-control"
node_modules/chakra-react-select/dist/index.js:5:26:
  5 │ var formControl = require('@chakra-ui/form-control')

chakra-react-select Version
5.0.0-rc.8
Link to Reproduction
No response
TypeScript?

[X] Yes I use TypeScript

Steps to reproduce

Go to '...'
Click on '...'
Scroll down to '...'
See error

Operating System

[X] macOS
[ ] Windows
[ ] Linux
[ ] iOS/iPadOS
[ ] Android

Additional Information
No response

It seems like this new chakra version removes some dependencies that this package uses. I think it's maybe related to the new chakra v3, making the migration from v2 to v3 more seamless.
I've fixed the error explicitly adding the following packages to my project dependencies:
        "@chakra-ui/form-control": "2.2.0",
        "@chakra-ui/layout":"2.3.1",
        "@chakra-ui/system": "2.6.2",
        "@chakra-ui/media-query": "3.3.0",
        "@chakra-ui/menu": "2.2.1",
        "@chakra-ui/spinner": "2.1.0",

not happy, but...

I got a similar error after updating @chakra-ui dependencies. I'm using "chakra-react-select": "^4.9.2",. It prevents me from starting the project.
"@chakra-ui/icons": "^2.1.1" --> "^2.2.4",
"@chakra-ui/react": "^2.8.2" --> "^2.10.1",

Error Log
✘ [ERROR] Could not resolve "@chakra-ui/form-control"

    node_modules/chakra-react-select/dist/index.mjs:4:31:
      4 │ import { useFormControl } from '@chakra-ui/form-control';
        ╵                                ~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@chakra-ui/form-control" as external to exclude it from the bundle, which
  will remove this error and leave the unresolved path in the bundle.

✘ [ERROR] Could not resolve "@chakra-ui/system"

    node_modules/chakra-react-select/dist/index.mjs:5:89:
      5 │ import { useTheme, useMultiStyleConfig, useStyleConfig, useColorModeValue, chakra } from '@chakra-ui/system';
        ╵                                                                                ~~~~~~~~~~~~~~~~~~~

  You can mark the path "@chakra-ui/system" as external to exclude it from the bundle, which will
  remove this error and leave the unresolved path in the bundle.

✘ [ERROR] Could not resolve "@chakra-ui/layout"

    node_modules/chakra-react-select/dist/index.mjs:6:29:
      6 │ import { Box, Divider } from '@chakra-ui/layout';
        ╵                              ~~~~~~~~~~~~~~~~~~~

  You can mark the path "@chakra-ui/layout" as external to exclude it from the bundle, which will
  remove this error and leave the unresolved path in the bundle.

✘ [ERROR] Could not resolve "@chakra-ui/media-query"

    node_modules/chakra-react-select/dist/index.mjs:7:35:
      7 │ import { useBreakpointValue } from '@chakra-ui/media-query';
        ╵                                    ~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@chakra-ui/media-query" as external to exclude it from the bundle, which
  will remove this error and leave the unresolved path in the bundle.

✘ [ERROR] Could not resolve "@chakra-ui/icon"

    node_modules/chakra-react-select/dist/index.mjs:9:21:
      9 │ import { Icon } from '@chakra-ui/icon';
        ╵                      ~~~~~~~~~~~~~~~~~

  You can mark the path "@chakra-ui/icon" as external to exclude it from the bundle, which will
  remove this error and leave the unresolved path in the bundle.

✘ [ERROR] Could not resolve "@chakra-ui/spinner"

    node_modules/chakra-react-select/dist/index.mjs:10:24:
      10 │ import { Spinner } from '@chakra-ui/spinner';
         ╵                         ~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@chakra-ui/spinner" as external to exclude it from the bundle, which will
  remove this error and leave the unresolved path in the bundle.

✘ [ERROR] Could not resolve "@chakra-ui/menu"

    node_modules/chakra-react-select/dist/index.mjs:11:31:
      11 │ import { MenuIcon, Menu } from '@chakra-ui/menu';
         ╵                                ~~~~~~~~~~~~~~~~~

  You can mark the path "@chakra-ui/menu" as external to exclude it from the bundle, which will
  remove this error and leave the unresolved path in the bundle.

<PROJECT_DIR>/node_modules/esbuild/lib/main.js:1472
  let error = new Error(text);
              ^

Error: Build failed with 7 errors:
node_modules/chakra-react-select/dist/index.mjs:4:31: ERROR: Could not resolve "@chakra-ui/form-control"
node_modules/chakra-react-select/dist/index.mjs:5:89: ERROR: Could not resolve "@chakra-ui/system"
node_modules/chakra-react-select/dist/index.mjs:6:29: ERROR: Could not resolve "@chakra-ui/layout"
node_modules/chakra-react-select/dist/index.mjs:7:35: ERROR: Could not resolve "@chakra-ui/media-query"
node_modules/chakra-react-select/dist/index.mjs:9:21: ERROR: Could not resolve "@chakra-ui/icon"
...
    at failureErrorWithLog (<PROJECT_DIR>/node_modules/esbuild/lib/main.js:1472:15)
    at <PROJECT_DIR>/node_modules/esbuild/lib/main.js:945:25
    at <PROJECT_DIR>/node_modules/esbuild/lib/main.js:1353:9
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  errors: [Getter/Setter],
  warnings: [Getter/Setter]
}

Node.js v20.17.0
error Command failed with exit code 1.

Sorry for the delay, I will take a look at this tonight or tomorrow when I get a chance.

Ok this should be fixed in v4.10.0! Please give it a shot any let me know if the issue is fixed for you. If it isn't, I'll reopen this issue.
Also @sirdavis99, if you're using the release candidate version, I published a new version for that as well, v5.0.0-rc.9

@csandman Thank you for your efforts. After upgrading I did not find any issues.


Add BoneCode specific namesspace to JSonDataObjects

As long as the JSonDataObject is included in this repo, it should have a BoneCode specific namespace, like BCEditor.JSonDataObjects.pas
Otherwhise, your packages might conflict with other packages using the same unit.

Fixed.


WebSockets

Added info on web-socket-js.
Added info about Safari concerns, IETF standardization.

@cboden Could you make revisions based on the feedback from @beverloo above? I agree with his recommendations.

[nit1]
Sorry!  Two spaces after ending a sentence is a very, very old force of habit.
[nit2]
"WebSocket" is the correct casing.
[Hixie]
I will update my wording clarifying the Flash on Safari bit.
Technically Chrome, Firefox, Opera, IE10 (beta) support RFC6455 or HyBi-(10 through 17) in which the protocol implementations are nearly all the same.  The data framing did not change in those versions (other than extension definitions [non-impactful]).  Changes were mostly documentation, such as how to handle unwanted requests from a foreign domain.  Each of those browsers automatically update and thus have recent support for HyBi or RFC6455.
Safari (including mobile) is currently the only browser that has support for Hixie.  I think it is fair to single it out.  Hixie is unreliable and insecure.

The other thing I would like to mention here to you guys is that disabling WebSockets on Safari is actually poor choice of wording on my part.
Using WebSockets is actually more involved on the server side...the JavaScript WebSocket API doesn't change from using Hixie, HyBi or RFC6455.  The server implementation should detect the protocol version and deny access to Hixie.  This is the old "feature detection vs browser detection" deal.
This all being said, a front end developer shouldn't have to worry about protocol versions as that data is handled by the browser and web server - the user only knows "this isn't working on Safari".
What information should be exposed to people viewing html5please.us?

The sole breaking change is that the Sec-WebSocket-Origin header got renamed to Origin (between HyBi-10 and -17), furthermore they should be ok. I'm not sure in which version Firefox and/or Opera updated to the new protocol, Chrome is fine starting version 16.
These concerns indeed are about the protocol, but it isn't rare that updating server-side code (especially in terms of larger projects) is harder than client-side code. Nonetheless, neither is it rare for the front-end developer to also mock around with a server-side handling (albeit through Node.JS), so I think concerns about the protocol should be included.
Either way, if you could clarify that the Flash-fallback only applies to desktop Safari (and address the other nits) then I'm fine with the change overall. Thank you!!
P.s.: I'm assuming "Hixie is unreliable and insecure." is just unfortunate wording, given that Hixie himself is fine :-).

Thanks for the input @beverloo!  I've made a new PR with the changes.
I never did understand the Origin change...it was "Origin" in Hixie, "Sec-WebSocket-Origin" somewhere in HyBi, then again back to "Origin" in later HyBi and RFC. IMO server implementations should support HyBi-10 through RFC including support for the Origin differences (but that's another discussion topic) :).
lol @ Hixie!  I meant the protocol, not Ian!


[User demo Request] Audio conversion + text summary

Required prerequisites

[X] I have searched the Issue Tracker and Discussions that this hasn't already been reported. (+1 or comment there if it has.)
[ ] Consider asking first in a Discussion.

Motivation
In this tutorial demo, we need to build a meeting minutes bot to help users quickly grasp the main topics of lengthy meetings. Will need to use Camel's OpenAIAudioModels class to convert audio into text and then utilize Camel's summary tool to draft the meeting minutes.
Solution
No response
Alternatives
No response
Additional context
No response

finished


Multibyte characters (emoji) are considered multiple characters

for the ContentState:
  "blocks": [
    {
      "data": {},
      "depth": 0,
      "entityRanges": [
        {
          "key": 0,
          "length": 12,
          "offset": 0
        }
      ],
      "inlineStyleRanges": [],
      "key": "471ua",
      "text": "be a fish 🐡~",
      "type": "header-one"
    }
  ],
  "entityMap": {
    "0": {
      "data": {
        "data": {
          "color": "#ffffff"
        }
      },
      "mutability": "MUTABLE",
      "type": "ENTITY"
    }
  }
}```

the entity "ENTITY with `{ data: { color: "#ffffff" } }` is only applied to the emoji, missing the trailing "~" character. Removing the trailing "~" character splits the multibyte emoji into halves (half white, half default color).

`> "be a fish 🐡~".length // = 13`, but is really 12 multibyte characters. The fix would be to treat multibyte characters as single characters, which would mean manually implementing multibyte functions for calclulating length and assessing offsets. ([similar to this](http://stackoverflow.com/questions/2848462/count-bytes-in-textarea-using-javascript))

I'll look into it, but probably not sooner than in a few days, unless you want to make a PR?

Ok, seems i lied and had some time to look into it :smile:
This is just an idea of how it could be fixed, also let me know if it actually does, as I didn't have time to do proper tests for this.

No worries, I'll take a look sometime before/on Monday.


Analytics.prototype.track callback should wait on result and indicate status

The callback function sent to Analytics.prototype.track is pretty useless - it just fires after a timeout instead of waiting on the response status. In some cases we may want to wait on event tracking completion before, say, navigating to a different webpage.

What status should it wait on?
There are multiple client side integrations, all of which may make a request. Each has its own behavior.

Most (if not all) don't even give us a callback to hook into.
Some queue the message and might not upload the messages until much later.
Some integrations might not even have loaded when you call track.

The idea behind the timeout is that it's a reasonable estimate of "hey, if everything went well, the event has been sent to integrations". Don't use it as a guarantee.

(I've closed the issue as I don't think there is a great solution here - but feel free to reopen or leave ideas).