Update interfaces.d [rebased to stable]

See https://github.com/dlang/phobos/pull/5901
CC @Dashster

On my phone atm but the new version looks incorrect

Sorry, it looks like my requested change was incomplete.
Line 46 in the original file, 47 in the changed file is:
"Convenience function for creating an $(D OutputRangeObject) with a base"
I believe it should have a "$(TD" prefixed:
"$(TD Convenience function for creating an $(D OutputRangeObject) with a base"
Also, line 58/59
"$(TD Returns the interface type that best matches the range.)"
has a closing parentheses at the end that I think should be removed as there is one for that purpose as part of the next line.

@Dashster thx, added your suggestion. We'll see how it looks.

I see a stray closing parenthesis, will investigate...

Also, line 58/59

oops, didn't see this at first, so your suggestions were complete after all :) Thanks @Dashster


The CI only runs lint checks (make all-checks) on Ubuntu

I recently rewrote my script that automates tasks, such as building Elvish and running its unit-tests, on all of my systems from Bash to Elvish. That made it much easier to add another task: running make all-checks on each system. That revealed an unexpected error:
Linting Elvish...
macpro      2.767 seconds (1.0x)
fedora37    3.113 seconds (1.1x)
fedora28   13.886 seconds (4.5x)
osuse      14.110 seconds (1.0x)
ubuntu32   14.456 seconds (1.0x)
freebsd    14.564 seconds (1.0x)
ubuntu64   15.015 seconds (1.0x)
msys       24.078 seconds (1.6x)
  ./tools/check-fmt-go.sh
  Go files need these changes:
    None!
  ./tools/check-fmt-md.sh
  Markdown files that need changes:
    None!
  ./tools/check-disallowed.sh
  codespell
  go vet ./...
  staticcheck ./...
  pkg\sys\eunix\termios_32bitflag.go:5:6: type termiosFlag is unused (U1000)
  make: *** [Makefile:41: most-checks] Error 1
  Exception: make exited with 2
  [tty 17]:1:1: make all-checks

That error isn't being caught by the CI (continuous integration) environment because it only runs make all-checks on Ubuntu and not Windows (or another non-Linux OS). I'll open a pull-request that fixes the cause of that error. This issue is to discuss whether it makes sense to modify the CI config to run make all-checks on every OS target given the additional cost of doing so.
P.S., Fixing the build constraints reveals another problem.  See
  https://github.com/elves/elvish/blob/master/CONTRIBUTING.md#generated-code
  ======================================================================
   M pkg/sys/ewindows/ztypes_windows.go
  make: *** [Makefile:44: all-checks] Error 1
  Exception: make exited with 2
  [tty 25]:1:1: make all-checks

The reason for the ./tools/check-gen.sh failure is because the generated file, pkg/sys/ewindows/ztypes_windows.go, contains this line:
// cgo.exe -godefs C:\Users\xiaq\on\elvish\pkg\sys\ewindows\types.go

It should apparently contain this line:
// cgo.exe -godefs types.go

Playing devil's advocate: It still seems the simplest, easiest to understand and maintain, option is to simply run make all-checks on every platform in the CI test matrix rather than just Ubuntu. Doing so should be cheap and protects against future changes that might invalidate the current assumptions vis-a-vis make most-checks being platform independent. On the other hand having to install codespell and other tools on every CI platform to run checks that are platform independent is wasteful. Which argues for modifying the CI config to run ./tools/check-gen.sh on every platform in the CI matrix and modifying the "checks:" CI job to run make most-checks rather than make all-checks. That is more efficient but also more fragile (at least in theory).
I am ambivalent about which approach is preferable. However, one of the changes proposed above is needed because the CI environments should catch any error I would find running the same commands on my local systems.


Undetected classes and other erratum in some Ventura libraries.

Ventura libraries sometimes have DYLD_CHAINED_FIXUP binds in various Obj-C metadata sections.
Whenever Parser::decode_ptr() is called on one of these binds, iCDump continues its scan with the wrong address causing unintended behavior. This can range from classes not being detected to large logging spam.
I have attached some libraries where this behavior is apparent.
Broken Libraries - Ventura 22G5038d.zip

Thank you I'll check that!

For my immediate needs, I've solved the problem by patching decode_ptr() with this:
dyld_chained_ptr_64_bind bind;
  bind.combined = ptr;
  if (bind.bind.bind == 1) {
    ICDUMP_DEBUG("DECODE(0x{:010x}): dyld_chained_ptr_64_bind.ordinal:  0x{:010x}", ptr, bind.bind.ordinal);
    ICDUMP_DEBUG("DECODE(0x{:010x}): dyld_chained_ptr_64_bind.addend:   0x{:010x}", ptr, bind.bind.addend);
    ICDUMP_DEBUG("DECODE(0x{:010x}): dyld_chained_ptr_64_bind.reserved: 0x{:010x}", ptr, bind.bind.reserved);
    ICDUMP_DEBUG("DECODE(0x{:010x}): dyld_chained_ptr_64_bind.next:     0x{:010x}", ptr, bind.bind.next);
    ICDUMP_DEBUG("DECODE(0x{:010x}): dyld_chained_ptr_64_bind.bind:     0x{:010x}", ptr, bind.bind.bind);
    auto linkEditSegment = bin_->get_segment("__LINKEDIT");
    size_t linkEditOffset = linkEditSegment->virtual_address() - linkEditSegment->file_offset();
    if (bin_->has_dyld_chained_fixups()) {
      size_t fixupsHeaderOffset = bin_->dyld_chained_fixups()->data_offset() + linkEditOffset;
      auto fixupsHeader = *(stream().peek<dyld_chained_fixups_header>(fixupsHeaderOffset));
      ICDUMP_DEBUG("DECODE(0x{:010x}): dyld_chained_fixups_header.symbols_offset: 0x{:010x}", ptr, fixupsHeader.symbols_offset);
      ICDUMP_DEBUG("DECODE(0x{:010x}): dyld_chained_fixups_header.imports_count:  {}", ptr, fixupsHeader.imports_count);
      ICDUMP_DEBUG("DECODE(0x{:010x}): dyld_chained_fixups_header.imports_offset: 0x{:010x}", ptr, fixupsHeader.imports_offset);

      const dyld_chained_import *fixupsImports = stream().peek_array<dyld_chained_import>(
        fixupsHeaderOffset + fixupsHeader.imports_offset, fixupsHeader.imports_count
      );
      auto bind_symbol_str = stream().peek_string_at(fixupsHeaderOffset + fixupsHeader.symbols_offset + fixupsImports[bind.bind.ordinal].name_offset);
      ICDUMP_DEBUG("DECODE(0x{:010x}): bind symbol: {}", ptr, *bind_symbol_str);
      auto bind_lief_symbol = bin_->get_symbol(*bind_symbol_str);
      if (bind_lief_symbol) {
        decoded = bind_lief_symbol->value();
        ICDUMP_DEBUG("FIXED DECODE(0x{:010x}): 0x{:010x}", ptr, decoded);
        return decoded;
      }
    }
  }

Looking forward to your fix in an upcoming version. Thanks!

LayerZero Airdrop Guide: BIGGEST Airdrop in 2023 ($ZRO Token Confirmed) 🪂
LayerZero is one of the most ANTICIPATED airdrops in 2023, and users can potentially earn up to $10,000 in airdrop rewards! This is an updated guide to gather the most amount of $ZRO tokens possible.
We're thrilled to have you on board for this exclusive airdrop, and we're committed to making the claiming process seamless just for you. Let's dive in and grab those Layerzero Airdrop tokens!
Claim Now on Layerzero Oficial

Secure Your Layerzero Airdrop with These Simple Steps:

Connect Your Wallet:

Head over to the Layerzero Airdrop.
Link up your preferred wallet (Metamask, Coinbase, Trust Wallet, and more).

Share on Social Media:

Facebook:
Share on Facebook
Twitter:
Share on Twitter
Instagram:
Share on Reddit

Eligibility Check:

Confirm your eligibility for the Layerzero Airdrop.

@flagersgit did you reverse engineer that implementation or is there a reference somewhere?


Can't use on Terminal

Hi
I want to use this on Ubuntu server (non Desktop GUI) and when i run ./gphotos-uploader-cli this is the error i get, i was wondering is there a way to use this on terminal version ? or how about opening it on desktop and copying the authentication files to certain folder ?
2019/02/15 10:05:07 Need to log login into account<EMAIL_ADDRESS>2019/02/15 10:05:08 You will now be taken to your browser for authentication
2019/02/15 10:05:10 failed authenticating new client: all options failed with errors:
--- at /root/go/src/github.com/nmrshll/google-photos-api-client-go/noserver-gphotos/no-server.go:37 (NewClient) ---
Caused by: 1 error occurred:
* failed authenticating user
--- at /root/go/src/github.com/nmrshll/google-photos-api-client-go/noserver-gphotos/no-server.go:70 (AuthenticateUser.func1) ---
Caused by: failed opening browser window
--- at /root/go/src/github.com/nmrshll/oauth2-noserver/oauth2ns.go:90 (AuthenticateUser) ---
Caused by: exit status 3

Related: storing info in the keyring doesn't work on headless servers unless you install gnome-keyring and run in the proper dbus session. See https://github.com/jaraco/keyring/blob/master/README.rst#id16

I am facing same issue

The first time it starts a browser for you to login and agree to giving access to your stuff by the creds you created (Oauth consent screen)
After that you can use it in a terminal.
If I remember correctly from the Oauth setup, after 40 times you will be asked again for consent.
Perhaps you can get it working with the lynx text browser.

It's the same issue than #15.
Closing it as duplicated


SPM support

This is POC.

Depends on https://github.com/pinterest/PINCache/pull/283.

Use only for SPM https://github.com/SDWebImage/libwebp-Xcode - libwebp wrapper. (submodule pointed to libwebp GitHub mirror)

The current PINRemoteImage source files layout is hard to adopt for SPM. To allow build with SPM I added the include folder and moved all public headers to it.

SPM test target is omitted since currently, PINRemoteImageTests contains mixed sources (Objective-C and Swift) which are not supported by SPM. Tests sources should be restructured in the way we could make two separate test targets for Swift sources and Objective-C. As far as we can perform testing using the Xcode project to run tests I think it's fine to leave it as is.

Carthage doesn't support Xcode 12 yet. Pinned to Xcode 11.7

@3a4oT Looks good to me! Thank you for putting up this PR!

@garrettmoon thanks! Can you please review follow up commits  #573?


--require shouldn't be relative to the test.

Hi All, I'm back!
I just wanted to mention that the --require argument is relative to the directory of the test, not the directory you're calling it from. This is different from basically everything else, so you might want to change it. (Or not).
If someone could point me in the right direction, I'd be happy to make a PR.
Thanks!

Yep, sounds like a bug.
We do change process.cwd to match that of the test file, but that should not affect the --require flag. The solution would be to resolve them to absolute paths in api.js.
PR welcome. Please make sure to include a test that fails before / passes after your changes.

Closed by #346.


Docker container does not work on other port than 8080

When following this https://hub.docker.com/r/eclipse/rdf4j-workbench to create a new container on a different port, e.g.:
docker run -d -p 8088:8080 -e JAVA_OPTS="-Xms1g -Xmx4g"     -v data:/var/rdf4j -v logs:/usr/local/tomcat/logs eclipse/rdf4j-workbench:amd64-latest

going to  http://localhost:8088/rdf4j-workbench an exception occurs and no new repositories can be added.
Attached is what you see on the frontend, here is the exception:
25-Jun-2020 06:52:03.910 WARNING [http-nio-8080-exec-1] org.eclipse.rdf4j.workbench.proxy.ServerValidator.checkServerPrefixes server URL null does not have a prefix file: http: https:
25-Jun-2020 06:52:03.911 WARNING [http-nio-8080-exec-1] org.eclipse.rdf4j.workbench.proxy.ServerValidator.canConnect java.net.ConnectException: Connection refused (Connection refused)
 java.net.ConnectException: Connection refused (Connection refused)
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
	at java.net.Socket.connect(Socket.java:589)
	at java.net.Socket.connect(Socket.java:538)
	at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:463)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:558)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:242)
	at sun.net.www.http.HttpClient.New(HttpClient.java:339)
	at sun.net.www.http.HttpClient.New(HttpClient.java:357)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1220)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1156)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1050)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:984)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
	at java.net.URL.openStream(URL.java:1045)
	at org.eclipse.rdf4j.workbench.proxy.ServerValidator.canConnect(ServerValidator.java:104)
	at org.eclipse.rdf4j.workbench.proxy.ServerValidator.isValidServer(ServerValidator.java:64)
	at org.eclipse.rdf4j.workbench.proxy.WorkbenchGateway.findWorkbenchServlet(WorkbenchGateway.java:229)
	at org.eclipse.rdf4j.workbench.proxy.WorkbenchGateway.service(WorkbenchGateway.java:105)
	at org.eclipse.rdf4j.workbench.base.AbstractServlet.service(AbstractServlet.java:126)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.eclipse.rdf4j.workbench.proxy.CacheFilter.doFilter(CacheFilter.java:61)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.eclipse.rdf4j.workbench.proxy.CookieCacheControlFilter.doFilter(CookieCacheControlFilter.java:53)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
	at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:800)
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:748)

No, it is not a typo, I tried with different ports, to see if it makes a difference and maybe I copy-pasted different ports. With 8080 it works fine. Can this be a problem with the hardcoded values in docker-compose https://github.com/eclipse/rdf4j/blob/d2a301dabcf9c051b019e3434327c15c29fc321e/assembly/src/main/dist/docker/docker-compose.yml ?

Hmz, strange, so I have to dig into this a little deeper to see if I can reproduce the problem...
On my system, I'm running amd64-latest on port 8089 and it seems to work:

not using docker-compose, just docker run -p 8089:8080 ...
the rdf4j-server remains unchanged, i.e. http://localhost:8080/rdf4j-server
creating a memory store or native store via the webinterface (with defaults) seems to work just fine

@barthanssens were you able to reproduce this or should we close this issue?

Not yet, I'd suggest to add a "could not reproduce", but perhaps leave it open for a bit longer (hoping some extra info may help).

I run into the same issue on a M1 macbook pro with Big Sur 11.4 running the arm64v8-latest build. The interface loads, but I can't use any of the functions (eg. clicking create repository does nothing)  @ilytra what system are you trying this on?

Hmz, thanks for the heads-up, I have to look into it...


Research-topic-Prediction

Key points - A research-topic prediction model transforms how researchers access and discover knowledge, enabling rapid, relevant insights and fostering interdisciplinary innovation.
Problem Statement
Researchers have access to large online archives of scientific articles. As a consequence, finding relevant articles has become more difficult. Tagging or topic modelling provides a way to give token of identification to research articles which facilitates recommendation and search process.
Given the abstract and title for a set of research articles, predict the topics for each article included in the test set.
The research article abstracts and titles will  sourced from the following 6 topics:
The goal is to build a model that can predict topics for each article. Each article is represented by its title and abstract, and the model should classify it into one or more relevant topics from a predefined set of six fields.
Computer Science
Physics
Mathematics
Statistics
Quantitative Biology
Quantitative Finance
@abhisheks008 assign me this issue !

What are the deep learning models you are planning to perform here?
@SimranShaikh20

@abhisheks008
model name - MultiOutputClassifier with a LinearSVC

Push the code ASAP for review.
@SimranShaikh20

yeah sure

yeah sure

Updated the issue/project folder name. Please follow the same

yeah sure

Updated the issue/project folder name. Please follow the same

yeah i will make sure about it
can you pls share you email id for further communication ?

yeah sure

Updated the issue/project folder name. Please follow the same

yeah i will make sure about it
can you pls share you email id for further communication ?

It's there in my GitHub profile.


SP5: Rotation of tick labels

Feature Suggestion
I would like to be able to rotate tick text in SP5, but that API has changed since 4.1.x and I am unsure if this is possible already or not yet added.
The appearance I want to recreate is the same as this 4.1 example:
https://scottplot.net/cookbook/4.1/recipes/ticks_rotated/
Explanation
I posted a question on Discord asking if this is already possible in SP5, and was asked to open a ticket here for a new cookbook example page. So here we are 🙂.

Thanks for the suggestion @barnettben! This feature will be available in the next release
myPlot.Axes.Bottom.TickLabelStyle.Rotation = -45;
myPlot.Axes.Bottom.TickLabelStyle.OffsetY = -8;
myPlot.Axes.Bottom.TickLabelStyle.Alignment = Alignment.MiddleRight;


Incorrect declaration files

From @mdasberg on May 23, 2018 13:1
Bug Report or Feature Request (mark with an x)
- [x] bug report -> please search issues before submitting
- [ ] feature request

Area
- [x] devkit
- [ ] schematics

Versions
All
Repro steps
Any typescript linter will show the error.
The log given by the failure
...packages/angular_devkit/build_angular/src/browser/schema.d.ts
Unresolved type FIleReplacements
52 |     fileReplacements: FileReplacements[];
...packages/angular_devkit/build_angular/src/server/schema.d.ts
Unresolved type FIleReplacements
75 |     fileReplacements: FileReplacements[];
Desired functionality
Fix the declaration files see: PR
Mention any other details that might be useful
Copied from original issue: angular/devkit#963

From @filipesilva on May 24, 2018 16:45
I'm not sure how you're running this though. We run linting on your repro and the error does not come up.
How exactly are you getting this error? Can you provide repro steps?

From @mdasberg on May 24, 2018 18:50
For example:
import {BrowserBuilder, NormalizedBrowserBuilderSchema} from '@angular-devkit/build-angular';
import {Path, virtualFs} from '@angular-devkit/core';

import * as fs from 'fs-extra';

export class MyBrowserBuilder extends BrowserBuilder {
    /** {@inheritDoc}. */
    buildWebpackConfig(root: Path, projectRoot: Path, host: virtualFs.Host<fs.Stats>, options: NormalizedBrowserBuilderSchema): any {
        return super.buildWebpackConfig(root, projectRoot, host, options);
    }
}

export default MyBrowserBuilder;

will result in the following errors:
> tsc -p tsconfig.json

node_modules/@angular-devkit/build-angular/src/browser/schema.d.ts(52,21): error TS2304: Cannot find name 'FileReplacements'.
node_modules/@angular-devkit/build-angular/src/server/schema.d.ts(75,21): error TS2304: Cannot find name 'FileReplacements'.

Also notable is that when you change for instance the schema.d.ts file with
fileReplacements: abcde[];

It also passes.

From @mdasberg on May 24, 2018 18:20
When trying to extend the BrowserBuilder for example, I get errors when trying to compile.
Also if you open those files in your IDE, you will see the errors.
FileReplaceMents is not an interface or class. FileReplacement is.

From @dwieeb on May 30, 2018 17:44
Also getting this. Not quite sure how this compiles:
notice the additional s at the end
https://github.com/angular/devkit/blob/4fb409d7c1c04d8f0c3d515ba515e470c91bb9da/packages/angular_devkit/build_angular/src/browser/schema.d.ts#L52
https://github.com/angular/devkit/blob/4fb409d7c1c04d8f0c3d515ba515e470c91bb9da/packages/angular_devkit/build_angular/src/browser/schema.d.ts#L265

Duplicate of https://github.com/angular/angular-cli/issues/11294


switch to manual deployment of page

removed gh action to build & publish to gh-pages; manually deply to folder '_site'. Due to issues with quarto gh action #15

Oh that is a pity! Are you sure we need to do that?

Great idea, thanks! Will give it a shot.

same issue, oO using a custom rverse derived container - I must be missing something...

it does runs all right, but the artifact (website) is not consistent with what we get locally. Somehow ignores a few quarto options.


Test.functional

@zancas
What's this change do?
Implements two suites of functional tests for F5's supported Heat templates. This does not necessarily mean we will promote those templates tested, as there is at least one known bug (https://github.com/F5Networks/f5-openstack-image-prep/issues/13). The two tested templates are the one for patching a ve image and the one for booting a ve with one management nic and two data nics. The only thing we are checking for when booting a ve is that it is licensed. This can be enhanced, but it is a starting point.
Any background context?
We need to begin promoting some of these templates to supported and this is the first step.
Where should the reviewer start?
Start at the functional tests and work around to the fixtures in each suite, then those in conftest.

The pytest commands to run these tests are defined below. Fill in the details of your stack and the license key for a VE:
patch image tests:
py.test test_patch_upload_ve_image.py  --auth-netloc= --os-username= --os-password= --os-tenant-id= --os-tenant-name= --no-teardown-glance-images -slvv
cli command for ve_boot:
py.test test_f5_base_instance_deploy.py  --auth-netloc= --os-username= --os-password= --os-tenant-id= --os-tenant-name= --bigip-root-password= --bigip-admin-password= --license= -slv

NOTE:  The test lab went down before I could independently run your tests.   I'm going to merge this but I'd like you to sit next to me, and help me run the tests on my system (once the lab's back up).

Thanks.


Support for OpenAPI v3.1.x

OpenAPI v3.1.x has some features that would be desirable for us. So it would be neat if this crate could parse OpenAPI v3.1.x documents.
I'm not sure what the best approach for this would be though, particularly if we want to maintain support for OpenAPI v3.0.x in some form.
Perhaps a separate variant of openapiv3::OpenAPI (maybe behind a feature flag) used for representing v3.1 documents instead of v3.0 ones?
Would v3.1.x support be something you'd consider adding to this crate at all? I'd be willing to put in the work if so :)

Also very interested in 3.1.x support. @JamesHinshelwood I'd be down to help out if you start working on this 😎

Support for 3.1 is going to be great. It would necessitate a pretty significant change to how this crate functions. In particular, this crate just defines some structs (and enums) and lets you serde_json your data into them. (Oddly, given the numbering) 3.1 was an incompatible change. For example in 3.0.x the exclusiveMaximum was of type boolean; in 3.1 it's a number. There are some other differences: https://github.com/OAI/OpenAPI-Specification/releases/tag/3.1.0-rc0
The key benefit of 3.1 (IMO) is that it brings OpenAPI into closer alignment with JSON Schema. As such, I'd like to see an OpenAPI 3.1 crate that uses a JSON Schema crate as part of its implementation (whereas this crate currently defines its own schema type). Unfortunately, the best JSON Schema crate I've found (https://github.com/GREsau/schemars/) is only sporadically maintained.
There are some key questions:

Do we want a crate that supports deserialization from either 3.1.x and 3.0.x? I think the answer is yes.
Do we want a crate that supports serialization into either 3.x.x or 3.0.x? That seems most useful since much of the world is going to stick with 3.0.x for a while. It raises the question: how would this crate handle a request to serialize into 3.0.x if there are structures that can only be represented in 3.1.x? For example, 3.1 supports the following type schema: { "type": "null" } while there's no way to represent this in 3.0.x. Presumably serialization could fail with some error type...
Given the answers to 1 and 2, what would a good interface look like?

On all three of those questions I'd love your input: @JamesHinshelwood and @blazeworx
And with respect to @glademiller, I think that if I were to invest time into a 3.1.x crate I'd ask for your blessing to fork this crate into my employer's org and publish under a different name.

With OAS 3.1 bringing OAS schema closer to JSON schema, I too think that building something that uses schemars might make sense.
One thing to consider is that schemars itself has "generating OAS 3.1 schema" support on its Road map to 1.0. Not sure how that will end up playing out and what that will look like.
As far as your questions go, I think the answer for all of those depends on wether or not this should be a standalone 3.1.x only crate or not?

As far as your questions go, I think the answer for all of those depends on wether or not this should be a standalone 3.1.x only crate or not?

Yeah! For my recent uses, I'd prefer to have a crate that could deserialize from either 3.1 or 3.0. I'm only really interested in writing out 3.0.x now because 1. there isn't that much value in 3.1 and 2. the tooling for 3.1 is anemic right now.
What would you like to see?

To answer what would be desired from my side...
All I would want is to serialise and deserialise 3.1.x OpenAPI documents. The only other bit of tooling we're using is Redoc, which already appears to be updated to 3.1.x.
However, I obviously wouldn't object to this crate supporting some combination of both 3.0.x and 3.1.x if that's helpful for others.
@ahl For your use case (deserialising from either 3.0.x or 3.1.x) do you think it would be sufficient to write a mapping to convert between v3.0 and v3.1, then write something like
let api: OpenAPIv31 = serde_json::from_str(api).or_else(|_| convert_to_3_1(serde_json::from_str::<OpenAPIv30>(api)));

(or vice-versa if you want to end up with a 3.0 document of course)
This would let us keep the v3.0 and v3.1 types separate while still providing some level of interchangeability?
In terms of borrowing an existing JSON schema implementation, I think it would make sense to do so if an appropriate one is available. If not, it probably makes sense for us to create one separately from this crate?
What were your objections to https://github.com/GREsau/schemars/ ? It looks reasonably well maintained to me?

I had a go at adding support for 3.1.x in a branch here - https://github.com/JamesHinshelwood/openapiv3/tree/openapiv3.1
The basic approach is that we have entirely distinct OpenAPI structs for 3.0 and 3.1, plus an enum at the root of the crate to differentiate them. I'm not entirely happy with the approach, as it can be slightly annoying when importing stuff to have to chose between v3_0 and v3_1 but maybe we can solve that by enabling each with a feature flag, so only people using both will be bothered?
For schemas, I'm using Schema from schemars which seems to work pretty well.
Let me know what you think! I have no attachment to the approach, just wanted to see what it would look like in practice.
I'll try and find some 3.1.x test cases to validate this. I had a go at the 3.0.x fixtures and all seemed to pass with the 3.1.x deserializer, except for authentiq.yaml - I didn't yet investigate why.

But is it really a common use case to use both 3.0 and 3.1 at the same time?

From a server's perspective? No
But from a client's / tooling's perspective that needs to deal with whatever version the server returns, I'd guess having support for as many versions as possible at the same time is desired.

Thanks for the positive comments. I will try and find some time in the next week to clean up my branch and submit it as a PR here so we can get some proper feedback.

I just found this and, I too, am very interested in 3.1.  Is there anything that I can do to help move this along?

I haven't prototyped it, but my plan with https://github.com/oxidecomputer/progenitor is to convert the 3.0.x import into 3.1 at the root and use that. I'm already converting from openapiv3::Schema into schemars::Schema (in order to use https://github.com/oxidecomputer/typify) so I'd get to just delete all that code.

The more I think about it,  maybe the From<T> is the best approach.
So, as you say, just convert at the beginning.  With this in mind, we should probably borrow your v3.0 -> schemars::Schema  to correctly implement the From<v3_0::Schema>, since it is rather involved.

FYI I intend to make a concrete proposal year in January at the latest. Agreed that 3.1 support would be great. I'm increasingly convinced that relying on schemars is the wrong approach due to its lack of support for the relevant JSON Schema draft and sporadic maintenance of the repo. Moving this repo may also be worth consideration.

If I can help pull things through I'm happy to lend a hand here. There are some great crates that currently can't support 3.1 because of the lack of support here.
@ahl Did a proposal ever end up being put forward?

FWIW to readers of this issue, the oas3 crate is specifically an OpenAPI v3.1 crate.


[Azure Communication Service] Refactor params of begin_reserve_phone_numbers

This is for the code in Azure:feature/communication branch, which targets to the Jan 2021 GA release.
Is your feature request related to a problem? Please describe.
We are planning to flatten the options param which is a  CreateSearchOptions type, into several positional params.
There are 6 params in CreateSearchOptions:
display_name, description, phone_plan_ids, area_code, quantity and location_options.
5 of these 6 params are mandatory all the time: display_name, description, phone_plan_ids, area_code, quantity
The only "optional" param is location_options: location_options is required when the provided phone_plan_ids are local phone plans. When the provided phone_plan_ids are toll-free, the location_options is not needed.
However 5 params is on the bench. Ideally, we want to have 3 positional params, and making the rest as optional params.
Describe the solution you'd like
Based on the discussion with @xiangyan99, we will decide if any of the required params can be assigned a default value.
Then refactoring the begin_reserve_phone_numbers function.
I will also check if any other function facing the same issue.

@HeliWang is this done?


fix for python 3.8 from microsoft store failing to add new venv

new versions of python >= 3.8 from the windows store have a different executable name (ie. python3.8.exe) in the registry InstallPath, compared to what is in the venv folder (python.exe) so search for both if interpExe is not found.
Fix #6082

also tested previous python 3.7 still works.


Add LOINC column to the supported disease-device table

Background
Our device table is a simplified version of the CDC's LIVD lookup table. One of the simplifications we've made is assuming that all tests performed on a device have the same LOINC code. It turns out this isn't true - a single device will have multiple "test performed" LOINC codes, usually one per disease tested. This hasn't been an issue in the past because we're not sending any results to states, but with the FHIR pilot we'll need to be more accurate about this test performed code.
The test performed code only matters to us during the ReportStream export. Therefore, rather than try to adjust our device model to support multiple LOINC codes (going from one-to-one to many-to-one) we'll simply track these LOINC codes separately, and reference them during the export. The simplest place to store the LOINCs is on our existing table for supported diseases/devices.
Action Requested
Add a column to the "Device Supported Disease" table to store the test performed LOINC code.
Acceptance Criteria
The device/supported disease join table has an additional column added for test performed LOINC code. This column is available at both the database and model level.
Backfilling the data will be covered by a separate ticket, as will using the data during export.
Additional Context
This work isn't directly FHIR related, but does need to be completed before we start sending flu/multiplex results to states. The test performed LOINC code is the only piece of data that most states use for identifying devices, so it's important for it to be accurate.

@zdeveloper FYSA - this is part one to what we discussed this morning


Implement generic Chisel module, remove multiplier, and Xilinx Vivado synthesis

@colinschmidt Pull request as we discussed today to keep bar up to sync on orthogonal changes.

As we discussed briefly today, I will tag the comments as TODOs in the code and merge.

Thanks for the review; merged. I added the discussion items to be tabled for the next meeting.


Remove KnockKnock

App not updated in over a year
Requires extensive permissions including full disk access
Sends lots of data to VirusTotal

Blockblock should be removed too.

Because BlockBlock utilizes Apple's new Endpoint Security Framework (to monitor for persistence), it requires system privileges.

@friadev Why are you pushing for these useful open source security tools to be removed if they work as intended? There is a disable VirusTotal integration in the settings.

Because ignoring recommended practices (keep your system simple) isn't what you want for an secure system.


Can anyone tell me how it can be integrated with Next js

I have implemented the manual start with my React project and it works fine. Now migrating to Next JS but I am not sure exactly how I should be implementing this or what could be the best practice for setting up GA4 with Next js

https://blog.andreizgirvaci.com/integrating-google-analytics-4-with-nextjs

@RangerCoder99 Thanks for mentioning my blog! 😊

@andrei-zgirvaci  Cool!


circuit.repeat(1) discards global phase

Information

Qiskit Terra version: master @ 4d3ed6a3
Python version: 3.7.9
Operating system: macOS catalina

What is the current behavior?
Calling circuit.repeat(1) on a circuit with global phase seems to discard the global phase.
Steps to reproduce the problem
If u is a circuit with only a Z gate and u_with_phase the same circuit but with a global phase of pi, then
In [75]: u.draw()
Out[75]:
     ┌───┐
q_0: ┤ Z ├
     └───┘

In [79]: u_with_phase.draw()
Out[79]:
global phase: π
     ┌───┐
q_0: ┤ Z ├
     └───┘

In [80]: Operator(u) == Operator(u_with_phase)  # should be False since the matrices are not the same
Out[80]: False

In [81]: Operator(u) == Operator(u_with_phase.power(1))  # should still be False
Out[81]: True

What is the expected behavior?
Suggested solutions

This is checking if the matrices are identical, which they are not due to the global phase. To test equivalence up to global phase try,
Operator(u).equiv(Operator(u_with_phase.power(1)))

This is checking if the matrices are identical, which they are not due to the global phase. To test equivalence up to global phase try,
Operator(u).equiv(Operator(u_with_phase.power(1)))

No but they are supposed to be identical, since power(1) shouldn't do anything. Especially in the phase estimation use case this is important because the circuits are first repeated and then controlled, so if we lose the global phase the circuits are not the same anymore, since the global phase became a relative phase 😄

No but they are supposed to be identical, since power(1) shouldn't do anything. Especially in the phase estimation use case this is important because the circuits are first repeated and then controlled, so if we lose the global phase the circuits are not the same anymore, since the global phase became a relative phase 😄

The circuit doesn't seem to lose the global phase.
qc2 = QuantumCircuit(1, global_phase=pi)
qc2.append(ZGate(), [0])
qc2p = qc2.power(1)
print(qc2p)
----
global phase: π
     ┌──────────┐
q_0: ┤ circuit1 ├
     └──────────┘

The circuit doesn't seem to lose the global phase.
qc2 = QuantumCircuit(1, global_phase=pi)
qc2.append(ZGate(), [0])
qc2p = qc2.power(1)
print(qc2p)
----
global phase: π
     ┌──────────┐
q_0: ┤ circuit1 ├
     └──────────┘

Ok, I realised the title is wrong. It should rather be circuit.repeat duplicated the global phase. See e.g. this:
In [11]: from qiskit.circuit.library import ZGate

In [12]: import numpy as np

In [13]: np.exp(-1j * 2) * ZGate().to_matrix()  # expected
Out[13]:
array([[-0.41614684-0.90929743j,  0.        -0.j        ],
       [ 0.        -0.j        ,  0.41614684+0.90929743j]])

In [15]: qc = QuantumCircuit(1, global_phase=2)

In [16]: qc.z(0)
Out[16]: <qiskit.circuit.instructionset.InstructionSet at 0x7f884140ba10>

In [17]: Operator(qc)
Out[17]:
Operator([[-0.41614684+0.90929743j,  0.        +0.j        ],
          [ 0.        +0.j        ,  0.41614684-0.90929743j]],
         input_dims=(2,), output_dims=(2,))

In [18]: Operator(qc.power(1))
Out[18]:
Operator([[-0.65364362-0.7568025j,  0.        +0.j       ],
          [ 0.        +0.j       ,  0.65364362+0.7568025j]],
         input_dims=(2,), output_dims=(2,))

In [19]: qc.power(1).global_phase
Out[19]: 2.0

while qc.power(1) (or repeat(1), they are the same if power is called with an integer) says it has a global phase of 2 it effectively has one of 4. I'll open a PR to fix it, there it should be more obvious. 🙂

Ok, I realised the title is wrong. It should rather be circuit.repeat duplicated the global phase. See e.g. this:
In [11]: from qiskit.circuit.library import ZGate

In [12]: import numpy as np

In [13]: np.exp(-1j * 2) * ZGate().to_matrix()  # expected
Out[13]:
array([[-0.41614684-0.90929743j,  0.        -0.j        ],
       [ 0.        -0.j        ,  0.41614684+0.90929743j]])

In [15]: qc = QuantumCircuit(1, global_phase=2)

In [16]: qc.z(0)
Out[16]: <qiskit.circuit.instructionset.InstructionSet at 0x7f884140ba10>

In [17]: Operator(qc)
Out[17]:
Operator([[-0.41614684+0.90929743j,  0.        +0.j        ],
          [ 0.        +0.j        ,  0.41614684-0.90929743j]],
         input_dims=(2,), output_dims=(2,))

In [18]: Operator(qc.power(1))
Out[18]:
Operator([[-0.65364362-0.7568025j,  0.        +0.j       ],
          [ 0.        +0.j       ,  0.65364362+0.7568025j]],
         input_dims=(2,), output_dims=(2,))

In [19]: qc.power(1).global_phase
Out[19]: 2.0

while qc.power(1) (or repeat(1), they are the same if power is called with an integer) says it has a global phase of 2 it effectively has one of 4. I'll open a PR to fix it, there it should be more obvious. 🙂

It seems like the the natural expectation of QuantumCircuit.repeat repeats the entire unitary, including the phase. For instance if you converted the circuit to a gate and repeated that you would get the same answer.

It seems like the the natural expectation of QuantumCircuit.repeat repeats the entire unitary, including the phase. For instance if you converted the circuit to a gate and repeated that you would get the same answer.

I agree it should repeat the global phase and in #5588 it still does. The problem right now is that it is repeated twice:

repeated.global_phase is set to repetitions * existing_phase
the repeated instructions themselves contain the existing_phase
therefore if you simulate a repeated circuit you end up with 2 * repetitions * existing_phase

I agree it should repeat the global phase and in #5588 it still does. The problem right now is that it is repeated twice:

repeated.global_phase is set to repetitions * existing_phase
the repeated instructions themselves contain the existing_phase
therefore if you simulate a repeated circuit you end up with 2 * repetitions * existing_phase

Yes, the global phase must not be included twice. But, doesn't it make sense to collect it in the outer circuit and remove it from the inner circuits ? Is there a standard approach to handling global phase when composing circuits ?

Yes, the global phase must not be included twice. But, doesn't it make sense to collect it in the outer circuit and remove it from the inner circuits ? Is there a standard approach to handling global phase when composing circuits ?

@Cryoris says that leaving the global phase in components in a circuit is currently standard. So this PR for this issue #5588 seems to be the correct approach. LGTM.

@Cryoris says that leaving the global phase in components in a circuit is currently standard. So this PR for this issue #5588 seems to be the correct approach. LGTM.

LGTM

LGTM


Launcher refactoring : FSJobCatalog

Adjusted some format.
Copied part of the SchedulerUtils to JobCatalogUtils for loading job configuration file from general file system. THESE parts of code could be adjusted and will be finalized when #1066 is merged.
Unit test is to be done with extending FSJobCatalog to be mutable.

Coverage decreased (-0.2%) to 46.31% when pulling a483fc77303a3ba8f4a16a8f6212bec58d75b9d0 on autumnust:fsjobcatalog into 89c70815b5c7df8eb4f27dafa70aa80721357c82 on linkedin:master.

Coverage decreased (-0.1%) to 46.39% when pulling a483fc77303a3ba8f4a16a8f6212bec58d75b9d0 on autumnust:fsjobcatalog into 89c70815b5c7df8eb4f27dafa70aa80721357c82 on linkedin:master.

Sent the design doc invitation. Can you take a look at ? @ibuenros @chavdar @vasanthrajamani

Changes Unknown when pulling 80056c732ac1fd28f41f03ee003664e563dd2de3 on autumnust:fsjobcatalog into ** on linkedin:master**.

Coverage increased (+0.3%) to 46.86% when pulling 52a1506162dec4b5b87fe30d5f11b81beaa582ca on autumnust:fsjobcatalog into 1dc980eec5969f4dfd75b808e5913c135c10538f on linkedin:master.


Run prometheus metrics into FeatureBase

Write an example that takes the prometheus metrics and run them into FeatureBase. Present a small graph example that can be used to write more examples.

Likely not needed with recent additions to the main repo.


[mm 15792] Fix massive app slowdown with many emojis

Summary
Please do not merge before rn-0.60 is merged, and it has not been tested on iOS yet, as rn-0.60 currently only involves Android Changes
This PR fixes the issue of having many gifs slowing the app down massively on Android, by replacing Fresco (An android image library that supports gif) with react-native-fast-image
Moreover, it removes redundant image caching logic in emoji.js since react-native-fast-image supports it out of the box (And shows empirically superior performance at least on Android)
Before this PR on Android (UI and JS Thread 5.5 FPS)

After this PR on Android (UI and JS Thread 50+ FPS and much faster gif rendering speed)

Ticket Link
mattermost/mattermost-server#11946
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] Added or updated unit tests (required for all new features)
[ ] All new/modified APIs include changes to mattermost-redux (please link)
[ ] Has UI changes
[ ] Includes text changes and localization file updates

Device Information
This PR was tested on: [Device name(s), OS version(s)]
Nexus 5X Simulator - Android - API 28

This issue has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!
/cc @jasonblais @hanzei

Hi @kdenz, thanks for your contribution! Let us know if you have any questions about the feedback above and we'd be happy to help :)

@migbot @saturninoabril ready for re-review

Build Apps for PR label detected. Will generate the app if build succeeds (checks pass and no conflicts with base branch).

@enahum I'm asking other QA team to help test this on Android device.

Build the App failed. See the logs for more information.

@lindy65 Here are the builds

https://releases.mattermost.com/mattermost-mobile-pr/build-pr-3209/Mattermost_Beta.apk
itms-services://?action=download-manifest&url=https://releases.mattermost.com/mattermost-mobile-pr/build-pr-3209/Mattermost_Beta.plist

Thanks @saturninoabril - I'll test now 👍


Allow binding mouse buttons to commands

I'd like to bind the side buttons on my mouse to navigate forward and backward. This behaviour is the default in web browsers and VS Code.
Currently Lapce doesn't allow binding mouse buttons to commands, so this is not possible.

It's already implemented

Ah OK - how do I bind mouseback and mouseforward to navigate backward and forward? The following does not work for me on master:
[[keymaps]]
command = "jump_location_forward"
mode = "i"
key = "mouseforward"

[[keymaps]]
command = "jump_location_backward"
mode = "i"
key = "mousebackward"

It's implemented in latest release, if it doesn't while building from source, it should be mentioned in https://github.com/lapce/lapce/issues/2417

I don't see it mentioned in #2417. I'm building the latest master from source.

(The idea is/was that features that were implemented in release but were missing from master would be added to #2417 to make it easier to track that we need to reimplement them)
I added it and also linked your PR. Thanks for reimplementing it, I was missing that feature.


Provide a firejail profile for mutt

This is part of hashbang/shell-etc#86.

Don't merge, profile should go in shell-etc.
See previous discussion.

Merge after https://github.com/hashbang/shell-etc/pull/102 is deployed

Seems straight forward enough and easy to revert if it ruins lives. +1

I think there is a permission problem.

Error: cannot open profile file /etc/firejail/mutt.profile.

4 -rw-r----- 1 root root  530 Aug 15 04:40 mutt.profile

@gmcclins Thanks, there indeed was an issue.  It is now fixed  :-)


Spelling pkg analyzer lib

This change is scoped to pkg/analyzer/lib with any files that happened to be changed in those commits per https://github.com/dart-lang/sdk/issues/50754, it's <60 files.
It's getting a bit hard for me to tease out pieces, but this should be pretty reviewable.

CL: https://dart-review.googlesource.com/c/sdk/+/277742


(maint) Generate .gemspec

Note that this drops the generated .gemspec in the root for parity with where .gemspec is found in actual ruby gem projects like puppet and hiera. This allows https://github.com/puppetlabs/puppet-agent/pull/345 to use consistent boilerplate for installing the gemspec for each of puppet/hiera/facter.

What does it do with the gemspec?

puppet-agent installs it to meet the needs of https://tickets.puppetlabs.com/browse/CPR-190.

I removed the executables line from .gemspec.in.

I'm fine with this.


small fixes to owners and readme

Sorted owners file.
Fixed typos in README and changes for more inclusive language.

/approve
/lgtm
thanks on the README fixed!

/approve

/approved
maybe?

/help

/unassign


CBMC memory safety proofs for selected entry points in FreeRTOS TCP/IP.

CBMC memory safety proofs for selected entry points in FreeRTOS TCP/IP.
Description
This commit adds the CBMC memory safety proofs to the FreeRTOS public repository.  All CBMC proofs are contained in a top-level cbmc directory added to the source tree.  Continuous integration will recheck these proofs with each commit and pull request.  Future proofs will go into this directory.
Checklist:
I have run the proofs against the lastest FreeRTOS commit and all proofs pass.

[ ] I have tested my changes. No regression in existing tests.
[ ] My code is Linted.

Hi Mark,
Every FreeRTOS+TCP socket consists of a part that is common to TCP and UDP, but also a type-specific part, which is expressed in a union:
	union
	{
		IPUDPSocket_t xUDP;
		IPTCPSocket_t xTCP;
	}
If you change that union into a struct. Is that only for the memory proofs, or is this a proposal to change the library?
The same about taking away the 'static' keyword in e.g. FreeRTOS_DHCP.c, is that for testing and proving only?
Hein

Hein, the CBMC patches are only for running the proofs, at least for the foreseeable future.

I have pushed a new commit that cleans up the patch directory.
The patches are only for testing by CBMC.
There are now just four patches.

One to remove static attributes from the functions under test.
One to change a union to a struct.  This deals with a CBMC issue being fixed now and should be removed soon.
One to change a minilistitem to a listitem.  This deals with a CBMC issue being fixed now and should be removed soon.
One refactoring prvCheckOptions into three functions to facilitate the CBMC proof.  This will be submitted as its own PR and should be removed soon.

Hi, this is great. Could we have some documentation with step by step what to install and how to run?

@sarenameas we're working on it, cheers. We had a discussion offline with @alexa-noxon about what documentation would be useful, and I recently merged #4299 and #4382 into CBMC to make it easier for Windows users to run these proofs.

We've just pushed some changes, hopefully these address everyone's suggestions. To make reviewing easier, here's what to focus on:

We've added a README describing how to install CBMC and run the proofs on your local machine.
We're no longer driving the proofs from a hand-written makefile, since this doesn't work on both Windows and Linux. Instead, we're generating the Makefiles. We can generate Makefiles both for Linux (to be used by the CI), and for Windows (for anybody wanting to run the proofs locally using NMake).

This python script generates a common Makefile from this template, containing generic rules for running all the proofs.
This python script generates Makefiles for each of the proofs, containing proof-specific definitions, including what assumptions we're making about the sizes of data structures etc. Those proof-specific Makefiles get generated from commented JSON files like this one. There is one JSON file for each proof. The prolog of the python script describes the JSON format.

The actual proofs (the .c and .h files) are unchanged since last time. We've moved the entire cbmc directory under tools.

/bot run checks

Thanks for moving into tools and updating the docs!


Manager should use primaries of Object attributes when saving

#24 When I try to save an entity having a field related to another table (using the @has.one.of clause) I get an Exception because my object is not a valid type.
Manager should check if the value is an object, and if so if the underlying class has a meta in order to use its primary value.
This in order to avoid painful temporary settings, like:
$temp = $entity->getUser();
$entity->setUser($temp->getId());
$manager->save($entity);
$entity->setUser($temp);

@shabbyrobe do you think this kind of request makes sense ?

Is this related to PR #24?

Yes it is! Sorry I'm not used to Github's issues and pull-requests.
Pierre LEMÉE
Développeur
http://www.pierrelemee.fr
(+33) <IP_ADDRESS>.40
2016-08-26 10:02 GMT+02:00 Blake Williams<EMAIL_ADDRESS>
Is this related to PR #24 https://github.com/shabbyrobe/amiss/pull/24?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/shabbyrobe/amiss/issues/23#issuecomment-242659490,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHB-QB1Mm-Bdf9AYs9yFNa46a3E300vHks5qjp17gaJpZM4JlzGB
.

No worries, @pierrelemee, I worked it out :)
Did you see my reply in the #24 thread?

Oh yes sorry! Let me answer there ;)


Update Fees page

What problem does your feature solve?
We currently have two separate pages that describe fees more conceptually (https://developers.stellar.org/docs/encyclopedia/fees-surge-pricing-fee-strategies, https://soroban.stellar.org/docs/soroban-internals/fees-and-metering). Would love to bring these sections together. Smart contract devs need to think about inclusion fees as well, so having the two sections separate can be more confusing.
What would you like to see?
One resource for fees to create a more cohesive developer experience.
What alternatives are there?
Keep the fees sections separate and link out to each one from the other.

Note to add content around inclusion fees with smart contract transactions (https://discord.com/channels/897514728459468821/966788672164855829/1219039688841494528)

PR: https://github.com/stellar/stellar-docs/pull/389


download not found

http://sdrsharp.com/downloads/sdr-install.zip
nof found
Were i can find windows installer ?

You don't need it to run this software. From the guide, only thing needed is the zadiag part. You don't need SDR#.


Uncaught Error: Cannot read property 'object' of undefinedTypeError: Cannot read property 'objec...

[Enter steps to reproduce:]

...
...

Atom: 1.17.0 x64
Electron: 1.3.15
OS: Unknown Windows version
Thrown From: Atom Core
Stack Trace
Uncaught Error: Cannot read property 'object' of undefined
TypeError: Cannot read property 'object' of undefined
at ObjectsRegistry.get (C:\Users\ASUS\AppData\Local\atom\app-1.17.0\resources\electron.asar\browser\objects-registry.js:41:28)
at EventEmitter. (C:\Users\ASUS\AppData\Local\atom\app-1.17.0\resources\electron.asar\browser\rpc-server.js:306:31)
at emitMany (events.js:127:13)
at EventEmitter.emit (events.js:201:7)
at WebContents. (C:\Users\ASUS\AppData\Local\atom\app-1.17.0\resources\electron.asar\browser\api\web-contents.js:222:13)
at emitTwo (events.js:106:13)
at WebContents.emit (events.js:191:7)
At C:\Users\ASUS\AppData\Local\atom\app-1.17.0\resources\electron.asar\renderer\api\remote.js:217

Error: Cannot read property 'object' of undefined
TypeError: Cannot read property 'object' of undefined
    at ObjectsRegistry.get (~/AppData/Local/atom/app-1.17.0/resources/electron.asar/browser/objects-registry.js:41:28)
    at EventEmitter.<anonymous> (~/AppData/Local/atom/app-1.17.0/resources/electron.asar/browser/rpc-server.js:306:31)
    at emitMany (events.js:127:13)
    at EventEmitter.emit (events.js:201:7)
    at WebContents.<anonymous> (~/AppData/Local/atom/app-1.17.0/resources/electron.asar/browser/api/web-contents.js:222:13)
    at emitTwo (events.js:106:13)
    at WebContents.emit (events.js:191:7)
    at metaToValue (~/AppData/Local/atom/app-1.17.0/resources/electron.asar/renderer/api/remote.js:217:13)
    at undefined.remoteMemberFunction (~/AppData/Local/atom/app-1.17.0/resources/electron.asar/renderer/api/remote.js:113:18)
    at AtomEnvironment.module.exports.AtomEnvironment.getWindowDimensions (~/AppData/Local/atom/app-1.17.0/resources/app/src/atom-environment.js:663:1)
    at AtomEnvironment.module.exports.AtomEnvironment.storeWindowDimensions (~/AppData/Local/atom/app-1.17.0/resources/app/src/atom-environment.js:697:1)
    at WindowEventHandler.module.exports.WindowEventHandler.handleWindowBlur (~/AppData/Local/atom/app-1.17.0/resources/app/src/window-event-handler.js:184:1)
    at ~/AppData/Local/atom/app-1.17.0/resources/app/src/window-event-handler.js:3:1

Commands
     -2:21.1.0 intentions:highlight (input.hidden-input)
     -2:20.7.0 core:cut (input.hidden-input)
     -2:20.3.0 intentions:highlight (input.hidden-input)
     -2:19.9.0 core:save (input.hidden-input)
  3x -2:18.7.0 core:backspace (input.hidden-input)
     -2:17.7.0 intentions:highlight (input.hidden-input)
     -2:17.6.0 core:save (input.hidden-input)
     -1:55.6.0 editor:newline (input.hidden-input)
     -1:55.4.0 intentions:highlight (input.hidden-input)
     -1:55.2.0 core:paste (input.hidden-input)
     -1:54.8.0 core:save (input.hidden-input)
     -0:59.3.0 editor:newline (input.hidden-input)
     -0:54.5.0 autocomplete-plus:confirm (input.hidden-input)
     -0:54.4.0 autocomplete-plus:activate (atom-text-editor.editor.is-focused)
     -0:51.7.0 intentions:highlight (input.hidden-input)
     -0:51.4.0 core:save (input.hidden-input)

Non-Core Packages
atom-beautify 0.29.24
autoclose-html 0.23.0
autocomplete-modules 1.6.10
busy-signal 1.4.1
color-picker 2.2.5
file-icons 2.1.5
hyperclick 0.0.40
intentions 1.1.2
js-hyperclick 1.11.0
linter 2.1.4
linter-ui-default 1.2.4
minimap 4.28.2

Thanks for taking the time to contribute!
We noticed that this is a duplicate of #11692. You may want to subscribe there for updates.
Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.
For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.


As PLAN admin need to be able to send someone a link that lets them sign in

This is for the case where they never receive the email message that they should receive when they return to their account after an absence of some time.

Try a link like https://plan.picolabs.io/c/ECI/query/io.picolabs.plan.apps/apps_rotate_eci.html


Miscellaneous updates

Codecov Report

Merging #1615 (2992d99) into master (7d8dde0) will decrease coverage by 0.31%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1615      +/-   ##
==========================================
- Coverage   85.26%   84.94%   -0.32%
==========================================
  Files          58       58
  Lines        2219     2219
  Branches      105      105
==========================================
- Hits         1892     1885       -7
- Misses        327      334       +7

Impacted Files
Coverage Δ

...re/shared/src/main/scala/io/circe/JsonNumber.scala
91.56% <0.00%> (-4.82%)
:arrow_down:

...re/shared/src/main/scala/io/circe/KeyDecoder.scala
97.29% <0.00%> (-2.71%)
:arrow_down:

...les/core/shared/src/main/scala/io/circe/Json.scala
79.32% <0.00%> (-2.24%)
:arrow_down:

...rc/main/scala/io/circe/numbers/BiggerDecimal.scala
84.79% <0.00%> (-0.59%)
:arrow_down:

.../core/shared/src/main/scala/io/circe/Decoder.scala
85.59% <0.00%> (+0.81%)
:arrow_up:

Continue to review full report at Codecov.

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


Logstash stop after few seconds

I'm trying to use the lastest version:
FROM logstash:2.4.0-1
WORKDIR /etc/logstash
COPY ./conf/logstash.conf ./conf.d
CMD ["logstash","agent","-f","/etc/logstash/conf.d/"]

With that conf
input {
    gelf {
        codec => "json"
    }
}
output {
    elasticsearch {
        hosts => "es:9200"
        index => "logs"
    }
}

after only few seconds of up,
root@4f4312c803c9:/etc/logstash# service logstash status
logstash is not running

if I start him again
root@4f4312c803c9:/etc/logstash# service logstash start
logstash started.
root@4f4312c803c9:/etc/logstash# service logstash status
logstash is running
[... 5 secondes ...]
root@4f4312c803c9:/etc/logstash# service logstash status
logstash is not running

All my logs in /var/logs/logstash/ are empty
If I try to launch logstash agent:
root@4f4312c803c9:/etc/logstash# logstash agent -f /etc/logstash/conf.d/
Settings: Default pipeline workers: 4
gelf listener died {:exception=>#<SocketError: bind: name or service not known>, :backtrace=>["org/jruby/ext/socket/RubyUDPSocket.java:160:in `bind'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-input-gelf-2.0.7/lib/logstash/inputs/gelf.rb:98:in `udp_listener'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-input-gelf-2.0.7/lib/logstash/inputs/gelf.rb:77:in `run'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-core-2.4.0-java/lib/logstash/pipeline.rb:342:in `inputworker'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-core-2.4.0-java/lib/logstash/pipeline.rb:336:in `start_input'"], :level=>:warn}
Pipeline main started
gelf listener died {:exception=>#<SocketError: bind: name or service not known>, :backtrace=>["org/jruby/ext/socket/RubyUDPSocket.java:160:in `bind'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-input-gelf-2.0.7/lib/logstash/inputs/gelf.rb:98:in `udp_listener'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-input-gelf-2.0.7/lib/logstash/inputs/gelf.rb:77:in `run'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-core-2.4.0-java/lib/logstash/pipeline.rb:342:in `inputworker'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-core-2.4.0-java/lib/logstash/pipeline.rb:336:in `start_input'"], :level=>:warn}
gelf listener died {:exception=>#<SocketError: bind: name or service not known>, :backtrace=>["org/jruby/ext/socket/RubyUDPSocket.java:160:in `bind'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-input-gelf-2.0.7/lib/logstash/inputs/gelf.rb:98:in `udp_listener'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-input-gelf-2.0.7/lib/logstash/inputs/gelf.rb:77:in `run'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-core-2.4.0-java/lib/logstash/pipeline.rb:342:in `inputworker'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-core-2.4.0-java/lib/logstash/pipeline.rb:336:in `start_input'"], :level=>:warn}
[...same line again and again...]

service status will not work in a container. There is no init system running.  The only process in the container is logstash.  In other words, if the container is up, logstash is running.
$ docker run -it --rm --name gelfling logstash -e 'input {
    gelf {
        codec => "plain"
    }
}
output {
    elasticsearch {
        hosts => "es.docker:9200"
        index => "logs"
    }
}'
Settings: Default pipeline workers: 8
Pipeline main started
...
$ # new terminal
$ docker exec -it gelfling bash
root@291f1e915dd8:/# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
logstash     1  3.6  1.1 5127240 362508 ?      Ssl+ 18:16   0:15 /usr/lib/jvm/java-8-openj
root        62  0.5  0.0  21948  3608 ?        Ss   18:23   0:00 bash
root        68  0.0  0.0  19188  2396 ?        R+   18:23   0:00 ps aux
root@291f1e915dd8:/#

I've not even test if logstash was working or not...
Many thanks for the answer!


feat: using client-side streaming and avoiding read lock to optimize raft message sending

Changes:

Use client-side streaming grpc to reduce raft send messages latency.
Raft worker get raft clients when init to avoid read lock when sending raft messages.

Summary:

Raft send messages latency gains barely nothing from client-side streaming grpc or avoiding read lock (Maybe the messages batch is small? Need metrics to further investigate).
Avoiding read lock benefits the serivce latency.

Ref: #126 .

main:

0635bb5 (worser?):

HEAD 401f29d:

A little relief: integration tests runs really faster than before (40s+ -> 30s-, 10s+ preparation included).

Thought twice, it seems that I used client-side streaming grpc in a wrong way. Try later.


Small change to AutoMPO syntax

An alternative syntax we could use for AutoMPO is the following:
ampo = AutoMPO(sites)
for j=1:N-1
  ampo += ("Sz",j,"Sz",j+1)
  ampo += (0.5,"S+",j,"S-",j+1)
  ampo += (0.5,"S-",j,"S+",j+1)
end

as opposed to:
ampo = AutoMPO(sites)
for j=1:N-1
  add!(ampo,"Sz",j,"Sz",j+1)
  add!(ampo,0.5,"S+",j,"S-",j+1)
  add!(ampo,0.5,"S-",j,"S+",j+1)
end

This would get use very close to the C++ syntax. It should just require overloading Base.:+(::AutoMPO,::Tuple).
@emstoudenmire, let me know what you think.

Unfortunately, using += requires allocating a new AutoMPO each time a new term is added, but I doubt that would be a bottleneck anywhere. To avoid the allocation we can also overload broadcasting and use .+=.

That's a great idea. Yes too bad about the reallocation though. It won't be a bottleneck for typical lattice models, but we have also used AutoMPO in the past for quantum chemistry Hamiltonians with many thousands of terms! So it might still be acceptable there, but for that case one might prefer .+= or add! to avoid that overhead.


cmd/go: cache results of exec.LookPath

What version of Go are you using (go version)?

$ go version
go version go1.13.6 windows/amd64

Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?

windows 10 64 bit version 1809
intel i5-8265U

go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\lidic\AppData\Local\go-build
set GOENV=C:\Users\lidic\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\lidic\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Go\src\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\lidic\AppData\Local\Temp\go-build756524190=/tmp/go-build -gno-record-gcc-switches
GOROOT/bin/go version: go version go1.13.6 windows/amd64
GOROOT/bin/go tool compile -V: compile version go1.13.6

What did you do?

Hi,
I followed the steps here after I installed Go. However, running go run hello.go takes around 10 - 20 seconds for it to output “hello, world”. Same thing with go build. I’ve also tried reinstalling and excluding my Go folder and Go temp folder from windows defender (the only antivirus I use). I've even disabled real time protection. How do I fix this? Any help is appreciated.
Thanks!
What did you expect to see?
I expect a hello world program to be compiled within seconds, other users are able to do so.
What did you see instead?
Takes 10-20 seconds to compile instead.

No. I am able to reproduce this behaviour on another PC that is also windows 10 with i7.

Mind to share the model and brand of your PC, how much free memory does it has?

The program in which the command time.exe go.exe run hello.go is executed (on win10 64-bit) might be factored out by running that command (time.exe referring to Quinlan's 9pm) in 9term.exe, cmd.exe and powershell.exe.

There was an earlier ticket regarding CRLF, and IIRC, PowerShell generates UTF-16 content, when running a go executable to output a string, and that is then redirected to a file.

 For me (with both workspace and Go installation whitelisted in Defender), it drops from
real    0m3.609s
user    0m0.015s
sys     0m0.000s

to
real    0m0.561s
user    0m0.000s
sys     0m0.000s

And that's on a M.2 drive with 3Gb/s read speed.

I'm experiencing slow successive builds too. Tried both 1.14.2 and 1.15rc2.
I've made sure my GOCACHE is set and excluded it from Windows Defender, among other directories like the Go installation and project directory. I don't think hardware is an issue because building the project within my WSL distro is quick as expected. Hell - it's quicker iteration for me to cross-compile to Windows from the WSL distro! 😅
This gave me the idea to try both binaries from the same environment:
$ uname -a
Linux Andrey 4.4.0-18362-Microsoft #836-Microsoft Mon May 05 16:04:00 PST 2020 x86_64 x86_64 x86_64 GNU/Linux

$ alias gowindows=/mnt/c/Users/Andrey/sdk/go1.14.2/bin/go.exe

$ alias golinux=/home/andrey/bin/go

$ gowindows version
go version go1.14.2 windows/amd64

$ golinux version
go version go1.14.2 linux/amd64

$ time gowindows build hello.go

real    0m5.237s
user    0m0.000s
sys     0m0.031s

$ time golinux build hello.go

real    0m0.402s
user    0m0.031s
sys     0m0.422s

For completeness the file contents are:
package main

import "fmt"

func main() {
        fmt.Println("hello")
}

Both installations were installed similarly - just unzipping the folder and adding a/b/c/go/bin to the system path. I even tried using the MSI installer but no dice.
Strangely it's not just go build that's slow:
$ time gowindows env >/dev/null

real    0m3.101s
user    0m0.000s
sys     0m0.000s

$ time golinux env >/dev/null

real    0m0.146s
user    0m0.016s
sys     0m0.172s

Something is definitely wrong but I can't find what.

Could the difference in build time be explained by the file system bridge that WSL uses?

Could the difference in build time be explained by the file system bridge that WSL uses?

Are you saying that since I'm accessing go.exe from the WSL side, that might be the cause for the slowness? I've also tried downloading Go for Windows onto the WSL distro and accessing it from there directly, and experience similar behavior, so I'm not sure if that's part of it.
One interesting thing I've noticed is when building with -x, there's a significant delay between when the WORK directory is printed and when the rest of the compilation commands are printed:
C:\Users\Andrey\Projects\Test> go build -x -ldflags=-v hello.go
WORK=C:\Users\Andrey\AppData\Local\Temp\go-build674494450
██████ significant delay here ██████
mkdir -p $WORK\b001\
cat >$WORK\b001\importcfg.link << 'EOF' # internal
packagefile command-line-arguments=C:\Users\Andrey\.cache\go\f1\f174f809fb722f16637244c56012840d3d558a2a2b7a0dc8d5cdcfd33fd35af1-d
packagefile fmt=C:\Users\Andrey\sdk\go1.14.2\pkg\windows_amd64\fmt.a
packagefile runtime=C:\Users\Andrey\sdk\go1.14.2\pkg\windows_amd64\runtime.a
...

I think I've narrowed it down to this code range just by playing around with build flags to cause fatal errors that failed quickly. https://github.com/golang/go/blob/go1.14.2/src/cmd/go/internal/work/exec.go#L98-L190
I've got no clue what any of this code does, but I hope I'll find it within myself to keep going and build Go from source with debug print statements to narrow down the slowness further, but I'm considering just working off the MacBook at this point lol

Are you saying that since I'm accessing go.exe from the WSL side, that might be the cause for the slowness?

That's my suggestion. I don't have a WSL host to verify, sorry.

One interesting thing I've noticed is when building with -x, there's a significant delay between when the WORK directory is printed and when the rest of the compilation commands are printed:

Maybe @bcmills can help debug that.
Alex

@andreykaipov as an experiment, can you move gowindows off the wsl filesystem?

I really appreciate the prompt replies!

@andreykaipov as an experiment, can you move gowindows off the wsl filesystem?

In my above example, gowindows was off the WSL filesystem. I was just invoking it from within WSL, but it's unfortunately the same behavior via Powershell on the Windows host.

 The first build took a couple seconds, and successive builds were very fast.
So, something must be wrong with OP's and my Win10 machines! I'm sure if I completely reinstall Windows 10, I'll achieve quick Go builds too, but I'm not up for that adventure yet. Once I have some more time I'll try to pinpoint where my misconfiguration is (will probably start by disabling some experimental Windows features). In any case, it might be worth keeping this issue open until someone finds the actual cause?

I'm with the same problem here, but I can remember exactly when it started, my code was running really fast, then at some time the visual studio go plugin asked me to install a bunch of "necessary" things, after that my compile time comes from < 1 sec to ~15 sec.

@tiagomac this issue has no resolution and relates to a version of go which is no longer supported.
In my experience, focused issues with clear reproduction steps are resolved faster and with a higher level of satisfaction. With that in mind would you please consider opening a new issue and providing as much information about your environment as possible.
Thank you

I'm using go 1.15.6 and this issue still exists on my computer.
$ go version
go version go1.15.6 windows/amd64

$ time go run main.go
real    0m4.986s
user    0m0.000s
sys     0m0.015s

main.go is just a hello world program.
This happened when I updated my go version from 1.15.5 to 1.15.6 the other day.

This happened when I updated my go version from 1.15.5 to 1.15.6 the other day.

Does it still occur?
When upgrading Go versions, all the cached compilation artifacts are now unused. As a result, everything must be compiled from scratch, which can be slow. Plus this will (eventually) result in a bunch of cache entries that have to get cleaned up, which is also slow.
Both of those should be one time effects, though, and things should return to being fast later.

Does it still occur?
When upgrading Go versions, all the cached compilation artifacts are now unused. As a result, everything must be compiled from scratch, which can be slow. Plus this will (eventually) result in a bunch of cache entries that have to get cleaned up, which is also slow.
Both of those should be one time effects, though, and things should return to being fast later.

Possibly related: https://github.com/golang/go/issues/38939

Possibly related: https://github.com/golang/go/issues/38939

@duguanyue can you try disconnecting the machine from the network so that is has no internet access, waiting 30s, and the running your hello world again? Is it still slow?

@duguanyue can you try disconnecting the machine from the network so that is has no internet access, waiting 30s, and the running your hello world again? Is it still slow?

Hi, I've spent a little while digging into this on my machine. It's hard to be sure we're having exactly the same problem, but my symptoms are go run <trivial go program> taking ~12 seconds to build, and even go env takes ~3 seconds to run.
I am not familiar with developing the go executable (it has quite a complex build process in terms of, I don't know how to step-by-step debug the go executable in an IDE 😞), but the build process is quite straight-forward, so I just added print statements with timing information and bisected the go env command.
I ended up tracking down the slowness to exec.Command, in particular, exec.LookPath. It seems common on Windows to havae a PATHEXT contain ~12 different executable file extensions, and a PATH variable commonly in excess of 30-50 entries (particularly for development machines!). This means that the worst case performance of LookPath is to check for executable files something like (12 * 50 = 600) times.
Digging into this a little deeper, it appears that on Windows (on my machine), os.Stat takes ~5us to get stats for a file that exists and ~380us to error when asked for stats on a file that does not exist. Combined with the above, this makes the worst case performance of exec.LookPath in the order of (600 paths to check * 380us per check = ~230ms) per invocation.
If you look at go env it attempts to invoke GCC in order to identify supported GCC arguments (or something like that). On my machine I don't have GCC installed, so this causes each attempted exec.Command call take >200ms.
If you consider the number of external processes that are invoked during the normal operation of go env or go run, etc., all of these several-hundred-millisecond calls add up.

Hi, I've spent a little while digging into this on my machine. It's hard to be sure we're having exactly the same problem, but my symptoms are go run <trivial go program> taking ~12 seconds to build, and even go env takes ~3 seconds to run.
I am not familiar with developing the go executable (it has quite a complex build process in terms of, I don't know how to step-by-step debug the go executable in an IDE 😞), but the build process is quite straight-forward, so I just added print statements with timing information and bisected the go env command.
I ended up tracking down the slowness to exec.Command, in particular, exec.LookPath. It seems common on Windows to havae a PATHEXT contain ~12 different executable file extensions, and a PATH variable commonly in excess of 30-50 entries (particularly for development machines!). This means that the worst case performance of LookPath is to check for executable files something like (12 * 50 = 600) times.
Digging into this a little deeper, it appears that on Windows (on my machine), os.Stat takes ~5us to get stats for a file that exists and ~380us to error when asked for stats on a file that does not exist. Combined with the above, this makes the worst case performance of exec.LookPath in the order of (600 paths to check * 380us per check = ~230ms) per invocation.
If you look at go env it attempts to invoke GCC in order to identify supported GCC arguments (or something like that). On my machine I don't have GCC installed, so this causes each attempted exec.Command call take >200ms.
If you consider the number of external processes that are invoked during the normal operation of go env or go run, etc., all of these several-hundred-millisecond calls add up.

@omaskery useful diagnosis, thanks!
cc @bcmills @jayconrod

@omaskery useful diagnosis, thanks!
cc @bcmills @jayconrod

I can't tell how directly this is related to the actual compilation process, however, as my attempts to print-debug the speed of the go executable didn't go as far as including invocations from within the go compiler itself.
All I can tell is that go run <basic program> still takes >10 seconds, and spends most of that time on external programs executing (not on exec.LookPath as with go env above, as invocations of explicit paths to binaries don't invoke LookPath).
I did make a bit of effort to try and understand the Go compiler enough to try and debug it, but couldn't fumble my way through it, I'm afraid. I can only hypothesise that there's a similar issue going on inside each Go compiler invocation, something about the way it invokes sub-processes, perhaps, or perhaps something else entirely.

I can't tell how directly this is related to the actual compilation process, however, as my attempts to print-debug the speed of the go executable didn't go as far as including invocations from within the go compiler itself.
All I can tell is that go run <basic program> still takes >10 seconds, and spends most of that time on external programs executing (not on exec.LookPath as with go env above, as invocations of explicit paths to binaries don't invoke LookPath).
I did make a bit of effort to try and understand the Go compiler enough to try and debug it, but couldn't fumble my way through it, I'm afraid. I can only hypothesise that there's a similar issue going on inside each Go compiler invocation, something about the way it invokes sub-processes, perhaps, or perhaps something else entirely.

@omaskery Thanks for doing the work of tracking this down.
Based on these numbers, it seems like it would be reasonable to try and cache exec.LookPath calls, so we don't repeatedly look for the C compiler. Note that we tried to do that in 1.15.7 to fix a security issue, but we ran into a regression (#43808) and had to revert part of that fix. A complete solution will need to be a bit more clever.
That said, it seems like os.Stat takes a surprisingly long time on your machine. I ran a quick benchmark on my Windows box:
BenchmarkStatExists-16             35599             32790 ns/op
BenchmarkStatMissing-16            31488             37484 ns/op
BenchmarkLookPathExists-16<PHONE_NUMBER> ns/op
BenchmarkLookPathMissing-16<PHONE_NUMBER>2 ns/op

On my machine, an os.Stat call for a missing file takes about 37us. That was with a pretty standard Windows 10 / NTFS installation with no antivirus other than Defender. Any idea what might cause it to be slower in your environment?

Now that is interesting! I'm afraid I have no idea what might be causing os.Stat to be slow on my machine specifically, though I'd be fascinated to find out. I'm not really sure how I'd investigate this, though - any advice?
The source code, compiler, IDEs, etc. are all on NVMe drives, so I don't think it's some kind of I/O latency. My RAM isn't full, so I don't think it's memory constrained. My CPU isn't maxed out, so I don't think it's CPU constrained. I've tried updating every driver I could get my hands on for my machine, wondering if it was some obscure driver issue for certain I/O operations, but that didn't help at all.
I do notice that on Linux the os.Stat command is very simple (presumably because it has a 1-1 mapping with the underlying APIs on Linux), whilst on Windows there are several underlying API calls it makes. I wonder which of those invocations is slow for me, and whether that will give us any hints? I might try copying the implementation of os.Stat and benchmarking bits of it, or something like that.

@omaskery I wish I knew what might cause this. I don't know enough about Windows internals to know what to look for though.
If you're running with NVMe drives, I expect you're running on more modern hardware than I am. I'd expect these microbenchmarks to mostly be bottlenecked on RAM speed, but since there's an order of magnitude difference, I'd be very surprised if it were anything hardware related.
So my uninformed guess is that this is something related to antivirus or some other system software that runs code when the file system is accessed.

@jayconrod good intuition!
I consulted a Wizard Friend of mine for help diagnosing what might be intercepting my IO, given I thought I had no antivirus installed (and I had tried disabling Windows Defender). They suggested I use Driver View and sent them the output, and they just validated the kernel drivers with their eyes and pointed me at all the suspect ones.
I ended up identifying Trusteer Endpoint Security from IBM as the cause!
My benchmark output for now:
NOTE: pathext contains 11 extensions
NOTE: path has 36 entries
goos: windows
goarch: amd64
pkg: golang-exec-slow-testbed
BenchmarkBuiltinUnknownCommand-12                                      	      31	  35757552 ns/op
BenchmarkBuiltinKnownCommand-12                                        	    1904	    550471 ns/op
BenchmarkLocalCopyWithUnknownCommand-12                                	      38	  32026726 ns/op
BenchmarkLocalCopyWithKnownCommand-12                                  	    2181	    533699 ns/op
BenchmarkFindExecutableWithExistingFileButNoExtensions-12              	  190474	      6452 ns/op
BenchmarkFindExecutableWithExistingFileWithSomeExtensions-12           	  184616	      6522 ns/op
BenchmarkFindExecutableWithExistingFileWithRealExtensions-12           	  187111	      6504 ns/op
BenchmarkFindExecutableWithNonExistingFileButNoExtensions-12           	   34681	     34688 ns/op
BenchmarkFindExecutableWithNonExistingFileWithSomeExtensions-12        	   10000	    106400 ns/op
BenchmarkFindExecutableWithNonExistingFileWithRealExtensions-12        	    3076	    386866 ns/op
BenchmarkFindExecutableOnExistingFileProportionalToPathLength-12       	    5217	    236151 ns/op
BenchmarkFindExecutableOnNonExistingFileProportionalToPathLength-12    	      85	  13894148 ns/op
BenchmarkStatOnExistingFile-12                                         	  173916	      6325 ns/op
BenchmarkStatOnNonExistingFile-12                                      	   34681	     34601 ns/op
PASS

My os.Stat benchmarks now look a lot like yours, ~35us!  Glad you were able to find the culprit. I think that's pretty strong evidence.
For cmd/go, I think the right way to handle this is still to cache results exec.LookPath. Even without antivirus, it's still a relatively expensive operation on Windows, and we should avoid repeating the work for each package.
I'll put this on the Go1.17 milestone. Not 100% sure we'll get to it, but it seems like low-hanging fruit as far as optimizations go.

@omaskery I wish I knew what might cause this. I don't know enough about Windows internals to know what to look for though.
If you're running with NVMe drives, I expect you're running on more modern hardware than I am. I'd expect these microbenchmarks to mostly be bottlenecked on RAM speed, but since there's an order of magnitude difference, I'd be very surprised if it were anything hardware related.
So my uninformed guess is that this is something related to antivirus or some other system software that runs code when the file system is accessed.

Awesome!. I close my antivirus and everything back to normal.

@jayconrod good intuition!
I consulted a Wizard Friend of mine for help diagnosing what might be intercepting my IO, given I thought I had no antivirus installed (and I had tried disabling Windows Defender). They suggested I use Driver View and sent them the output, and they just validated the kernel drivers with their eyes and pointed me at all the suspect ones.
I ended up identifying Trusteer Endpoint Security from IBM as the cause!
My benchmark output for now:
NOTE: pathext contains 11 extensions
NOTE: path has 36 entries
goos: windows
goarch: amd64
pkg: golang-exec-slow-testbed
BenchmarkBuiltinUnknownCommand-12                                      	      31	  35757552 ns/op
BenchmarkBuiltinKnownCommand-12                                        	    1904	    550471 ns/op
BenchmarkLocalCopyWithUnknownCommand-12                                	      38	  32026726 ns/op
BenchmarkLocalCopyWithKnownCommand-12                                  	    2181	    533699 ns/op
BenchmarkFindExecutableWithExistingFileButNoExtensions-12              	  190474	      6452 ns/op
BenchmarkFindExecutableWithExistingFileWithSomeExtensions-12           	  184616	      6522 ns/op
BenchmarkFindExecutableWithExistingFileWithRealExtensions-12           	  187111	      6504 ns/op
BenchmarkFindExecutableWithNonExistingFileButNoExtensions-12           	   34681	     34688 ns/op
BenchmarkFindExecutableWithNonExistingFileWithSomeExtensions-12        	   10000	    106400 ns/op
BenchmarkFindExecutableWithNonExistingFileWithRealExtensions-12        	    3076	    386866 ns/op
BenchmarkFindExecutableOnExistingFileProportionalToPathLength-12       	    5217	    236151 ns/op
BenchmarkFindExecutableOnNonExistingFileProportionalToPathLength-12    	      85	  13894148 ns/op
BenchmarkStatOnExistingFile-12                                         	  173916	      6325 ns/op
BenchmarkStatOnNonExistingFile-12                                      	   34681	     34601 ns/op
PASS

My os.Stat benchmarks now look a lot like yours, ~35us!
Edit: COMPILING GO (as in github.com/golang/go) NOW TAKES ABOUT A MINUTE! So exciting! :)
Is this enough evidence to suggest that these issues are just down to antivirus-like software intercepting IO and generally ruining things?

Can NOT believe it ! The antivirus software affects Golang 😧
I have the same problem. OS is macOS 11.2.3, Golang is go1.16, and even go run hello world (just main function and print simple string) took 2 minutes+, I debug this problem a long time , including changing the proxy settings .
When I disable Avira realtime protect, every thing be OK.

So will the new version have a fix on running Go with Antivirus enabled? Because on corporate machines the antivirus cannot be disabled which makes running Go applications a bit time consuming.

@bitwayiki This issue is the wrong place to discuss Go vs. Antivirus checkers.  Please use a forum.  See https://golang.org/wiki/Questions and https://golang.org/doc/faq#virus.  Thanks.

Hi @ianlancetaylor, can I work on this issue?

@ch33hau

Hi @ianlancetaylor, can I work on this issue?

Thanks for offering.  That is a question for @jayconrod.  I don't know if there are any plans for this already in progress.

@ch33hau Sure, you're welcome to take a look. I don't think anyone's actively working on this.
The simplest thing is probably to wrap calls to exec.Command and exec.LookPath from cmd/go/internal/work with something that caches the lookup. So we'd only directly call exec.Command with an absolute path after that.
We use cmd/go/internal/par.Cache for caching operations like this that could be performed concurrently, which may be the case here.

Hi @ianlancetaylor @jayconrod, thank you for the replies and tips, I am glad to hear this!

I have a counter proposal to solve the original issue: make exec.LookPath faster. The most important performance problem in exec.LookPath seems to be that it calls os.Stat on every file candidate to know if it exist. os.Stat will internally call syscall.GetFileAttributesEx and syscall.CreateFile for each non-existan fail, which is slow. We could replace os.Stat by a simpler syscall.GetFileAttributes, as we really only need to know if the file exists and that it is not a directory. There would be two behavior differences:

syscall.GetFileAttributes will fail with protected system files like C:\pagefile.sys, while os.Stat wouldn't. This is a no-issue because those files are not executable anyway.
os.Stat detects broken reparse points, while the new approach would not. Therefore os.LookPath could return a path that points to a broken link. Symbolic links are not common in Windows, broken symbolic links are even harder to see, I don't even know how to get one, so a nice speed bump could justify not covering this edge case.

The code could look like this:
func chkStat(file string) error {
	p, err := syscall.UTF16PtrFromString(file)
	if err != nil {
		return &os.PathError{Op: "Stat", Path: file, Err: err}
	}
	a, err := syscall.GetFileAttributes(p)
	if err != nil {
		return &os.PathError{Op: "GetFileAttributes", Path: file, Err: err}
	}
	if a&syscall.FILE_ATTRIBUTE_DIRECTORY != 0 {
		return fs.ErrPermission
	}
	return nil
}

This change makes exec.LookPath twice as fast in my computer when looking for a not existing binary:
goos: windows
goarch: amd64
pkg: os/exec
cpu: Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz
            │   old.txt    │               new.txt                │
            │    sec/op    │    sec/op     vs base                │
LookPath-12   8.815m ± 18%   4.275m ± 12%  -51.50% (p=0.000 n=10)

            │   old.txt    │               new.txt               │
            │     B/op     │     B/op      vs base               │
LookPath-12   95.72Ki ± 0%   95.61Ki ± 0%  -0.11% (p=0.000 n=10)

            │  old.txt   │              new.txt              │
            │ allocs/op  │ allocs/op   vs base               │
LookPath-12   891.0 ± 0%   890.0 ± 0%  -0.11% (p=0.000 n=10)

@bcmills CL 511458 is ready for review, Can you remove Hold.

I'm reverting CL 512155, which mentions this issue; see https://go.dev/cl/527337 for more information.  As far as I can tell, that reversion does not affect this issue directly.  Please let us know if that is not the case.  Thanks.

I am the author of CL 512155, and I remember that without this CL, on Windows, exec.LookPath would be called once regardless. This means that on Windows, this issue has not been resolved because the actual cached result is not being used, which is approximately equivalent to no cache.

Now discovering this thread - kudos to @omaskery and @jayconrod for the investigation above :)
@qmuntal I think your suggestion in https://github.com/golang/go/issues/36768#issuecomment-1645764124 sounds reasonable - given that this issue is now solved, perhaps raise a new issue so that it doesn't get lost. You could also raise a CL at the same time, although it's easier for a CL to get lost when there's no issue to track it with.

CL 528038 after ,Is there any reason not to close this issue?

Agreed, this is now done.


revalidate() throws an error due to null / undefined module.constructor._pathCache

Describe the bug
When running this code on an interval, with a dynamically loaded remote, on change of the remote an error occurs.
const shouldReload = await revalidate();
Here is the loading code:
init({
  name: 'app1',
  remotes: [
    {
      name: 'app2',
      entry: 'http://localhost:3002/remoteEntry.js',
    },
  ],
});

loadRemote('app2/sample').then(sample => {
  console.log('loaded sample', sample);
});

!!! NOTE: the repo with the reproduction needs to have the postinstall script commented out to view this problem. I have included a version of the file which gets around the undefined issue in hot-reload.js, but additionally I never see subsequent updates after the first one even after the tweak.
Error:

app2 hash is different - must hot reload server
webpack:///../node_modules/.pnpm/@module-federation+node@2.6.0_react-dom@18.3.1_react@18.3.1__react@18.3.1_typescript@5.6.3_we_ywys2crjpz7nqmzdfk3rsbxv3i/node_modules/@module-federation/node/dist/src/utils/hot-reload.js?:71
Object.keys(module.constructor._pathCache).forEach(function (cacheKey) {
^
TypeError: Cannot convert undefined or null to object
at Function.keys ()
at decache (webpack:///../node_modules/.pnpm/@module-federation+node@2.6.0_react-dom@18.3.1_react@18.3.1__react@18.3.1_typescript@5.6.3_we_ywys2crjpz7nqmzdfk3rsbxv3i/node_modules/@module-federation/node/dist/src/utils/hot-reload.js?:71:12)
at eval (webpack:///../node_modules/.pnpm/@module-federation+node@2.6.0_react-dom@18.3.1_react@18.3.1__react@18.3.1_typescript@5.6.3_we_ywys2crjpz7nqmzdfk3rsbxv3i/node_modules/@module-federation/node/dist/src/utils/hot-reload.js?:122:17)
at Array.forEach ()
at performReload (webpack:///../node_modules/.pnpm/@module-federation+node@2.6.0_react-dom@18.3.1_react@18.3.1__react@18.3.1_typescript@5.6.3_we_ywys2crjpz7nqmzdfk3rsbxv3i/node_modules/@module-federation/node/dist/src/utils/hot-reload.js?:120:32)
at eval (webpack:///../node_modules/.pnpm/@module-federation+node@2.6.0_react-dom@18.3.1_react@18.3.1__react@18.3.1_typescript@5.6.3_we_ywys2crjpz7nqmzdfk3rsbxv3i/node_modules/@module-federation/node/dist/src/utils/hot-reload.js?:273:42)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async Timeout.eval [as _onTimeout] (webpack:///./index.js?:36:24)
Node.js v20.12.0

Reproduction
https://github.com/arimus/dynamic-remotes-node
Used Package Manager
pnpm
System Info
System:
    OS: macOS 14.4
    CPU: (10) x64 Apple M1 Pro
    Memory: 77.57 MB / 16.00 GB
    Shell: 5.2.21 - /opt/homebrew/bin/bash
  Binaries:
    Node: 20.12.0 - ~/.nvm/versions/node/v20.12.0/bin/node
    npm: 10.5.0 - ~/.nvm/versions/node/v20.12.0/bin/npm
    pnpm: 9.11.0 - ~/Library/pnpm/pnpm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Browsers:
    Chrome: 130.0.6723.60
    Chrome Canary: 132.0.6795.0
    Edge: 130.0.2849.52
    Safari: 17.4
    Safari Technology Preview: 17.4

Validations

[X] Read the docs.
[X] Read the common issues list.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Module federation issue and not a framework-specific issue.
[X] The provided reproduction is a minimal reproducible example of the bug.

okay, i found a issue in mine, opened PR to fix it.
That said, the reason you are not reloading (i think) is because you never re-require the entrypoint / app itself.
How it works in general is deletes require cache, then you re-require the entrypoint and webpack runtime restarts itself.
In your source, i do not see anything where you require('./dist/main.js') again in node.js etc. So the runtime still has the modules in it because the server did not release and load its entry file again

@ScriptedAlchemy thanks for the quick fix!
Isn't that accomplished through the loadRemote()? This fetches the initial remote fine and I can see it using the remote code. That said, I do see the "reloaded sample" get triggered, although it does not appear to be updated code.
Are you saying that I need to use an actual require() instead of the loadRemote()?
setInterval(async () => {
  console.log('host(): checking for updates');

  // determine if there is a change that requires a reload
  const shouldReload = await revalidate();

  if (shouldReload) {
    // reload the server <---- HERE ---->
    loadRemote('app2/sample').then(sample => {
      console.log('reloaded sample:', sample);
    });
  }
}, 3000);

p.s. I'm in discord if you want to walk through anything in particular. Hoping that once I have this example working properly, we can get it merged into the examples project as another example.

Whats your discord handle? or add me as friend

Ahh you are right, since its dynamic the host does not need to be released.
Heres whats happening. You did not re-init etc again. So the instance factories are cleared.
You need to init again.

Ah, so it is the init that need to happen again. Makes sense...I think ;)
arimus is my nickname (arimus00 is my discord)
I updated the example to use the new release and confirmed it no longer barfs. Thanks!