29_fortune_cookie_1.py bug

#hacktoberfest
Delete redundant elif statment
random_fortune can never be 8 (random.randint(0, 7)) and the options list has no element at index 8

Post October Monthly Challenge cleanup. It's changing 24 files here :( Have to close this one.


doctrine/orm v3 - Declaration of ClassMetadataFactory::newClassMetadataInstance($className)

Hello,
Got this error after upgrading to ORM v3:
Child process error (exit code 255): Fatal error: Declaration of PHPStan\Doctrine\Mapping\ClassMetadataFactory::newClassMetadataInstance($className) must be compatible with
Doctrine\ORM\Mapping\ClassMetadataFactory::newClassMetadataInstance(string $className): Doctrine\ORM\Mapping\ClassMetadata in
vendor/phpstan/phpstan-doctrine/src/Doctrine/Mapping/ClassMetadataFactory.php on line 60

Currently ORM v3 is not supported, I took a look and it's not easy  to fix (https://github.com/phpstan/phpstan-doctrine/pull/531)

Hello, phpstan-doctrine is not yet fully compatible and verified to work with Doctrine ORM 3.0 and DBAL 4.0, but I did some work to make forward-compatible changes that should work both with old and new versions: https://github.com/phpstan/phpstan-doctrine/compare/9534fcd0b6906c62594146b506acadeabd3a99b3...30cf38dda057a78180c4df1f6f41e33eb49c4eca
These changes have just been released in phpstan-doctrine 1.3.60: https://github.com/phpstan/phpstan-doctrine/releases/tag/1.3.60 Please report back how they work for you, thanks.
The work on full compatibility with Doctrine ORM 3.0 and DBAL 4.0 continues in https://github.com/phpstan/phpstan-doctrine/pull/535.

Please continue the discussion in https://github.com/phpstan/phpstan-doctrine/issues/529, thanks.


Add JavaModule.mandatoryJavacOptions

This will hold options contributed by traits like ErrorProneModule.
Those are not propagated to the inner test traits intentionally, since those options are typically configured by other means, e.g. dedicated targets.

I think the idea sounds reasonable. Why is it called managed instead of mandatory? Should we standardize on one name?
In the past the convention was just that mandatory* were things that traits would set and end users wouldn't. Are we adding a new convention that they're also not propagated? That seems fine, but is something to be aware of (and probably should be written down somewhere)

I though about mandatory, but went with a different name as the main goal was to have a different propagation behavior then the preexisting mandatoryIvyDeps and mandatoryScalacOptions.
Both could be changed to no propagate (their value should still compute to the same value, which is a good idicator), but unfortunately, this would be a binary incompatible change and has to wait for Mill 2.13.
For the sake of consistency, I can change to mandatoryJavacOptions, although the name is even less specific.

Changed to mandatoryJavacOptions.

What if we exposed a task in JavaModule that decides how dependencies are propagated to the Tests submodules?
It could be something like:
def javacOptionsTestsPropagation: Task[Seq[String] => Seq[String]] = T.task { identity }

This way your plugin can override it to filter out the option that you don't want to propagate.

I think filtering options isn't my favorite go-to solution, since it's always a bit error-prone. Since we use stackable traits which can't be remove we also should take care to not add unnecessary options, which can't be easily removed.

I took the opportunity to no longer propagate mandatoryScalacOptions to see if all tests pass. They should. I kept the override to just can super, so that binaries expecting this def in ScalaTests should work without issues.

I checked, we're not propagating mandatoryIvyDeps to tests, so we now no longer propagate any mandatory* target to tests. Nice and consistent.


Redirect loop at YOURLS root

hi

Closing until more details are added.

install subdomain
url.linuxfedora.ir
But I get the following error
((This problem can sometimes be caused by disabling or refusing to accept cookies.))
https://pasteboard.co/Hu6GGui.png

@dgw

http://url.linuxfedora.ir/admin/ works, so YOURLS is at least installed and configured that much.
The root of that domain is stuck in a 302 redirect loop to itself, which is why you see that error. This is usually a server configuration issue. I can't help you any more specifically without knowing more about your environment. For this issue, HTTP server (Apache or Nginx) and version would be a good start.
I don't know why you've :-1:'d my closing comment. There was literally no way that anyone could even try to help until you provided details of the problem, starting with a proper error message. ("This problem can sometimes be caused by disabling or refusing to accept cookies" is a hint for the user, not an error that the webmaster can act on. The real error is above that: "Firefox has detected that the server is redirecting the request for this address in a way that will never complete.")

@LeoColomb, where's majordome when we actually want it to prompt for missing issue templates? :joy_cat:

@dgw Hu hu, sorry, majordome is still sleeping most of the time! 😄
@arjahanifard I have to second @dgw, you're a not providing any information, and you have cleaned out the issue template.
Please take a look at the Contribution Guidelines, which will tell you exactly what your ticket has to contain in order to be processable.

Your /admin/ works, so YOURLS is at least installed and configured that much.
The root of that domain is stuck in a 302 redirect loop to itself, which is why you see that error. This is usually a server configuration issue. I can't help you any more specifically without knowing more about your environment. For this issue, HTTP server (Apache or Nginx) and version would be a good start.
I don't know why you've 👎'd my closing comment. There was no way that anyone could even try to help until you provided details of the problem, starting with a proper error message. ("This problem can sometimes be caused by disabling or refusing to accept cookies" is a hint for the user, not an error that the webmaster can act on. The real error is above that: "Firefox has detected that the server is redirecting the request for this address in a way that will never complete.")
@LeoColomb, where's majordome when we actually want it to prompt for missing issue templates? 😹

i have the same issue
here is my nginx conf
  # HTTPS over IPv4 & IPv6
  listen 443 ssl; # managed by Certbot
  ssl_certificate /etc/letsencrypt/live/url.waitforaday.site/fullchain.pem; # managed by Certbot
  ssl_certificate_key /etc/letsencrypt/live/url.waitforaday.site/privkey.pem; # managed by Certbot
  include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

  # Server names
  server_name url.waitforaday.site;
  error_log   /var/log/nginx/url.waitforaday.site_error.log;

  # Root directory
  root /www/url;

  # Rewrites
  location / {
    index /yourls-loader.php;
    #try_files $uri $uri/ /yourls-loader.php$is_args$args;
  }

  # PHP engine
  location ~ \.php$ {
    include fastcgi.conf;
    # OR
    # include fastcgi_params;
    fastcgi_index index.php;
    fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
  }
}
server {
  if ($host = url.waitforaday.site) {
      return 301 https://$host$request_uri;
  } # managed by Certbot
	server_name url.waitforaday.site;
  listen 80;
  return 404; # managed by Certbot
}


Will not run on ChromeOS dev build

Please search to check for an existing issue (including closed issues, for which the fix may not have yet been released) before opening a new issue: https://github.com/k9mail/k-9/issues?q=is%3Aissue
Expected behavior
Tell us what should happen
App should run
Actual behavior
Tell us what happens instead
Will not run, just disappears.  After multiple tries, a dialog with choices pops up, saying it keeps crashing.  Selecting "send feedback" gives an icon on the taskbar, which will not close, nor will it open.  Cannot send feedback.
Steps to reproduce

Update chromebook to Version 74.0.3726.0 (Official Build) dev (64-bit).
Try to run K9

Environment
K-9 Mail version:
Not certain, since it won't run, but the latest version in the Play Store
Android version: ChromeOS Version 74.0.3726.0 (Official Build) dev (64-bit)
Account type (IMAP, POP3, WebDAV/Exchange):  IMAP
Please take some time to retrieve logs and attach them here:
Unable, since it won't run at all
This is probably a ChromeOS issue, since I'm having problems with other Android and Linux apps, but the developers should be made aware of it.  K9 runs as expected on my Pixel with latest Android updates.

I switched my ChromeOS device to 74.0.3726.0 and K-9 Mail installs and works fine for me.
I'm afraid without a debug log there's not much we can do.


ci: enable releases on main branch

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Unable to set cache path on appengine.

Since all Directories are read only, I am unable to set a cache path on app engine. I have tried to overide the config by using database as the drive but no success, could anyone assist please
InvalidArgumentException
Please provide a valid cache path.

The cache path can be set to /tmp, which is writeable and ephemeral (it will be destroyed once the instance shuts down).
Which sample are you running?

If you're running Symfony, put the following in your Kernel class in src/Kernel.php:
    public function getCacheDir()
    {
        if ($this->environment === 'prod') {
            return sys_get_temp_dir();
        }
        return parent::getCacheDir();
    }

    public function getLogDir()
    {
        if ($this->environment === 'prod') {
            return sys_get_temp_dir();
        }
        return parent::getLogDir();
    }


babel presents

I am trying to make browserify transforms with babelify work, but I do not understand how to pass in the es2015 presents option. In other configurations I have seen this:
browserify: {
      debug: true,
      transform: [ 'babelify',{
        presets: ['es2015']
      } ]
    },

this however causes an error in async.js [framework.browserify]: Error: path must be a string. Is there a way to make it work?

Have you tried specifying babel transforms in the .babelrc file?

That's not the correct syntax. transform itself is an array so you'll need this:
browserify: {
  debug: true,
  transform: [
    ['babelify',{
      presets: ['es2015']
    }]
  ]
}

@bendrucker  thanks :D


Gradle.properties in nested multi-projects isn't being read

If I have a multi-project within my root project, the gradle.properties file in the multi-project directory is not being read. The documentation contradicts that behavior.
Expected Behavior

Each gradle.properties file from the project directory up to the build root directory should potentially be read (or documentation should be corrected to match behavior)
Current Behavior

gradle.properties in the leaf project directory is read and then the gradle.properties file in the build root directory is read. Any other gradle.properties file in the directory tree are not read
Some investigate was done in the forums: https://discuss.gradle.org/t/reading-of-gradle-properties-in-nested-projects/45203/2
Context

I have a top level multi-project build that’s acting as an umbrella build and I have a nested multi-project that has a couple of subprojects. Here’s the structure:
umbrella proj
- settings.gradle (includes multi-proj:libA)
- gradle.properties (1)
- multi-proj (includes libA)
-- gradle.properties (2)
-- libA
--- gradle.properties (3)

I wanted to use the same version for the different subprojects of my multi-proj. I figured I could set it in one place, the gradle.properties in the multi-project directory.
I’ve been running gradle jar in the umbrella directory. If I set the version in (1), libA’s jar file name includes that. If I set version in (3), it uses that instead of (1). If I unset it in (3) and set it in (2), it ignores (2) and uses (1).
Give this text from build environment section of the docs, I assumed that (2) should also be read at some point:
gradle.properties in the project’s directory, then its parent project’s directory up to the build’s root directory.
Steps to Reproduce

Sample project here: https://github.com/cgarman/gradle-properties-test
Your Environment

Gradle 8.0.2. Java 17. macOS 12.6.3

Thank you for providing a valid reproducer.
The issue is in the backlog of the relevant team but this area of Gradle is currently not a focus one so it might take a while before a fix is made.

Relates to

https://github.com/gradle/gradle/issues/23572


PD Batch Edit Mix Announcement Modal

Placeholder ticket for announcement modal for the Batch Edit: Mix feature!

Closed by #7628


ValueError: ('%s is not decorated with @add_arg_scope', ('nets.mobilenet.mobilenet', 'depth_multiplier'))

Hi, I get a weird error when I am about to start fine tuning the ssd mobilenet v2 checkpoint:
python models/research/object_detection/legacy/train.py --alsologtostderr --train_dir=train  --pipeline_config_path=ssd_mobilenet_v2_quantized_300x300_coco.config

Error:
Traceback (most recent call last):
  File "models/research/object_detection/legacy/train.py", line 186, in <module>
    tf.app.run()
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/tensorflow/python/platform/app.py", line 40, in run
    _run(main=main, argv=argv, flags_parser=_parse_flags_tolerate_undef)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/absl/app.py", line 299, in run
    _run_main(main, args)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/absl/app.py", line 250, in _run_main
    sys.exit(main(argv))
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/tensorflow/python/util/deprecation.py", line 324, in new_func
    return func(*args, **kwargs)
  File "models/research/object_detection/legacy/train.py", line 182, in main
    graph_hook_fn=graph_rewriter_fn)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/object_detection/legacy/trainer.py", line 291, in train
    clones = model_deploy.create_clones(deploy_config, model_fn, [input_queue])
  File "/workspace/workspace/test/models/research/slim/deployment/model_deploy.py", line 192, in create_clones
    outputs = model_fn(*args, **kwargs)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/object_detection/legacy/trainer.py", line 204, in _create_losses
    prediction_dict = detection_model.predict(images, true_image_shapes)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/object_detection/meta_architectures/ssd_meta_arch.py", line 568, in predict
    preprocessed_inputs)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/object_detection/models/ssd_mobilenet_v2_feature_extractor.py", line 118, in extract_features
    [mobilenet.depth_multiplier], min_depth=self._min_depth):
  File "/usr/lib/python3.5/contextlib.py", line 59, in __enter__
    return next(self.gen)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/tensorflow/contrib/framework/python/ops/arg_scope.py", line 152, in arg_scope
    _name_op(op))
ValueError: ('%s is not decorated with @add_arg_scope', ('nets.mobilenet.mobilenet', 'depth_multiplier'))

I am using the last version of the models repository and I've only changed the directory paths for the records, labelmaps, the number of classes and number of testing samples.  Moreover I am using the 1.14.0 of Tensorflow.
How can I solve it?

Hi, I get a weird error when I am about to start fine tuning the ssd mobilenet v2 checkpoint:
python models/research/object_detection/legacy/train.py --alsologtostderr --train_dir=train  --pipeline_config_path=ssd_mobilenet_v2_quantized_300x300_coco.config

Error:
Traceback (most recent call last):
  File "models/research/object_detection/legacy/train.py", line 186, in <module>
    tf.app.run()
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/tensorflow/python/platform/app.py", line 40, in run
    _run(main=main, argv=argv, flags_parser=_parse_flags_tolerate_undef)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/absl/app.py", line 299, in run
    _run_main(main, args)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/absl/app.py", line 250, in _run_main
    sys.exit(main(argv))
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/tensorflow/python/util/deprecation.py", line 324, in new_func
    return func(*args, **kwargs)
  File "models/research/object_detection/legacy/train.py", line 182, in main
    graph_hook_fn=graph_rewriter_fn)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/object_detection/legacy/trainer.py", line 291, in train
    clones = model_deploy.create_clones(deploy_config, model_fn, [input_queue])
  File "/workspace/workspace/test/models/research/slim/deployment/model_deploy.py", line 192, in create_clones
    outputs = model_fn(*args, **kwargs)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/object_detection/legacy/trainer.py", line 204, in _create_losses
    prediction_dict = detection_model.predict(images, true_image_shapes)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/object_detection/meta_architectures/ssd_meta_arch.py", line 568, in predict
    preprocessed_inputs)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/object_detection/models/ssd_mobilenet_v2_feature_extractor.py", line 118, in extract_features
    [mobilenet.depth_multiplier], min_depth=self._min_depth):
  File "/usr/lib/python3.5/contextlib.py", line 59, in __enter__
    return next(self.gen)
  File "/workspace/workspace/test/.env/lib/python3.5/site-packages/tensorflow/contrib/framework/python/ops/arg_scope.py", line 152, in arg_scope
    _name_op(op))
ValueError: ('%s is not decorated with @add_arg_scope', ('nets.mobilenet.mobilenet', 'depth_multiplier'))

I am using the last version of the models repository and I've only changed the directory paths for the records, labelmaps, the number of classes and number of testing samples. Moreover I am using the 1.14.0 of Tensorflow.
How can I solve it?

You need to install tf-slim 1.1.0


improvementDrop column stats after schema change.

Drop column stats after schema change. So the auto analyze could be triggered and will collect stats under new schema.

run buildall

run cloud_p0

run cloud_p1


Proposal: Decouple Profile Resolution from Zonefile URLs

Proposal
User profiles are increasingly used to host control-plane state in BNS.  What this means is that we need to do a better job of ensuring that the control-plane information remains as available as possible.  In particular, the inability to resolve a user's profile means that a user's multiplayer data remains inaccessible, even if it is online.
In this proposal, I recommend adding a field in the user's profile called api.bns.replicas.  This field maps to some state that includes a URL that points to the primary replica of the user's profile (as well as any authoritative secondary replicas), if different from that in the zone file.  The point of this field is to (a) make it easy for users to change where their latest profile is hosted, if different from the zone file, and (b) make it possible for profiles to be stored and resolved by many different non-authoritative nodes called profile resolvers.
The ultimate purpose of adding this field is to make it possible to remove the need for a zone file URL to remain valid forever.  To achieve this, the proposal for blockstack.js documented here is coupled with another proposal to build up a network of profile resolvers, just as we currently do with zone files.  Each profile resolver node can host non-authoritative replicas of profiles on behalf of other users who want to resolve the profile.  If the user's profile's api struct is sufficiently fresh on them, then any such node can direct other clients towards the user's authoritative replicas.
This issue was touched on briefly here.
Background
Resolving a name to a profile is a two-step process today:  (1) fetch and authenticate the name's zone file, and (2) use the URI record to fetch and authenticate the name's associated profile.  The original thinking in the BNS system design was that the user should always be able to control where their profile could be found.  At the time, it was thought that the user's profile and zone file would be tightly coupled -- the zone file information would always be followed, and the information it contained always need to be chain-anchored in order to render it as difficult as possible to censor profile URL updates.  The current design does this by ensuring that all BNS nodes have a copy of the latest URI record (by means of having the latest zone file data for all BNS names), and if they don't, they can at least inform clients that the zone file they need is missing.
However, there are several limitations to this approach:

Changing a profile URL is expensive and time-consuming -- someone has to send a blockchain transaction (either a subdomain update batch, or an on-chain NAME_UPDATE).

The benefits of requiring a blockchain transaction each time the user changes their profile URL are questionable in practice.  In particular, if a popular Gaia hub goes offline permanently, the act of mass-migrating its many users away from it will make the transaction-generation process slower and more expensive and will upset many users (who may have their data knocked offline for some time -- at least, until the transactions confirm).

Related to what happens if a Gaia hub crashes and goes offline, right now the BNS system has no way to allow users to specify alternative replicas of their profile, and offers no way to propagate knowledge of other authoritative replicas to Blockstack Core nodes.  This is problematic because it makes it possible for a large Gaia hub failure to prevent off-chain data from being resolved -- even if the user runs their own Gaia hub for app-specific data!

When the user registers a BNS name, they usually do not appreciate the need to run their own Gaia hub or choose one besides the default.  If they discover the need to do so later, they need to go through the difficult process of updating their BNS zone file.

What I'm suggesting we do is decouple a BNS name's profile from its zone file URL. We could remove the need to send a zone file update altogether by treating the zone file URL as the initial replica URL instead of the primary replica URL, and use some state in the profile itself to help clients determine where the primary replica can be found.  In the design below, we would be able to make it so a user's profile could be hosted on many different Gaia hubs (including stale copies), but the user would be able to designate which replica should be treated as fresh.
Design
By far the most important pieces of control-plane information obtained from the user's profile are:

The user's owner public key
The URLs to each multiplayer application's Gaia hubs
The Gaia hub configuration

All of this information must be present and available to clients in order to interact with other users' data.  Right now, we don't do a good job of ensuring that this data is highly available -- it is only as available as the user's initially-chosen Gaia hub (which they almost certainly did not choose themselves).
What I recommend is making it so profiles contain an additional piece of control-plane state to point to the user's authoritative profile replicas.  That is, the user can decide that the profile pointed to by the zone file is not the profile's primary replica, and can do so completely off-chain.  While this adds one extra step to resolving the user's profile, the upsides are that (a) users now have a way to migrate their profiles off of Gaia hubs without a transaction, (b) users can ensure their control-plane data is available from many sources, and (c) clients can use non-authoritative resolvers to direct them towards authoritative profile replicas.
To achieve all this, the user's profile would store the following extra fields:

api.bns.replicas -- this contains an entry called urls that is a list of url and ttl fields:

api.bns.replicas.urls[].url -- this is a URL to the user's profile replica.
api.bns.replicas.urls[].ttl -- this is the time-to-live for caching the profile replica URL, and is used by downstream and non-authoritative profile resolvers to help clients find an authoritative replica.

api.bns.replicas.sequence -- this is a monotonically-incrementing sequence number that the profile owner increments whenever they replicate new profile data.  The sequence number is used to invalidate older cached data in the profile resolver network.

The profile resolution algorithms would work as follows.  The default slow-path case would be:
(1) given a BNS name, look up the zone file on a Core node and authenticate it
(2) given the profile URL, resolve it to the initial profile replica and authenticate it
(3) get the api.bns.replicas[0].url field if present.  If not, return the profile.
(4) if the api.bns.replicas[0].url is different than the URL in (2), fetch the profile it points to
(5) verify that the profile is signed by the same key as the initial profile replica
(6) if the new profile has a different api.bns.replicas[0].url field, go to (2)
(7) otherwise, return the profile

Step (2) can fail of the primary replica URL is set, but the data unavailable.  If this happens, then api.bns.replicas[1].url is tried, and so on.
Step (1) can fail if the initial replica URL does not resolve to valid profile data.  If this happens, then the user would fall back to a non-authoritative profile resolver (see below) and use it to find an authoritative replica.  The client would need to select one or more non-authoritative resolvers a priori.
To resolve a profile from a non-authoritative profile resolver, the client would:
(1) given a BNS name and a non-authoritative resolver, query the cached api.bns.replicas state
(2) verify that the state was signed by the BNS name owner (querying the key from a Core node)
(3) for each entry in api.bns.replicas, try to fetch the profile
(4) on success, verify that the profile was signed by the BNS name owner.  If not, go to (3)
(5) verify that the successfully-fetched URL is present in the profile's api.bns.replicas.  If not, go to (3)
(6) return the first profile to succeed

Clients should limit the number of profile resolution attempts made, discussed in the implementation section below.
Clients would learn a particular BNS name owner's preferred profile resolvers via a _profile_resolver URI entry in either their name's zone file, or the on-chain name's zone file.  The non-authoritative resolvers should be tried in the following order:

The URL in the user's name's zone file's _profile_resolver URI record, if given
If the name is off-chain, then the profile_resolver URI record in the corresponding on-chain name's zone file may be considered as well.
The set of public resolver nodes, described here.

Profile Updates
If for whatever reason a profile is rendered unresolvable, the user now has two courses of action:

Change the api.bns.replicas URLs and re-upload the profile to both the initial and new locations, if possible.  Also, upload the new profile to as many non-authoritative resolvers as possible.
Send a blockchain transaction that changes the initial replica URL to the desired primary replica URL.

The first option is preferred if possible because it can be done near-instantaneously and does not require a transaction.  Profile resolvers would need to allow the user to easily update their cached copies of the api.bns.replicas state.
The second option is slower and more expensive, but can be done far more cheaply for off-chain names via any off-chain subdomain registrar (recall that by design, any subdomain registrar can send an off-chain NAME_UPDATE for any other subdomain).
Profile Resolver Network
The initial replica URL may stop resolving to fresh profile data for a multitude of reasons.  If the user cannot or does not want to issue a new initial replica URL via a transaction, then the user would instead (a) replicate their profile to new locations and (b) replicate the new URLs to a network of non-authoritative profile resolvers.
If we're going to completely do away with the need for a zone file update, then we need to build out a network of profile resolvers that build up a cached mapping between a BNS name and its latest api.bns.replica control-plane state.  Anyone can run a profile resolver -- there is no coordination required between them, since a profile resolver only needs to be able to access the BNS name state to authenticate new profile information.  Profile resolvers would be designed to be able to serve as "downstream replicas" of other profile resolvers, and the client software would be aware of a set of "well-known" resolver nodes.
In fact, I'd like to ultimately make it an add-on service for Blockstack Core nodes, so any such Blockstack Core node can resolve a BNS name to its latest profile replica this way.  Moreover, personal-use Blockstack Core nodes that run on users' computers could be configured to lazily cache api.bns.replicas state on name lookups, so that a user that frequently interacts with other users can quickly learn their latest profile replica URLs.
Profile resolvers are not part of the trusted computing base, nor are they part of the consensus code.  They simply host downstream replicas of the user's profile in order to help clients find the user's authoritative replicas.  The worst they can do to clients is serve stale profiles, but this can be fixed by the user simply by either (1) re-keying their name, or (2) changing their initial replica in the zone file to point to their primary replica in their profile.
The proposed design of a profile resolver node is described here.  The availability of such a network would serve to allow users to update their profile URLs in a way that is still decentralized but without requiring a blockchain transaction.
Implementation
Implementing this proposal can be done in a backwards-compatible way.  All that needs to happen in blockstack.js is the lookupProfile method needs to be aware of api.bns state and handle it according to the above algorithms.
Validation and Caveats

The api.bns structure must be well-formed per the rules described above.  The replicas field must be a list, and each item must be an object with a url field that is a valid HTTP(S) URL, and an optional ttl field that is a non-negative integer.

The lookupProfile method should not attempt to make more than N sequential requests and M total requests to resolve a profile, in order to not keep the user waiting or suck up all of their bandwidth.  M and N can be something like 5 by default, but a caller may choose to override it.

The lookupProfile method needs to take a URL to at least one profile resolver as an optional parameter.  The RESTful interface to this resolver is documented with the profile resolve network
issue here

Conclusion
The need to make profile resolution work without zone files will be necessary for the long-term success of this project. This proposal adds an entry to the user's profile that tells clients where to go and look for the current profile, and treats the zone file URL as a URL to a stale profile that only needs to contain this pointer.  A sibling issue describes how to build a network of profile resolvers that allow the user to disseminate the location of their latest profile URLs to a wide variety of hosts, similar to how we do now with zone files.
Thoughts and feedback are welcome!

Tagged myself to make sure I review this (why don't github issues allow reviewers 👎 )

cc @hstove @yknl @markmhx

Thanks @jcnelson, this is great 👍
A couple of questions:
How do clients discover profile resolvers?
Who should determine which profile resolvers are used? Is it the app or user configuration?
What's the incentive for running a profile resolver, assuming it will use a non-trivial amount of disk space.

How do clients discover profile resolvers?

We would use BNS -- a profile resolver would register a BNS name for itself that contains a _profiles URI record that points to a service endpoint for updating and resolving profiles with new api.bns.replicas state (this is similar to how subdomain registrars get discovered today).  This is written up in detail here.
For example, If we deploy this scheme as described, we'd probably add a profile resolver entry to id.blockstack's zone file so people who own .id.blockstack off-chain names could use it to query and update newer profile URLs.  This node would likely be configured to only accept and serve profile data for BNS names that end in .id.blockstack, however.

Who should determine which profile resolvers are used? Is it the app or user configuration?

The user can ultimately choose which non-authoritative resolver(s) to query.  I updated the proposal to add a api.bns.replicas.resolvers[] list entry that contains the name owner's preferred list of non-authoritative resolvers, which other users can use to find subsequent profile data.
In addition, we could allow users to provide their preferred resolvers via a URI record in their zone file (_profile_resolver).

What's the incentive for running a profile resolver, assuming it will use a non-trivial amount of disk space.

There is no built-in incentive mechanism.  You would run your own profile resolver node if you wanted to ensure that you had up-to-date knowledge of everyone's current profile URLs, or you would pay someone else to do so on your behalf.  However, the user should be able to provide a hint to other users which resolvers to query.  I've updated the proposal to describe this.
In the document detailing the profile resolver node, the network of profile resolvers would end up looking a lot like DNS servers today -- there would be a set of "public" profile resolvers that index any BNS name's profile URLs, and there would be a set of "private" profile resolvers that would only index some BNS name's profile URLs.  The public ones would be discovered via BNS -- they would have dedicated BNS names and would have a _profiles URI record that identified their service points.  The private ones would be listed either in the user's profile or zone file.
Specific to off-chain names in use today, we would probably run a "private" profile resolver for .id.blockstack.  We would add a _profile_resolver URI entry to its zone files that contains the URL to the profile resolver service endpoint, and we would configure our node so it would only take updates from owners of .id.blockstack names.  I've updated the proposal to describe this.

I like this idea! It can enable gaia hub migrations relatively cheaply -- a profile resolver would ultimately not be much different than the current search indexer.
I think there's opportunity to simplify a little bit, though.
First, designating profile_resolver or _profile_resolver entries in the zonefile doesn't seem to add much benefit -- it just puts a user in the same relationship with a profile resolver that they currently have with their primary hub. However, it complicates the proposal by requiring a new field be added to registrations, be parsed by blockstack.js, and handled as an additional control path in lookups. I think we can just eliminate it.
Second -- I think that the use of the term non-authoritative with respect to profile resolvers is somewhat misleading. They cannot forge profiles, but they would have more or less the same power as the authoritative profile URL from a user's zone file (namely, the power to replay old profiles). The difference is that they will never be the "first" in a lookup path.
Third -- I don't think the sequence number adds much for clients, and profile resolvers could instead use the standard cache-invalidation headers supplied by HTTP, which have the advantage of being present in HEAD requests.
Finally, I think that this proposal can actually be split in two:

Allow a recursive lookup in profiles to allow a profile to point to an order list of other profiles.
In the event that a profile URL is unavailable, allow lookups to initiate from a public profile cache.

Immediate benefits to user choice can be gleamed by just implementing (1). Redundancy and failure-tolerance benefits come from (2), but (2) is also a source of changes in the user threat model --- it's no longer only user-designated Gaia hubs that can perform rollback attacks, but also public resolvers. Ultimately, I don't think the threats of (2) are significant, but I think that it'd be useful to separate the proposal so that the consequences and implementations can be considered separately.

First, designating profile_resolver or _profile_resolver entries in the zonefile doesn't seem to add much benefit -- it just puts a user in the same relationship with a profile resolver that they currently have with their primary hub. However, it complicates the proposal by requiring a new field be added to registrations, be parsed by blockstack.js, and handled as an additional control path in lookups. I think we can just eliminate it.

I'm fine with omitting this for now.  We can always add it in later if finding a working resolver proves problematic.

Second -- I think that the use of the term non-authoritative with respect to profile resolvers is somewhat misleading. They cannot forge profiles, but they would have more or less the same power as the authoritative profile URL from a user's zone file (namely, the power to replay old profiles). The difference is that they will never be the "first" in a lookup path.

I think they can be much more prone to serve stale profiles by accident, especially if the user does not always upload new profiles to them.  In particular, a profile resolver may be serving a profile that the user did not upload themselves, but that someone else did on their behalf.

Third -- I don't think the sequence number adds much for clients, and profile resolvers could instead use the standard cache-invalidation headers supplied by HTTP, which have the advantage of being present in HEAD requests.

It's used for two other purposes:  (1) to show clients how old the profile actually is according to the user who signed it (the HTTP headers may indicate a different timestamp -- i.e. how old the replica is on this resolver), an (2) to allow correct profile resolvers to prevent other people from uploading stale profiles.  I think we should rename the "sequence" number to be the "epoch timestamp" if it better serves these purposes and more clearly indicates these intentions.

Allow a recursive lookup in profiles to allow a profile to point to an ordered list of other profiles.

Why recursive?  I'd prefer iterative, since it's less intense on the resolver.  If you want the resolver to assist with the resolution, then the resolver should probably just return HTTP 302 for the next replica to try (so "vanilla" Web clients can fall over to fetching profiles from different resolvers automatically).

In the event that a profile URL is unavailable, allow lookups to initiate from a public profile cache.

I think the client needs to explicitly switch to querying a public profile cache, so that the client logic can inform the caller which resolver was used (and whether or not it was user-sanctioned).

but (2) is also a source of changes in the user threat model --- it's no longer only user-designated Gaia hubs that can perform rollback attacks, but also public resolvers.

I think stale data can happen by accident with far more frequency in this model, simply by virtue of the fact that profile replication is now asynchronous and eventually-consistent.  I think that as long as the client knows (1) the user-signed timestamp of the profile, and (2) which resolver(s) were tried (and whether or not they were user-sanctioned), then the client can make an informed decision as to what to do with the profile it eventually gets.

Allow a recursive lookup in profiles to allow a profile to point to an ordered list of other profiles.

Why recursive? I'd prefer iterative, since it's less intense on the resolver. If you want the resolver to assist with the resolution, then the resolver should probably just return HTTP 302 for the next replica to try (so "vanilla" Web clients can fall over to fetching profiles from different resolvers automatically).

I think I may have worded this confusingly. The "recursive" lookup is just the nature of allowing a profile JSON to contain a pointer to a new profile location, which causes lookupProfile in blockstack.js to recurse.
The point is that resolvers aren't a necessary element for decoupling the profile resolution from the zonefile urls. There's two largely separable pieces here:

Allowing profiles to point to another profile, causing an additional client-side lookup to occur. The client-side recursion would be bounded.
Adding profile "resolvers" to the network, which are really just profile caches.

Implementing (1) is a very minimal project. (2) is much broader, introduces new elements to the network, and introduces new parties into the threat model.

It's used for two other purposes: (1) to show clients how old the profile actually is according to the user who signed it (the HTTP headers may indicate a different timestamp -- i.e. how old the replica is on this resolver), an (2) to allow correct profile resolvers to prevent other people from uploading stale profiles. I think we should rename the "sequence" number to be the "epoch timestamp" if it better serves these purposes and more clearly indicates these intentions.

For those purposes, then, the "iat" field of profiles (which is already added by default) could be used.

The point is that resolvers aren't a necessary element for decoupling the profile resolution from the zonefile urls.  There's two largely separable pieces here:

Allowing profiles to point to another profile, causing an additional client-side lookup to occur. The client-side recursion would be bounded.
Adding profile "resolvers" to the network, which are really just profile caches.
Implementing (1) is a very minimal project. (2) is much broader, introduces new elements to the network, and introduces new parties into the threat model.

I agree.  The act of implementing item (2) is more-or-less the act of implementing a separate peer network, where each replica executes an anti-entropy protocol to ensure that eventually all replicas of a profile are fresh.  However, I think the threat model is pretty much the same before and after:  any malicious network entity sitting between the client and the profile replica can either serve corrupt data (which the client will catch and reject), or replay a stale replica that is newer than the last replica the client has seen.  The these attack are possible today (e.g. an evil CDN cache can do them), but harder to carry out since there's only one profile replica in the first place (whereas in this proposal, there would be many replicas, with varying degrees of quality and uptime).
The general tactic to deal with the stale data problem is to create a reliable channel for invalidating stale replicas.  We already have this with the blockchain, but it's slow and expensive.  Having a priority list of resolver peers to talk to would alleviate this somewhat, since the user can identify peers known to do a good job at consistently serving fresh replicas.  Moreover, the user would directly upload new profile data to all peers in the priority list, so at least those replicas will be fresh when a profile-write completes.  Another client would only fall back to other peers outside of a profile's priority list if the profile itself could not be fetched, or if the profile is suspected to be sufficiently "old" that the priority list is no longer helpful.

For those purposes, then, the "iat" field of profiles (which is already added by default) could be used.

D'oh!  Yeah, let's just use that and drop the sequence field.


Missing table legend in k8s.io/docs/concepts/storage/persistent-volumes/

This is a...

[x] Feature Request
[ ] Bug Report

Problem:
It's not clear how to read the table mapping the compatibility between the storage drivers and PV access modes (e.g. supported/not-supported, recommended/not-recommended,...?). Came to the surface while having a dispute in the team how this table should be understood.
Proposed Solution:
I'd like to ask to add a legend to the table listing the supported storage drivers and access modes.
Page to Update:
https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes

1.13, going back at least to 1.10

/language en


Discard slave if flagged with s_down or o_down

Flags s_down and o_down are not being taken in account when connecting.

Great! Thank you for the patch!


[WIP] db: remove TransactionLegacy once it is closed

The TransactionLegacy instances are tracked by TransactionMBeanImpl in a
concurrent hashmap. Even when TransactionLegacy instances are closed,
the hashmap keep the references and makes it hard for the closed instances
to be garbage collected. This adds code to remove the TransactionLegacy
instance from the mbean when the instance is close().
This only happens when B&R feature is enabled, the sync thread seems to get stuck while performing DB query and ends up consuming most of the TransactionLegacy instances

Related: https://github.com/apache/cloudstack/issues/3987
Leaks seen by MAT:

The MBean explore shows a steady increase in  the leaks:

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Now let's try to see what causes DB connection pool to not return a Connection cc @DaanHoogland @nvazquez
Thread/CPU/Memory have led to no hints so far, GC and threads have a normal pattern:

Commit that removed it - https://github.com/apache/cloudstack/commit/7b7f4cd1fd72ece80a7efecf6d841b293773f726
@blueorangutan package

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

On big reason why this was not seen before is Java 11 uses G1, perhaps we should move back to ParallelGC - -XX:+UseParallelGC

Packaging result: ✔centos7 ✔debian. JID-1261

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✔debian. JID-1262

@blueorangutan test

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✖centos7 ✖debian. JID-1263

@blueorangutan package

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✔debian. JID-1265

@blueorangutan test

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

I'll tidy the PR later, still chasing what triggers connections to be not returned.

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✔debian. JID-1266

After this fix, basic tests show non-linear growth:

@blueorangutan package

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✔debian. JID-1267

@blueorangutan package

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✔debian. JID-1268

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✔debian. JID-1269

@blueorangutan test

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

In a test env, no leaks seen after 10hrs:

Trillian test result (tid-1602)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 43008 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4121-t1602-kvm-centos7.zip
Intermittent failure detected: /marvin/tests/smoke/test_kubernetes_supported_versions.py
Smoke tests completed. 82 look OK, 1 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_01_add_delete_kubernetes_supported_version
Error
1807.28
test_kubernetes_supported_versions.py

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✖debian. JID-1273

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✖centos7 ✖debian. JID-1275

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✔debian. JID-1288

@blueorangutan test

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

@blueorangutan test centos7 vmware-67u3

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + vmware-67u3) has been kicked to run smoke tests

Trillian test result (tid-1625)
Environment: vmware-67u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 62427 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4121-t1625-vmware-67u3.zip
Intermittent failure detected: /marvin/tests/smoke/test_kubernetes_clusters.py
Smoke tests completed. 83 look OK, 0 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

Do we do specific plugin test, @rhtyd ? (B&R)

@DaanHoogland the changes are in the B&R framework which is also tested by a simulator based plugin; so veeam B&R plugin specific testing is not necessary. The background sync thread still calls the same plugin specific interface/methods, so no changes on that boundary.

In view of that we only need to have knowledge of long term behaviour. I do not think this is going to be an impediment before merging given the smoke test result and our observations in the demo environment.
We need to merge against the 4.14 branch (changed the base).
Any other tests/approvals @andrijapanicsb @borisstoyanov @GabrielBrascher @svenvogel @wido @PaulAngus @weizhouapache @... ?

@blueorangutan package

Packaging result: ✔centos7 ✔debian. JID-1298

@blueorangutan test

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

We need another review to get this merged, so we can work towards a <IP_ADDRESS> release with the two critical issues (a) SG package dependency fix, (b) this issue. Please help review @weizhouapache @wido @GabrielBrascher @svenvogel @kiwiflyer @nvazquez @borisstoyanov and others

ping2 - @weizhouapache @svenvogel @andrijapanicsb @wido @GabrielBrascher @nvazquez

ping 3 - @nvazquez @harikrishna-patnala @sureshanaparti @shwstppr @andrijapanicsb @weizhouapache @svenvogel @andrijapanicsb @wido @GabrielBrascher

I think we have two lgtm and succesful tests on this @rhtyd , merge?

Yes, let's do it.


Change in date.difference API for Swift 3

Could you please help me on Swift 3 API for below Swift 2.x
func elapsedDaysFromDate(refDate: NSDate) -> Int {
    return (refDate.difference(NSDate(), unitFlags: NSCalendarUnit.Day)?.day)!
}

Since SwiftDate 4.x you can do:
let intervalInDays = yourDateDiff.in(.days)

Check the documentation here


fix(@angular/cli): remove mangle and compress from server build

Using those for server might break the runtime, and since it all runs on the server
we dont need to compress, local name mangling works fine. Also remove the build
optimizer pass on server optimized builds.
Fixes #8616

Build optimizer without uglify compress is not very helpful. Please note that the optimization is not turned off. Build optimizer is a separate plugin that works with uglify.
Memory consumption on server does not matter as much as you'd think, once the files are loaded and compiled. The difference between a 2MB and a 3MB node bundle is minimal. Unless you run on a raspberry pi I presume.

Though this would be a part of 6.0.1 :(

It is.  This PR is for the 1.7.x variant of the change.


Reaper doesn't look for supercronic in PATH

Since #172 in v0.22.3 I'm getting
time="2024-10-12T08:43:03+02:00" level=info msg="reaping dead processes"
time="2024-10-12T08:43:03+02:00" level=fatal msg="Failed to fork exec: no such file or directory"

I debugged that behavior to https://github.com/aptible/supercronic/blob/cca6b3a90abc99a024f4b437da0f1886da68ca7a/reaper.go#L34
If the current working dir is / but supercronic is installed in a directory included in PATH e.g. /usr/local/bin/supercronic the reaper still tries to execute supercronic from / which doesn't exist there.

I made a fix, you can try it. @atesca09
https://github.com/aptible/supercronic/pull/178

Thanks for the prompt fix! I've tested the changes, and it works for me now.


Dave update getting started docs, and other supplimentary docs

Looking to just get some input on if there is anything I have missed. Please also check out for typos, bad grammar, or repetitiveness.
I will be testing these on dharma this week, so I will be able to catch any errors as I go through the docs.
Resolves #388

I believe we've been using SUBGRAPH_NAME for mandatory values and [PORT] for optional values, although notations here vary. commander, which we are using for graph-cli, uses <SUBGRAPH_NAME> and [PORT], so I'm happy to follow that.

Addressed all the comments.
I also think jannis got half way through, so there might be some more mistakes.
I will be back on tonight and can address all fixes and get this merged tonight!


Fix loading of PICO_TOOLCHAIN_PATH

Add double quotes because build option it's a string.
Remove comment as requested by @kilograham.
Resolves #258.

Nice :+1:   Apologies if any of my uninformed comments threw you off the scent! :nose:

sorry, can you please rebase this onto develop-1.1.1 (it'll get released sooner that way) - still working thru the best branching policy!

@kilograham  I've started started over from develop1.1.1 and changed the base as develop1.1.1.
Trust this is how you wanted it...


BUG: Environment Missing Altair

When I created a conda environment from the 2023.9/shotgun/released/ubuntu environment file and ran make test on the moshpit main branch, I got an error about not having altair installed. I conda installed altair and it resolved the issue.

Hey @Oddant1, thanks for reporting that! I believe that the reason for this is the busco action actually not being included in the 2023.9 release: when I compare the commit history on the main branch vs. the release-2023.9 I can see that the latter one has one bug fix cherry-picked from the main branch but skips the busco commit (plus some other ones). Which raises a question for me: is that a problem or is it fine? @ebolyen could you maybe advise a bit on that? I guess when the next release branch comes everything should be fixed again, right?

I think this is going to end up being fine, as the recipe has altair in it. So the next prepare (which I'm working on) will have that in the next dev env (and release).


I cant import components.less from bower

I'm using bower for front end dependencies, when i import the components.less i can't compile the less because this dependency in slider.less
@import (inline) "../../../node_modules/react-draggable2/lib/styles.css";
The question is, if the react-draggable2 root can be put in a variable, so i can override it
Thanks!

I had that dependency giving me problems as well. Actually, being a very tiny style, i believe the import can be skipped by adding
.react-draggable, .react-draggable-dragging {
  user-select: none;
}

.react-draggable {
  position: relative;
}

to the material-ui's style.
@hai-cea what about removing that @import? When ok, we could have a vendors/react-draggable.less instead.

This also breaks compiling the material-ui less from another npm package.

Actually, disregard that.
If you do the following then the less is compiled just fine:
        .pipe(less({
            paths: [ path.join(__dirname, 'node_modules', 'react-draggable2', 'lib') ],
            plugins: [autoprefix, cleancss]
        })


Is there a version for Arch Linux? Or maybe an Appimage?

Is there a version for Arch Linux? Or maybe an Appimage? Thx

Hi Forza!
I’m so sorry we don't have an installer for arch linux!
Do you have

an alternative OS (or run a virtual machine in arch linux) you can use, it is the simplest way to install the software?
can convert and install it using tools like Debtap/Alien/rpm2cpio?

Let me know if you need help with anything else!


Overview metrics should obey HIDE env vars

Describe the bug
When a user enables a HIDE_* env variable, it does not apply to the overview table and only to the detailed table but it should apply to both.
see https://github.com/github/issue-metrics/discussions/300
To Reproduce
Run the tool with HIDE_TIME_TO_CLOSE: true and see that Time to close is still in the output of the first table. See example
Expected behavior
Time to close should be hidden
Screenshots
No response
Additional context
No response

Okay, I wrote this issue incorrectly. opened a new issue to track the right problem.


Add an option to limit BlockEnd hints to tall blocks

I've been using clangd 17 with the new BlockEnd inlay hints added in #1634, and I'm finding that the hints are quite useful for tall blocks (say, more than 10 lines) where the beginning of the block is more likely to be offscreen, but just add visual noise for shorter blocks where the beginning of the block is more likely to be on-screen.
It might be nice to add a config option to set the minimum number of lines a block should be to get the hint.
@daiyousei-qz what do you think?

I believe we had one in the original patch, but it was removed as requested in the code review. We decided to try to configure a good default in clangd. @sam-mccall for comment.

We decided to try to configure a good default in clangd.

I'm seeing the hints even after blocks with a 1-line body.

It looks like the limit currently in the code is 2, and the block height is considered to include the lines with the braces, so the only blocks that are excluded are the ones where the braces are on the same line.
I think I'd want to set the minimum to something in the 6-10 line range. I suppose I'd be fine with a hard-coded limit in that range, but I also feel like this is an area where different developers may have different preferences.

Yeah, this depends on the font size and how tall people's screen gets. Though I think the number should be large enough so it's not getting too dense in noise yet not too large so the threshold exceeds the number of lines the screen could display. In this case, 6-10 sounds good to me.

@HighCommander4 Do you want to me handle this issue? We have to determine either we want to add a config or update the minimum line requirement.
I started using clangd17 lately and noticed the verboseness is amplified by new hints added at end of statement blocks.

@HighCommander4 Do you want to me handle this issue? We have to determine either we want to add a config or update the minimum line requirement.
I started using clangd17 lately and noticed the verboseness is amplified by new hints added at end of statement blocks.

Sure, please go ahead.
I think just changing the hard-coded limit for now should be fine. If we get users asking for the hints on shorter blocks, we can consider a config option at that time.


Redirect to different domain url.

I am using react-router for client side routing. I have a button and when some one clicks that button, I want to redirect the user to a different url. For e.g I want to redirect the user to "http://www.google.com". I used navigation mixin and used this.transitionTo("https://www.google.com"). But when I do this I get this error "Invariant Violation: Cannot find a route named "https://www.google.com"".
I may be doing something silly there. I can use window.location but is that the right way to go ?

Is there a reason you're not using a regular anchor tag?

transitionTo is only for internal URLs. Use window.location or .

I have a form and form can have multiple pages. I have next, back and submit button on the form. When user clicks the next and back button, I do the respective operation, but on submit, I can go to a third party url, or an internal app url depending upon the configuration.
In order to use transitionTo, i need to use the navigation mixin, is there any way i could avoid using the mixin?

@ransanjeev    this.context.router.transitionTo ?

Please assign the value of window.location as @taurose suggested. The router's navigation methods are only for your app, not the whole web.


Poll refactor

@collin @mparent61 @MelizzaP @MichaelButkovic
Moved things around as best I could for the time being. Big problem is the relational aspect of all of this, so poke holes where necessary. I'm "done" with the starwipe portion of this, but I'll open that up once we've properly dissected this part.

:+1:

:+1:

:+1:  other than my q

Coverage decreased (-0.2%) to 88.4% when pulling 16cdbf3e755b8dc7d5ae0cc83a6c10f28909b9fd on poll-refactor into 87defb7eec52ef530b4acc61e009010d95ed9329 on master.

Looks okay.

so do you pal

Coverage decreased (-0.2%) to 88.4% when pulling 16cdbf3e755b8dc7d5ae0cc83a6c10f28909b9fd on poll-refactor into 87defb7eec52ef530b4acc61e009010d95ed9329 on master.


Generate SPM segments from FHIR

This PR ...

Adds the generation of the SPM segment
Adds a "coded with exceptions" CWE HL7 mapping helper.

Test Steps:

Run the FHIR -> HL7 conversion command ./gradlew primeCLI --args='fhirdata --input-file "src/testIntegration/resources/datatests/HL7_to_FHIR/sample_co_1_20220518-0001.fhir" -s metadata/hl7_mapping/ORU_R01/ORU_R01-base.yml'
You will notice these differences:

SPM.2.2.4 Doesn't include ISO . This follows the previous decision not to include ISO if the universal id is not included
SPM.14 only includes RA, This is noted in the mapping and is due to the fact that HCA is supposed to be sending us text but instead is sending a CE
SPM.26. In the sample file some numbers are ints while others are doubles. The output of the generated HL7 is always a double.

Changes

Adds the generation of the SPM segment
Adds a "coded with exceptions" CWE HL7 mapping helper.
Adds a None concept to the CodingSystemMapper so throw an exception if there is no mapping.

Checklist
Testing

[X] Tested locally?
[ ] Ran ./prime test or ./gradlew testSmoke against local Docker ReportStream container?
[ ] (For Changes to /frontend-react/...) Ran npm run lint:write?
[ ] Added tests?

Linked Issues

#5755

Per my test, you are missing SPM-14-2 and SPM-14-3

NM.  You are right.  The type is incorrect from the original data.


allow -Xlint in OrganizeImports.removeUnused

Thank you for creating an awesome Scalafix rule!
I'm trying OrganizeImports rule in my personal project and so far it works great.
Recently I sent a PullRequest to Scalafix RemoveUnused rule to respect -Xlint and -Xlint:unused scalacOptions, and it has been merged.
https://github.com/scalacenter/scalafix/pull/1163
Since OrganizeImports.removeUnused function comes from RemoveUnused rule, I'd think it's nice to keep compatibilities. So please let me send this PullRequest.

@taisukeoe, thanks for this PR! Merging :)


fix: update DevCard Contribution term to Repo

What type of PR is this? (check all applicable)

[ ] 🍕 Feature
[x] 🐛 Bug Fix
[ ] 📝 Documentation Update
[ ] 🎨 Style
[ ] 🧑💻 Code Refactor
[ ] 🔥 Performance Improvements
[ ] ✅ Test
[ ] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert

Description

This PR updates the term "Contribution" to "Repo" on the DevCard feature.
Related Tickets & Documents

fixes #1318
Mobile & Desktop Screenshots/Recordings

BEFORE
Greater than 1 Repo

1 or Less Repo

AFTER
Greater than 1 Repo

1 or Less Repo

Added tests?

[ ] 👍 yes
[x] 🙅 no, because they aren't needed
[ ] 🙋 no, because I need help

Added to documentation?

[ ] 📜 README.md
[ ] 📓 docs.opensauced.pizza
[ ] 🍕 dev.to/opensauced
[ ] 📕 storybook
[x] 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?
NA
[optional] What gif best describes this PR or how it makes you feel?

Thanks @babblebey. Will you provide some before/after screenshots?

Thanks @babblebey. Will you provide some before/after screenshots? It helps for a quicker review

Done @brandonroberts
Kindly note, I committed some more changes to the branch.

Hey @babblebey, will you check the build error?

hint npm run build

Hey @babblebey, will you check the build error?

hint npm run build

Will do @OgDev-01

Hey @babblebey, will you check the build error?

hint npm run build

@OgDev-01
I did, found an error and fixed the term repos in place of contributor in the DevCard story.
Thank you || O seun || Danke


Fix missing const in CapsuleShapeSW::get_area

Looks good, merging...

Now that Godot 3.1 has been released, we don't plan to cherry-pick new features and enhancements to the 3.0 branch, unless there is very strong support in favor of it. Removing cherrypick label for 3.0.

@akien-mga but.. it is a a type mismatch with the base virtual function, and is actually a bug.
Small showcase:
#include <iostream>

class A {
public:
    virtual float get_x() const { return 10.0; }
};

class B : public A {
public:
    virtual float get_x() { return 20.0; }
};

int main()
{
    A* test = new B();

    std::cout << test->get_x() << std::endl; // Prints 10, due to missing const

    return 0;
}

You're the one who tagged it "enhancement" ;)


Object (de-)serialization

Closing this for now, in my opinion this should be a separate package that is based on this one.


Activity Explorer - Clarify how the Office 365 Management Audit can be used

There are two issues:
I (and most users will) need to export more than 10k entries from the Purview Data Loss Prevention Activity Explorer. The message in the Activity Explorer is to use the Office 365 Management Activity API to perform the export. However, when exporting from the API a number of fields shown in the Activity Explorer are not available from the API e.g. Removable media device model is available in the Activity Explorer but seemingly not in the Office 365 Management Activity API. (It is definitely not in Record Type 63 for DLP activities) Where in the API are the missing fields? What is missing from the documentation is the 'how to construct the same data set' using the Office 365 Management Activity API.
The other issue (which something for the page owner of https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-reference#list-available-content ) is that the date range filters are not working with the List Available Content API call (https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-reference#list-available-content ). The call is only returning data for the current day no matter how the filters are constructed. This means consumers cannot actually access the audit data say for the last 30-days or recreate the Activity Explorer data.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 3a3d3633-893d-9354-9402-c47ed7dec790
Version Independent ID: fc12340b-403f-b531-04be-91f00a8f0af6
Content: Get started with Activity explorer - Microsoft Purview (compliance)
Content Source: microsoft-365/compliance/data-classification-activity-explorer.md
Service: o365-seccomp
GitHub Login: @chrfox
Microsoft Alias: chrfox

Fixing the filtering issue (see (https://github.com/MicrosoftDocs/office-365-management-api/issues/367) ) has revealed that created on removable media is in the API (and part of DLPEndpoint)  However it is not in the Audit Search filter.

As a result you have to export all of the DLPEndpoint items and filter them outside of the audit. This is a significant undertaking when DLP is enabled as it results in very large exports...

Investigating

@buildbod Thanks for your feedback! New issues and pull requests for this content are closed while we update this content to support upcoming feature improvements.


Calendar coordinate system seem to does not support dataset

Version
4.5.0
Steps to reproduce
data format like this  [{data:'2019-12-14', value:111}]  seem to can not display in  Calendar coordinate system
What is expected?
Calendar coordinate system support dataset
What is actually happening?
Calendar coordinate system seem to does not support dataset

Please provide a full demo of your requirement: https://jsfiddle.net/ovilia/n6xc4df3/


NotificationView Migrate to DAOMenu2 + GroupBy Support and other cleanups

So a lot more work ended up having to be done

Previously NotificationView was its own custom controller, we moved this to use the standardized controller rendered by DAOMenu2.
Added a DateGroupingExpr to work with the GroupingDAOList.
Added ability to pass in a SummaryView to the DAOControllerConfig (may have to update the naming of this since a SummaryView individually entails the normal DAODetailView, etc. was thinking BrowserSummaryView makes more sense)
Added ability to optionally hide the query bar on the DAOBrowserView to the DAOControllerConfig
Tried to generalize the context menu actions on NotificationRowView so that it doesnt just specifically work with NotificationView itself, not sure if it was even working as expected before
Added isAvailable to read and markUnread context menu actions
Fixed spacing on the DAOTable based on comments from Logan
Added MyNotificationDAO as decorator which handles showing the users OWN notifications if they have permission to view all notifications
Wired up the support from summaryView import so that it can update the summaryView if a notificatoin was marked as read or unread. Previously you had to refresh the page and currently with notificationView it just pops a new stack of the notificationView not sure if htis works but I made work around so it will use this if no browse
Added canned queries for read and unread notifications
Changed Read to => Mark as Read and Mark Unread => Mark as Unread after talking with Logan

Still has two unresolved comments. Please address and I'll merge.


HADOOP-6801. io.sort.mb and io.sort.factor were renamed and moved to …

…mapreduce but are still in CommonConfigurationKeysPublic.java and used in SequenceFile.java

Rebased the patch.


Add Search Endpoint

This is a first attempt to add a search endpoint into this library. This is not a final stage, rather a discussion about the approach and maybe how it can be improved. Basically, this is the solution I came up with by giving the Pages class a Map of ParserFunctions (instead of only one) to enable distinguishing the different paging json objects in the search result.

@rinukkusu hi,
I cleaned up the code. Now the EndpointPaging class contains another method called _getBundledPages(), which returns a set of Pages that can contain different datatypes. Both class Pages and BundledPages inherit from the abstract _Pages class, which contains just some common members.
I thought to add this comment to clarify potential confusion, because the PR diff is quite messy.
Thank you :)


Update check%ranges type in cable.nml

Fixes #22
Needed for compatibility with CABLE/main branch.

I am not sure how to specify the version of benchcab and CABLE this is compatible with. And the same for the previous versions of bench_example. So far, we linked the version of bench_example to the version of benchcab but this shows the version of CABLE is important as well. But we aren't going to release CABLE versions very often.
Should we use the CABLE commit hash in a version tag?

@abhaasgoyal thanks for the ideas. I'm wondering how to guide users through all this. A commit description is maybe too hidden.
For example, let's say someone branched out CABLE before the check%ranges changes and want to use benchcab. They need to use bench_example at the commit before the one for the merge of this PR. And that's a bit tricky to find.
Would it be better, i.e. easier on users, to have several versions of the namelist directory instead of updating the namelist file? We could have a version (not sure the format) in the directory name with a symbolic link of the latest version to a generic namelist name. Then, we tell to users to change the symlink to an older version of the namelist files if needed?

I think the symlinks could create confusion since if the user were to compare 2 realisations which have namelist changes, they will have to specify patch according to the symlink either way (which would have different values and not reproducible without mentioning which symlink). They will also have to find the correct version to symlink to manually. I think we do need to make changes in benchcab / CABLE to make the solution work (outside the scope of this PR).
Maybe we can still have
(a) multiple folders
(b) git submodule (which I think is better for automated management)
based on versions of namelist files, and let benchcab decide which version of namelist to pickup. Some ways to pick it up:
(a) putting the version number via config (preferred since it's easier, but then multiple folders would be better for new users)
(b) finding a way to have dependency resolution between namelist and CABLE in an automated way.
For now, maybe have different folders for namelist, along with a CHANGELOG in the parent folder of versions. We do tell users to symlink the versions as well. However, we should create an issue in benchab where instead of symlinking, users put the version namelist to use in config.yaml under a certain realisation.

For the moment, I've created version folders with a symlink to the latest folder.
I don't know if I want to make changes to benchcab or tell users that if their branch isn't compatible with the latest benchcab either at compilation or for running configurations, then they should merge the main branch in their branch first.


StyledEngineProvider doesn't have exported types

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

I can't seem to import StyledEngineProvider from material ui next in a typescript project

i'm getting error Cannot find module '@material-ui/core/StyledEngineProvider' or its corresponding type declarations.
i've made used i've updated the packages with material-ui.next

Expected Behavior 🤔

i should be able to import StyledEngineProvider

Steps to Reproduce 🕹
here is the code sandbox recreation
https://codesandbox.io/s/material-ui-issue-forked-d4uuc?file=/src/Demo.tsx
Context 🔦
I'm trying to import StyledEngineProvider into a typescript project

It looks like an issue with Codesandbox. I had no issue when I download the reproduction and run it locally.

I have this issue locally with material ui next package.

Could you provide a reproduction?

@oliviertassinari  I fixed it!  thanks for the quick replies! 👏🏾

deleted yarn.lock and installed packages again
i think since i speicified 'next' the resolution must have been stuck in another version.

Actually, the issue inside codesandbox is the cache, I had to force the latest version: https://codesandbox.io/s/material-ui-issue-forked-jiynb?file=/src/Demo.tsx.


General overview

Somehow allow for live reload (potentially even hot code replacement), http2, and server-side transpilation of code. This would allow you to have no development build process at no cost (besides the incremental build time), and the user wouldn't have to worry about changing any of their file imports. They could write <script src="test.ts"></script> and the server would be able to serve up from memory the transpiled file. Just do in-memory incremental builds all of the time.

I've been doing some research. So, we should be able to use the es6 module loader polyfill in the browser. Just include it. Then include all scripts as normal. On the server, transpile TS code to es5. So set the target to es5, and set the module to system. That will transpile TS code to es5, and imports will be transpiled with the System.register thing, which has the same semantics as module loading will have. The point is, this should work.

Somehow generate good SSL certs so that browsers don't complain. Look at the simplehttp2server project to see how those are generated.

We'll have to wait for TS 2.1 to allow async await transpilation to ES5. But once we have that, we'll be able to use just TypeScript to transpile all es6, es6 modules, and async/await, which are the major features that I've come to not be able to love without in development.

It's becoming simpler. When a file is requested, check if its transpilation is stored in memory. If it is, return it in the response. If it isn't, transpile it, store the transpilation in memory, set a file watcher on that file, and return it in the response. When the file changes, run transpilation on that file, store it in memory, and then trigger a live reload.


Investigate which node is making the network crash

Find out the source of timestamp overflow. Perhaps a single validator is responsible for all the wrong blocks, find out if the block is actually wrong and unused.

Crashed at block 2707093 http://blockexplorer.trustlines.foundation/blocks/2707093/transactions

@cducrest @schmir-at-bb : How sure are we, that this was actually a chain problem and not a problem with the blockexplorer? Do we have additional logs to look into?
I've checked for all 4 blocks the previous and following blocks and

The timestamps are almost exactly 5 seconds apart
The validators are in the order they are defined in the chainspec
There are no uncles in the blocks
The step values are also correct

eth.events SQL: SELECT * FROM block WHERE number IN('2707092', '2707093', '2707094', '2707887', '2707888', '2707889', '2708037', '2708038', '2708039', '2757104', '2757105', '2757106') ORDER BY number

See https://github.com/paritytech/parity-ethereum/issues/10688#issuecomment-503472922

Bernd already commented on that issue. It looks like system clocks have been off for a bit: https://github.com/paritytech/parity-ethereum/issues/10688#issuecomment-499553861
I do think this issue doesn't need further work.

The issue has been fixed in https://github.com/paritytech/parity-ethereum/pull/10720 which is just waiting to be merged.
We have to make sure the validator nodes update the time regularly though. Added documentation in this PR https://github.com/trustlines-protocol/blockchain/pull/172

Closing this because it no longer makes sense.


Add H5MD writer

Do we have any objectives in using external h5xx library? (https://github.com/fhoefling/h5xx) It is quite tedious to work natively with hdf5 library.

I am not sure if this is helpful, but xtp has a quite substantial hdf5 interface.

we can easily move all that to tools

If it suits your needs.


Hotkeys are working while they are not assigned

Description:
I have all hotkeys assigned to Ctr+Alt+Shift+SomeButton. When I'm using them then all is fine. But if I use another button (which is not assigned anywhere) then it works like it assigned. In my case pressing Up or Down (without any modifiers) causes Play or Stop respectively. Maybe this is because of error in a log "ERROR - Error occured when updating the startup registry key".
Steps To Reproduce:
Described above.
Expected behavior:
Only assigned hotkeys must work.
Screenshots:

Environment:

Windows 10 x64 22H2 19045.4894
BeatBind Version1.8.3

Log File:
Newly created log to reproduce an issue.
beatbind.log

From your screenshot, Play and Pause are assigned to Up and Down respectively, so pressing Up or Down will trigger them. If you want it so Play and Pause aren't triggered, you have to delete Up and Down from the input fields, like the other hotkeys to the right.
I guess it can be a little confusing, and I plan on updating the UI so it's easier to manage hotkeys

you can ignore that error btw. I'll fix it later so it's not shown if Start on Windows startup is false

Omg, I thought that it all works only with modifiers 😂 Thanks!

I guess it can be a little confusing, and I plan on updating the UI so it's easier to manage hotkeys

This would be great ;)


description for Application Key needed

Hey,
i want ask if its possible to have a short step-by-step instruction for getting the Applications ID.
I found some instruction in the internet, but this (https://github.com/florianholzapfel/panasonic-viera#use-saved-credentials) but it didn`t worked well.
Is there another way to get the ID?

would be really great :)


Could you provide a sample .env file?

I've been trying to reverse-engineer one, but I still get failed "pre-start" since I have no database.
So far, I got this:
DISABLE_LDAP=1
DOCKER_DATABASE_DIR=/db/effort
DATABASE_NAME=loggin.db

PS. It's a bit confusing that README mentions an env variable (`` HOST_DATABASE_DIR) that's not used.

Oh, I just found the one that's used for Selenium tests.


Package connectivity overhaul

Hi all,
I started out with the simple goal of adding a single connectivity test for a to-entities policy, but as I went on to read and understand more of the code, I realized this package could benefit from a more streamlined data and execution model. You will find the business logic was kept mostly the same, but I've incorporated multiple concepts we're used to from Go's testing package.
Some of the goals of this refactor:

Overall separation of concerns, slicing the package into more clearly-defined layers: ConnectivityTest -> []Test -> []Scenario -> []Action
Move from an imperative (scripting) style to a declarative style: a Test is now a scope. Policies can be registered to it, and the framework automatically takes care of applying and removing them when appropriate. (including when interrupting the test program) Tests that depend on state left behind from previous tests is bound to be a source of bugs.
Providing a friendly test suite API. It should be abundantly clear which policies are active during a test, and what the expected outcome is.
Improving output readability. Like Go's testing, if everything's peachy, there doesn't need to be a flood of output. A lot of time was spent improving this, but there's still lots to do.

Test and Action now have their own Log(), Fail(), Fatal(), Debug() logging APIs.

Fail() marks the current test as failed.
Fatal() does Fail() and exits the current goroutine, firing defers.

Within the scope of a Test, all output is buffered until a failure is encountered, after which it is flushed to stdout.
The --verbose log level disables this buffering.
A --debug log level was added for development. Debug statements were added in a few places, like command stdout.
Logs generated at different levels are visually distinct. (e.g. Action logs are indented)

Simplifying the internal implementation and improving code readability. We're expecting to add hundreds more tests, so maintainability is key. Most interfaces that only had a single implementation were removed, as I didn't find them to add any value (on the contrary - they got in the way). A more canonical Go style was adopted.
Adding context cancellation to most of the infrastructure (addresses part of https://github.com/cilium/cilium-cli/issues/67)
Setting us up for parallellizing tests. Each test now gets its own goroutine, although only one executes at a time for now.
Splitting out check.go :slightly_smiling_face:

With the introduction of scopes, this would allow us to spin up multiple cilium-test namespaces (stacks) and schedule Tests onto them, e.g. up to 5 in parallel. This would solve demultiplexing flow logs. If we would execute tests in parallel from the same source pod, we wouldn't have a way of attributing flows to test executions. Haven't thought that much about this, suggestions welcome!
I haven't touched the flow matcher at all, that was kept as-is. I think there's more boilerplate to be removed from Scenarios so they don't have to call the matcher explicitly, that's something the framework should do implicitly.
To-do

[x] Rebase this onto master.
[x] Split out into a few commits, although that might be tricky given the amount of changes made, and there's no clear way around this.

The test fail in the Kind/encryption workload is due to the ipcache race that I have a fix in a follow-on PR. It can be ignored for now.
AKS test failed waiting for Cilium to be deployed. Not sure if AKS needs more time than the timeout allows, restarted that test.

Restarted AKS test which failed due to known flake: https://github.com/cilium/cilium/issues/16097

Added debugging for unexpected RSTs. It may happen that RSTs are seen either before the first flow, or after the last flow. That would explain why the offending RST is not printed. Debugging this with additional messages when an unexpected RST is found and also by adding --all-flows option to the AKS test run.

Added commit that skips separate SYN flow validations when a DROP is expected when flow aggregation is on.

Also added commit that limits Middle and Except validations to flows between the First and Last flows. Would be better yet to recall the (wildcarded) source port of any first flow and require a port number match in later flows so that we would actually verify that the different flows apply to the same TCP connection or UDP echange.

Limiting flow validation to happen between first and last flow backfired. In one resulting flake DNS flows are listed after the TCP SYN, and since the expectation was to see the DNS exchange first and SYN in the "Middle", the SYN was not found when flows before the DNS were ignored.

Added a commit to track ephemeral port numbers. This safely ignores RSTs seen in the flow data when they are for other connections, e.g., from a previous test run. This required to make Except flow requirements more specific by adding the TCP filters to them.

tcpPorts and udpPorts are keyed by the known destination port (e.g., 80), the map value is the (stored) ephemeral port. The ports are reversed for return direction packets, that's why the lookup is keyed with source port, which is the known port (e.g., 80) and the destination port must match the stored ephemeral port number.

Thanks for pointing this out, fixed.
CI is green, should be good to go now. :rocket:


Binding element incorrectly reported as having any type in JS with JSDoc starting with 5.6.2

🔎 Search Terms
Binding element implicitly has an any type 7031
🕗 Version & Regression Information

This changed between versions 5.5.4 and 5.6.2

⏯ Playground Link
https://www.typescriptlang.org/play/?strictNullChecks=true&target=9&suppressImplicitAnyIndexErrors=true&ts=5.6.2&filetype=js#code/PQKhCgAIUgBAHAhgJ0QW0gbwPICMBWApgMYAuAvpANrED2AdgGYCWA5gLpQwIrpYAKKUs0QAbADwAlErWQATcQHJ8AZwaLIAH0jK19Yhu26GAVkUAaSCtLJm9VlXYA+J5RoMWrAHSI5c5sIMYgBizKKEKpzQwOCEAB7wsqSQjACu+oH0kPDIhEi5AMIebAAUmFCQlb7+mSFhEQBcWBWVrZCqDJAAvNRRrZQ9mOTgA1jkAJTNbXT0auFeorSsJR304yNAA
💻 Code
/**
 * @param {Object} [config]
 * @param {Partial<Record<'json' | 'jsonc' | 'json5', string[]>>} [config.additionalFiles]
 */
export function prepareConfig({
    additionalFiles: {
        json = []
    } = {}
} = {}) {
    console.log(json)
}

🙁 Actual behavior
json is errored as Binding element 'json' implicitly has an 'any[]' type.(7031) even though it's typed as string[]

🙂 Expected behavior
No error expected, as json is typed as string[]
Additional information about the issue
This worked well in 5.5.4 but broke with upgrade to 5.6.2. It works correctly in .ts file, but breaks in .js file with JSDoc.

I'll fix this as part of https://github.com/microsoft/TypeScript/pull/59924

@Andarist ok, thanks. I guess it's gonna go out as 5.6 patch bump?

@burtek in the end I decided to create a separate PR for this one since I was able to fix this independently and the other PR raises some design questions. The fix is available here: https://github.com/microsoft/TypeScript/pull/59975
As to your question, this is a recent regression so I'd advocate for backporting a fix but that's up to the TS team.

This issue actually existed before 5.6, but only for array binding patterns (playground link):
/**
 * @param {[[string[]?]?]} [x]
 */
function f1([[json = []] = []] = []) { return json } // Implicit any[] error on json binding element

In 5.6 we aligned array and object literal padding and the issue then showed up in object binding patterns as well:
/**
 * @param {{ a?: { json?: string[] }}} [config]
 */
function f2({ a: { json = [] } = {} } = {}) { return json } // Implicit any[] error on json binding element

The culprit here is logic we have in widenTypeInferredFromInitializer to issue no implicit any errors in JS files. We shouldn't be issuing these errors when we're obtaining the implied type for a binding pattern. I'll put up a PR to fix. Unfortunately the fix in #59975 isn't the right one.


ContentfulLivePreviewProvider: toggling inspector mode state off removes borders, but tooltip element remains visible

I have had to work around this with the following code inside of an effect
  const tooltip = document.querySelector('.contentful-tooltip')
  if (tooltip instanceof HTMLElement) {
      if (!isInspector) {
          tooltip.style.display = 'none'
      } else {
          tooltip.style.display = 'flex'
      }
  }

Hey 👋
We changed the way how the InspectorMode works and this one is now also fixed with<EMAIL_ADDRESS>:)


Why the performance of these methods is much lower than they claimed?

Thanks for this Nice work. I found the results here are much lower than they claimed in the same dataset (e.g., in NodeFormer uses 20 labels per class for training the accuracy is 83.4, and OpenGSL is 78.81). Is there any idea why this happened?

83.4 mentioned here comes from random split, while we chose to use fixed split in our work. Besides our own implementation, we ran the source code using the script provided by Nodeformer, (line 16) and the result was close to 78.81.

Thanks for the quick reply, it looks like the random division here makes a big difference. I am curious whether different divisions will lead to differences in the conclusions in the paper? Especially for NodeFormer, it seems that he is not as simple as the simplest method

Different splits can make a difference, especially for small datasets like cora, as they may result in different distributions of supervised information. This issue has been identified in some previous works. In the future, we plan to incorporate more reliable datasets. As for Nodeformer, I suggest that it may be more suitable for scenarios with abundant supervised information due to its transformer architecture without inductive bias. We will explore this aspect further in the future.

Thank you for your reply. It's interesting to know this. And looking forward to the updates of OpenGSL.


Fixes #2950 : Support for browse to command to launch the custom domain URL if present

This checklist is used to make sure that common guidelines for a pull request are followed.
General Guidelines

[ ] The PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).

Command Guidelines

[ ] Each command and parameter has a meaningful description.
[ ] Each new command has a test.

(see Authoring Command Modules)

View a preview at https://prompt.ws/r/Azure/azure-cli/5022
This is an experimental preview for @microsoft.com users.
(It may take a minute or two for your instance to be ready)
Email feedback to 'azfeedback' with subject 'Prompt Feedback'.

To merge after knack conversion.


update dependency for django-polymorphic

The current version of django-polymorphic is 2.1.2, which can't be installed because django-filer only allows its version to be <2.1.
Version 2.1 adds support vor django 2.2.
The problem is that you now can't properly install projects which depend on django-polymorphic<2.2 if django-filer==1.6 (for example) is installed.
polymorphic==2.0.3 (which gets installed with current filer-version) has some problems in the admin interface where you can't add some models for example.

In the next release, this will be fixed.

Is there a date when the next version will be released?
Django 2.1 is no longer supported (as seen in the 2.1 docs at the top).

1.7.0 was released 2 weeks ago, support was added there.


update movieku

@appdevelpo i tried the extension with this pr by sideloading it from local dir.
and i can see the latest titles in the search but i'm getting an error when i try to open a title.

@appdevelpo i tried the extension with this pr by sideloading it from local dir. and i can see the latest titles in the search but i'm getting an error when i try to open a title.

you now can have a try

you now can have a try

it works fine now 👍


Lock operator-sdk version and force use of vendor dir for builds

In order to force the usage of the vendor dir for builds, we need to add the 'mod=vendor' go build flag. However, in order to add the go build flag, we need to ensure we're using a operator-sdk version that supports passing in go build flags.
To address both of these issues, I added logic to our Makefile that ensures we're all using a specific version of the operator-sdk cli when performing builds (cached into build/_output/tools). Then I added the --go-build-args="-mod=vendor" flag to the ocs-operator build.
The result is the build should be forced to use the packages within the vendor directory. If something isn't present within the vendor directory, then the build should fail.

/ok-to-test


In get_coin_info the "coin" parameter is now required

https://kucoinapidocs.docs.apiary.io/#reference/0/market/get-coin-info(open)
Even though the Kucoin documentation does not reflect it yet.
Tried it in their console, throws the "Required String parameter 'coin' is not present" message.

Thanks @primski I've fixed this in v0.1.12


UIL with Google Map Markers: Getting ImageAware is reused for another image. Task is cancelled

Hello, I am populating a map with markers which contain a custom icon that is obtained from the internet and then cached on disk for re-use.
I noticed that this statement appears and that for my ImageLoadingListener, the onLoadingCancelled is called which results in the market icon not being displayed and the default Google Marker( the red pointy thing :D ) being displayed
This is my code.
Looping through some data and creating markers
for(SomeObject so: listOfObjects){
            Marker marker = mGoogleMap.addMarker(new MarkerOptions().position(new LatLng(so.getLatitude(), so.getLongitude())));
            loadMarkerBitmap(marker,so);
        }

The loadMarkerBitmap method which sets the marker icon
 ImageLoader.getInstance().loadImage(so.getImageURL , new ImageLoadingListener() {
            @Override
            public void onLoadingStarted(String imageUri, View view) {

            }

            @Override
            public void onLoadingFailed(String imageUri, View view, FailReason failReason) {

            }

            @Override
            public void onLoadingComplete(String imageUri, View view, Bitmap categoryIcon) {
                Bitmap combined = Bitmap.createBitmap(mapPin.getWidth(), mapPin.getHeight(), Bitmap.Config.ARGB_8888);
                Bitmap scaledIcon = Bitmap.createScaledBitmap(categoryIcon,(mapPin.getWidth() * 45) / 100, (mapPin.getHeight() * 45) / 100,true);
                Canvas canvas = new Canvas(combined);
                canvas.drawColor(Color.TRANSPARENT, PorterDuff.Mode.CLEAR);
                canvas.drawBitmap(mapPin,0,0, null);
                canvas.drawBitmap(scaledIcon,canvas.getWidth()/2 - scaledIcon.getWidth()/2,(canvas.getHeight()/2 - scaledIcon.getHeight()/2), null);
                marker.setIcon(BitmapDescriptorFactory.fromBitmap(combined));
            }

            @Override
            public void onLoadingCancelled(String imageUri, View view) {

            }
        });

o the problem is according to the source code loadImage call cancels previous task for the same image URI e.g. if you started a task with this URL e.g. http://www.google.fr/images/srpr/logo11w.png" and then another whilst the first one was on-going would cancel it
The solution is to use a NonViewAware for example
ImageSize imageSize = new ImageSize(width,height);
NonViewAware nonViewAware = new NonViewAware(imageSize, ViewScaleType.FIT_INSIDE);
ImageLoader.getInstance().displayImage(url,nonViewAware, new ImageLoadingListener() {

This solved for the issue for me, all images display and nothing is cancelled


ci: support building grt in sweeps

@jeffng-or FYI, add a sweep_parallel filegroup to build stuff in parallel and then afterwards build grt in serial

@jeffng-or @vvbandeira FYI, CI failures after build completed successfully.

@oharboe
The error is in the report generation. It is complaining about GRT-0116 error message which is that the stage finished with congestion.


[TOOLS] Update .dcos publish tooling to reuse s3_urls_from_env method

Sample output :
---
[S3 URL] DCOS BUNDLE: s3://infinity-artifacts/autodelete7d/hello-world/20181109-125953-EpRDIXWzmU7JuRtv/hello-world-stub-universe.dcos
DCOS BUNDLE: https://infinity-artifacts.s3.amazonaws.com/autodelete7d/hello-world/20181109-125953-EpRDIXWzmU7JuRtv/hello-world-stub-universe.dcos
---

For reference (of being consistent) this is a sample stub universe url :
s3://custombucket/autodelete7d/cassandra/20181108-204003-xELpcvU9VZnEzTvw/stub-universe-cassandra.json

and this is a sample artifact :
https://infinity-artifacts.s3.amazonaws.com/autodelete7d/cassandra/20181108-204003-xELpcvU9VZnEzTvw/cassandra-scheduler.zip

For publishing to a non default bucket/directory :
$ env S3_BUCKET=custombucket S3_DIR_PATH=custom-permanent-path ./frameworks/helloworld/build.sh .dcos

would create something like :
s3://custombucket/custom-permanent/hello-world/20181109-125953-EpRDIXWzmU7JuRtv/hello-world-stub-universe.dcos

OR
$ env S3_BUCKET=takirala-dev S3_DIR_PATH=custom-permanent S3_DIR_NAME=dir-name ./frameworks/helloworld/build.sh .dcos

would create something like :
s3://custombucket/custom-permanent/dir-name/hello-world-stub-universe.dcos

CI looks green now. Merging.