 This default branch name
2021-02-20T23:20:51.4828896Z hint: is subject to change. To configure the initial branch name to use in all
2021-02-20T23:20:51.4830024Z hint: of your new repositories, which will suppress this warning, call:
2021-02-20T23:20:51.4830838Z hint:
2021-02-20T23:20:51.4832429Z hint: 	git config --global init.defaultBranch
2021-02-20T23:20:51.4833083Z hint:
2021-02-20T23:20:51.4833861Z hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
2021-02-20T23:20:51.4834999Z hint: 'development'.  You can look around, make experimental
2021-02-20T23:20:52.2372028Z changes and commit them, and you can discard any commits you make in this
2021-02-20T23:20:52.2372858Z state without impacting any branches by switching back to a branch.
2021-02-20T23:20:52.2373332Z
2021-02-20T23:20:52.2373894Z If you want to create a new branch to retain commits you create, you may
2021-02-20T23:20:52.2374851Z do so (now or later) by using -c with the switch command. Example:
2021-02-20T23:20:52.2375305Z
2021-02-20T23:20:52.2375898Z   git switch -c
2021-02-20T23:20:52.2376279Z
2021-02-20T23:20:52.2376698Z Or undo this operation with:
2021-02-20T23:20:52.2377019Z
2021-02-20T23:20:52.2377505Z   git switch -
2021-02-20T23:20:52.2377780Z
2021-02-20T23:20:52.2378431Z Turn off this advice by setting config variable advice.detachedHead to false
2021-02-20T23:20:52.2379008Z
2021-02-20T23:20:52.2379808Z HEAD is now at 0ac9cd4 Merge 65e830d23c34b153871673f148bf773958cb9772 into 007a96d5665f1e13a5000d1bc877e2c53833afed
2021-02-20T23:20:52.2383278Z ##[endgroup]
2021-02-20T23:20:52.2432335Z [command]/usr/bin/git log -1 --format='%H'
2021-02-20T23:20:52.2466186Z '0ac9cd4cddee2f717deb1ee07ccbf0b3722b4cb8'
2021-02-20T23:20:52.2695805Z ##[group]Run<EMAIL_ADDRESS>2021-02-20T23:20:52.2696594Z with:
2021-02-20T23:20:52.2697063Z   project: GithubActionTest
2021-02-20T23:20:52.2697633Z   team: \CxServer\SP\Checkmarx
2021-02-20T23:20:52.2698138Z   app: SampleApp
2021-02-20T23:20:52.2698618Z   preset: Checkmarx Default
2021-02-20T23:20:52.2699106Z   break_build: false
2021-02-20T23:20:52.2699547Z   incremental: true
2021-02-20T23:20:52.2699987Z ##[endgroup]
2021-02-20T23:20:52.2774716Z ##[command]/usr/bin/docker run --name e4a29cb82beb914dda9692a833b501e006_a0b60a --label 5588e4 --workdir /github/workspace --rm -e INPUT_PROJECT -e INPUT_TEAM -e INPUT_CHECKMARX_URL -e INPUT_CHECKMARX_USERNAME -e INPUT_CHECKMARX_PASSWORD -e INPUT_CHECKMARX_CLIENT_SECRET -e INPUT_APP -e INPUT_PRESET -e INPUT_BREAK_BUILD -e INPUT_INCREMENTAL -e INPUT_PARAMS -e INPUT_GITHUB_TOKEN -e TEAM -e PROJECT -e APP -e CHECKMARX_USERNAME -e CHECKMARX_PASSWORD -e CHECKMARX_CLIENT_SECRET -e CHECKMARX_BASE_URL -e CHECKMARX_SCAN_PRESET -e CHECKMARX_INCREMENTAL -e CX_FLOW_BREAK_BUILD -e CXFLOW_PARAMS -e GITHUB_TOKEN -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_ACTION_REPOSITORY -e GITHUB_ACTION_REF -e GITHUB_PATH -e GITHUB_ENV -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/temp/github_home":"/github/home" -v "/home/runner/work/temp/github_workflow":"/github/workflow" -v "/home/runner/work/temp/runner_file_commands":"/github/file_commands" -v "/home/runner/work/github-slideshow/github-slideshow":"/github/workspace" 5588e4:a29cb82beb914dda9692a833b501e006  "\CxServer\SP\Checkmarx" "GithubActionTest" "SampleApp" "" "" "" "" "Checkmarx Default" "true" "false" "" ""
2021-02-20T23:20:54.5261618Z    ___             ___ _
2021-02-20T23:20:54.5275594Z   / _  __      / \ | _____      __
2021-02-20T23:20:54.5276069Z  / /  \ / / / \ | |/ _ \ \ /\ / /
2021-02-20T23:20:54.5276445Z / / >  <_____/ /   | | () \ V  V /
2021-02-20T23:20:54.5276811Z _///_\    /    ||___/ _/_/
2021-02-20T23:20:54.5277071Z
2021-02-20T23:20:54.8502173Z 2021-02-20 23:20:54.846  INFO 7 --- [           main] com.checkmarx.flow.CxFlowApplication     : Starting CxFlowApplication on 324d55bdaa4e with PID 7 (/app/cx-flow.jar started by root in /github/workspace)
2021-02-20T23:20:54.8520816Z 2021-02-20 23:20:54.851  INFO 7 --- [           main] com.checkmarx.flow.CxFlowApplication     : No active profile set, falling back to default profiles: default
2021-02-20T23:20:57.7035550Z 2021-02-20 23:20:57.702  INFO 7 --- [           main] ptablePropertiesBeanFactoryPostProcessor : Post-processing PropertySource instances
2021-02-20T23:20:57.7974057Z 2021-02-20 23:20:57.794  INFO 7 --- [           main] c.u.j.EncryptablePropertySourceConverter : Converting PropertySource configurationProperties [org.springframework.boot.context.properties.source.ConfigurationPropertySourcesPropertySource] to AOP Proxy
2021-02-20T23:20:57.7983894Z 2021-02-20 23:20:57.796  INFO 7 --- [           main] c.u.j.EncryptablePropertySourceConverter : Converting PropertySource commandLineArgs [org.springframework.core.env.SimpleCommandLinePropertySource] to EncryptableEnumerablePropertySourceWrapper
2021-02-20T23:20:57.7990129Z 2021-02-20 23:20:57.797  INFO 7 --- [           main] c.u.j.EncryptablePropertySourceConverter : Converting PropertySource systemProperties [org.springframework.core.env.PropertiesPropertySource] to EncryptableMapPropertySourceWrapper
2021-02-20T23:20:57.7997325Z 2021-02-20 23:20:57.797  INFO 7 --- [           main] c.u.j.EncryptablePropertySourceConverter : Converting PropertySource systemEnvironment [org.springframework.boot.env.SystemEnvironmentPropertySourceEnvironmentPostProcessor$OriginAwareSystemEnvironmentPropertySource] to EncryptableSystemEnvironmentPropertySourceWrapper
2021-02-20T23:20:57.8004124Z 2021-02-20 23:20:57.797  INFO 7 --- [           main] c.u.j.EncryptablePropertySourceConverter : Converting PropertySource random [org.springframework.boot.env.RandomValuePropertySource] to EncryptablePropertySourceWrapper
2021-02-20T23:20:57.8009187Z 2021-02-20 23:20:57.798  INFO 7 --- [           main] c.u.j.EncryptablePropertySourceConverter : Converting PropertySource applicationConfig: [file:/app/application.yml] [org.springframework.boot.env.OriginTrackedMapPropertySource] to EncryptableMapPropertySourceWrapper
2021-02-20T23:20:57.8864056Z 2021-02-20 23:20:57.885  INFO 7 --- [           main] c.u.j.filter.DefaultLazyPropertyFilter   : Property Filter custom Bean not found with name 'encryptablePropertyFilter'. Initializing Default Property Filter
2021-02-20T23:20:57.8966588Z 2021-02-20 23:20:57.895  INFO 7 --- [           main] c.u.j.r.DefaultLazyPropertyResolver      : Property Resolver custom Bean not found with name 'encryptablePropertyResolver'. Initializing Default Property Resolver
2021-02-20T23:20:57.9010319Z 2021-02-20 23:20:57.900  INFO 7 --- [           main] c.u.j.d.DefaultLazyPropertyDetector      : Property Detector custom Bean not found with name 'encryptablePropertyDetector'. Initializing Default Property Detector
2021-02-20T23:20:58.0826044Z 2021-02-20 23:20:58.081  INFO 7 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'org.hibernate.validator.internal.constraintvalidators.bv.NotBlankValidator' of type [org.hibernate.validator.internal.constraintvalidators.bv.NotBlankValidator] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
2021-02-20T23:20:58.0878129Z 2021-02-20 23:20:58.086  INFO 7 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'org.hibernate.validator.internal.constraintvalidators.bv.NotNullValidator' of type [org.hibernate.validator.internal.constraintvalidators.bv.NotNullValidator] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
2021-02-20T23:20:58.0900455Z 2021-02-20 23:20:58.089  INFO 7 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'flowProperties' of type [com.checkmarx.flow.config.FlowProperties] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
2021-02-20T23:20:58.0925432Z 2021-02-20 23:20:58.091  INFO 7 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'flowAsyncConfig' of type [com.checkmarx.flow.config.FlowAsyncConfig$$EnhancerBySpringCGLIB$$daaebe85] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
2021-02-20T23:21:00.8534086Z 2021-02-20 23:21:00.847  INFO 7 --- [           main] o.s.ws.soap.saaj.SaajSoapMessageFactory  : Creating SAAJ 1.3 MessageFactory with SOAP 1.1 Protocol
2021-02-20T23:21:01.2162810Z 2021-02-20 23:21:01.215  INFO 7 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService
2021-02-20T23:21:01.2189263Z 2021-02-20 23:21:01.218  INFO 7 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService 'scanRequest'
2021-02-20T23:21:01.2295355Z 2021-02-20 23:21:01.228  INFO 7 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService
2021-02-20T23:21:01.2297480Z 2021-02-20 23:21:01.229  INFO 7 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService 'webHook'
2021-02-20T23:21:01.4748417Z 2021-02-20 23:21:01.473  INFO 7 --- [           main] com.checkmarx.flow.CxFlowRunner          : =======BUILD INFO=======
2021-02-20T23:21:01.4750316Z 2021-02-20 23:21:01.474  INFO 7 --- [           main] com.checkmarx.flow.CxFlowRunner          : Version: cx-flow-1.6.18
2021-02-20T23:21:01.4764317Z 2021-02-20 23:21:01.475  INFO 7 --- [           main] com.checkmarx.flow.CxFlowRunner          : Time: 2021-02-16T16:07:55.240Z
2021-02-20T23:21:01.4765806Z 2021-02-20 23:21:01.475  INFO 7 --- [           main] com.checkmarx.flow.CxFlowRunner          : =======================
2021-02-20T23:21:02.7387504Z 2021-02-20 23:21:02.737  INFO 7 --- [           main] com.checkmarx.flow.CxFlowApplication     : Started CxFlowApplication in 9.209 seconds (JVM running for 10.103)
2021-02-20T23:21:02.7489651Z 2021-02-20 23:21:02.748  INFO 7 --- [           main] com.checkmarx.flow.CxFlowRunner          : Using custom bean implementation  for bug tracking
2021-02-20T23:21:02.8025827Z 2021-02-20 23:21:02.801  INFO 7 --- [           main] c.c.flow.service.ScaFilterFactory        : Initializing SCA filters.
2021-02-20T23:21:02.8043845Z 2021-02-20 23:21:02.803  INFO 7 --- [           main] com.checkmarx.flow.CxFlowRunner          : Executing scan process
2021-02-20T23:21:02.8066853Z 2021-02-20 23:21:02.806  INFO 7 --- [           main] c.c.flow.service.ProjectNameGenerator    : Project name being used: GithubActionTest
2021-02-20T23:21:02.8085426Z 2021-02-20 23:21:02.807  INFO 7 --- [           main] com.checkmarx.flow.utils.ZipUtils        : Creating zip file /github/workspace/cx.82317c01-4fe3-43a8-8248-52d99ff5a7f1.zip from contents of path .
2021-02-20T23:21:02.8087264Z 2021-02-20 23:21:02.808  INFO 7 --- [           main] com.checkmarx.flow.utils.ZipUtils        : Applying exclusions:
2021-02-20T23:21:03.1140699Z 2021-02-20 23:21:03.113  INFO 7 --- [           main] com.checkmarx.flow.utils.ZipUtils        : Successfully created /github/workspace/cx.82317c01-4fe3-43a8-8248-52d99ff5a7f1.zip
2021-02-20T23:21:03.1166121Z 2021-02-20 23:21:03.115  INFO 7 --- [           main] c.c.f.sastscanning.ScanRequestConverter  : Overriding team with \CxServer\SP\Checkmarx
2021-02-20T23:21:03.1263433Z 2021-02-20 23:21:03.125  INFO 7 --- [           main] com.checkmarx.sdk.service.CxAuthService  : Logging into Checkmarx /cxrestapi/auth/identity/connect/token
2021-02-20T23:21:03.2388458Z 2021-02-20 23:21:03.237 ERROR 7 --- [           main] com.checkmarx.flow.CxFlowRunner          : An error occurred while processing request
2021-02-20T23:21:03.2389322Z
2021-02-20T23:21:03.2391456Z org.springframework.web.client.ResourceAccessException: I/O error on POST request for "/cxrestapi/auth/identity/connect/token": null; nested exception is org.apache.http.client.ClientProtocolException
2021-02-20T23:21:03.2394547Z 	at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:746)
2021-02-20T23:21:03.2396723Z 	at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:672)
2021-02-20T23:21:03.2399031Z 	at org.springframework.web.client.RestTemplate.postForObject(RestTemplate.java:416)
2021-02-20T23:21:03.2401374Z 	at com.checkmarx.sdk.service.CxAuthService.getAuthToken(CxAuthService.java:99)
2021-02-20T23:21:03.2403551Z 	at com.checkmarx.sdk.service.CxAuthService.getAuthToken(CxAuthService.java:62)
2021-02-20T23:21:03.2405863Z 	at com.checkmarx.sdk.service.CxAuthService.createAuthHeaders(CxAuthService.java:237)
2021-02-20T23:21:03.2407955Z 	at com.checkmarx.sdk.service.CxService.getTeamId(CxService.java:1295)
2021-02-20T23:21:03.2410919Z 	at com.checkmarx.flow.sastscanning.ScanRequestConverter.determineOwnerId(ScanRequestConverter.java:123)
2021-02-20T23:21:03.2414669Z 	at com.checkmarx.flow.sastscanning.ScanRequestConverter.determineTeamAndOwnerID(ScanRequestConverter.java:87)
2021-02-20T23:21:03.2418572Z 	at com.checkmarx.flow.service.AbstractVulnerabilityScanner.executeCxScan(AbstractVulnerabilityScanner.java:234)
2021-02-20T23:21:03.2422319Z 	at com.checkmarx.flow.service.AbstractVulnerabilityScanner.scanLocalPath(AbstractVulnerabilityScanner.java:278)
2021-02-20T23:21:03.2425948Z 	at com.checkmarx.flow.service.AbstractVulnerabilityScanner.scanCli(AbstractVulnerabilityScanner.java:189)
2021-02-20T23:21:03.2428608Z 	at com.checkmarx.flow.CxFlowRunner.lambda$scanLocalPath$1(CxFlowRunner.java:497)
2021-02-20T23:21:03.2430211Z 	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
2021-02-20T23:21:03.2431745Z 	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
2021-02-20T23:21:03.2433362Z 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
2021-02-20T23:21:03.2435070Z 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
2021-02-20T23:21:03.2437014Z 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
2021-02-20T23:21:03.2438941Z 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:546)
2021-02-20T23:21:03.2440996Z 	at java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
2021-02-20T23:21:03.2443171Z 	at java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:505)
2021-02-20T23:21:03.2445117Z 	at com.checkmarx.flow.CxFlowRunner.runOnActiveScanners(CxFlowRunner.java:555)
2021-02-20T23:21:03.2447061Z 	at com.checkmarx.flow.CxFlowRunner.scanLocalPath(CxFlowRunner.java:497)
2021-02-20T23:21:03.2448928Z 	at com.checkmarx.flow.CxFlowRunner.commandLineRunner(CxFlowRunner.java:400)
2021-02-20T23:21:03.2450695Z 	at com.checkmarx.flow.CxFlowRunner.run(CxFlowRunner.java:83)
2021-02-20T23:21:03.2452399Z 	at org.springframework.boot.SpringApplication.callRunner(SpringApplication.java:786)
2021-02-20T23:21:03.2454619Z 	at org.springframework.boot.SpringApplication.callRunners(SpringApplication.java:776)
2021-02-20T23:21:03.2456631Z 	at org.springframework.boot.SpringApplication.run(SpringApplication.java:322)
2021-02-20T23:21:03.2458344Z 	at com.checkmarx.flow.CxFlowApplication.main(CxFlowApplication.java:21)
2021-02-20T23:21:03.2459892Z 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2021-02-20T23:21:03.2461643Z 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
2021-02-20T23:21:03.2463744Z 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
2021-02-20T23:21:03.2465380Z 	at java.lang.reflect.Method.invoke(Method.java:498)
2021-02-20T23:21:03.2467773Z 	at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:49)
2021-02-20T23:21:03.2469643Z 	at org.springframework.boot.loader.Launcher.launch(Launcher.java:107)
2021-02-20T23:21:03.2471307Z 	at org.springframework.boot.loader.Launcher.launch(Launcher.java:58)
2021-02-20T23:21:03.2473004Z 	at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:88)
2021-02-20T23:21:03.2474658Z Caused by: org.apache.http.client.ClientProtocolException: null
2021-02-20T23:21:03.2476580Z 	at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:187)
2021-02-20T23:21:03.2478893Z 	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
2021-02-20T23:21:03.2481434Z 	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
2021-02-20T23:21:03.2515274Z 	at org.springframework.http.client.HttpComponentsClientHttpRequest.executeInternal(HttpComponentsClientHttpRequest.java:87)
2021-02-20T23:21:03.2520358Z 	at org.springframework.http.client.AbstractBufferingClientHttpRequest.executeInternal(AbstractBufferingClientHttpRequest.java:48)
2021-02-20T23:21:03.2524694Z 	at org.springframework.http.client.AbstractClientHttpRequest.execute(AbstractClientHttpRequest.java:53)
2021-02-20T23:21:03.2527517Z 	at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:737)
2021-02-20T23:21:03.2528884Z 	... 36 common frames omitted
2021-02-20T23:21:03.2530887Z Caused by: org.apache.http.ProtocolException: Target host is not specified
2021-02-20T23:21:03.2532972Z 	at org.apache.http.impl.conn.DefaultRoutePlanner.determineRoute(DefaultRoutePlanner.java:71)
2021-02-20T23:21:03.2535790Z 	at org.apache.http.impl.client.InternalHttpClient.determineRoute(InternalHttpClient.java:125)
2021-02-20T23:21:03.2538440Z 	at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
2021-02-20T23:21:03.2540130Z 	... 42 common frames omitted
2021-02-20T23:21:03.2540461Z
2021-02-20T23:21:03.2541830Z 2021-02-20 23:21:03.237  INFO 7 --- [           main] com.checkmarx.flow.CxFlowRunner          : Finished with exit code: 10
2021-02-20T23:21:03.2584505Z 2021-02-20 23:21:03.256  INFO 7 --- [extShutdownHook] o.s.s.concurrent.ThreadPoolTaskExecutor  : Shutting down ExecutorService 'webHook'
2021-02-20T23:21:03.2586759Z 2021-02-20 23:21:03.256  INFO 7 --- [extShutdownHook] o.s.s.concurrent.ThreadPoolTaskExecutor  : Shutting down ExecutorService 'scanRequest'
2021-02-20T23:21:03.5140693Z Post job cleanup.
2021-02-20T23:21:03.6198291Z [command]/usr/bin/git version
2021-02-20T23:21:03.6248045Z git version 2.30.0
2021-02-20T23:21:03.6283845Z [command]/usr/bin/git config --local --name-only --get-regexp core.sshCommand
2021-02-20T23:21:03.6323664Z [command]/usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'core.sshCommand' && git config --local --unset-all 'core.sshCommand' || :
2021-02-20T23:21:03.6577012Z [command]/usr/bin/git config --local --name-only --get-regexp http.https://github.com/.extraheader
2021-02-20T23:21:03.6607803Z http.https://github.com/.extraheader
2021-02-20T23:21:03.6620617Z [command]/usr/bin/git config --local --unset-all http.https://github.com/.extraheader
2021-02-20T23:21:03.6657481Z [command]/usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'http.https://github.com/.extraheader' && git config --local --unset-all 'http.https://github.com/.extraheader' || :
2021-02-20T23:21:03.6943675Z Cleaning up orphan processes


Release numbering policy and 1.0

We need a release numbering policy - an objective one. As far as that is possible. And we should go for a "1.0" now.
The Autobahn libraries are not "finished", right. The API isn't frozen. There are still gaps feature wise. But:

the WAMP protocol on the wire and its lower levels of implementation have been stable for long now
the original primary goals for these libraries have been largely met already
we have a pretty solid track record regarding stability/security
other software depends on Autobahn
these libraries are actually used in production

Semver is a popular choice for libraries in particular. So this is one obvious option for Autobahn. Each AutobahnXXX would run on its own semver counter.
Semver tries to communicate breaking changes in releases by major version bumps. Ideally, from comparing 2 semvers, a user could infere the likelihood something breaks. This is a useful information for a library user.
However, if each AutobahnXXX runs on its own counter (and that is the only way I can see semver work here), then the counters for major version might diverge - drastically, depending on semver strictness and progress in the different XXXs.
The semvers don't have meaning across the different AutobahnXXXs (and Crossbar.io): do these versions work together? Are they "from the same time period" (and hence likely tested together)?
Interestingly, this is less about API breakage (as semver is), but about functional and integration breakage.
If we wanted to communicate that, a calver scheme, run across both Autobahns and Crossbar.io could allow us to communicate that: "yeah, all versions 16.04 of Autobahn and Crossbar.io have been tested together." Of course, likely Autobahn 16.10 will operate with Crossbar.io 16.04, and NN.MM should generally work with XX.ZZ, but there is a limit to what we can test/guarantee for such combinations. And then there are missing features that need coordinated implementation: eg call canceling. To be able to cancel a call from AB JS, running through CB to a calle in AB Py requires touching code in all 3! And how do we communicate that a user needs certain versions of all 3?
Just saying: "if you take 16.04 of all, you are fine" seems way easier than "wait, let me see, that would be AB Py 3.4.2 with AB JS 1.2.10 and CB 2.0.12!" wtf?

The calendar-versioning also seems to match more closely how releases currently happen: at least AB Py and CB usually get released together, and it's usually just "whatever is on master currently".
I guess the only thing calver makes "hard" is if you want to have an "old" version and backport changes to it (e.g. a "1.X.Y" line, and a "2.Z.Q" line) but AB/CB doesn't do that either (and I guess nothing stops you from making a "14.x" release in 2017 if there's a bugfix worth back-porting for some reason, e.g. 17.x changed the API).
Personally, I kind of like the variant of calver that uses the year for the first number, but just increases the second number. E.g. 16.1.0 is the first release of 2016, no matter if it's in January or not, 16.2.0 is the second release in 2016 etc. Not sure if one needs all three versions or not, but I guess that lets you do a "16.1.1" if there's a minor mistake in the 16.1.0 release :/

we have moved to calendar versioning some time ago


The edges of the image drawn by Paint are not smooth.

The edges of the image drawn by Paint are not smooth, like this:

How to fix it?

if I need to support antialiased painting, is there any good way?

Off the top of my head, you would have to make your own version of the vtkPaintFilter (along with the PaintFilter.worker.js) that, given a coordinate, draws your desired shape (e.g. ball) with antialiasing. In addition, you will need to decide how to encode semi-transparent pixels in the underlying vtkImageData, and deal with blending if you have multiple colors.
We currently do not have a need for antialiased paint in vtk.js, but if you want to take a shot at implementing and contribute then I'll be glad to help look over what you have. :)

Yes, I am trying to encode semi-transparent pixels in the underlying vtkImageData, do you have the relevant documentation?

You can encode them however you want. vtkImageData only stores pixel data. Rendering-wise, you will have to look at vtkImageMapper's scalarOpacity field, which will allow you to define a vtkPiecewiseFunction that maps pixel values to opacity for rendering.


Creating a time-series model doesn't render the widget

It only renders if it exist in a vizJSON when the dashboard is created.

Issue moved to CartoDB/deep-insights.js #240 via ZenHub.io

Moved to https://github.com/CartoDB/deep-insights.js/issues/240


Mesh prefixes variable names

Issue workflow progress

Progress of the issue based on the
Contributor Workflow

[ ] 1. The issue provides a reproduction available on
Github,
Stackblitz
or
CodeSandbox

Make sure to fork this template and run yarn generate in the terminal.
Please make sure Mesh package versions under package.json matches yours.

[ ] 2. A failing test has been provided
[ ] 3. A local solution has been provided
[ ] 4. A pull request is pending review

Describe the bug

graphql-mesh prefixes some of variables with _v1_ which makes it confusing, the client ends-up in non-sense error: "the variables which doesn't exists have wrong value.
To Reproduce Steps to reproduce the behavior:
Tried to reproduce it on sandbox, but couldn't
Expected behavior
Variables to stay as they are.
Environment:

OS: linuux
"<EMAIL_ADDRESS>version "0.33.8"
NodeJS: v19.4.0

Additional context
I was trying to find where this prefix comes from without any success.
Leaving single source fixes the issue.

I don't think we are going to change this prefixing because Mesh doesn't forward queries from the gateway to the services. It generates a new query based on the gateway's request. It uses prefixes due to some internal reasons.
But if you think this causes an issue, please share a reproduction on CodeSandbox or StackBlitz.

Funny thing is that it doesn't always happens. Will play tomorrow again with sandbox to try to reproduce it.
Locally when there are 2 sources - it happens, but in sandbox it doesn't happens. Can you point me to the code which internally generates the new docs so I can put breakpoints there? Thanks.

I was able to reproduce it here:  https://github.com/Warxcell/graphql-mesh-renaming-vars
with following query
query t($where: AssetFilter!) {
  assetCollection(where: $where) {
    total
    items {
      title
    }
  }
}

vars:
{
  "where": {
    "sys": {
      "publishedAt": "dsada"
    }
  }
}

result:


add a tweet @ moc 'when's your next town hall' button if no events

@meganrm @nathanmwilliams
Do we want to add this as a button to each MoC card when there are no events?  Or as a button to mention all their MoC's in one tweet and stick it in the #no-events section?
From a quick look at https://dev.twitter.com/web/tweet-button/mention-button I'm not seeing a way to mention multiple people.
However it'd be pretty easy to just use a share button and stick all the MoCs in the tweet that way.  Only caveat is that it'll include a link to THP with that in the body text which is great for exposure but want to make sure that's kosher first.

Do them individually.


Coloured Syntax for D files

If the intent of dido is to remain D-specific, I'd just recommend using the lexer available via the already included libdparse library. Seems simple enough to use and implement.

That was the plan, and then I started working a lot on other things. But I expect it to be done somewhere in year 2015 (along with proper navigation pane).


tour: Unclear description of naked returns

Context: https://tour.golang.org/basics/7
For me as newcomer the language the the sentence:
A return statement without arguments returns the current values of the results. This is known as a "naked" return.

does not really explain what a naked return is. Does it return all calculated values of a function? or just the last two used values? or the ones that have the same names as in the return values? What happens if I have another variable in the function is it also returned?
Not sure if anyone agrees, while thinking about it and trying code in the browser I quickly found what works and what doesn't.
I first tried:
func split(sum int) (x, y int) {
	x = sum * 4 / 9
	y = sum - x
	z = x * x
	return
}

Doesn't compile, because z is not defined, got me "aha , so x, and y are defined in the return statement. (variable declarations are only in the next chapter of the tour, so I peeked ahead and I tried)
func split(sum int) (x, y int) {
	x = sum * 4 / 9
	y = sum - x
	var z = x * x
	return
}

which errors because z is unused. Thats where I figured that return does not just take the last two calculated values but the actual names. Which now makes sense but in the beginning was confusing somehow.
The change could be something like:
The named values defined in the return statement can be used as variables in the function body. In this case they don't need to be specified after the return statement. This is known as a "naked" return.

Cheers,
Henning

CC @adg @campoy

How about

A return statement without arguments returns the current values of the return values. This is known as a "naked" return.

??
The full text is:

Go's return values may be named and act just like variables.
These names should be used to document the meaning of the return values.
A return statement without arguments returns the current values of the return values. This is known as a "naked" return.
Naked return statements should be used only in short functions, as with the example shown here. They can harm readability in longer functions

I've sent a change with more rewording. Please take a look.

@adg Thanks a lot, the change looks good to me.


Support dictionary-style assignment and retrieval in IPFSDict

Currently, the IPFSDict class only supports attribute-style assignment and retrieval for storing and accessing key-value pairs. However, it does not support the standard dictionary-style assignment and retrieval using square brackets.
For example, the following code only saves value1 to the dictionary:
my_dict = IPFSDict()

# Add data to the dictionary
my_dict.key1 = 'value1'
my_dict['key2'] = 'value2'

# Save the dictionary to IPFS
cid = my_dict.save()
print(my_dict)

To support both attribute-style and dictionary-style assignment and retrieval, we should override the __setitem__ and __getitem__ methods in the IPFSDict class:
def __setitem__(self, key, value):
    self.__setattr__(key, value)

def __getitem__(self, key):
    return self.__getattribute__(key)

By implementing these changes, both ways of adding values to the IPFSDict will work as expected.

Version 1.0.6 has been released to fix this.


The built jars contains wrong file

What are you trying to show me here?

What are you trying to show me here?

License and credits

fixed in latest versions


Fix single quote and nil issues with cluster recipe

This builds on #267 to add:

More fixes to catch single quotes from cluster_status, current_cluster_node_type and node_name

Fixes from #267 the node_name still had single quotes which were removed on L113
The cluster_status, disc_nodes and ram_nodes functions passed back a match of ["rabbit@rabbit1'","'rabbit@rabbit2"] which contained single quotes from the middle of the match. This was removed L83, L91 and L100

In rare instances, if the cluster_status returns on a non running server or is not clustered yet, the matchers caused no matched and nil errors. Fixes were introduced to pass nil in some functions through and to better handle them specifically with cluster_join:

Passthrough of nil in some functions
Additional debug logging and handling of nil responses from functions

To note, this is also duplicates in some ways of #263 and #273 but with additional changes and differences in the way nil was handled.

This looks great! Fixed multiple nil issues in this recipe!


Add a unit test for linting

We'll be using lintr. Instructions: https://github.com/jimhester/lintr#testthat

@thomascrines used lintr::lint_package as an after_success step in our build process here: https://github.com/jsphdms/scotgov/pull/50. This is the recommended approach (instead of creating a unit test) so I'm closing this issue.


Harvesting - Wallet not showing income from 25% harvester service fee

Reproduce:

set up a node leaving automatic harvesting on
set the beneficiary account to be the same address as the node account
credit the node account (which is already converted to multisig) with some xym and allow it to harvest
go to the wallet and select the cosigner account
open the harvesting page of the wallet and select the multisig account above

In the list of blocks harvested, it will show the income from the 75%, but the 25% beneficiary income does not show in the wallet while it does show in the explorer.

Fixed in integration branch.
Before:

After fix:


Feat:add a new page of biographies

Describe the feature
in litrary releams we covered there is a section of biographies so i add a new page cov ering biographies .
Add ScreenShots
https://github.com/anuragverma108/SwapReads/assets/159682348/acc943a5-e3ef-47cc-b17b-7947577e0c7f
Record

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

@huamanraj @anuragverma108 please review my issue and assigm me under gssoc label and i have also created pull request for the same


Feat/sign up

About the changes

Public signup + unleash

Unleash

Feature flags, which allows us to remotely switch features on and off based on conditions.
It's being used here simply to turn on the sign up button when we are ready.

Signup feature

it's just a signup form like any other
you can sign up via email or via one of the buttons (apple/google).

Signup technical stuff

Opens with a cupertinomodalroute-thing, which is basically that it pops out a bit so that you can still see the thing behind, like this:

Uses flutter_hooks, which decreases the boilerplate when you have texteditingcontrollers, etc.
LoginScreen was just renamed to OnboardingScreen (but github makes it look like a new file)

Important files

/lib/screens/signup.dart
/lib/components/onboarding
/test/auth/signup_test.dart
Discussion points

What do you think about flutter_hooks?
Unleash provider, is it ok? It's a bit hard to read. Do you understand what it does?

About the changes
Public signup + unleash

Unleash

Feature flags, which allows us to remotely switch features on and off based on conditions.
It's being used here simply to turn on the sign up button when we are ready.

Signup feature

it's just a signup form like any other
you can sign up via email or via one of the buttons (apple/google).

Signup technical stuff

Opens with a cupertinomodalroute-thing, which is basically that it pops out a bit so that you can still see the thing behind, like this:

Uses flutter_hooks, which decreases the boilerplate when you have texteditingcontrollers, etc.
LoginScreen was just renamed to OnboardingScreen (but github makes it look like a new file)

Important files
/lib/screens/signup.dart /lib/components/onboarding /test/auth/signup_test.dart
Discussion points

What do you think about flutter_hooks?
Unleash provider, is it ok? It's a bit hard to read. Do you understand what it does?

Flutter hooks look cool. Because most of the boilerplate code like initState, didWidgetUpdate, onDispose, etc is taken care of, The widgets look short and more readable.
The unleash provider was easy to understand.

Flutter hooks look cool. Because most of the boilerplate code like initState, didWidgetUpdate, onDispose, etc is taken care of, The widgets look short and more readable.
The unleash provider was easy to understand.

Awesome, thanks!


allows HEROKU_HOST without https://api. prefix

allows HEROKU_HOST without https://api. prefix

Cool! I feel like I'm missing something though... does this allow setting of the api url via the HEROKU_API_URL environment variable somehow?

no I changed the implementation without updating the title, sorry about that

Do you have an example of how I would I set HEROKU_HOST vs HEROKU_API_URL?

HEROKU_API_URL isn't a thing. With HEROKU_HOST if you specify a protocol it will use that exactly, so https://midgard.heroku.com or if you specify just a hostname, it will prepend it with api.: dickeyxxx.herokai.com would be api.dickeyxxx.herokai.com.
This isn't ideal. I'd rather just have a HEROKU_API_URL that's explicit, but it's needed to work with devclouds, direwolf and whatever else might be using this stuff.

Huh, I guess I thought it was a thing, since I've seen it in caas, ion-client, telex, identity and other components. I guess those don't really apply in CLI land though.

I think it should be, but I don't want to have multiple ways of doing the same thing if I can help it


when i use app-cmd open an file such "1 2.txt" with space,it divided into two parts "1" and "2.txt" how can i open "1 2.txt" as a whole

when i use : xfreerdp /v /u /p /port:7070 /app:"||my_rtf" /app-cmd:"C:\1 2.txt"
my app error with cant found C:\1 this file how can i open "1 2.txt" as a whole

check your app or shell.


Invite WiMi to research group

As a chair admin/representative, I want to invite users to be WiMis.

It should be possible to invite people to be WiMis of a chair at the chair's detail page (e.g. http://portal.eaalab.hpi.uni-potsdam.de/chairs/1), similarly to how HiWis can be invited to projects.

Users do not need to be "invited". A head of department / assistant can add users to chairs, making them wimis. There is no need for confirmation on the wimi user side.

A notification on the wimi side would be nice.
The activity log should be updated the the info that there is a new wimi.

Adding WiMis to a chair was implemented in #397.
Notifications are handled by #405.


Move email delivery to custom jobs

The default email delivery job that comes with Rails 4.2 doesn't do any error handling so create custom email jobs that prevents retries where someone has incorrectly typed their email address and gracefully handles temporary failures so that we don't get Appsignal notifications.

LGTM


Route Trace

Is there any way to trace the routes correctly through the streets?

What device are you using? I suspect there is some problem with time or GPS coordinates.

I'm testing with an android device (using traccar client).

Which version of Traccar Client are you using?

The last version, from play store, anyway, the route should fit the pattern of the streets, I'm wrong?

Traccar just connects reported GPS points with lines, but yes, it should follow the streets as long as the data is correct. Can you please provide tracker-server.log file for me to investigate.

this route was tested in your demo site: demo.traccar.org

The latest version was release after you recorded your track. I guess you were using the latest one at that point which had an option for "mixed" location provider. Did you use that provider?

@tananaev I really like your project and there could be a nice possibility to join forces for features like the requested here "snap to road". We've developed this algorithm called 'map matching' based on GraphHopper here, also Java, also Apache License so it could be a nice fit :)
See this animation

And one could also attach properties back to the coordinates like maximum speed, road name, turn instructions, road type, ...
Still investigating the issues here, what kind of use case would be the most interesting for traccar users. Do you have a forum or mailing list?

@karussell, this particular issue here has nothing to do with snapping to road. If you want to discuss this topic, I would recommend to create a new issue or find a relevant one.
There is a forum here if you want to discuss it there:
https://www.traccar.org/forums/


Refactor Bellman Ford algorithm

Need to refactor Bellman-Ford Algorithm and add test cases
https://codeclimate.com/github/ArseniyAntonov/python-algorithms/algorithms/graphs/Belman_Ford_shortest_paths_algorithm_with_negative_arbitrage.py/source#issue-b6e23c2c4cc329e1c2505191c1fc56a5

Duplicated file removed


Fix requiredSelection behavior in BaseComboField, Fixes #353, Fixes #354

Does this also end up fixing #354 ?  It appears to - is it clear why?
Apologies, this is a pretty complicated bit of code all around (the general field system + dropdown support) and I don't have a good grasp of it - hard to really get it in my head while multitasking. But I would love to take this if you are confident about the changes and how it relates to both tickets.

I didn't cross reference. Will test and try to work out if/why it does.

Closing in favor of Tom's change


Support kebab-case names in parse sepc

This pull request improves the user experience when package names contain hyphens. Users can use either the original form (my-app) or the canonical form (my_app).
See more about name using hyphens in this RFC.

Hey, thanks for the PR! Sorry for the delay, but I personally just don't feel like I should be deciding whether to include this kind of functionality, only being involved in this project for a rather short time.
That said, personally I like this change. The only improvement I can suggest is mentioning this in README.md too.
@SirWindfield @KodrAus wdyt?

I do like the change! Is it possible that two crates exist with the same name but one uses hyphens, the other dashes? I can only imagine that this can't be the case, as their import names would be the same. This would be the only concern I'd have though.

@Gnnng I thought it was obvious so didn't leave another review comment, but the typo was replicated in the assertion a few lines below, you need to update that one too :)

My bad, just fixed it and rebased it. Thanks for reviewing it. Any suggestions on what to put in the README.md? It's better if it comes from the maintainers so feel free to amend the PR.

Any suggestions on what to put in the README.md?

I was thinking something similar to what you wrote for lib.rs.

This looks good to me! There shouldn't be any conflicts for names. Cargo accepts either - or _ but considers those characters equal for  determining the name.

This looks good to me! There shouldn't be any conflicts for names. Cargo accepts either - or _ but considers those characters equal for  determining the name.

This looks good to me! There shouldn't be any conflicts for names. Cargo accepts either - or _ but considers those characters equal for  determining the name.

This looks good to me! There shouldn't be any conflicts for names. Cargo accepts either - or _ but considers those characters equal for  determining the name.

@Gnnng Can you rebase again and add this to the readme? If not I might do it, but no promises.

@Gnnng Can you rebase again and add this to the readme? If not I might do it, but no promises.

Sure, let me do that.

Sure, let me do that.

I can take a closer look an Tuesday, up until then I don't have enough time for a full review :)

So with the crate name also being overridable replacing - by _ is not always the right conversion from package name to crate name (example: rust-s3 where the package is named rust-s3 but the library crate is named s3, not rust_s3).
I guess this still doesn't break anything though, it could just be expected by people that it does more than it actually does 🤷🏼

We could add a notice to the README with this example to bring attention to these cases :thinking:


E2E PageObject pattern

Refactor e2e tests using PageObject pattern.
Sources (explanations):

https://stackoverflow.com/questions/48216151/page-object-mode-with-node-es7-puppeteer (see answer);
https://github.com/just-boris/page-object (functional approach);
https://github.com/puppeteer/puppeteer/issues/1782#issuecomment-357089464

Closed at #35 #34 #33 #32


Dependency ranges too small

In acf871d9444c5, the dependencies were pinned. Partly with my Gentoo Linux packager hat on, I thoroughly dislike this change because the dependency ranges are so small; and pinning the dependency with == seems very unlikely to be justified. If I want to install this package, it needs to cooperate with the rest of what's installed, and saying "you have to use the exact version I tested with" is essentially unhelpful. If there actual Reasons to require a very recent version (because otherwise there are bugs, or whatever), that's fine, of course, but in those cases >= deps should be used.

@djc there probably are a few versions that need not be pinned as specifically. The versions should however be pinned where breaking changes are possible. Assuming packages follow semantic versioning that means all versions should be pinned to the current minor version to avoid breaking changes. However, when a package has yet to reach a 1.0 version, then any version can introduce a breaking change. In such cases, a specific pinned version is the only way to ensure a breaking change isn't introduced in a dependency.
If you would like to make a pull request that adjusts the dependencies to be less restrictive and protective against possible breaking changes we would be happy to merge those in.

Well, I think assuming strict semantic versioning is probably too restrictive, particular for those pre-1.0 packages. So I'm not sure what would satisfy you? To me, the previous version of ['decorator>=3.4.2', 'requests>=2.3.0', 'six>=1.4', 'update_checker>=0.11'] looked alright, but I assume you have better knowledge of potentially breaking changes or bugs in versions included in those ranges.

FWIW, I've patched setup.py according to the pre-normalized dependencies, and this has seemed to resolve the OAuth issues I was having. I have not yet run the full test suite, though.

What are the version discrepancies? Have you considered using a virtual environment?

Not sure what you mean about version discrepancies.
I almost never use virtual environments; Gentoo gives me a perfectly powerful package manager that is generally capable of doing what I want.

Not sure what you mean about version discrepancies.

Which dependencies along with their version numbers were conflicting with what PRAW wanted until you made a change.

I almost never use virtual environments; Gentoo gives me a perfectly powerful package manager that is generally capable of doing what I want.

I used to think the same thing until I started working with many different projects each of which had their own unique version requirements. It sounds like you're now running into that problem for the first time.

Which dependencies along with their version numbers were conflicting with what PRAW wanted until you made a change.
I was previously using praw-2.1.10, so that's a pretty old version. Gentoo's Python packages, which are generally kept up to date pretty well, give me requests-2.8.1, decorator-4.0.2 and six-1.10.0 (update_checker is only in there for praw, anyway).

I used to think the same thing until I started working with many different projects each of which had their own unique version requirements. It sounds like you're now running into that problem for the first time.
I use virtualenv sometimes if I want to install apps that need a bunch of dependencies. However, for libraries (especially something like praw that should be fairly simple), I expect the maintainers to keep track of what their code actually needs from their dependencies. I'm fine if praw actually needs a very recent requests/decorator/six.

What I object to is the very narrow ranges (in the case of decorator and six) that I suspect are much narrower than what praw actually needs. As a library maintainer, I feel you should own your dependencies and maintain them in a way that they cause minimal upheaval to your downstream users. Requiring a very narrow version range runs counter to that idea.

You make a fair point. Would you like to try limiting the six and decorator dependencies to their major version and see if the tests pass? That would certainly be less restrictive and, assuming those packages follow semantic versioning, avoid backwards-incompatible changes in the dependencies.

I don't think I can easily try that. Sounds like a great idea, though! Really, I think the best way forward would be to revert the six dependency back to 1.4, since at least that one was done explicitly. For decorator, using >= 3.0.0 (or 4.0.0) might make sense, you're probably just using the basics of the package and not actually depending on any trick business. For update checker, it looks there were real reasons at least for the 0.10 dependency.
(This is also a pet peeve I have with praw commits: the "Normalize setup.py" is a rather broad change, and it doesn't really state why the dependencies where changed. I consider it best practice to have the commit message state why the dependency version was updated, so that you can go back later -- like I did just now -- and figure out why those changes were made.)
Anyway, thanks for being responsive to my concerns!

Hi there, I would like to see about changing the dependency restrictions to at least allow update_checker 0.12. How can I go about running the tests to ensure that everything still works with this version?
Thanks

@agwblack done in 377860398e322d40b1daf325931fbe520fee0c61.

@bboe Cheers!

Closing due to inactivity. Feel free to open a PR with older dependencies listed.


Added API for Add/Update Organization Membership. Refs[#238]

Creating new PR. There are some issues in this PR.


Issue with running writing-transforms solution

I have run the provided solution directly out of the box and the output of browserify -t ./tr.js main.js is blank.  When I remove split() from the list of transforms then the result at least has a value, but is just one row prepended with a  0.  When I put in console.logging inside of the liner function I see that split seems to have work and it outputs on the interface correctly. But when running it all together I get nothing.  Am I missing anything obvious? Or maybe this is a version issue.
main.js
var txt = require('./wake.txt');
console.log(txt);

tr.js
var through = require('through2');
var split = require('split');
var sprintf = require('sprintf');
var quote = require('quote-stream');
var combine = require('stream-combiner2');

module.exports = function (file) {
  if (!/\.txt$/.test(file)) return through();
  var num = 0;
  var liner = through(function write (buf, enc, next) {
    var line = buf.toString('utf8') + '\n';
    if (num % 5 === 0) {
      // Add a line number and push to stream
      this.push(sprintf('%3d %s', num, line));
    } else {
      // Add p and push to stream
      this.push('    ' + line);
    }
    num++;

    // Process next batch
    next();
  });

  // Add 'module.exports=' so this will be considered an exportable module
  var prefix = through();
  prefix.push('module.exports=');

  // Return a through function
  // in this case it is a combination of multiple transformers
  return combine([
    split(),
    liner,
    quote(),
    prefix
  ]);
};

package.json
{
  "name": "browserify-adventure",
  "version": "1.0.0",
  "description": "",
  "main": "beep-boop.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "domify": "^1.4.0",
    "querystring": "^0.2.0",
    "quote-stream": "^1.0.2",
    "split": "^1.0.0",
    "sprintf": "^0.1.5",
    "stream-combiner2": "^1.1.1",
    "through2": "^2.0.1",
    "uniq": "^1.0.1"
  }
}

I took a look: this doesn't seem to be anything incorrect you've done. I think there's an issue with split and how it's getting upgraded to streams3.  Thanks for reporting!

Thanks, I used split2 and that resolved the issue.


nearby to return distance to objects

Would it be possible for nearby queries to return distance inside objects as well?
so instead of
{"type":"Point","coordinates":[1,2]}
may be we can get something like
{"type":"Point","coordinates":[1,2], "distance": 3000}
that will make ordering of results easier.
My real issue is to get the nearest object, but then for a relative big search area I get many result, and I think they are not ordered by distance.

Hi @auselen,
Would this be for the NEARBY command specifically? I think that returning the distance of each object along with the results should be trivial for points.
Perhaps adding a DISTANCES keyword, such as:
NEARBY fleet DISTANCES POINT 33 -115

For complex objects this will be a bit more challenging because of object edge detection and such. #95 touches on this problem a bit (a feature that I would like work on in the near future).  Though it'd possible to return the center of the object's bounding box as point to use for the distance calculation.
Right now Tile38 tries to follow the GeoJSON spec as much as possible. I wondering if it's best to have the distance member as a separate value outside the geojson block, similar to the way the object id is seperate. So it would be id,object,distance for each item that is returned.
As for ordering from closest to farthest, I've been working on a new r-tree implementation that should support k nearest neighbors and make this possible. I don't have an eta, but I'll keep you posted when it's ready.

DISTANCES keyword and [id, object, distance] would work just fine as well. Should I expect this to be released soon?
I don't think about complex objects about now just because I understand that's hard business.
What I'm doing is to find nearest city given a point, I get locations from geonames, and I'm just thinking of working around picking the right one by weighting distance, population, etc. just some approximation instead of doing bounding boxes etc.

I'll add the DISTANCES keyword to roadmap. I'm a bit backlogged right now, but hopefully I can get to it soon.

Sharing a one liner to fill tile38 with geonames data. I realized keys can't have spaces (not possible to surround them with quotes, so can't use city name as key) also not possible to set some string info for the point (like city name in this case). Other than those, it's great!
curl -s http://download.geonames.org/export/dump/cities1000.zip | zcat | awk -F $'\t' '{print "set city",$1,"POINT",$5,$6} END {print "quit"}' | ./tile38-cli

<IP_ADDRESS>:9851> SERVER
{"ok":true,"stats":{"aof_size":29887319,"avg_item_size":332,"heap_released":0,"heap_size":48752640,"id":"e4ddbd6ac9841d874e4511b1519b5303","in_memory_size":3357186,"max_heap_size":0,"mem_alloc":48752640,"num_collections":1,"num_hooks":0,"num_objects":146831,"num_points":146831,"num_strings":0,"pid":25680,"pointer_size":8,"read_only":false},"elapsed":"353.304µs"}

@auselen using city as a key name is kinda bad idea. In Russia in e.g. there is a lot of cities with a non-unique names. You will just mess all data. Also in US, they have a cities with similar names.

No question there but it's more of a one line demo thing. Also imagine concatenating all the administrative names to city name to get it more distinctive. I don't know if it's a redis thing to not to have spaces in keys.

@auselen Redis does support spaces in keys. I think you may have found a limitation of the tile38-cli command.
When I use the redis-cli and use the following command it seems to work.
curl -s http://download.geonames.org/export/dump/cities1000.zip | \
    zcat | \
    awk -F $'\t' '{print "set city \""$2"\" POINT",$5,$6} END {print "quit"}' | \
    redis-cli -p 9851

@tidwall this feature already in doc's maybe you can close this issue?


[1.x] Handles Telescope ingest

This PR resolves #148
Telescope works by stroing events after a response has been sent or a job processed. With Reverb, neither of these things happen so Telescope entries accumulate causing in memory consumption.
This PR attempts to address that by periodically storing and flushing the buffer of entries in a similar approach to Pulse.

If you have telescope installed but, following the documentation, in a production environment not loading the TelescopeServiceProvider, then reverb => StartServer fails on line:
\Laravel\Telescope\Telescope::store($this->laravel->make(\Laravel\Telescope\Contracts\EntriesRepository::class));
because then EntriesRepository is not bound. Am I missing something here?

@maartengithub this is a great catch, thank you. Updated here: https://github.com/laravel/reverb/pull/164

Thanx. I saw that it was pulled into main branch already. Now I can push my codebase to production:) Have a nice weekend.MaartenVerstuurd vanaf mijn iPadOp 19 apr. 2024 om 16:14 heeft Joe Dixon @.***> het volgende geschreven:
@maartengithub this is a great catch, thank you. Updated here: #164
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>


HHH-11735 Support traversal of to-many-associations in audit queries

Link to jira issue

Superseded by PR #4477


Font style formatting never applied to first new paragraph

v:  2.1.0
OS: Windows 11
Steps to reproduce:

Create a new transcript.
Change the font and press 'Modify' to apply the style.
Mash some steno keys and observe that the font is not what was selected.
Press Modify again to apply the style, changing the paragraph font.
Asterisk backspace all of the paragraph.
Mash some more steno keys and observe that the font has reverted to the pre-Modify default font.

The upshot of this is that on a new transcript file, or after starting the first paragraph over, the current style is never applied. The desired behavior is for those font settings to be applied to the first new text in the document unless set otherwise. This can be fixed in post-editing, but since I use font size to make seeing the transcript and paper tape easier, it causes some usability issues. I'm not entirely sure how the formatting system works still, so I've been dragging my feet on actually attempting to make a working patch.

The styling system needs to be redone, it's on my todo list.
The system as it is now, someone changes parameters in a style, it's not possible to undo them and we can only undo what style is applied to a paragraph only if it had an existing style. It's a bit of a mess.
If the paragraph style doesn't match the set style, the quick fix is do Styling -- Refresh Editor.
I'm going to leave this open to remind myself.


[Question]: 401 when running ./src/dev.sh layout or build, no local versions of microsoft.aspnetcore.app.ref

Describe your question
I followed the instructions here. Upon running /src/dev.sh layout, it mostly succeeded, but failed during the restore step with the below error. Subsequent runs of build produce the same error.
-----------------------------------------
  Building
-----------------------------------------
MSBuild target = Build
MSBuild version 17.9.8+610b4d3b5 for .NET
  4c7bc633572b50c0ee2e0b218805563cdc7979ea
  Building 4c7bc633572b50c0ee2e0b218805563cdc7979ea --- win-x64
  Determining projects to restore...
  Failed to download package 'Microsoft.WindowsDesktop.App.Ref.6.0.30' from 'https://pkgs.dev.azure.com/mseng/c86767d8-af79-4303-a7e6-21da0ba435e2/_
  packaging/61a4ae2c-15fb-4085-b7f6-0044b9eb7b85/nuget/v3/flat2/microsoft.windowsdesktop.app.ref/6.0.30/microsoft.windowsdesktop.app.ref.6.0.30.nupk
  g'.
  Response status code does not indicate success: 401 (Unauthorized - No local versions of package 'microsoft.windowsdesktop.app.ref'; please provid
  e authentication to access versions from upstream that have not yet been saved to your feed. (DevOps Activity ID: 43C4F9C7-2492-46EB-99DA-1BF1477F
  A698)).

<omit many more lines of the above due to retries>

Failed: build
~/source/repos/azure-pipelines-agent

According to #4327 it appears that a package needs to be saved to this feed. I am external to Microsoft, so I don't think I can provide any valid authentication. If there's anything I can do to resolve, just let me know.
Versions
latest code from master
Windows 11
git version 2.39.0.windows.2
Environment type (Please select at least one enviroment where you face this issue)

[X] Self-Hosted
[ ] Microsoft Hosted
[ ] VMSS Pool
[ ] Container

Azure DevOps Server type
dev.azure.com (formerly visualstudio.com)
Operation system
Windows 11
Version controll system
Git
Azure DevOps Server Version (if applicable)
No response

Hi @lettucemode I'm unable to reproduce your issue. Could you try to run git clean -xfd in the repo root?
What does the dotnet restore command return?

@KonstantinTyukalov as it turns out, as of 10 minutes ago, the build & layout commands are working as expected. I then ran git clean -xfd and then dotnet restore in the root per your suggestion, and there are no errors.
$ dotnet restore
  Determining projects to restore...
  Restored C:\Users\2know\source\repos\azure-pipelines-agent\src\Agent.Plugins\Agent.Plugins.csproj (in 637 ms).
  Restored C:\Users\2know\source\repos\azure-pipelines-agent\src\Agent.Sdk\Agent.Sdk.csproj (in 643 ms).
  Restored C:\Users\2know\source\repos\azure-pipelines-agent\src\Microsoft.VisualStudio.Services.Agent\Microsoft.VisualStudio.Services.Agent.csproj (in 642 ms).
  Restored C:\Users\2know\source\repos\azure-pipelines-agent\src\Test\Test.csproj (in 641 ms).
  Restored C:\Users\2know\source\repos\azure-pipelines-agent\src\Agent.PluginHost\Agent.PluginHost.csproj (in 663 ms).
  Restored C:\Users\2know\source\repos\azure-pipelines-agent\src\Agent.Listener\Agent.Listener.csproj (in 671 ms).
  Restored C:\Users\2know\source\repos\azure-pipelines-agent\src\Agent.Worker\Agent.Worker.csproj (in 674 ms).

Thanks for your time spent looking into this! I'll go ahead and close.

@KonstantinTyukalov as it turns out, as of 10 minutes ago, the build & layout commands are working as expected. I then ran git clean -xfd and then dotnet restore in the root per your suggestion, and there are no errors.
$ dotnet restore
  Determining projects to restore...
  Restored ...\source\repos\azure-pipelines-agent\src\Agent.Plugins\Agent.Plugins.csproj (in 637 ms).
  Restored ...\source\repos\azure-pipelines-agent\src\Agent.Sdk\Agent.Sdk.csproj (in 643 ms).
  Restored ...\source\repos\azure-pipelines-agent\src\Microsoft.VisualStudio.Services.Agent\Microsoft.VisualStudio.Services.Agent.csproj (in 642 ms).
  Restored ...\source\repos\azure-pipelines-agent\src\Test\Test.csproj (in 641 ms).
  Restored ...\source\repos\azure-pipelines-agent\src\Agent.PluginHost\Agent.PluginHost.csproj (in 663 ms).
  Restored ...\source\repos\azure-pipelines-agent\src\Agent.Listener\Agent.Listener.csproj (in 671 ms).
  Restored ...\source\repos\azure-pipelines-agent\src\Agent.Worker\Agent.Worker.csproj (in 674 ms).

Thanks for your time spent looking into this! I'll go ahead and close.


Error: write after end

It appears when piping to an external stream, things can sometimes go wrong. First read goes well, but then sometimes it fails on write after end. I feel this has something to do with events not being read correctly (e.g. perhaps a conflict with watchify). Opening an issue to gather more details - this might very well be userland, but then better docs are required

Published a quick hotfix in v4.0.4 where prefixes weren't applied to the node if streamed out - whoops (':

So this is fixed - closing!


⚠ SceneTime has degraded performance

In dfd083c, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 7459 ms

Resolved: SceneTime performance has improved in 2e9fedf after 5 minutes.


Replace VS w/ CS in Code System names to eliminate confusion

See: https://github.com/standardhealth/spec_json2html/issues/4
This is likely an interim solution until declarative code systems (https://github.com/standardhealth/shr-grammar/issues/7) are supported.

Fixed in grammar_4.2 branch.

Merged.


Handle the export command while non-file schema

The export command assumes to save into local file (file:///c:/xxx). On the other hand, Marp for VS Code is also working on remote container (e.g. vscode-remote:// schema such as Docker container, SSH, and WSL). In this case, the export command may try to save into the host filesystem which is not known by CLI if selected Show locals in the save dialog.
We should consider one of them:

Simply output error if detected non-file schema in the path for save.
Handle the path to the host of container (Export to a temporal file and save to the host through VS Code API)

Is this the reason why an export of e.g. c:\temp\test.md into c:\temp\test.pdf does not succeed, i.e. the exported PDF file does not show up in the selected output folder but no error message is given? Everything works if my md files are in the wsl.
If this is the case then I am forced to have the files in WSL file space, which would be inconvenient in terms of file backup with Dropbox etc.


[FIX] refactor dingz.updateAccessory

Describe the enhancement
The updateAccessory() method of the dingz accessory needs refactoring:

integrate updating of the Accessory metadata (FW, Serial, Name etc.)
call DingzEvent.UPDATE_INFO to initiate an accessory Update
untangle some of the intertwined code snippets that doe (almost) the same thing e.g. in getDingzDeviceInfo() and  platform.getDingzDeviceInfo

Examples and context
https://github.com/johannrichard/homebridge-dingz/blob/f33d1dea46896d96007d03e83b9643a460d8805a/src/dingzAccessory.ts#L1126-L1156

Issues #116, #118, #120 and #123 are all related to the fact that this part of the code is still quite a mess.
I will therefore do two things:

Deprecate (or even remove) v1.8.0 of the extension (falling back to v1.7.1 which is working)
Refactor the code such that updates of the accessories and their states across all device types (i.e. myStrom and dingz)

I hope this will solve these issues and cure the sick patient that v1.8.0 has become. 🤒🤕

Also of importance to all this:
homebridge/HAP-NodeJS#543

Things to be fixed in updateAccessory():

add / remove 'not_connected' dimmers
better / simpler handling of dimmers

Question: must we call this method really regularly or would it be sufficient to update on start?


[Brain storming] New language dependency system

Motivation
Our current language dependency system has a few problems:

It is incompatible with ESM.
The current system relies on load order to manage both require dependencies and optional dependencies. Optional dependencies simply cannot be expressed using ESM's static import syntax.

It has to be enforced by the user.
Nothing stops our users from loading languages in the wrong order. We regularly get issues where people have this problem.

It does not support third-party language definitions.
Right now, all dependencies have to be declared in components.json. This makes it very hard for authors of third-party languages to integrate their languages. They are essentially forced to write languages with zero dependencies.

The first problem is huge because ESM is a goal for v2.0.
Goals
Primary goals:

ESM-compatible.
We have to be able to either write or create ESM source files. Source files have to be able to import each other to fulfill their require dependencies. (E.g. the JS language has to be able to import C-like.)

Optional dependencies.
The dependency system has to support optional dependencies. They are the reason this issue exists and they are necessary for Prism.

Secondary goals:

Third-party authors should be able to "hook" into our dependency system.
Making the Node hack unnecessary.

Non-goals

Backwards-compatibility.

Modify dependencies.
Modify dependencies are not strictly necessary. Right now, Prism has 13 modify dependencies. 12 of those can be easily converted into optional dependencies. Only 1 modify dependency will be difficult to convert into an optional dependency but I'm sure that we can find a solution for that.

@LeaVerou @Golmote @mAAdhaTTah

Languages don't just add themselves to Prism, they add a function to create them instead.

Welcome to the party. ;-)  This is exactly how we do it.  This isn't a common thing in our ecosystem but I know at least one person doing this exact thing with their 3rd party grammar (to extend our built-in XML grammar)... you load a plugin, it fetches the original pre-compiled grammar definition (by rerunning it's definer function), modifies it (adding new sublanguage support), and then reregisters it (when it will get recompiled).
You don't have a compile step I don't think but otherwise I think the process would be similar.
You still have a potential load-order issue if multiple plugins were trying to make incompatible changes to the same grammar, but that's a bit more of an edge case.

Welcome to the party. ;-) This is exactly how we do it.

Now that you mention it, they really are the same. Does Highlight.js also deal with optional dependencies?

You still have a potential load-order issue if multiple plugins were trying to make incompatible changes to the same grammar

That's true. Right now, languages and plugins are handled by the same dependency system. The new system should probably also handle both. If both languages and plugins use the same system, the load-order issue should disappear, I think.
That being said, any dependency system that works for languages can trivially be extended to plugins, so we only need to talk languages here.

Does Highlight.js also deal with optional dependencies?

We'd have to define what that means exactly.  Technically our sublanguage support is all optional.  If you don't have a language registered it will silently not work for sublanguage blocks.  Register the language and suddenly it starts working.  And all plugins are all optional and registered at runtime.

Interesting. By using the id of a language in sublanguage, Highlight.js gets around having to worry about optional dependencies.
Prism should definitely copy this trick :)
That being said, Prism's languages use optional dependencies not only for embedded languages, some also conditionally add more tokens if another language is present. (This is how I intend to get rid of modify dependencies.)
While this trick doesn't eliminate optional dependencies, we could use it to cut down on the number of optional dependencies. It's also pretty easy to implement and will make some (recursive) language definitions simpler.

That being said, Prism's languages use optional dependencies not only for embedded languages, some also conditionally add more tokens if another language is present

Do you have an example or two of that? I feel like for the most part we avoid that with sub languages. The rules are there in the parent language but they are effectively NOOP without the appropriate grammar installed.

Do you have an example or two of that?

Regex in JS and Markdown in GraphQL are examples of embedded languages.
As for "conditionally add more tokens": nothing yet, I believe. Prism has modify dependencies right now but I intend to replace them with optional dependencies (to make the deps system simpler).
A good example for that is CSS and CSS extras. While the selector insides could be done as an embedded language, the added color, hexcode, etc tokens cannot. With optional deps, you could implement CSS+CSS extras kinda like this:
// prism-css-extras.js
Prism.languages['css-extras'] = { 'color': /.../, ... };
Prism.languages['css-selector'] = { ... };

// prism-css.js
// CSS now has an optional dependency to css extras
Prism.languages.css = {
  ...,
  'selector': { pattern: /.../, inside: 'css-selector' },

  // add the css extra tokens
  ...(Prism.languages['css-extras'] || {})
};

Languages would be separate modules importing all their (required) dependencies. Prism could offer a promise syntax for when a specific language has been included. Optional or modify dependencies could do things once/if that promise resolves.
But stepping back for a moment, I think we should start from the opposite side: how do we expect users to include languages and plugins in v2? What's the least-friction syntax for them?

how do we expect users to include languages and plugins in v2? What's the least-friction syntax for them?

From what I know, we have 4 camps.

A Prism bundle from our download page

<script src="path/to/prism.js">

A Prism core + Autoloader combo

<script src="https://some-cdn.io/prismjs/prism-core.js"></script>
<script src="https://some-cdn.io/prismjs/prism-autoloader.js"></script>

ESM imports

import Prism from "prismjs"
// ???
// well that's the problem. We don't support that yet.

CommonJS imports

const Prism = require("prismjs")

// if your on a server
const loadLanguages = require("prismjs/components/")
loadLanguages(["sql"])

// However, bundlers and loadLanguages don't do well together, so users are sometimes forced to do this:
require("prismjs/components/prism-sql")
// Does SQL have dependencies and now doesn't work because I forgot the require them ??? Who knows!

We really don't have to worry about camps 1 and 2.
So, what syntax do we want for ESM and CommonJS? @LeaVerou

<script src="https://some-cdn.io/prismjs/prism-core.js"></script>
<script src="https://some-cdn.io/prismjs/prism-autoloader.js"></script>

If this was a super common pattern I'd consider having a single unified file that's just a concat.

@RunDevelopment
We should definitely continue to support 1, 2, and support 3. How important is 4? Node supports ESM now, but not sure if they can be mixed with CJS.
1 can be generated by using Rollup in the client, which is possible, though painfully underdocumented.
I think 3 should be something like:
import Prism from "path/to/prism.js";
import "path/to/language1.js";
import "path/to/plugin1.js";
...

and not this other pattern I saw recently:
import Prism from "path/to/prism.js";
import language1 from "path/to/language1.js";
import plugin1 "path/to/plugin1.js";
language1(Prism);
plugin1(Prism);
...

which is more friction and boilerplate for the end user. The upside of the latter is that it avoids ordering issues, but ideally plugins should be written in such a way that they work in any order.

Node supports ESM now

"Now" means since v13.2.0. Right now, we still support NodeJS v10.x, so we definitely have to support CommonJS.
That being said, if we figure out a good way to handle ESM, we can trivially make an equivalent CommonJS API. So we probably don't have to worry about CommonJS at all.
Please correct me if I'm wrong, but I think we really only need to talk about ESM imports from now on.

[...] ideally plugins should be written in such a way that they work in any order.

That's the goal of this issue...
Right now, import order is important and has to be enforced by the user when importing specific languages (no matter the import style! Even <script src="../prism-lang.js"> imports are affected).
The ESM API I used in the above example was only a mean to demonstrate my proposed dependency system. Whether we use side-effect-free imports or not doesn't matter in terms of the language dependency system.

"Now" means since v13.2.0. Right now, we still support NodeJS v10.x, so we definitely have to support CommonJS.

I believe ESM support was backported & unflagged in the v12.17 release, so if we require from that minor version up, we can go ESM-only.

In terms of optional dependencies, if register took in a generate function, rather than the final language, Prism could generate the languages lazily at first highlight so they don't even need to be registered in a particular order. Similarly, it would allow Prism to regenerate languages that have optional dependencies if those optional deps are registered after the language has already been generated. Having the language resolution internally would also allow Prism to be smarter and throwing/returning errors if you attempt to highlight something without its dependencies registered.

"Unlike Node.js 14, using ESM will still emit a runtime experimental warning, either when a module is used a the application's entrypoint or the first time dynamic import() is called." - Node v12.17.0 release notes

I wouldn't exactly call that a great user experience...
Anyway, I would prefer it if we had this discussion at a later date. If we support ESM, we can trivially support CommonJS as well. Whether or not we actually want to support CommonJS can be decided once we support ESM.

if register took in a generate function

That's the idea I proposed here. I called that function create tho ;)

Having the language resolution internally would also allow Prism to be smarter and throwing/returning errors if you attempt to highlight something without its dependencies registered.

I think it would be better if this problem was just not possible. I really want to avoid the current situation where you can do
const Prism = require("prismjs");
require("prismjs/lang/prism-sql");

and nothing works because you forgot that SQL has dependencies (does SQL actually have dependencies? idk). Whether we throw an error during import or during highlighting doesn't matter. Our users shouldn't have to worry about language dependencies at all.
In my idea here, each language has to bring its own dependencies with it when registering. This is a rather explicit solution but it does mean that a registered language is guaranteed to just work.

Whether we throw an error during import or during highlighting doesn't matter. Our users shouldn't have to worry about language dependencies at all.

Agreed.

In my idea here, each language has to bring its own dependencies with it when registering. This is a rather explicit solution but it does mean that a registered language is guaranteed to just work.

This might work, but we should also support providing the grammar as a literal, for the simple case. In general, the complicated cases should not get in the way of simple usage.

In my idea here, each language has to bring its own dependencies with it when registering.

By "bring its own dependencies," is just... importing them... viable?
import { register } from 'prismjs';
import 'path/to/dep';

register({ ... language definitions ... });

I dunno if we're overthinking it by needing to provide the literal or something in the definition.

@mAAdhaTTah I assumed that's what he meant. If not, yes, definitely importing them should be the way to go!

Node v12 (latest versions) should do ESM without the warning, but I can't give you a specific version number.  That's my understanding from having this same discussion on Highlight.js.  So v10 is the only major version you drop support for if if you go ESM only.
To me "hard dependencies" are only an issue on the browser side (with raw JS files, option 1).  If you're using imports (or require) with a build system or Node then a dependency can't really be missing at runtime.  You'd be informed at build time and fix your broken build.
With Highlight.js we're removed all hard dependencies at runtime.  Every CDN build of a language is an isolated module.  If Typescript requires some components of Javascript, then those bits are compiled in.  In the past we would do a requireLanguage("javascript") call which could break at runtime depending on whether or not the user had installed javascript.  This is now no longer possible.
This is all done with ESM in the original source and Rollup is just used to compile every language (which might have numerous imports) into a single monolithic JS file that includes everything necessary.

By "bring its own dependencies," is just... importing them...

Yes, I provided a code example showing that.
Hard (require) dependencies between languages are done using ESM and optional dependencies are done at runtime by Prism itself.

With Highlight.js we've removed all hard dependencies at runtime.

I think we might want to yoink this idea. This trivially solves the problem of we would implement Autoloader.
AMD is another option but I think that "monolithic JS file"s are the better approach.

@LeaVerou @mAAdhaTTah
To answer your question: It will be an overhaul.
Right now, I imagine an API like this:
import { register } from "../global-register"
import a from "./prism-a"
import b from "./prism-b"

export default register({
  id: "my-lang",
  require: [a, b],
  optional: "c",
  grammar({ getLanguage }) {
    return { 'comment': /.../, ... };
  }
})

So why this:

register adds the given language proto to the the language registry of the global Prism instance. This means that users can import "path/to/lang" or <script src="path/to/lang.js" /> and it'll work.
register itself is quite a simple function that is defined as such (just more robust):export function register(proto) {
  globalThis.Prism.register(proto);
  return proto;
}

Language protos need to include their require deps and declare their optional deps. If they don't, then the runtime addition of optional dependencies (e.g. via Autoloader) won't work.
create is a function because the lazy runtime creating of languages means that you can only use dependencies after the registry instanciated them. It also has to be a pure function, because the registry might have to run it again when dependencies change.
The export because other languages have to be able to get the proto of this language if they depend on it.

Of course, for simple grammars without dependencies, we could allow:
import { register } from "../global-register"

export default register({
  id: "my-lang",
  grammar: { 'comment': /.../, ... }
})

However, there is one this approach doesn't address yet: effects. Languages with hooks and all plugins have side effects. This is a problem because the registry has to be able to reload components.
So I'm thinking about an effect function that adds the hooks and other side effects of a component. Since we need to be able to undo the effects, the effect function returns a function that undoes the effect. Similar to React's useEffect's cleanup function.
import { register } from "../global-register"

export default register({
  id: "my-plugin",
  // the object for Prism.plugins[id]
  plugin: { configProp1: 3 },
  effect(Prism) {
    // hooks.add returns a function (type: `() => void`) that removes the added hook
    return Prism.hooks.add('before-tokenize', env => {});
  }
})

(Note: Some plugins don't just have hooks as their effects, so we need a general solution for effects.)

Some thoughts, in no particular order and not very edited as I'm scrambling to meet a deadline:
I'm not sure we'd still want to have a global Prism object once we move to ESM, it kinda defeats the purpose.
With ESM projects, there are two main use cases, with often a tension between them:
- Novice users want convenience. They don't want to handle importing various modules and registering things. They just want something that works, ideally with a single import.
- Advanced users often want tree-shakeability. This means no side effects from modules that are not actually used but just imported. This is where registration methods can be useful.
The way many projects handle this is to have separate index.js and index-fn.js files, the former with side effects and the latter without. That's what we did in color.js too.
The additional challenge with Prism is that it doesn't make sense to have a single bundle with all languages and plugins, the sheer number of them makes this insane. So, while catering to advanced users is fairly straightforward, it's not clear how to cater to the simple case, the novices. Remember that the no-fuss Prism installation was one of the things that made it so successful, so we need to be careful to maintain this in v2. Having to import each language separately and registering stuff is incredibly fussy. It's useful for advanced users, but it cannot be the only way. It still needs to be possible to use Prism by simply including a <script type=module>. Though just having the existing generator, adapted for the ESM architecture would help with that I assume, so maybe my concern is misplaced.
Once each language is a separate module, it may make sense for Prism itself to have a mode where it loads any languages it encounters, asynchronously, via import(language_module_url), which would be relative to import.meta.url. Then people could even just import it from prismjs.com directly, and stuff just works.

I don't understand why the proposed format has a require property. One of the advantages of ESM is that they manage their own dependencies. We should hook into that, rather than continuing to have our own dependency system.

I don't understand why the proposed format has a require property

We have to be able to recreate (formerly reload) languages because of optional dependencies, so we must know all dependencies of a given component. The rules are as follows:

If a component gets added, then all languages that optionally depend on this component must be recreated.
If a component gets recreated, then all components that depend on this component (optionally or required) must also get recreated.

(This is what we do right now. v2 follows the same rules, but it lazily creates languages, so recreating a language is free if the language wasn't used yet.)
The require property is also necessary for correctness when making different Prism instances (e.g. for our testing). If the required property wasn't there, then you could make a new Prism instance and manually add a language/plugin proto without its dependencies.

The way many projects handle this is to have separate index.js and index-fn.js files, the former with side effects and the latter without. That's what we did in color.js too.

That's a good idea. We could do that for every component. Right now, I chose side effect (register) + export. But making them side effect free and then generating a version with side effects (so you can <script src=""/> import them) is better.

Once each language is a separate module, it may make sense for Prism itself to have a mode where it loads any languages it encounters, asynchronously, via import(language_module_url), which would be relative to import.meta.url

We have to change AutoLoader anyway, so we might as well change it to work like this.

I'm not sure we'd still want to have a global Prism object once we move to ESM, it kinda defeats the purpose.

We need side effects to support the <script/> import case, so that's how I did side effects. How else would you do it?

I'm not sure we'd still want to have a global Prism object once we move to ESM, it kinda defeats the purpose.

We need side effects to support the <script/> import case, so that's how I did side effects. How else would you do it?

As long as two modules import Prism from the same URL, they can both add stuff to it and it's the same object. :)

True. With Autoloader using the side-effect-free versions, this could work.
However, this does make the assumption that every component imports the same Core module. This won't necessarily be the case for bundles (the monolithic component files that include all their dependencies), so this might cause problems.
Well, since side effect versions will be generated anyway, we can change how we do side effects later in the case that importing Core directly doesn't work out.

Yeah but bundles don't need to import Core at all, the core and the languages/plugins are all in the same file.
Unless you're talking about the use case where somebody imports a bundle, then tries to add more languages and plugins to it?

No, with bundles, I mean monolithic components here (is there a name for this stuff?). I.e. JS depends on C-like, so the bundle dist of JS would include a copy of C-like, while the ESM dist would import C-like. The goal of these bundle files in to eliminate any and all imports, so you can use them with a regular <script src=""/>, which has better browser support than type=module.
Or are we just going to say that browsers have to support type=module? Same for import(), which has even worse browser support.

Unless you're talking about the use case where somebody imports a bundle, then tries to add more languages and plugins to it?

That can be pretty easily done like this, so I think this use case is covered.
<script type=module>
import Prism from "bundle.js"
import a from "lang-a.js"
import b from "plugin-b.js"
Prism.register(a)
Prism.register(b)
</script>

Or are we just going to say that browsers have to support type=module? Same for import(), which has even worse browser support.

Brain dump:
... I kinda want to lean forward with v2. Is that bad? Could we get away with not using a build process at all? What would that look like? I know we want to make this easy to use for beginners, so if we had a prism/autostart (or any better name), they could import that, which would use the autoloader & load events to highlight, and everything else could be a pure module. Does that lean too far away from ease-of-use? Beginners would then a weaker performance (all languages are loaded from the server lazily, so highlighting is delayed until the language is loaded), but wouldn't even need to build a version from the website. They could download the bundle of files & put them on a server, or import or script them in directly from a CDN. Are we doing beginner users a disservice from denying so a wide swath of their own audience (any of their readers using a browser that doesn't support import()will have problems)?
More radical idea: What if we took this a step further and did away with the single global Prism instance and instead provide a factory function to create that instance? Since we have /autostart, it won't make it any more difficult for beginners and would give advanced users more flexibility (but is that useful flexibility? Maybe not...).

I really like the idea of /autostart. I'm also in favor of separating the load evens and Core. It feels a little silly that so much browser-specific code gets loaded and promptly ignored by Node.
Although, the transition away from it feels a bit too steep right now. On scale from "Prism does everything for you" and "you have to do it all yourself", it feels like we only provide the extremes right now. But the intermediate steps will hopefully be easy to add once we have the extremes.

What if we took this a step further and did away with the single global Prism instance and instead provide a factory function to create that instance?

I also like that. I intended to pack the main Prism functionality into a class anyway. The global Prism instance would have been exactly that: an instance.

I kinda want to lean forward with v2. Is that bad?

Not necessarily. People that need strong browser support can use v1.
The question is: How far do we want to go/what is the exact feature set we are going to require? We require ES6, yes, but different parts of ES6 have vastly different support. I mean, parts of ES7 have better support than some of ES6.

Could we get away with not using a build process at all?

I'm not quite sure what you mean with that. Like npm run build, minification included?

I would be fine with only supporting very modern browsers with v2. Remember, cutting edge releases now, are the majority release in a year. It costs much more to refactor, whereas wider browser support is only a matter of time (and v2 will take some time to finish anyway). So I think only supporting the last 1-2 versions of current browsers when we start work on v2 is fine. I wouldn't even consider browsers that don't support type=module or import(), those are ancient history.
My understanding was that people use bundles to reduce HTTP requests and DNS lookups, not primarily for browser support.

I'm not quite sure what you mean with that. Like npm run build, minification included?

I believe he means import Prism from "https://prismjs.com/src/prism-core.js" (or local files), without having to make any bundles.
But yeah, I suppose there's always minification.

Yeah, I was thinking minification would be the responsibility of the user. Do people use minifiers without bundlers? Is it too much on an assumption that you'd use those together?

So I think only supporting the last 1-2 versions of current browsers when we start work on v2 is fine.

That sounds good. I would even suggest jumping to at least ES2017 to get async functions for any planned promise APIs.
We might even want to go ES2018, because that added Unicode property escapes (e.g. \p{L}) which is huge for us, because Unicode classes are commonly used in language specs, but we could never get them right. Lookbehinds would also be huge, but Safari is raining on that parade, unfortunately.
Going even further, the v flag proposal would also be useful to us (we currently us lookarounds to do set operations, which comes at a performance cost). So would we be comfortable going with the current ES version or even ESNext and then transpiling down?
To be clear: I'm suggesting this because these are useful features that Prism would benefit from, not because of a "then let's go all the way" mentality.

Yeah, I was thinking minification would be the responsibility of the user.

Autoloader is supposed to work with CDNs, so we have to include minified files somewhere.
I also don't want to lose the ability to do magic with our builds. If we completely got rid of builds, then we would make it impossible to later use a transpiler or upgrade to TS (at least let me hope). We also lose our Prism-specific minifier logic (the optimized source inlining), although that might not be too bad, because I got that included in Terser (albeit a less optimized version).

So I think only supporting the last 1-2 versions of current browsers when we start work on v2 is fine.

That sounds good. I would even suggest jumping to at least ES2017 to get async functions for any planned promise APIs.
We might even want to go ES2018, because that added Unicode property escapes (e.g. \p{L}) which is huge for us, because Unicode classes are commonly used in language specs, but we could never get them right. Lookbehinds would also be huge, but Safari is raining on that parade, unfortunately.
Going even further, the v flag proposal would also be useful to us (we currently us lookarounds to do set operations, which comes at a performance cost). So would we be comfortable going with the current ES version or even ESNext and then transpiling down?
To be clear: I'm suggesting this because these are useful features that Prism would benefit from, not because of a "then let's go all the way" mentality.

I think that's fine. Wow, had never seen of the v flag, that's indeed super useful for Prism!

Wrt Safari and lookbehind, I see the bug is Assigned, so all hope is not lost.

I think that's fine.

Uhm, what is? I've given 3 options...

I see the bug is Assigned, so all hope is not lost.

They didn't work on it for 5 years now, but the ticket exists, yes. I'm about on the same level of hope as this person :)

I think that's fine.

Uhm, what is? I've given 3 options...

I don't see 3 options, I see a suggestion that we depend on 3 modern to cutting edge features, and I'm fine with depending on all of them 😁

I see the bug is Assigned, so all hope is not lost.

They didn't work on it for 5 years now, but the ticket exists, yes. I'm about on the same level of hope as this person :)

True. Can we polyfill or transpile it?

I'm fine with depending on all of them 😁

Oh, that's great!

Can we polyfill or transpile it?

No. Unfortunately, it's fundamentally not possible to mimic the behavior of lookbehinds (positive or negative) with other regex features, so transpiling is off the table.
The only way to polyfill it, would be to have another regex engine that supports it and fallback to that engine if the browser doesn't support lookbehinds. One way would be to import Rust's fancy regex via wasm (we would have to make the wasm module ourselves). One could potentially also make a wasm module out of the regex engines of v8 or spidermonkey, but that might be difficult (e.g. v8's regex engine is tightly integrated with v8's memory model for JS objects, IIRC). However, all of those wasm modules would be at least 1MB in size (e.g. the wasm of re2 and rust's regex crate are both around 1MB, and they are simpler regex engines than what we would need).


SQRT function doesn't work

This is the used placeholder:
%math_SQRT((%var_block_z%-%var_player_z%)*(%var_block_z%-%var_player_z%))%
Thats the error in the console:
! [Wed 15:21:42 WARN  PlaceholderAPI] [math] Invalid Placeholder detected!
! [Wed 15:21:42 WARN  PlaceholderAPI] [math] Placeholder: %math_SQRT((%
! [Wed 15:21:42 WARN  PlaceholderAPI] [math] Cause:       'SQRT((' is not a valid Math expression.

The Math Extension is on the latest version on PAPI 2.11.5

Hi, I think you reached the wrong repository.
I think you should ask your question at the the PlaceholderAPI project.
EvalEx knows nothing about those patterns you mentioned.

Oh, I'm sorry. I will contact PAPI support. Still, thank you ^^


Auto emit types

Is it planned to emit the type metadata for every attribute on class level. Especially when defining a data model this would be very helpful. It would be great to be able to add something like a decorator @emitAllMetadata to the class and then the metadata for every attribute will be emitted.
@emitAllMetadata
class Myclass {
  public color: string;
}

let test = new Myclass();

console.log(Reflect.getMetatdata('design:type', test,'color'));
// output: string

I know it will create a lot of overhead when doing this for every class but especially in the backend where its's needed to verify data before storing in the database it could be very helpful.

We have no plans in changing or increasing the scope of the metadata emit feature.