BUG: L-BFGS-B has surprisingly high memory consumption

Describe your issue.
As observed in https://github.com/scikit-learn/scikit-learn/issues/17125, it seems that L-BFGS-B has a surprisingly high memory usage.
Exploration made a while back shows that it is mainly the case managing the bounds in _minimize_lbfgsb
Especially, the allocation of the wa array is costly.
Reproducing Code Example
Modifying the code using memory_profiler, for:
    from guppy import hpy; hp=hpy()
    print("In LBFGS")
    print(hp.heap())

    _check_unknown_options(unknown_options)
    m = maxcor
    epsilon = eps
    pgtol = gtol
    factr = ftol / np.finfo(float).eps

    x0 = asarray(x0).ravel()
    n, = x0.shape

    print("Before defining bounds")
    print(hp.heap())

    if bounds is None:
        bounds = [(None, None)] * n
    if len(bounds) != n:
        raise ValueError('length of x0 != length of bounds')
    # unbounded variables must use None, not +-inf, for optimizer to work properly
    bounds = [(None if l == -np.inf else l, None if u == np.inf else u) for l, u in bounds]

    print("After defining bounds")
    print(hp.heap())
    print("Number of bounds", len(bounds))

In LBFGS
Partition of a set of 249017 objects. Total size = 57602504 bytes.
 Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
     0    135   0 22872454  40  22872454  40 numpy.ndarray
     1  70473  28 12325724  21  35198178  61 str
     2  57218  23  4354288   8  39552466  69 tuple
     3  17052   7  3019018   5  42571484  74 types.CodeType
     4  33976  14  2908817   5  45480301  79 bytes
     5  16275   7  2213400   4  47693701  83 function
     6   2096   1  2031240   4  49724941  86 type
     7    832   0  1403016   2  51127957  89 dict of module
     8   3641   1  1362584   2  52490541  91 dict (no owner)
     9   2096   1  1048960   2  53539501  93 dict of type
<715 more rows. Type e.g. '_.more' to view.>
Before defining bounds
Partition of a set of 249032 objects. Total size = 57603590 bytes.
 Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
     0    136   0 22872550  40  22872550  40 numpy.ndarray
     1  70473  28 12325724  21  35198274  61 str
     2  57218  23  4354288   8  39552562  69 tuple
     3  17052   7  3019404   5  42571966  74 types.CodeType
     4  33976  14  2908817   5  45480783  79 bytes
     5  16275   7  2213400   4  47694183  83 function
     6   2096   1  2031240   4  49725423  86 type
     7    832   0  1403016   2  51128439  89 dict of module
     8   3641   1  1362584   2  52491023  91 dict (no owner)
     9   2096   1  1048960   2  53539983  93 dict of type
<715 more rows. Type e.g. '_.more' to view.>
After defining bounds
Partition of a set of 2851193 objects. Total size = 225641329 bytes.
 Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
     0 2659378  93 150075248  67 150075248  67 tuple
     1    136   0 22872550  10 172947798  77 numpy.ndarray
     2   1585   0 22550168  10 195497966  87 list
     3  70473   2 12325724   5 207823690  92 str
     4  17052   1  3019791   1 210843481  93 types.CodeType
     5  33976   1  2908817   1 213752298  95 bytes
     6  16275   1  2213400   1 215965698  96 function
     7   2096   0  2031240   1 217996938  97 type
     8    832   0  1403016   1 219399954  97 dict of module
     9   3641   0  1362584   1 220762538  98 dict (no owner)
<715 more rows. Type e.g. '_.more' to view.>
Number of bounds 2602160

where bounds is actually a list of pair of None.
Error message
None.

SciPy/NumPy/Python version and system information
Build Dependencies:
  blas:
    detection method: pkgconfig
    found: true
    include directory:
    lib directory:
    name: blas
    openblas configuration: unknown
    pc file directory:
    version: 3.9.0
  lapack:
    detection method: pkgconfig
    found: true
    include directory:
    lib directory:
    name: lapack
    openblas configuration: unknown
    pc file directory:
    version: 3.9.0
  pybind11:
    detection method: pkgconfig
    include directory:
    name: pybind11
    version: 2.10.4
Compilers:
  c:
    commands: x86_64-conda-linux-gnu-cc
    linker: ld.bfd
    name: gcc
    version: 12.3.0
  c++:
    commands: x86_64-conda-linux-gnu-c++
    linker: ld.bfd
    name: gcc
    version: 12.3.0
  cython:
    commands: cython
    linker: cython
    name: cython
    version: 0.29.35
  fortran:
    commands: x86_64-conda-linux-gnu-gfortran
    linker: ld.bfd
    name: gcc
    version: 12.3.0
  pythran:
    include directory:
    version: 0.13.1
Machine Information:
  build:
    cpu: x86_64
    endian: little
    family: x86_64
    system: linux
  cross-compiled: false
  host:
    cpu: x86_64
    endian: little
    family: x86_64
    system: linux
Python Information:
  path: python
  version: '3.11'

Looking at the code I'd expect the size of the wa array to grow proportionally with the problem size, n. What is the problem size that is causing the issue?

Hi Andrew,
I do not have time to dive into this, more context is given in https://github.com/scikit-learn/scikit-learn/issues/17125.

We may be able to reduce memory taken up by various bounds arrays.


fix: current year in footer

Problem
Current year in the footer was hardcoded to 2023 through a CURR_YEAR constant, which meant it would only update when someone updated that constant every year.
Changes Made

Used javascript's in-built new Date().getFullYear() to replace the hardcoded year in the footer.
Also removed the import of that constant in the same file.

Initially i wanted to change the CURR_YEAR constant itself to new Date().getFullYear() but i didn't end up doing that as that may break some functionality in src/pages/Wrapped/Wrapped.js
Screenshots
Before

After

I ended up just updating the CURR_YEAR constant to 2024. Thanks for the feedback!


Add missing Foundation.h import to generated Objective-C code

@yulin-liang This #import is needed when using GPB_GRPC_PROTOCOL_ONLY

The broken python test is a known issue: #23028
But the  followingSanity Checks issue need to be fixed:
--- /var/local/git/grpc/src/compiler/objective_c_plugin.cc	2020-09-02 02:22:06.645932000 +0000
+++ /tmp/tmp.6NdgNUgqw9	2020-09-02 02:26:15.509932000 +0000
@@ -236,8 +236,7 @@
       }

       Write(context, file_name + ".pbrpc.h",
-            file_header +
-                SystemImport("Foundation/Foundation.h") + "\n" +
+            file_header + SystemImport("Foundation/Foundation.h") + "\n" +
                 PreprocIfNot(kForwardDeclare, imports) + "\n" +
                 PreprocIfNot(kProtocolOnly, system_imports) + "\n" +
                 class_declarations + "\n" +

Amending this commit was difficult because it was pushed to the master branch, so I've created a new PR: https://github.com/grpc/grpc/pull/24049


[Issue 1422] Runtime config

References

Fixes #1422

Description
App configuration defined at runtime to afford distribution portability and developer convenience. Provide injectable configuration. All configurations are now able to be set via environment variables (see README). The configuration file is now able to be externalized.
Instructions for Reviewers
In order to accomplish runtime config, the server has to build and host the configuration on start. The same configuration is then used by the server for SSR and by the UI in the browser. For the browser, the configuration must be provided on app initialization or before app module bootstrap
The configuration can then be used via injection
@Injectable(APP_CONFIG) appConfig: AppConfig

or by continued use of the environment object
import { environment } from '../environments/environment';

Caveats and Complications

Angular environment files now define initial required configuration for development and production
a. these files should not change anymore
b. if need additional environment can create additional build configurations and environment files
Angular CLI ng serve hosts assets directly from src/assets
a. this requires the appConfig.json file be created under that directory
b. file added to .gitignore
Many Cypress tests fail when asynchronously fetching configuration before bootstrapping app module
a. unknown reasons and avoided changes to test
b. led to better approach of passing config via transfer state for SSR
CSR does not supply config in transfer state
a. conditionally on environment production variable fetch configure before bootstrapping app module
Use of environment on root of JavaScript (runs immediately)
a. the one case has been moved to a function call in a config utility to access environment when called
b. should be avoided in further development
Environment imported and used outside of injection context (able to inject in constructor)
a. would require significant design changes to hoist to an injection context
b. primary culprit is the request model
c. requires to continue use environment until redesigned
d. should be avoided in further development
Must extend environment with app config either via asynchronously fetching before bootstrap or passing through transfer state between server  and browser
a. must be done before any access to environment object
b. accomplished by either fetching before bootstrap or by using promise in app initialization

List of changes in this PR:

Build app config at runtime
Remove build time environment scripting
Use Angular CLI fileReplacements for Angular environment files (standard use)
Provide AppConfig via APP_CONFIG injection token
Extend environment object before/during app initialization
Update readme and configuration documentation

The primary place in code where environment is used before being extended with app config is main.browser.ts. This is unavoidable and acceptable as the environment files are no longer configurable and now should be considered as code (ts files and all).

Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

[x] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
[x] My PR passes TSLint validation using yarn run lint
[x] My PR doesn't introduce circular dependencies
[ ] My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
[ ] My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
[x] If my PR includes new, third-party dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.

Thanks for this PR, @wwelling . Does this now allow for building one artifact and using it in dev, QA, and Prod... only needing to change the config for each environment? If so, this is essential.

@awoods that is correct. This will allow a built distribution to apply local configurations, external configurations, and/or environment variables at runtime. One docker image can be used between all environments.

We can easily use js-yaml to switch to YAML config file.
import * as yaml from 'js-yaml';
const config = yaml.load(externalConfig)

production: true
ui:
  ssl: false
  host: localhost
  port: 4000
  nameSpace: /
  rateLimiter:
    windowMs: 60000
    max: 500
  baseUrl: http://localhost:4000/
rest:
  ssl: true
  host: api7.dspace.org
  port: 443
  nameSpace: /server
  baseUrl: https://api7.dspace.org/server
cache:
  msToLive:
    default: 900000
  control: max-age=60
  autoSync:
    defaultTime: 0
    maxBufferSize: 100
    timePerMethod:
      PATCH: 3
auth:
  ui:
    timeUntilIdle: 900000
    idleGracePeriod: 300000
  rest:
    timeLeftBeforeTokenRefresh: 120000
form:
  validatorMap:
    required: required
    regex: pattern
notifications:
  rtl: false
  position:
    - top
    - right
  maxStack: 8
  timeOut: 5000
  clickToClose: true
  animate: scale
submission:
  autosave:
    metadata: []
    timer: 0
  icons:
    metadata:
      - name: dc.author
        style: fas fa-user
      - name: default
        style: ''
    authority:
      confidence:
        - value: 600
          style: text-success
        - value: 500
          style: text-info
        - value: 400
          style: text-warning
        - value: default
          style: text-muted
universal:
  preboot: true
  async: true
  time: false
debug: false
defaultLanguage: en
languages:
  - code: en
    label: English
    active: true
  - code: cs
    label: Čeština
    active: true
  - code: de
    label: Deutsch
    active: true
  - code: es
    label: Español
    active: true
  - code: fr
    label: Français
    active: true
  - code: lv
    label: Latviešu
    active: true
  - code: hu
    label: Magyar
    active: true
  - code: nl
    label: Nederlands
    active: true
  - code: pt-PT
    label: Português
    active: true
  - code: pt-BR
    label: Português do Brasil
    active: true
  - code: fi
    label: Suomi
    active: true
browseBy:
  oneYearLimit: 10
  fiveYearLimit: 30
  defaultLowerLimit: 1900
  types:
    - id: title
      type: title
    - id: dateissued
      type: date
      metadataField: dc.date.issued
    - id: author
      type: metadata
    - id: subject
      type: metadata
item:
  edit:
    undoTimeout: 10000
collection:
  edit:
    undoTimeout: 10000
themes:
  - name: dspace
mediaViewer:
  image: false
  video: false

Not sure why the single spec failed on node 12.x but not on 14.x. This is certainly a retry situation.

@wwelling : Just an FYI, this has merge conflicts now, likely because we just merged this PR https://github.com/DSpace/dspace-angular/pull/1428 and it adds new settings to the environment.common.ts (which will need migrating to the new YAML format).  Apologies, but this is the only PR (that I'm currently aware of) which makes changes to environment.common.ts

The build and the start have been mostly decoupled now. The environment file used only during build will only specify whether to enable production mode enableProdMode() and universal server settings. The start of the application now uses the commonly used node environment variable NODE_ENV to specify which mode to run the distribution in.
yarn build:prod
set NODE_ENV=prod
yarn serve:ssr

@wwelling : I'm a little worried about requiring users to remember to set NODE_ENV=production for production behavior, even if that's how it's "commonly done". It seems dangerous to default this to development for DSpace. Is there any way to default NODE_ENV to production for DSpace?

We can default to production but not sure if that is appropriate. I think we should try to determine a best practice. Unless we just want to say this is a DSpace best practice. The package.json scripts have already been cleaned up. The only one referring to dev is running dev server with Angular CLI yarn start:dev.

@tdonohue I will gladly default it to production. That is not a problem. As development is usually run using yarn start:dev I think we are developer friendly enough. I will also update the scripts to specify the appropriate NODE_ENV.

@tdonohue set to default to production if running distribution, node dist/server/main. Also, added NODE_ENV to yarn serve:ssr to be explicit running in production. And last but not least added headTags to dspace them in config.example.yml

@wwelling : Apologies, looks like I created another small merge conflict in this PR after merging #1468 -- that PR removes the browseBy.types settings from environment.*.ts (as they are now determined dynamically from the backend).  So, the merge conflict resolution will involve removing those settings from the new config setup here.

@tdonohue no problem. Merged in main and resolved conflicts.

Thanks @artlowel.


Fixed JIRA RESTEASY-1323.

https://issues.jboss.org/browse/RESTEASY-1323

This pull request and #755 both fix RESTEASY-1323. Now, who wants to write a unit test?

Please review my test case. Thanks.

Thanks, Ruiqiang. This PR is ready to merge.


printer-commands ipp attribute in get-printer-attributes response contains 'Clean' for laser printers

Hi,
I found during investigation for https://github.com/OpenPrinting/system-config-printer/issues/50 that CUPS defines printer-command 'Clean' for laser printers when the uri contains MDNS address like:
ipp://HP%20LaserJet%20M1536dnf%20MFP%20(42307C)._ipp._tcp.local/
or when the uri is the same as in CUPS:
ipp://:631/printers/
The device is laser printer so 'Clean' command can't be available.
But when device uri is defined as:
ipp://<device_address>:631/ipp/print
printer-command atttribute contains 'none'.

The commands come from the PPD (cupsCommands), so please forward this to the project corresponding to the PPD...


Adjusted the position of eye icon.

Resolving the issue #123 and #274.

Thanks for contributing @Prabhroop-Singh2002 :)


User polls

The home page should have user polls on it about character balancing and so on.

I still think this is a good idea and perhaps even crucial in the long run, but having resigned myself to the necessity of a Discord group during alpha/beta, that will probably be the better medium for polling the community.


Support # in links

Search Terms
link, member
Problem
JSDoc and JavaDoc use # to refer to instance methods and fields of a class (e.g. Class#method) while . is used for static methods and fields (e.g. Class.staticField).
TypeDoc does not support this. Even worse, TypeDoc doesn't even error or warn when encountering such links.

(input code, referenced method)
Suggested Solution
Support #. TypeDoc doesn't really differentiate between static and instance members right now, so treating # as a . should work.

Also, is it a bug that invalid links are just printed as is? Shouldn't there be a warning since it's an invalid reference?

Shouldn't there be a warning since it's an invalid reference?

There is, if you turn on listInvalidSymbolLinks
Semi-dupe of #488


chore: add node16 support

Address: https://github.com/clinicjs/node-clinic/issues/295

CI is failing badly :(

Yes, actually, this will be more complex than I was imagining. There are some incompatibilities between the tap version and the nodejs as well.
Just for reference:
# using v14
npx<EMAIL_ADDRESS>./test/cmd-collect.test.js

# success

# using v14
npx<EMAIL_ADDRESS>./test/cmd-collect.test.js

# assert fail

# using v16
npx<EMAIL_ADDRESS>./test/cmd-collect.test.js

# assert fail

# using v16
npx<EMAIL_ADDRESS>./test/cmd-collect.test.js

# assert fail

I'll complete the support over other packages (heapprofile, doctor) and come back to this one that will require more time to fix.
cc: @simoneb

@RafaelGSS I'm not aware of issues between tap and Node.js. I trust you have more context than I do, but I'm mentioning just to make sure you avoid going down a rabbit hole as the issue may be something else

@RafaelGSS I'm not aware of issues between tap and Node.js. I trust you have more context than I do, but I'm mentioning just to make sure you avoid going down a rabbit hole as the issue may be something else

Sure thing. I'll look at it with calm and share my thoughts before any work to align with you.

I had a quick look at the failures and they seem legitimate failures, meaning failing assertions because 2 !== 3

one more reason why this doesn't look like a node.js version thing is that it's failing on all node versions

one more reason why this doesn't look like a node.js version thing is that it's failing on all node versions

actually, it's working fine on v14 + tap@14

Well, I did some adjusts for v16+, and looks good so far in my local tests. There is an important diff between those node versions as looks like it was expected by a quick talk that I had with @mcollina.
Just for reference, look at the following snippet:
const fs = require('fs')
const asyncHooks = require('async_hooks')

const filename = `test-${process.version}.txt`
const out = fs.createWriteStream(filename, {
  fd: fs.openSync(filename, 'w')
})

exports.skipThis = false
const skipAsyncIds = new Set()
const hook = asyncHooks.createHook({
  init (asyncId, type, triggerAsyncId) {
    // Save the asyncId such nested async operations can be skiped later.
    if (exports.skipThis) return skipAsyncIds.add(asyncId)
    // This is a nested async operations, skip this and track futher nested
    // async operations.
    if (skipAsyncIds.has(triggerAsyncId)) return skipAsyncIds.add(asyncId)

    // Track async events that comes from this async operation
    exports.skipThis = true
    console.trace('Writing...')
    exports.skipThis = false
  },
})
hook.enable()

setTimeout(() => {}, 200)

on v16 the fs.createWriteStream triggers:
 at Object.construct (node:internal/streams/destroy:283:11)
 at WriteStream.Writable (node:internal/streams/writable:258:15)
 at new WriteStream (node:internal/fs/streams:369:3)
 at Object.createWriteStream (node:fs:2843:10)
 ...

It's curious because the hook is created after the createWriteStream, however, it's triggered anyway.
I'm trying to create a workaround for that.
Also, you may have noticed that the tests are mostly broken on windows. It's fixable and I'll check it soon as fs workaround is solved.

Overall LGTM, I prefer to not provide an approval though because I would like that to come from somebody who's more familiar with this, namely @mcollina

Just for reference, this also solves the wrong behavior on v16:
Command:
./bin.js bubbleprof --autocannon [ / --method GET ] -- node example.js

// example.js
const Fastify = require('fastify')

const fastify = Fastify()
console.log('Starting', process.version)

fastify.get('/', (req, res) => {
  res.send({
    headers: req.headers,
    rawHeaders: req.headers,
  })
})

fastify.listen(3000, (err) => {
  if (err) throw err
})

process.on('SIGINT', () => {
  console.log('[SERVER] received sigint')
  process.exit()
})

process.on('exit', (code) => {
  console.trace('[SERVER] - Exiting', code)
})

v14:

v16 before this PR

v16 After this PR

Of course, I've also looked at inner elements and it makes sense to me.


KV connection error

Hey guys,
as the title says i´ll get:
level=error msg="KV connection error: KV store connection error: dial tcp: lookup redis: i/o timeout, retrying in 324.987404ms" providerName=redis
For my understanding ;-) i got two server: Master (<IP_ADDRESS>) and Slave (<IP_ADDRESS>) i put redis: endpoints: -"redis:6379" in the traefik.yml on the Master and start the traefik container.
Then i create a new container on the Slave, where i put as REDIS_ADDR=<IP_ADDRESS>:6379 and BIND_IP=<IP_ADDRESS>
then when i start both containers i´ll get above error. Maybe i´m on the wrong path here ;-)
thanks

side note maybe the problem is that I'm running a traefik container on the slave too?

so now i´ve stoped the traefik container on slave and i get
level=fatal msg="failed to connect to redis: dial tcp <IP_ADDRESS>:6379: connect: connection refused" traefik-kop-traefik-kop-1 exited with code 0

got it 😅 was stupid and forgot to put the redis service in the docker-compose file of traefik... 🙈


Measbeats patch 2

close pr. reason: please correct the meta.json. it contains two "descriptions". please only have one description in the meta.json. Thank you for your understanding.


library-preload bundle is missing resources since 1.58

Expected Behavior
library-preload bundles should contain all relevant resources of a library
Current Behavior
When generating the preload bundle for sap.ui.core at version 1.58.2, various resources are missing from that bundle. At runtime those resources are loaded synchronously:

Steps to reproduce the issue

Clone the openui5-sample
Checkout branch ui5-tooling
Install version 1.58.2 of the dependencies:

npm install<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>

Execute build:
ui5 build -a
Start an http server for the dist directory:
serve dist
Start the app in a browser and observe the additionally requested resources as seen in the screenshot above

Context

OS/Platform: macOS 10.13.6
Node.js Version: v10.5.0
npm Version: 6.4.1
Browser (if relevant): Chrome 69
Other information: ui5 tooling version 0.2.1

Affected components

[x] ui5-builder
[ ] ui5-server
[ ] ui5-cli
[ ] ui5-fs
[ ] ui5-project
[ ] ui5-logger

Root-cause seems to be bad configuration of the core preload bundle:
https://github.com/SAP/ui5-builder/blob/1b775a97d8e735fd2f45a31e1679de7b2a423574/lib/tasks/bundlers/generateLibraryPreload.js#L11-L41


Add Curator to Operate First documentation.

After we have reports easily visible by ops staff, we should add links and (if needed) instructions for how to see them to the Operate First SRE documentation (e.g. Hitchhiker's guide and top-level descriptions of components of Operate First).  DoD:  Documentaiton submitted to Operate First via PR and accepted.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close

@sesheta: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


ImportError: no module named 'chatterbot.ext' on own app

When I run the sample Django Chatterbot app, it runs fine but not when I run my own project. I have tried pip install chatterbot --upgrade.
Stack trace:
$ python manage.py makemigrations
Traceback (most recent call last):
  File "manage.py", line 22, in <module>
    execute_from_command_line(sys.argv)
  File "g:\Python\lib\site-packages\django\core\management\__init__.py", line 367, in execute_from_command_line
    utility.execute()
  File "g:\Python\lib\site-packages\django\core\management\__init__.py", line 341, in execute
    django.setup()
  File "g:\Python\lib\site-packages\django\__init__.py", line 27, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "g:\Python\lib\site-packages\django\apps\registry.py", line 85, in populate
    app_config = AppConfig.create(entry)
  File "g:\Python\lib\site-packages\django\apps\config.py", line 116, in create
    mod = import_module(mod_path)
  File "g:\Python\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 986, in _gcd_import
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 956, in _find_and_load_unlocked
ImportError: No module named 'chatterbot.ext'

My settings.py:
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'chatterbot.ext.django_chatterbot',
]

My urls.py:
from django.conf.urls import url, include
from django.contrib import admin
from chatterbot.ext.django_chatterbot import urls as chatterbot_urls

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^chatterbot/', include(chatterbot_urls, namespace='chatterbot')),
]

Ctrl+clicking on chatterbot.ext.django_chatterbot displays the correct file!

I'm not entirely sure what fixed it but after creating another app and including it before chatterbot, it migrated fine.


no text formatting in Q/A section, and weird visual bugs when writing code.. https://cdn.discordapp.com/attachments/738809117736566854/747921577298886728/unknown.png ...

no text formatting in Q/A section, and weird visual bugs when writing code.. https://cdn.discordapp.com/attachments/738809117736566854/747921577298886728/unknown.png

can you repost the picture?

Problem #2

When in the note editor, the markdown button for code gives inline code rather than multiline code


Added code block support to the blog

Currently looks like this

Would like feedback on
a. What color we should use for the background (they're copy pasted from github along with the syntax highlighting)
b. How to make syntax-highlight.css less repetitive as scss does not seem to work??
I also updated the test cases and test data to reflect these changes

cool.


🔧 MAINTAIN: migrate to sphinx-prettyproof

Per the discussion in #32, we're renaming the package from sphinxcontrib-prettyproof to sphinx-prettyproof.

These instructions on renaming a project are helpful but I'm not entirely sure. These look like the steps taken to depreciate cli. Would appreciate some feedback @chrisjsewell on your best-practices for renaming a package in PyPI if your time permits :-)

Codecov Report

Merging #44 into master will increase coverage by 0.81%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #44      +/-   ##
==========================================
+ Coverage   97.07%   97.89%   +0.81%
==========================================
  Files           6        5       -1
  Lines         239      237       -2
==========================================
  Hits          232      232
+ Misses          7        5       -2

Flag
Coverage Δ

#pytests
97.89% <100.00%> (+0.81%)
:arrow_up:

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

Impacted Files
Coverage Δ

sphinx_prettyproof/directive.py
100.00% <ø> (ø)

sphinx_prettyproof/domain.py
100.00% <ø> (ø)

sphinx_prettyproof/nodes.py
97.29% <ø> (ø)

sphinx_prettyproof/proof_type.py
100.00% <ø> (ø)

sphinx_prettyproof/__init__.py
90.90% <100.00%> (ø)

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 9ba9efb...2c8dc01. Read the comment docs.

@choldgraf @jstac @mmcky I just checked and sphinx-proof does not exist on PyPI or as an RTD project. I'm +1 to drop "pretty" and keep it as sphinx-proof. What do you think?


Facilitate access to nmdc_materialized_patterns schema via PyPI package

The PyPI package exposes several functions that can be used to get nmdc.schema.json in various formats. The task in this ticket is to allow package consumers to get the nmdc_materialized_patterns schema in those same formats.
Related: https://github.com/microbiomedata/nmdc-runtime/issues/552

This has been implemented in berkeley-schema-fy24, but I think it will be useful to have in the nmdc-schema repo for an upcoming migration. I will either reopen this ticket or create one that's similar (TBD).


Sharepoint / O365: Session uploaded file size reported by MS Graph does not equal local file size

Category

[ ] Question
[ ] Documentation issue
[X] Bug

Expected or Desired Behavior
OneDrive should report the correct file size when uploaded
Observed Behavior
When uploading a file via a session upload, to an O365 sharepoint site, the file size of the object returned does not match the actual file which was uploaded.
Files that appear to report incorrect sizes are:

PDF
MS Office Documents
HTML files

Files that do not appear to report incorrect sizes are:

Text files

When uploading to a standard OneDrive Business Account, this behavior does not occur.
Steps to Reproduce

Upload a file via API using a session upload
Review session response for file upload completion and note the 'size' value
Compare the 'size' value to the actual file size

For further details, refer to https://github.com/abraunegg/onedrive/issues/205 which provides additional diagnostic information

@ificator
Any update on this issue?

@ificator
Updated from an affected user:
Background: I just started using this client two weeks ago when I got a new machine at work. I saw this issue the very first day I tried using it on a plain .txt file. Today the problem came back in an interesting way.
I have a file called 2018-10-12 Burn Down Rate.xlsx that I initialized locally and then uploaded using this tool. It was one of 6 Excel sheets that I initialized today, but the only one to throw the file size does not match error.
My local copy of this file is 20,143 bytes. The Sharepoint Documents repository shows 25.6 KB with no obvious way of seeing the exact number of bytes. However, when I use my web browser to download the file, it comes out to 26,194 bytes! The visible content within this Excel sheet is identical, but the files themselves must be different.
A cursory look shows that Sharepoint is modifying the files after they are uploaded. I extracted each of the .XLSX files as ZIP archives and I can see that Sharepoint has injected a new file at the path docProps/custom.xml that does not exist in my original upload. There is an entire extra folder named customXml filled with 6 additional files and a subfolder as well.
So Sharepoint is modifying these files after they are uploaded. That's.... interesting. My current workaround is to delete the local file after I see the error and allow it to re-sync the updated copy from Sharepoint. I don't know if that is a sane default but it is the workflow I have adopted.

@ificator
Any update on this issue?

Were these files opened or viewed between the times that they were uploaded and then downloaded?  Have you checked file history to see if the file has been modified by another application?
Could you please provide information about your original upload request:

Date (in UTC, please)
request-id
SPRequestGuid (for requests made to OneDrive for Business)

@chackman

Were these files opened or viewed between the times that they were uploaded and then downloaded? Have you checked file history to see if the file has been modified by another application?

No I do not believe so. The response from OneDrive in the response json is immediate after session upload is complete, and this is where the size difference is being noted. The file is being modified by OneDrive / MS Graph immediately after upload. As the change is size is right after the upload to indicate that the file was successfully uploaded - there is 'zero' chance something else is modifying this other that the OneDrive backend.

Could you please provide information about your original upload request:

Date (in UTC, please)
request-id
SPRequestGuid (for requests made to OneDrive for Business)

Will ask the users to generate some requests  using additional debugging to capture this.

@chackman
Tracker case against 'onedrive' client application for Linux: https://github.com/abraunegg/onedrive/issues/205

@chackman
Below are 2 different users logs with the data requested:
Log 1: https://pastebin.com/SNCnpM1n
Log 2: https://pastebin.com/57B0e0Vh

Thanks; I'm waiting for more information from a partner team about this issue.

@chackman
Any update here - Microsoft should not be modifying user's files when uploaded to OneDrive service. This is impacting a significant number of users, using various Linux clients to sync data to OneDrive.

I'm still waiting for more information from a partner team about this issue.

After doing a little research this is normal behavior for SharePoint and has been since at least SharePoint 2010. When uploading a file that can contain metadata SharePoint will associate some metadata from the library the file is uploaded to directly in the file. Office files are probably the most typical files where this will happen but it's not unreasonable to assume that this will happen for other rich file types as well.

Whilst it might be considered 'normal behaviour' to Microsoft to modify a file after upload - either by enrichment or other - it is still a file modification that breaks file validation mechanisms to indicate that the file was uploaded successfully. This modification would constitute unacceptable behaviour because it is happening without user knowledge or acceptance.
Just because an uploaded file 'can' be enriched, does not mean that it should be 'automatically' enriched.
Is there any way to disable this 'automatic' SharePoint document enrichment?

This is a feature in SharePoint document libraries that has been around for some time.  With respect to validation, have you encountered cases where a file upload appears to have succeeded, but in fact, it did not succeed?
If upload didn't work even though it appeared to work, then please provide more information about the upload that silently failed.

This is a feature in SharePoint document libraries that has been around for some time. With respect to validation, have you encountered cases where a file upload appears to have succeeded, but in fact, it did not succeed?

Any file that is successfully uploaded, but modified by Microsoft & file size changed (due to modification or enrichment) when comparing to that of the actual file on my local disk - should in my mind constitute a 'failed upload' as what I 'uploaded' is not what is present on OneDrive - the Microsoft modified version is what exists. If I was then to use any sort of 'checksum' to validate if my files are 'in sync' - I would have different files which would then need to either:

reupload (which again would get modified)
replace with MS modified / enriched version .... why would I want a MS modified version of my file?

I would suggest that this 'feature' - despite its 'age' either needs to be clearly documented somewhere, or somehow switched off by default for SharePoint libraries and enabled by some sort API flag if wanted.

Agree with @abraunegg.
Looks very odd for my can't trust on the host. I want to upload a file and make sure it is the same. If I also have a text file with the checksum, and when download I use the content for this checksum file to detect if I downloaded the exact file that I've upload, won't be possible.
I strongly suggest being able to disable this "feature".

This "enriched" information should be stored in a separate/hidden data stream or blob, so "User" files are never changed.
I took a look what changes on HTML files and found added "mso:" markup in the file.
Every Developer get crazy if he finds such in handwritten file(s).

Unfortunately, as stated earlier, this is how the document library features work.
We will look into documentation feedback; however, UserVoice is the appropriate place to suggest feature enhancements and improvements.

Does this behavior happen on a user's OneDrive for Bussiness?

Does this behavior happen on a user's OneDrive for Bussiness?

@0x3333 sadly yes.

Unfortunately, as stated earlier, this is how the document library features work.
We will look into documentation feedback; however, UserVoice is the appropriate place to suggest feature enhancements and improvements.

@chackman the problem is it doesn’t only affect document files but binary files as well. My Leveldb files get corrupted by this leading to data loss.

It seems I can at the moment workaround this problem by uploading files with the ".partial" extension and then moving them to the real filename after the transfer. I used the "SP.MoveCopyUtil.MoveFileByPath()" API of sharepoint online.

Has anyone actually contacted Microsoft about this? We are using Office365 and have support. I wonder what their response would be. Obviously they won't support third party tools, but if the hashes don't match after uploading normally, it's a clear problem.

Has anyone actually contacted Microsoft about this? We are using Office365 and have support. I wonder what their response would be. Obviously they won't support third party tools, but if the hashes don't match after uploading normally, it's a clear problem.

Based on the conversation in this thread, I doubt they'll just happily advertise this feature to you again. I haven't thought of contacting the support before though...

No dice on that. We've had this issue in the past, and it is known and expected behavior unfortunately. The reason for the hash change is tied to the change in UUID to all for items to be searched and scanned in SharePoint.
Guess we'll just have to hope and assume that files are uploaded successfully and completely.

Why is this issue closed? It is a serious bug about the API or the API doc.

Hi, using rclone, with the same issue.
To upload docx files, I now upload a zip file and then rename it to docx. In that case the file is not changed.
So I suppose that the enrichment is done inside the upload process. So when the file is successfully on sharepoint and you rename it then, it won't get enriched.

Would it work to have an option to automatically use one of the renaming workarounds described to prevent SharePoint from modifying the file, such as the .partial extension used by @lindi2 or the .zip extension used by @GeorgesDLH ?

Can enrichment be turned off on Sharepoint? In our case this thing just happened around a month back. In our case we export a Confluence space and sync this upload to Sharepoint. For this we first download them, rsync over the export and then sync it again. Because of the enrichment feature Sharepoint thinks, that nearly all files have changed and our engineers have to download 4GBs and thousands of files every morning.


Please provide "helm rollback" option in the HelmRelease

When rolling out new versions of a HelmRelease, there is a case that a release might be marked as FAILED by Helm due to some error. In that case, Flux cannot deploy new versions of the HelmRelease file, even if the error has been corrected, as the following error appears in the logs:
ts=2019-03-15T16:54:32.871180927Z caller=release.go:186 component=release error="Chart release failed: staging-test: &status.statusError{Code:2, Message:\"a release named staging-test already exists. nRun: helm ls --all staging-test; to check the status of the release nOr run: helm del --purge staging-test; to delete it\", Details:[]*any.Any(nil)}"

In order to overcome this issue, there are two options without downtime that I am aware of:

Create a new HelmRelease with a different name, let it deploy, delete the old one.
Do a helm rollback

Given that the last revision of Helm will be in FAILED state, the one that will be running in the cluster will be the last successful one. The helm rollback <release_name> <last_successful_revision> will just make Helm point to the last successful revision so that we overcome this issue.
Regarding the two available options above, the first one involves some manual labor, where the second one can be automated. The downside of the second option is that helm rollback is not stable for stateful applications.
Could we please implement it as an option that one has to explicitly enable for Flux to do the helm rollback if this issue is hit? This will be backwards compatible, not create a problem to stateful workloads and allow someone that wants to force this rollback to do so. This will be very handy for stateless application where this issue is hit.
Thanks!

Is that the best way to solve this?  I think I've hit this issue too, I had a helm release that failed, I rolled forward manually upgrading to another release that eventually succeeded, but now my HelmRelease has recovered.
I made a failed release by changing the service type from LoadBalancer to ClusterIP, which I've just learned that Kubernetes will not allow because the field is immutable, or something.  This crashed my helm release and marked it FAILED, which is the same thing that would have happened without helm-operator, of course.
So I manually deleted the service which was preventing the upgrade, and ran the helm upgrade manually (or waited long enough for helm-operator to try again) and it worked.  I suppose this is a bigger problem for UX if the flux users don't have permission to delete a service manually.  Maybe also worth noting that a change from ClusterIP to LoadBalancer does not trigger the same issue.

I may have said it wrong.  It looks like helm-operator will not recover on its own, even if you delete the service.  But pretty sure that helm-operator can be recovered by manually triggering another release with helm upgrade.

I started working on this in #2006, and what is currently there already works.
One of the challenges I am facing is the fact that in case an upgrade fails and it rolls back the release, it will end up in an infinite loop of retrying the upgrade (and rolling back) until a human notices and fixes the error.
This is harmless in theory, it will however result in about 40 nonsense revisions/hour with the default interval settings.


Mechanism to pass arbitrary metadata to readers/writers

In https://github.com/chemfiles/chemfiles/pull/453#discussion_r917272601 and a couple of other instances, I wanted to give the final user the ability to communicate metadata to the format implementation. This could be used to request a variant of a format, or give some hard to guess metadata to the format (timestep/first simulation step/etc.).
I envision something like this:
using TrajectoryOptions = std::map<std::string, Property>

Trajectory(std::string path, char mode, TrajectoryOptions options ={});

// in the C API
struct chfl_trajectory_options_t {
    size_t count;
    const char** names; // array of NULL terminated strings of size count
    const chfl_properties* properties;  // array of `count` properties
}

chfl_trajectory_open(const char* path, char mode, chfl_trajectory_options_t options)

That would be used like this
auto options = TrajectoryOptions();
options.insert("dcd_timestep", 1.5);
options.insert("dcd_first_step, 128);

auto trajectory = Trajectory("data.gz", 'w', options);

We could also replace the mechanism to request a specific format with this new metadata:
auto options = TrajectoryOptions();
options.insert("format", "XYZ");
options.insert("compression, "GZ");

auto trajectory = Trajectory("data.gz", 'r', options);

I think the file mode is fundamental enough to stay as a separate parameter.

Some other metadata we might want to pass to the formats:

picking between fractional and cartesian coordinates in CIF (https://gitter.im/chemfiles/chemfiles?at=6340430fa72aed016620cf70)


[SUGGEST] Auto Pistol Delay

Useful feature for pistol accuracy when used with Aimbot and Autostop for 100% accuracy.

+rep, now pray that daniel will see this and say ye. also, pls add triggerbot hitchance

no one has updated aimbot for a long time in this cheat xd

because it works fine without updates XD

auto scope bug?


Issue110: MarathonTask.ip_addresses attribute is set properly

Good day,
this PR fixes #110.
ip_addresses field is passed via init parameters in MarathonTask, but never set.

Thanks!


Support building static library

For my unikraft-rs initiative, I am building Unikraft as a static library to then link it using Cargo.
Currently, I am assembling a static library myself. For the initial approach, see mkroening/unikraft-static as well as @razvand's initial instructions, which are linked there.
I am currently filtering all entries in build with this predicate:
(file_type.is_file()
    && file_name.starts_with("lib")
    && file_name.ends_with(".o")
    && !file_name.ends_with(".ld.o"))

Which are then linked using ar rcs libunikraft.a <OBJECT_FILES>.
It would be awesome, if KraftKit supported building static libraries, so I would not have to handle the complexity of ensuring clean builds in my build script myself.
What do you think?

I'm all about this, but let me know first if there's an already existing command for make to do this

nice, okay, then we can come back to this once it's upstream 🙏

Closing in favor of

https://github.com/unikraft/unikraft/pull/957


Support statefulset

Besides deployment, stateful set would be nice to have as well.

@dmpe thanks for this issue, can you elaborate a bit more? thanks!

@cpanato stateful set for databases? Would like to contribute to this repo. What are some interesting problems.


Python - huggingface's neuralcoref for spaCy

Project description
NeuralCoref is a pipeline extension for spaCy 2.1+ which annotates and resolves coreference clusters using a neural network.
Metadata
Related to  #87059

homepage URL: https://github.com/huggingface/neuralcoref
source URL: https://github.com/huggingface/neuralcoref
license: mit
platforms: linux

I am new to Nix and would like to put in the comment myself - but I got stuck.
I cloned nixpkgs and added nixpkgs/pkgs/development/python-modules/neuralcoref/default.nix
{ lib
, buildPythonPackage
, fetchPypi
, spacy
, cython
, pytest
}:

buildPythonPackage rec {
  pname = "neuralcoref}";
  version = "4.0";

  src = fetchPypi {
    inherit pname version;
    sha256 = "23aee7418edf5c2e90b3f9f15931563b07ded8c59de386ae654b403322430ad9";
  };

  propagatedBuildInputs = [
    spacy
    cython
    pytest
  ];

  checkInputs = [
  #  pytest
  ];

  doCheck = false;

  meta = with lib; {
    description = "Neuralcoref: Coreference Resolution in spaCy with Neural Networks";
    homepage = "https://github.com/huggingface/neuralcoref";
    license = licenses.mit;
    maintainers = with maintainers; [ conradmearns ];
  };
}

I then tried nix-build -A neuralcoref from that directory, but I get the following error.
error: cannot auto-call a function that has an argument without a default value ('lib')

add a callPackage in python-packages.nix and the call it from the top-level, so nix-build -A python3Packages.neuralcoref.

Added #90252


pre-processing per row data padding due to hardware alignment requirement

Just want to know whether per row data padding to match with hardware's alignment requirement is untimed or not.

The text in Section 7.1 says that untimed pre-processing:

May pad to arbitrary size (don’t be creative)

You should feel free to pad to the hardware's required alignment during untimed pre-processing.

The text in Section 7.1 says that untimed pre-processing:

May pad to arbitrary size (don’t be creative)

You should feel free to pad to the hardware's required alignment during untimed pre-processing.

I thought that "pad" refers to padding on the image dimensions. So it's not?

My reading is that you may pad the batch, image, channel, or other dimensions.

WG approved and close.


feat(schematics): schematics support angular v18

the is the part of #163

the is the part of #173


[Bug] Looking up git refs fails.

Describe the bug
All the git refs fail and cannot be found. These were all install fresh today
Steps to reproduce
asdf plugin add XXX
asdf-plugin-manager export > .plugin-versions
asdf-plugin-manager add-all

Expected behavior
To check all the git refs
Screenshots
Additional context
> asdf-plugin-manager list
asdf-plugin-manager  https://github.com/asdf-community/asdf-plugin-manager.git  07a8a5a
direnv               https://github.com/asdf-community/asdf-direnv.git          2b649c8
lua                  https://github.com/Stratus3D/asdf-lua.git                  36fae6e
luajit               https://github.com/smashedtoatoms/asdf-luaJIT.git          bbfe3cd
python               https://github.com/danhper/asdf-python.git                 5e277e2

> asdf-plugin-manager add-all
[INFO] Adding: asdf-plugin-manager https://github.com/asdf-community/asdf-plugin-manager.git 07a8a5a
Plugin named asdf-plugin-manager already added
Location of asdf-plugin-manager plugin: /Users/XXXXX/.local/share/asdf/plugins/asdf-plugin-manager
Updating asdf-plugin-manager to 07a8a5a
fatal: couldn't find remote ref 07a8a5a
HEAD is now at 07a8a5a chore(deps): bump asdf-vm/actions from 2 to 3 (#30)
[INFO] Done.
[INFO] Adding: direnv https://github.com/asdf-community/asdf-direnv.git 2b649c8
Plugin named direnv already added
Location of direnv plugin: /Users/XXXXX/.local/share/asdf/plugins/direnv
Updating direnv to 2b649c8
fatal: couldn't find remote ref 2b649c8
HEAD is now at 2b649c8 Bump asdf-vm/actions from 2 to 3
[INFO] Done.
[INFO] Adding: lua https://github.com/Stratus3D/asdf-lua.git 36fae6e
Plugin named lua already added
Location of lua plugin: /Users/XXXXX/.local/share/asdf/plugins/lua
Updating lua to 36fae6e
fatal: couldn't find remote ref 36fae6e
HEAD is now at 36fae6e Add Lua 5.4.5 and 5.4.6 (#32)
[INFO] Done.
[INFO] Adding: luajit https://github.com/smashedtoatoms/asdf-luaJIT.git bbfe3cd
Plugin named luajit already added
Location of luajit plugin: /Users/XXXXX/.local/share/asdf/plugins/luajit
Updating luajit to bbfe3cd
fatal: couldn't find remote ref bbfe3cd
HEAD is now at bbfe3cd Attempting to fix missing luarocks.cfg
[INFO] Done.
[INFO] Adding: python https://github.com/danhper/asdf-python.git 5e277e2
Plugin named python already added
Location of python plugin: /Users/XXXXX/.local/share/asdf/plugins/python
Updating python to 5e277e2
fatal: couldn't find remote ref 5e277e2
HEAD is now at 5e277e2 Merge pull request #169 from asdf-community/renovate/configure
[INFO] Done.

This appears to be because these are short refs (generally 7 characters) and Git won't resolve those. I wonder how it ever worked. Is it a regression in asdf?
Some initial digging: asdf-plugin-manager export calls asdf plugin-list --refs, which in turn calls the internal function get_plugin_remote_gitref, which is basically git rev-parse --short. The --short argument isn't configurable.

@timdp
I did manage to get export to use the full git ref, however, there is an issue with asdf update itself
So I closed the pull request.
asdf update does  something like this
git fetch --prune --update-head-ok origin daa7d6ee57:daa7d6ee57
and will not find the repo/commit based on the short git ref.
I think something like the following is required
git fetch --prune --update-head-ok origin  daa7d6ee570117f893b7f3a8ae034a722d641a6a:daa7d6ee57
 > git --git-dir .git rev-parse HEAD
daa7d6ee570117f893b7f3a8ae034a722d641a6a

> git branch
* (HEAD detached at daa7d6e)
  master

I will raise something with the asdf team

Assuming everything's a Git ref, you could probably also bypass asdf entirely and run git fetch and git log (with the appropriate flags) in the local tool repo yourself? Seems invasive though.

Hi @andrewcrook :wave:
Which asdf and asdf-plugin-manager version do you have?

Any updates here?
I think one option would be to add a git rev-parse call to expand/normalize hashes before passing them to asdf. That would require an API to resolve a plugin name to the git repo path though, which I don't think asdf exposes, so maybe it's just shifting the problem.
As a sidenote, shouldn't the fatal error make asdf-plugin-manager crash out?

I've released v1.2.0, it should fix that issue which actually coming from asdf update itself.
I used the same idea proposed by @timdp to checkout the git hash.
Could you please give it a try?
asdf install asdf-plugin-manager 1.2.0

Working great here! 👍🏻

@timdp thanks for the confirmation :handshake:


Hide error messages

Made some changes here. No need to use the graphql-errors module, now it simply looks for Meteor.Error error type. As we're only handling resolve functions, syntax errors should work as before.


ghcide 0.2.0 startup performance regression when using splint

I noticed a startup performance regression when upgrading from 0.1.0 -> 0.2.0:
Before on 0.1.0 running time ghcide took 7.44s user 0.95s system 108% cpu 7.760 total.
Ran the above command after this commit:
https://github.com/willbush/exercises/commit/c5611dfbafca4b6680aa45a12f31960a053f6bfd
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update* ghcide --version
ghcide version: 0.1.0 (GHC: 8.8.3) (PATH: /nix/store/48ajx48f59s0yqd6qb34zj7xzhgn3vc9-ghcide-0.1.0/bin/ghcide)
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update time ghcide
ghcide version: 0.1.0 (GHC: 8.8.3) (PATH: /nix/store/48ajx48f59s0yqd6qb34zj7xzhgn3vc9-ghcide-0.1.0/bin/ghcide)
Ghcide setup tester in /home/will/code/exercises/haskell-exercises.
Report bugs at https://github.com/digital-asset/ghcide/issues

Step 1/6: Finding files to test in /home/will/code/exercises/haskell-exercises
Found 18 files

Step 2/6: Looking for hie.yaml files that control setup
Found 1 cradle

Step 3/6, Cradle 1/1: Loading /home/will/code/exercises/haskell-exercises/hie.yaml

Step 4/6, Cradle 1/1: Loading GHC Session

Step 5/6: Initializing the IDE

Step 6/6: Type checking the files
File:     /home/will/code/exercises/haskell-exercises/bench/BenchAll.hs
Hidden:   no
Range:    3:17-3:31
Source:   not found
Severity: DsError
Message:
  Could not load module ‘Criterion.Main’
  It is a member of the hidden package ‘criterion-<IP_ADDRESS>’.
  Perhaps you need to add ‘criterion’ to the build-depends in your .cabal file.
Files that failed:
 * /home/will/code/exercises/haskell-exercises/bench/BenchAll.hs

Completed (17 files worked, 1 file failed)
ghcide  7.44s user 0.95s system 108% cpu 7.760 total
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update

After upgrading to 0.2.0 running time ghcide took 69.99s user 1.81s system 106% cpu 1:07.33 total.
Ran the above command after this commit:
https://github.com/willbush/exercises/commit/0627ace26002bd76db3f0723308cc10e24df13d3
Important to note that this is using the new multi-components feature which fix the bench component error that I was ignoring before.
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update* ghcide --version
ghcide version: 0.2.0 (GHC: 8.8.3) (PATH: /nix/store/ngv8g1lv1nzwqp0wac5d0i6vfmxsj122-ghcide-0.2.0/bin/ghcide)
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update* time ghcide
ghcide version: 0.2.0 (GHC: 8.8.3) (PATH: /nix/store/ngv8g1lv1nzwqp0wac5d0i6vfmxsj122-ghcide-0.2.0/bin/ghcide)
Ghcide setup tester in /home/will/code/exercises/haskell-exercises.
Report bugs at https://github.com/digital-asset/ghcide/issues

Step 1/4: Finding files to test in /home/will/code/exercises/haskell-exercises
Found 18 files

Step 2/4: Looking for hie.yaml files that control setup
Found 1 cradle

Step 3/4: Initializing the IDE

Step 4/4: Type checking the files
[INFO] Consulting the cradle for "/home/will/code/exercises/haskell-exercises/test/AdventOfCode/Day4Spec.hs"
> Resolving dependencies...
> Build profile: -w ghc-8.8.3 -O1
> In order, the following will be built (use -v for more details):
>  - haskell-exercises-<IP_ADDRESS> (lib) (configuration changed)
>  - haskell-exercises-<IP_ADDRESS> (test:haskell-exercises-test) (configuration changed)
> Configuring library for haskell-exercises-<IP_ADDRESS>..
> Preprocessing library for haskell-exercises-<IP_ADDRESS>..
> Building library for haskell-exercises-<IP_ADDRESS>..
> [1 of 9] Compiling AdventOfCode.Day1 ( src/AdventOfCode/Day1.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day1.o ) [Splint changed]
> [2 of 9] Compiling AdventOfCode.Day3 ( src/AdventOfCode/Day3.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day3.o ) [Data.List.Extra changed]
> [3 of 9] Compiling AdventOfCode.Day4 ( src/AdventOfCode/Day4.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day4.o ) [Splint changed]
> [4 of 9] Compiling AdventOfCode.Day5 ( src/AdventOfCode/Day5.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day5.o ) [Splint changed]
> [5 of 9] Compiling Common.Fibonacci ( src/Common/Fibonacci.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/Common/Fibonacci.o ) [Splint changed]
> [6 of 9] Compiling Common.Helpers   ( src/Common/Helpers.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/Common/Helpers.o ) [Splint changed]
> [7 of 9] Compiling Common.Primes    ( src/Common/Primes.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/Common/Primes.o ) [Splint changed]
> [8 of 9] Compiling AdventOfCode.Day2 ( src/AdventOfCode/Day2.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day2.o )
> [9 of 9] Compiling ProjectEuler.Problems ( src/ProjectEuler/Problems.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/ProjectEuler/Problems.o )
> Configuring test suite 'haskell-exercises-test' for haskell-exercises-<IP_ADDRESS>..
> Warning: The package has an extraneous version range for a dependency on an
> internal library: haskell-exercises -any && ==<IP_ADDRESS>, haskell-exercises -any
> && ==<IP_ADDRESS>. This version range includes the current package but isn't needed
> as the current package's library will always be used.
> Preprocessing test suite 'haskell-exercises-test' for haskell-exercises-<IP_ADDRESS>..
[INFO] Using interface files cache dir: /home/will/.cache/ghcide/main-eefdd04e13d0e88bd75d0b0b3aceed75a156f06a
[INFO] Making new HscEnv[main]
[INFO] Consulting the cradle for "/home/will/code/exercises/haskell-exercises/src/ProjectEuler/Problems.hs"
> Resolving dependencies...
> Build profile: -w ghc-8.8.3 -O1
> In order, the following will be built (use -v for more details):
>  - haskell-exercises-<IP_ADDRESS> (lib) (configuration changed)
> Configuring library for haskell-exercises-<IP_ADDRESS>..
> Preprocessing library for haskell-exercises-<IP_ADDRESS>..
[INFO] Using interface files cache dir: /home/will/.cache/ghcide/haskell-exercises-<IP_ADDRESS>-inplace-e22b30c2e452d949bb9ce34e1d96b55943a90485
[INFO] Using interface files cache dir: /home/will/.cache/ghcide/main-12942c39ee6a446941e165d3567bce01bd75f3c4
[INFO] Making new HscEnv[haskell-exercises-<IP_ADDRESS>-inplace,main]
[INFO] Consulting the cradle for "/home/will/code/exercises/haskell-exercises/bench/BenchAll.hs"
> Resolving dependencies...
> Build profile: -w ghc-8.8.3 -O1
> In order, the following will be built (use -v for more details):
>  - haskell-exercises-<IP_ADDRESS> (lib) (configuration changed)
>  - haskell-exercises-<IP_ADDRESS> (bench:haskell-exercises-bench) (configuration changed)
> Configuring library for haskell-exercises-<IP_ADDRESS>..
> Preprocessing library for haskell-exercises-<IP_ADDRESS>..
> Building library for haskell-exercises-<IP_ADDRESS>..
> Configuring benchmark 'haskell-exercises-bench' for haskell-exercises-<IP_ADDRESS>..
> Warning: The package has an extraneous version range for a dependency on an
> internal library: haskell-exercises -any && ==<IP_ADDRESS>, haskell-exercises -any
> && ==<IP_ADDRESS>. This version range includes the current package but isn't needed
> as the current package's library will always be used.
> Preprocessing benchmark 'haskell-exercises-bench' for haskell-exercises-<IP_ADDRESS>..
[INFO] Using interface files cache dir: /home/will/.cache/ghcide/main-048d6160eb48c12c9a06d27f4ee3a06cb0d87269
[INFO] Using interface files cache dir: /home/will/.cache/ghcide/haskell-exercises-<IP_ADDRESS>-inplace-ddfa2433c6638ac0417ba23f186728f884edea76
[INFO] Using interface files cache dir: /home/will/.cache/ghcide/main-048d6160eb48c12c9a06d27f4ee3a06cb0d87269
[INFO] Making new HscEnv[main,haskell-exercises-<IP_ADDRESS>-inplace,main]

Completed (18 files worked, 0 files failed)
ghcide  69.99s user 1.81s system 106% cpu 1:07.33 total
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update*

It hangs for a while after logging Preprocessing benchmark 'haskell-exercises-bench' for haskell-exercises-<IP_ADDRESS>.. using ~100% CPU.

It might be a hie-bios issue. time hie-bios check test/Main.hs is taking a lot longer for me. Want me to report it there?
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update ghcide --version
ghcide version: 0.1.0 (GHC: 8.8.3) (PATH: /nix/store/48ajx48f59s0yqd6qb34zj7xzhgn3vc9-ghcide-0.1.0/bin/ghcide)
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update hie-bios version
hie-bios version 0.4.0 compiled by GHC 8.8.3
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update time hie-bios check test/Main.hs
hie-bios check test/Main.hs  7.10s user 0.65s system 98% cpu 7.883 total
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update time hie-bios debug test
Root directory:      /home/will/code/exercises/haskell-exercises
GHC options:         -fbuilding-cabal-package -O0 -outputdir /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp -odir /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp -hidir /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp -stubdir /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp -i -i/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp -i/home/will/code/exercises/haskell-exercises/test -i/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/autogen -i/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/global-autogen -I/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/autogen -I/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/global-autogen -I/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp -optP-include -optP/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/autogen/cabal_macros.h -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db /home/will/.cabal/store/ghc-8.8.3/package.db -package-db /home/will/code/exercises/haskell-exercises/dist-newstyle/packagedb/ghc-8.8.3 -package-db /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/package.conf.inplace -package-id array-<IP_ADDRESS> -package-id base-<IP_ADDRESS> -package-id bytestring-<IP_ADDRESS> -package-id containers-<IP_ADDRESS> -package-id extra-1.7.3-fff4295a289246150c9691a37ec25db605a485c03e6491c8fd3e2ac752498bb1 -package-id haskell-exercises-<IP_ADDRESS>-inplace -package-id hspec-2.7.1-DTGDYPmkrDq5rk3zcuroRh -package-id ilist-<IP_ADDRESS>-3bir64FlqXmCihO3Bl08qp -package-id safe-0.3.18-F31ek1WnrA3UJF2AhicNf -package-id splint-<IP_ADDRESS>-97e2e0b78e177291135562a287424dd5043758bde79c1f0430f4fb5b840fa54f -package-id utility-ht-0.0.15-1zMKpkUjWvmL5idQFPrnB1 -XHaskell2010 test/Main.hs CommonSpec ProjectEuler.ProblemsSpec AdventOfCode.Day1Spec AdventOfCode.Day2Spec AdventOfCode.Day3Spec AdventOfCode.Day4Spec AdventOfCode.Day5Spec -Wall -Wcompat -Widentities -Wincomplete-record-updates -Wincomplete-uni-patterns -Wpartial-fields -Wredundant-constraints -fplugin=Splint -hide-all-packages
System libraries:    /nix/store/jw9jhyn472jp8n287v2mywpv31wdrnln-ghc-8.8.3-with-packages/lib/ghc-8.8.3
Config Location:     /home/will/code/exercises/haskell-exercises/hie.yaml
Cradle:              Cradle {cradleRootDir = "/home/will/code/exercises/haskell-exercises", cradleOptsProg = CradleAction: Cabal}
Dependencies:        haskell-exercises.cabal cabal.project shell.nix default.nix
hie-bios debug test  3.56s user 0.53s system 96% cpu 4.227 total
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update*
direnv: loading ~/code/exercises/haskell-exercises/.envrc
direnv: export +AR +AS +CC +CONFIG_SHELL +CXX +HOST_PATH +IN_NIX_SHELL +LD +NIX_BINTOOLS +NIX_BINTOOLS_WRAPPER_x86_64_unknown_linux_gnu_TARGET_HOST +NIX_BUILD_CORES +NIX_BUILD_TOP +NIX_CC +NIX_CC_WRAPPER_x86_64_unknown_linux_gnu_TARGET_HOST +NIX_ENFORCE_NO_NATIVE +NIX_GHCPKG +NIX_GHC_DOCDIR +NIX_GHC_LIBDIR +NIX_HARDENING_ENABLE +NIX_INDENT_MAKE +NIX_LDFLAGS +NIX_LOG_FD +NIX_STORE +NM +OBJCOPY +OBJDUMP +RANLIB +READELF +SIZE +SOURCE_DATE_EPOCH +STRINGS +STRIP +allowSubstitutes +buildInputs +builder +configureFlags +depsBuildBuild +depsBuildBuildPropagated +depsBuildTarget +depsBuildTargetPropagated +depsHostHost +depsHostHostPropagated +depsTargetTarget +depsTargetTargetPropagated +doCheck +doInstallCheck +extraClosure +installPhase +name +nativeBuildInputs +origArgs +origBuilder +origExtraClosure +origOutputs +origPATH +origSystem +out +outputs +patches +phases +preHook +preferLocalBuild +propagatedBuildInputs +propagatedNativeBuildInputs +shell +shellHook +stdenv +strictDeps +system ~LOCALE_ARCHIVE ~NIX_GHC ~PATH
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update* ghcide --version
ghcide version: 0.2.0 (GHC: 8.8.3) (PATH: /nix/store/ngv8g1lv1nzwqp0wac5d0i6vfmxsj122-ghcide-0.2.0/bin/ghcide)
direnv: loading ~/code/exercises/haskell-exercises/.envrc
direnv: export +AR +AS +CC +CONFIG_SHELL +CXX +HOST_PATH +IN_NIX_SHELL +LD +NIX_BINTOOLS +NIX_BINTOOLS_WRAPPER_x86_64_unknown_linux_gnu_TARGET_HOST +NIX_BUILD_CORES +NIX_BUILD_TOP +NIX_CC +NIX_CC_WRAPPER_x86_64_unknown_linux_gnu_TARGET_HOST +NIX_ENFORCE_NO_NATIVE +NIX_GHCPKG +NIX_GHC_DOCDIR +NIX_GHC_LIBDIR +NIX_HARDENING_ENABLE +NIX_INDENT_MAKE +NIX_LDFLAGS +NIX_LOG_FD +NIX_STORE +NM +OBJCOPY +OBJDUMP +RANLIB +READELF +SIZE +SOURCE_DATE_EPOCH +STRINGS +STRIP +allowSubstitutes +buildInputs +builder +configureFlags +depsBuildBuild +depsBuildBuildPropagated +depsBuildTarget +depsBuildTargetPropagated +depsHostHost +depsHostHostPropagated +depsTargetTarget +depsTargetTargetPropagated +doCheck +doInstallCheck +extraClosure +installPhase +name +nativeBuildInputs +origArgs +origBuilder +origExtraClosure +origOutputs +origPATH +origSystem +out +outputs +patches +phases +preHook +preferLocalBuild +propagatedBuildInputs +propagatedNativeBuildInputs +shell +shellHook +stdenv +strictDeps +system ~LOCALE_ARCHIVE ~NIX_GHC ~PATH
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update*
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update* ghcide --version
ghcide version: 0.2.0 (GHC: 8.8.3) (PATH: /nix/store/ngv8g1lv1nzwqp0wac5d0i6vfmxsj122-ghcide-0.2.0/bin/ghcide)
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update* hie-bios version
hie-bios version 0.5.0 compiled by GHC 8.8.3
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update* time hie-bios check test/Main.hs
hie-bios check test/Main.hs  63.33s user 0.80s system 99% cpu 1:04.26 total
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update* time hie-bios debug test
Root directory:      /home/will/code/exercises/haskell-exercises
Component directory: /home/will/code/exercises/haskell-exercises
GHC options:         -fbuilding-cabal-package -O0 -outputdir /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp -odir /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp -hidir /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp -stubdir /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp -i -i/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp -itest -i/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/autogen -i/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/global-autogen -I/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/autogen -I/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/global-autogen -I/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp -optP-include -optP/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/autogen/cabal_macros.h -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db /home/will/.cabal/store/ghc-8.8.3/package.db -package-db /home/will/code/exercises/haskell-exercises/dist-newstyle/packagedb/ghc-8.8.3 -package-db /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/package.conf.inplace -package-id base-<IP_ADDRESS> -package-id bytestring-<IP_ADDRESS> -package-id containers-<IP_ADDRESS> -package-id haskell-exercises-<IP_ADDRESS>-inplace -package-id hspec-2.7.1-AYqVNi5hQsf1wmfcMaAvYi -package-id safe-0.3.19-K9VEwmVF618FMbBq820Jtf -package-id splint-<IP_ADDRESS>-EfeGUjPg3EH5csaM5RQFKX -package-id utility-ht-0.0.15-Fwfs6jpVSckI8R4noxPJwJ -XHaskell2010 test/Main.hs CommonSpec ProjectEuler.ProblemsSpec AdventOfCode.Day1Spec AdventOfCode.Day2Spec AdventOfCode.Day3Spec AdventOfCode.Day4Spec AdventOfCode.Day5Spec -Wall -Wcompat -Widentities -Wincomplete-record-updates -Wincomplete-uni-patterns -Wpartial-fields -Wredundant-constraints -fplugin=Splint -hide-all-packages
System libraries:    /nix/store/pcn15ax93viwpfg7rxp4psnkvbs0b86p-ghc-8.8.3-with-packages/lib/ghc-8.8.3
Config Location:     /home/will/code/exercises/haskell-exercises/hie.yaml
Cradle:              Cradle {cradleRootDir = "/home/will/code/exercises/haskell-exercises", cradleOptsProg = CradleAction: Cabal}
Dependencies:        haskell-exercises.cabal cabal.project cabal.project.local shell.nix default.nix
hie-bios debug test  3.57s user 0.46s system 97% cpu 4.146 total
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update* time hie-bios check test/Main.hs
hie-bios check test/Main.hs  59.86s user 0.68s system 99% cpu 1:00.67 total

Actually, after running time ghcide again, its hanging on [INFO] Making new HscEnv[haskell-exercises-<IP_ADDRESS>-inplace,main].
Think I narrowed this down a bit. I'm using this GHC plugin https://github.com/tfausak/splint, and I remember from reading the blog post that the author says it adds a tenth of a second per module.
So I commented out every line in my cabal file that has splint and ghcide 8.33s user 1.38s system 101% cpu 9.579 total:
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update time ghcide
ghcide version: 0.2.0 (GHC: 8.8.3) (PATH: /nix/store/ngv8g1lv1nzwqp0wac5d0i6vfmxsj122-ghcide-0.2.0/bin/ghcide)
Ghcide setup tester in /home/will/code/exercises/haskell-exercises.
Report bugs at https://github.com/digital-asset/ghcide/issues

Step 1/4: Finding files to test in /home/will/code/exercises/haskell-exercises
Found 18 files

Step 2/4: Looking for hie.yaml files that control setup
Found 1 cradle

Step 3/4: Initializing the IDE

Step 4/4: Type checking the files
[INFO] Consulting the cradle for "/home/will/code/exercises/haskell-exercises/test/AdventOfCode/Day1Spec.hs"
> Resolving dependencies...
> Build profile: -w ghc-8.8.3 -O1
> In order, the following will be built (use -v for more details):
>  - haskell-exercises-<IP_ADDRESS> (lib) (configuration changed)
>  - haskell-exercises-<IP_ADDRESS> (test:haskell-exercises-test) (configuration changed)
> Configuring library for haskell-exercises-<IP_ADDRESS>..
> Preprocessing library for haskell-exercises-<IP_ADDRESS>..
> Building library for haskell-exercises-<IP_ADDRESS>..
> Configuring test suite 'haskell-exercises-test' for haskell-exercises-<IP_ADDRESS>..
> Warning: The package has an extraneous version range for a dependency on an
> internal library: haskell-exercises -any && ==<IP_ADDRESS>, haskell-exercises -any
> && ==<IP_ADDRESS>. This version range includes the current package but isn't needed
> as the current package's library will always be used.
> Preprocessing test suite 'haskell-exercises-test' for haskell-exercises-<IP_ADDRESS>..
[INFO] Using interface files cache dir: /home/will/.cache/ghcide/main-a92ea35edd4cfe0347f9d9425ad905c5ba2c4e1a
[INFO] Making new HscEnv[main]
[INFO] Consulting the cradle for "/home/will/code/exercises/haskell-exercises/src/Common/Primes.hs"
> Resolving dependencies...
> Build profile: -w ghc-8.8.3 -O1
> In order, the following will be built (use -v for more details):
>  - haskell-exercises-<IP_ADDRESS> (lib) (configuration changed)
> Configuring library for haskell-exercises-<IP_ADDRESS>..
> Preprocessing library for haskell-exercises-<IP_ADDRESS>..
[INFO] Using interface files cache dir: /home/will/.cache/ghcide/haskell-exercises-<IP_ADDRESS>-inplace-b4e0a8652609d44b7c9fd0bfa0e95f0d3b384925
[INFO] Using interface files cache dir: /home/will/.cache/ghcide/main-d3742137e0e88c8f86158187a0f63a20d69a2da9
[INFO] Making new HscEnv[haskell-exercises-<IP_ADDRESS>-inplace,main]
[INFO] Consulting the cradle for "/home/will/code/exercises/haskell-exercises/bench/BenchAll.hs"
> Resolving dependencies...
> Build profile: -w ghc-8.8.3 -O1
> In order, the following will be built (use -v for more details):
>  - haskell-exercises-<IP_ADDRESS> (lib) (configuration changed)
>  - haskell-exercises-<IP_ADDRESS> (bench:haskell-exercises-bench) (configuration changed)
> Configuring library for haskell-exercises-<IP_ADDRESS>..
> Preprocessing library for haskell-exercises-<IP_ADDRESS>..
> Building library for haskell-exercises-<IP_ADDRESS>..
> Configuring benchmark 'haskell-exercises-bench' for haskell-exercises-<IP_ADDRESS>..
> Warning: The package has an extraneous version range for a dependency on an
> internal library: haskell-exercises -any && ==<IP_ADDRESS>, haskell-exercises -any
> && ==<IP_ADDRESS>. This version range includes the current package but isn't needed
> as the current package's library will always be used.
> Preprocessing benchmark 'haskell-exercises-bench' for haskell-exercises-<IP_ADDRESS>..
[INFO] Using interface files cache dir: /home/will/.cache/ghcide/main-8bab1fe4d73f15810e0acc7d36264bddd7d2fd03
[INFO] Using interface files cache dir: /home/will/.cache/ghcide/haskell-exercises-<IP_ADDRESS>-inplace-4749039437757701ff7f79b2460659a78f7eb2b3
[INFO] Using interface files cache dir: /home/will/.cache/ghcide/main-8bab1fe4d73f15810e0acc7d36264bddd7d2fd03
[INFO] Making new HscEnv[main,haskell-exercises-<IP_ADDRESS>-inplace,main]

Completed (18 files worked, 0 files failed)
ghcide  8.33s user 1.38s system 101% cpu 9.579 total
λ ~/code/exercises/haskell-exercises/ ghcide-0.2.0-update*

Wonder if I can add a build flag to work aroud this issue without having to stop using splint.

The first post talks about a regression of > 1 min, but might that have been an initial compile? hie-bios can take up to hours, as it first calls stack build/cabal build, and that might build half of Hackage.
Later measurements seem to be saying we've dropped from 7.5s to 10s? We expected the introduction of multi-component to impose about a 25% performance reduction (see #522), and neither number seems too concerning.

The first post talks about a regression of > 1 min, but might that have been an initial compile?

It was taking > 1 min every time I call ghcide in the terminal. Later measurement was just to show it was resolved by removing splint. Going from 7.5s to 10s by using multi-components seems fine to me. I'm not sure if this is an issue affecting any GHC plugin or an issue with splint. I opened an issue with that plugin (mentioned above) to make the author aware of it. Feel free to close if you feel this is not a ghcide problem.

If you put back split, does it take 1m to do ghcide? And do you see a similar delay when starting the IDE? This is using GHC 8.8.3, so split will be reparsing the source code, but shouldn't have much delay. I imagine a no-op plugin would also cause a delay, so my guess is a regression between source plugins and multi component. Maybe the source plugin gets repeatedly reloaded?
CC @mpickering who might be interested, but I suspect there's some detective work to prove the above theory first.

If you put back splint, does it take 1m to do ghcide?

It does. I double checked that.

And do you see a similar delay when starting the IDE?

I do. I haven't timed it, but It takes noticeable longer amount of time to start and restart lsp-workspace-restart in Emacs. With splint removed, from the time I restart to the time I get pop-up documentation seems like only a couple of seconds.
Plugin author replied here pointing out possible causes. I'll probably reply to that later today.

with this plugin: https://github.com/mbj/source-constraints added to all three components time ghcide gets:
10.09s user 1.58s system 108% cpu 10.731 total

With this no-opt plugin (which I got from here) added as a module to the library component and the test and bench components using it with -fplugin=DoNothing.Plugin:
module DoNothing.Plugin (plugin) where

import GhcPlugins

plugin :: Plugin
plugin = defaultPlugin { installCoreToDos = install }

install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
install _ todo = do
  putMsgS "Hello!"
  return todo

time ghcide gets:
9.89s user 1.52s system 106% cpu 10.728 total

I also tried to run https://github.com/kowainik/smuggler, but I couldn't get it to build for some reason.
Attempting to run time ghcide when it's not building takes 45.34s user 5.26s system 96% cpu 52.178 total and produces a lot of output with the same error for each file. I'm not sure it that's of any interest or relevance.
I even copied the Splint code directly into my project to test using the plugin the same way I was using the no-opt plugin and the issue remains.
I'm not sure how to proceed. Have any ideas?

So it's suggestive that something in Splint is at fault (and by that, it probably means HLint underneath). A profile would be great, but I'm not sure if that's even remotely plausible to profile both Ghcide and Split in one go.
What is the time to run HLint on each file in isolation? e.g. for *.hs do hlint ..., not a single HLint run.

It takes 3 - 4 seconds.
λ ~/code/exercises/haskell-exercises/ master* time find -name '*.hs' | xargs -I {} sh -c "echo {};hlint {}"
./src/AdventOfCode/Day2.hs
No hints
./src/AdventOfCode/Day4.hs
No hints
./src/AdventOfCode/Day1.hs
No hints
./src/AdventOfCode/Day3.hs
No hints
./src/AdventOfCode/Day5.hs
No hints
./src/Common/Helpers.hs
No hints
./src/Common/Fibonacci.hs
No hints
./src/Common/Primes.hs
No hints
./src/ProjectEuler/Problems.hs
No hints
./test/AdventOfCode/Day2Spec.hs
No hints
./test/AdventOfCode/Day4Spec.hs
No hints
./test/AdventOfCode/Day5Spec.hs
No hints
./test/AdventOfCode/Day1Spec.hs
No hints
./test/AdventOfCode/Day3Spec.hs
No hints
./test/Main.hs
No hints
./test/ProjectEuler/ProblemsSpec.hs
No hints
./test/CommonSpec.hs
No hints
./bench/BenchAll.hs
No hints
./dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/b/haskell-exercises-bench/build/haskell-exercises-bench/autogen/Paths_haskell_exercises.hs
No hints
./dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/autogen/Paths_haskell_exercises.hs
No hints
./dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/autogen/Paths_haskell_exercises.hs
No hints
find -name '*.hs'  0.00s user 0.00s system 95% cpu 0.002 total
xargs -I {} sh -c "echo {};hlint {}"  3.86s user 0.13s system 97% cpu 4.078 total

If you build the project however you normally do, both with/without Splint enabled, what's the time difference?

I added a redundant bracket so I could see that the linter is running or not in the build output.
without Splint:
λ ~/code/exercises/haskell-exercises/ master* cabal clean
λ ~/code/exercises/haskell-exercises/ master* time cabal build
Resolving dependencies...
Build profile: -w ghc-8.8.3 -O1
In order, the following will be built (use -v for more details):
 - haskell-exercises-<IP_ADDRESS> (lib) (first run)
Configuring library for haskell-exercises-<IP_ADDRESS>..
Preprocessing library for haskell-exercises-<IP_ADDRESS>..
Building library for haskell-exercises-<IP_ADDRESS>..
[1 of 9] Compiling AdventOfCode.Day1 ( src/AdventOfCode/Day1.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day1.o )
[2 of 9] Compiling AdventOfCode.Day2 ( src/AdventOfCode/Day2.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day2.o )
[3 of 9] Compiling AdventOfCode.Day3 ( src/AdventOfCode/Day3.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day3.o )
[4 of 9] Compiling AdventOfCode.Day4 ( src/AdventOfCode/Day4.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day4.o )
[5 of 9] Compiling AdventOfCode.Day5 ( src/AdventOfCode/Day5.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day5.o )
[6 of 9] Compiling Common.Fibonacci ( src/Common/Fibonacci.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/Common/Fibonacci.o )
[7 of 9] Compiling Common.Helpers   ( src/Common/Helpers.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/Common/Helpers.o )
[8 of 9] Compiling Common.Primes    ( src/Common/Primes.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/Common/Primes.o )
[9 of 9] Compiling ProjectEuler.Problems ( src/ProjectEuler/Problems.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/ProjectEuler/Problems.o )
cabal build  3.88s user 0.43s system 98% cpu 4.366 total

with Splint:
λ ~/code/exercises/haskell-exercises/ master* cabal clean
λ ~/code/exercises/haskell-exercises/ master* time cabal build
Resolving dependencies...
Build profile: -w ghc-8.8.3 -O1
In order, the following will be built (use -v for more details):
 - haskell-exercises-<IP_ADDRESS> (lib) (first run)
Configuring library for haskell-exercises-<IP_ADDRESS>..
Preprocessing library for haskell-exercises-<IP_ADDRESS>..
Building library for haskell-exercises-<IP_ADDRESS>..
[1 of 9] Compiling AdventOfCode.Day1 ( src/AdventOfCode/Day1.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day1.o )
[2 of 9] Compiling AdventOfCode.Day2 ( src/AdventOfCode/Day2.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day2.o )
[3 of 9] Compiling AdventOfCode.Day3 ( src/AdventOfCode/Day3.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day3.o )
[4 of 9] Compiling AdventOfCode.Day4 ( src/AdventOfCode/Day4.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day4.o )
[5 of 9] Compiling AdventOfCode.Day5 ( src/AdventOfCode/Day5.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/AdventOfCode/Day5.o )
[6 of 9] Compiling Common.Fibonacci ( src/Common/Fibonacci.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/Common/Fibonacci.o )
[7 of 9] Compiling Common.Helpers   ( src/Common/Helpers.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/Common/Helpers.o )

src/Common/Helpers.hs:10:15: warning:
    Redundant bracket
    Perhaps: acc
   |
10 |   go !acc 0 = (acc)
   |               ^^^^^
[8 of 9] Compiling Common.Primes    ( src/Common/Primes.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/Common/Primes.o )
[9 of 9] Compiling ProjectEuler.Problems ( src/ProjectEuler/Problems.hs, /home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/build/ProjectEuler/Problems.o )
cabal build  4.90s user 0.48s system 99% cpu 5.426 total

It looks to have added about a second to the build time. I ran it a few times with and without splint and I didn't see a lot of variance.

So I looked into this a bunch back in June, got distracted and forgot about it and recently decided to look into it again some more. What I found is that it has something to do with the environment provided by the nix GHC with packages wrapper. The nix derivation I use to set up the environment uses developPackage, which uses that wrapper. I stumbled on that because I setup another fresh cabal project with nothing but "Hello, World" where I couldn't replicate the issue.
I used printenv to dump the environmental variables and painstakingly searched for what could be different between the two environments provided by nix (although through different methods).
It turned out the ordering of ghc-8.8.4 and ghc-8.8.4-with-packages in my PATH environment variable was the difference. When ghc-8.8.4-with-packages comes first, then ghcide takes a minute. When ghc-8.8.4 comes first, then it takes ~7 seconds. From my understanding with-packages is using packages already built by nix using the same compiler version. When I use ghc without packages cabal is used to build what's needed and caches them in some folder (maybe ~/.cabal/packages/hackage.haskell.org/).
It's still a mystery exactly what's wrong though. I added a bunch of logging to ghcide, compiled, and used that for testing to try to find where in the code it is going slow, but didn't really get anywhere. I really should take the time to learn to profile Haskell code properly.
I did try throwing a Strict language pragma at the top of Main.hs just to see if blindly making the code more strict would change what I was seeing. I randomly would get this error when I did that, but that could be unrelated:
[DEBUG] session done
[INFO] Consulting the cradle for "/home/will/code/tester/plugins/TestPlugin.hs"
> Resolving dependencies...
> cabal: internal error: eval_thunk_selector: strange selectee 4345696
>     (GHC version 8.8.4 for x86_64_unknown_linux)
>     Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
[DEBUG] Session loading result: Left [CradleError (ExitFailure (-6)) ["Failed to parse result of calling cabal","Resolving dependencies...\n","cabal: internal error: eval_thunk_selector: strange selectee 4345696\n    (GHC version 8.8.4 for x86_64_unknown_linux)\n    Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug\n",""]]
File:     /home/will/code/tester/plugins/TestPlugin.hs
Hidden:   no
Range:    1:0-2:0
Source:   cradle
Severity: DsError
Message:
  Failed to parse result of calling cabal
  Resolving dependencies...

  cabal: internal error: eval_thunk_selector: strange selectee 4345696
  (GHC version 8.8.4 for x86_64_unknown_linux)
  Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug

I suspect the Strict is unrelated - it's a feature that's not heavily used and provokes bugs.
No idea why including more packages hurts things. I note that all-packages probably includes the GHC API included, but HLint uses ghc-lib - a copy of the GHC library. However, Ghcide also uses GHC API, so I don't see why that would change anything. I'm really at a loss.


Export supported_features of light.isy994

Description:
Related issue (if applicable): fixes #5428
Checklist:
If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] Tests have been added to verify that the new code works.

Thank you @andrey-git for quickly addressing the issue even though you don't have an ISY994. 🍺
Taking the comments from this PR, I have addressed the issue in a different way in PR #5433 and tested to confirm the ISY component still works. I'll go ahead and close this PR so the new one can be reviewed.


[Ubuntu 20.04] Setup fails when provisioning VMs due to DNS error

My setup: base vanilla server with just needed packaged installed
vars/k8s_cluster.yml changes: container runtime containerd and kube version 1.21
Error

PLAY [Check connection and set facts] **********************************************

TASK [Wait 600 seconds for target connection to become reachable/usable] ***********
fatal: [k8s-test-master-0.k8s.test]: FAILED! => {"changed": false, "elapsed": 600, "msg": "timed out waiting for ping module test: Failed to connect to the host via ssh: ssh: Could not resolve hostname k8s-test-master-0.k8s.test: Name or service not known"}
fatal: [k8s-test-master-2.k8s.test]: FAILED! => {"changed": false, "elapsed": 600, "msg": "timed out waiting for ping module test: Failed to connect to the host via ssh: ssh: Could not resolve hostname k8s-test-master-2.k8s.test: Name or service not known"}
fatal: [k8s-test-worker-0.k8s.test]: FAILED! => {"changed": false, "elapsed": 600, "msg": "timed out waiting for ping module test: Failed to connect to the host via ssh: ssh: Could not resolve hostname k8s-test-worker-0.k8s.test: Name or service not known"}
fatal: [k8s-test-master-1.k8s.test]: FAILED! => {"changed": false, "elapsed": 600, "msg": "timed out waiting for ping module test: Failed to connect to the host via ssh: ssh: Could not resolve hostname k8s-test-master-1.k8s.test: Name or service not known"}

PLAY RECAP *************************************************************************
k8s-test-master-0.k8s.test : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
k8s-test-master-1.k8s.test : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
k8s-test-master-2.k8s.test : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
k8s-test-worker-0.k8s.test : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
localhost                  : ok=36   changed=24   unreachable=0    failed=0    skipped=16   rescued=0    ignored=0

make: *** [Makefile:13: create] Error 2

DNS resolution from host is in fact broken
DNS resolution from inside the vms works
More Infos
virsh list --all
 Id   Name                State
-----------------------------------
 1    k8s-test-master-2   running
 2    k8s-test-master-1   running
 3    k8s-test-master-0   running
 4    k8s-test-worker-0   running

 Name       MAC address          Protocol     Address
-------------------------------------------------------------------------------
 vnet0      52:54:00:b6:34:b9    ipv4         <IP_ADDRESS>/24

 Name       MAC address          Protocol     Address
-------------------------------------------------------------------------------
 vnet2      52:54:00:f6:86:8c    ipv4         <IP_ADDRESS>/24

 Name       MAC address          Protocol     Address
-------------------------------------------------------------------------------
 vnet1      52:54:00:b2:12:c5    ipv4         <IP_ADDRESS>/24

 Name       MAC address          Protocol     Address
-------------------------------------------------------------------------------
 vnet3      52:54:00:1e:93:48    ipv4         <IP_ADDRESS>/24

dig k8s-test-master-0.k8s.test

; <<>> DiG 9.16.1-Ubuntu <<>> k8s-test-master-0.k8s.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40048
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;k8s-test-master-0.k8s.test.	IN	A

;; AUTHORITY SECTION:
.			42	IN	SOA	a.root-servers.net. nstld.verisign-grs.com.<PHONE_NUMBER> 1800 900<PHONE_NUMBER>0

;; Query time: 3 msec
;; SERVER: <IP_ADDRESS>#53(<IP_ADDRESS>)
;; WHEN: Tue Oct 12 09:09:57 UTC 2021
;; MSG SIZE  rcvd: 130

resolvectl query k8s-test-master-0.k8s.test
k8s-test-master-0.k8s.test: <IP_ADDRESS>     -- link: k8s-test

-- Information acquired via protocol DNS in 1.0ms.
-- Data is authenticated: no

I think that are the NS of equinix metal, the provider of the bare metal server where I'm running this.