TabNine consumes too much CPU

This is on a Splunk app project with JS, python code.

I am seeing the same behaviour on ruby projects, at least 1 CPU uses 100%

We've made several improvements since regarding cpu and memory consumption of TabNine.
Can you verify that your issue is fixed?

Seems alleviated, thought not yet ready to say it's fixed.

I would say not fixed, have seen plenty of times where it uses 600% of CPU.

@International Did you see it go to 600% while typing, or when idle?

One of the times it went to 600% I checked activity monitor,tabnine was not in the top 10-15 processes. I was writing code, was in a meeting, then added a new ruby gem as dependency and the fan turned on. Tabnine was using 600%. Seems there is some kind of predisposition to use so much cpu after not writing code for some time. Had a few moments even today when it was using 400%.

On 5 Apr 2020, at 08:55, amircodota<EMAIL_ADDRESS>wrote:

@International Did you see it go to 600% while typing, or when idle?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@International That's great feedback.
Do you remember which ruby gem it was?
Was this an open source project by any chance? What editor are you using?
Would love to try the exact same use case myself.

If I remember correctly, it was https://github.com/chaps-io/gush https://github.com/chaps-io/gush .
Regarding the editor, it depends on the size/type of the file. Sometimes I use atom, sometimes vs code, sometimes sublime.
I think I have tabnine configured in all of them.

On 7 Apr 2020, at 09:29, amircodota<EMAIL_ADDRESS>wrote:
@International https://github.com/International That's great feedback.
Do you remember which ruby gem it was?
Was this an open source project by any chance? What editor are you using?
Would love to try the exact same use case myself.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/codota/TabNine/issues/110#issuecomment-610201149, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHZXRRIKI4SCI33HIPUILDRLLB3PANCNFSM4IHZZOJQ.


refactor(core/slide/slideTo): remove duplicate code

Method src/core/slide/slideTo.js refactored.
No breaking changes, only conditional optimized and duplicate lines of code removed.

@lucasrleandro I have a quick question, I have noticed that if i do a slideTo or SlideToLoop(index, 200, false) somehow events from swipermovement are still fired.
  const handleDividerVisible = (itemId: string) => {
    const dividerIndex = sidebarSwiperData.findIndex((divider) => divider.itemId === itemId);
    console.log(`dividerindex: ${dividerIndex}`);
    if (swiper) {
      // TODO: for this to work we need ti disable Waypoints when scrollTo is active ( LOOP)
      const speed = 400;
      const runCallbacks = false;
      swiper.slideToLoop(dividerIndex, speed, runCallbacks);
    }
  };

On our swiper component we have something to track realIndex that triggers a .scrollTo liek so
      <AppBar sx={classes.sidebarSwiperAppBar}>
        <SidebarSwiper
          sidebarSwiperData={sidebarSwiperData}
          onSwiper={setSwiper}
          onRealIndex={handleSwiperIndexChange}
        />
      </AppBar>
      ```

      Somehow even tho we do the .slideToLoop with callbacks disables it still triggers the event... in our case we have a horizontal swiper, and a vertical scroller with content and dividers that we try to connect bi. directional. So this causes some loopy behaviour. Do you have an idea how to hat at this ?

Merged, thanks!


Use refreshMillis prop as the interval

I also a replaced the "TODO" about why using bind with an explanation of why bind matters there. Hopefully other developers will find that helpful.

Thanks! I'd be happy to accept the refreshMillis fix!
I believe Joel's comment isn't referencing how bind works in general though--normally React autobinds methods on your component, so that you don't need to .bind any of them yourself. I think it doesn't autobind methods that you don't write though, like setState or forceUpdate, which is why bind was necessary here. A comment to that effect might be more helpful.

Just created pull #36, which doesn't have the bind comment change in it. Closing this one. :smile:

TIL :)

:) True. Autobinding is confusing which is why we're moving towards arrow functions on class property initializers instead.
class TimeAgo extends React.Component {
  monkey() {
    // I'm not autobound...
  }
  gorilla = () => {
    // but I am!
  }
}

I'm probably in the minority, but I find the es6 syntax to be really confusing and chaotic. I suppose I'll have to get used to it. :disappointed:

@jhubert Yeah, that's a valid concern. Our hope is that it's unfamiliar now but will be familiar once you learn it elsewhere (or you'll learn it for React and then be able to reapply it elsewhere).

@spicyj it's gorilla =  not gorilla: ? I guess I'd expect gorilla: bind to the scope outside the class?

Here's the latest proposal:
https://gist.github.com/jeffmo/054df782c05639da2adb
I think the colon conflicts with type syntax. The colon/equals/comma/no-comma/semicolon thing is unfortunate though.


bower "main" field cannot contain minified files

Appears that best practice (at-least for bower) is to provide the files in un-minified format and allow the end user to minify them along with their own files.
This issue; https://github.com/katspaugh/wavesurfer.js/issues/699 covers it, as do the linked issues; https://github.com/VictorBjelkholm/ngProgress/issues/119 and https://github.com/Packet-Clearing-House/maptable/issues/11
Any chance we can get this fixed up?

I'm not that familiar with bower and would apprechiate some help regarding this. A PR for the master (and possibly master-1 branch) would help me much.
The bower.json is located at https://github.com/dfahlander/Dexie.js/blob/master/bower.json. For now its main attribute points out the minified dist version of the file. Also, I ignore source files.

I believe, based on the referenced issues, you just need to change the main options to use dexie.js instead of dexie.min.js and bower will stop complaining about invalid meta-data when people install it.
It explicitly says in the spec not to use minified files for the main option.

@dfahlander Now that it's merged, is there a chance of getting a release out? Would be 1.5.2 I think?


Allow completing functions as first-class objects

Wouldn't it be better to complete just function names without parenthesis? And for the function signature to appear once you've typed invocation parenthesis? In code like this
const even = n => n % 2 === 0
;[0, 1, 2, 3, 4].filter(even)

tern autocompletes even with parenthesis (not what's needed here and in many places like this)

I agree, after this landed in tern, I have realized just how many times I pass around functions or access properties in the function itself.
I think more often than invoking it directly.

Isn't this an option (tern_argument_completion) that already defaults to false?

Not quite. I have "tern_argument_completion": false and tern still inserts empty parenthesis with the cursor inside after each completed function name. I have to hit backspace to clean them up every time I mean a function as first-class value, that is I don't mean to invoke it. I think the default behavior should be not to insert invocation parenthesis. E.g. MS Visual Studio Code doesn't do it and Atom's version has this option Do not add parenthesis if method is completed (not enabled by default though)

I see, it always added those parens. That's not good. Attached patch changes this.


Swiping really quickly causes middle/bottom card to be swiped instead of the top card

https://embed.plnkr.co/ebTZz51SsYUs7wzLemuo/ go here and just swipe really quickly a few times and then start swiping slowly and you will see the issue.

Are you swiping from a mobile phone or a web browser? I could not reproduce it.
May be i should think about a way to immobilize the bottom cards when the front one is not totally swiped yet.

Web browser, Chrome to be specific.

Actually I forgot to mention that you need to swipe quickly a few times and then use the buttons. Seems to be able to reproduce it easier that way.

Ok i did reproduced it with the button clicked. I will take a look at it.

Great :)

Fixed in 1.0.15


chore(master): release 2.8.7

:robot: I have created a release beep boop
2.8.7 (2024-10-29)
Bug Fixes

.finally() cannot invoke at keq request (4315979)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/keq-request/keq/releases/tag/v2.8.7 :sunflower:


CPLP-1783 refactoring Checklist-Worker to use fine-granular process-steps

implements https://jira.catena-x.net/browse/CPLP-1783
refactoring worker to use fine-granular process-steps with unified status-model.

Regarding the REGISTRATION_VERIFICATION process, we currently have two endpoints which is getting triggered.
1. api/administration/registration/application/4f0146c6-32aa-4bb1-b844-df7e8babdcb4/approve

2. api/administration/registration/application/4f0146c6-32aa-4bb1-b844-df7e8babdcb4/decline

those endpoints will either directly set the REGISTRATION_VERIFICATION checklist item to DONE or FAILED.

registration-verification endpoint refactored using RegistrationVerificationHandler: https://github.com/catenax-ng/tx-portal-backend/pull/138/commits/e684511ad4669efcef755294a7017f9c7d2f5f13

To avoid circular dependencies and unsuitable locations of businesscode I did relocate the ChecklistProcessor into the Checklist.Worker module and all the handlers into the externalsystems businesslogic.
Last commit is still work in progress as I need to fix the dependency-injection-extension and unit-tests


Fail to record using Azure Kinect DK recorder

I am new to Azure Kinect. After installing the MSI package of azure Kinect SDK (https://github.com/microsoft/Azure-Kinect-Sensor-SDK/blob/develop/docs/usage.md), I tried to record data stream using Azure Kinect DK recorder but got an error like below.

I used Firmware Versions as below.
OS: Windows 10
RGB camera firmware:      1.6.110
Depth camera firmware:    1.6.80
Depth config file:        6109.7
Audio firmware:           1.6.14
I could use Azure Kinect viewer v1.4.1 without any problem but failed to record the data stream.
Thx.

Try opening the command prompt as administrator or changing the current directory.

This error is occurs because you are writing into the tools directory under Program Files. In general it is a bad practice to write to  Program Files and Windows now prevents none administrative users from writing to any systems directory. Instead include a path with the filename to an appropriate user directory.

Thank you for your responses. It worked after I changed the directory.

Thank you for your responses. It worked after I changed the directory.

Hi, can you please illustrate how I can change the directory where the recordings are saved? I am encounting the same problem right now. Thank you very much.


Module/import upgrades

This PR adds support for the following:

glob imports (import * from 'foo.kcl)
import constants
re-exports (export import ...)
import a whole module (parsing only, will try to finish this next week, import 'foo.kcl')

It also includes:

Remove the Vec in VariableDeclaration which was always a single item (I was going to unify Variable decls and imports, but it didn't work out)
Make an execution module (simple refactoring, it was driving me a bit nuts having the execution code spread all over the place)
Fix the import tests which required a second file and a supplied project directory to find it in. They were previously checking for an error where they should check success or checking for the wrong error.

I have mostly managed to split this all up into self-contained commits, but after rebasing this is a bit imperfect, sorry.

Oh, and as for why: importing whole modules is for assemblies, the rest is steps towards a modularised std.


Prevent race condition on server connection

Probably not gonna occur in our case, but surely a good pattern to follow.
Explained in : https://www.youtube.com/watch?v=DqHb5KBe7qI    starting at 16:20

Good catch @dvinubius


It just doesnt work

I have installed betterdiscord but whenever i start up discord i just cant find the place to change my background so im assuming it didnt work so i tried reinstalling it and it still didnt work and i did put it out of my download folder and opened it with admin so i have no clue what the problem is i have windows 10 btw

Can you elaborate on this:

cant find the place to change my background

BBD doesn't just "have a place to change the background" you need a theme for that.


Link to sequence that is currently running

Use case
As a user, I'm triggering multiple sequences at the same time. As a consequence, the first one is blocking the others from getting launched.
This can result in the following picture, where one sequence is running (R) and two sequences are queued (Q):

Improvement

In a queued sequence, provide a link to the currently running sequence:

As a user, I can then directly jump to the sequence that is blocking the current execution. This is helpful in order to find stuck sequences that are blocking others.

Definition of Done

[ ] As a user, I can directly jump to the sequence that is blocking the current sequence from getting executed.

As we discussed, a precise message should state the current status:
Sequence is blocked by another sequence. Click **here** to get to the current running sequence.


Add patch for filename paths

#328

Is the following situation possible with input?
<EMAIL_ADDRESS>"content",
"src/_hello/kitty/b.sol": "content",

Is the following situation possible with input?
<EMAIL_ADDRESS>"content",
"src/_hello/kitty/b.sol": "content",

I would say it's not possible, because in solidity you always import it like import<EMAIL_ADDRESS>I also didn't come up with an idea of how to handle not only first component of path,  however, If you suggest a way how to handle this type of import, I would discuss it.


fix a scrollbar updating bug

Addresses https://github.com/flutter/devtools/pull/3262#discussion_r688073232, the remote ScrollMetricsNotification accepted incorrectly and cause the scroll bar paint incorrectly.

Thanks so much for your help in quickly finding the root cause and fixing it! I've confirmed that this patch resolves the issue I was seeing with the horizontal scrollbar in https://github.com/flutter/devtools/pull/3262.
Before this change:

With this change (works as expected!):


Updated condition creating the geo fencing object

Related Issue

Hidden magic variable for geo-fencing
Clickup ticket - https://app.clickup.com/t/1tjwczh

Proposed Changes/fix

Need to pass the geofencing flag as rtc props input and update the condition to create geo fencing functionality
Updated the props context and condition to create - RtcEngine.createWithAreaCode

Rebased with original branch and pushed the required changes


feat(theme): introduce dark theme

I propose to introduce dark theme for gib nerd coding in the dark.
#18

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

What's the status here?

What's the status here?

I suspect https://github.com/denoland/deno_doc/issues/377 may be a bottleneck, but I don't know for sure.

To much conflict wait for deno docs and maybe open new pr


Look in GDA to work out what we need to do between grid and rotation

To be documented here

When we have this list discuss with @neil-i03 how much of it is actually needed

Between XRC and rotation collection we do the following:

Detector is moved to collection location
Check that the cryo is in - Can we just assume this in Hyperion?
Bunch of stuff for plate screening - discussed with Neil that this is out of scope for now
Snapshots - covered in https://github.com/DiamondLightSource/hyperion/issues/349
Backlight moved out
Scatterguard in, generally moved to data collection pos - Can we just assume we're already in this position in Hyperion?
Some logic to get the wavelength/transmission based on metal id i.e. https://jira.diamond.ac.uk/browse/I03-335 - Can we ignore this usecase for Hyperion for the time being?
Move to requested wavelength - I suspect only relevant if we have changed based on metal id?
Move to requested beam size - Hyperion is already doing this just after the grid scan based on xtal size
Check the "sample current" is not too low - I can't even find in GDA where the sample current might be being read from, I suspect this can be removed
Open the detector shutter
Some configuration of a HighestExistingFileMonitor - I think this is for the GDA client to be able to pick up the latest file for reading, I don't think we care about this in Hyperion?
Disable ROI - Hyperion should have already done this after the grid scan
Wait on xbpm feedback - this is the same as for XRC except for wedged MAD we don't wait for stability, do we want that logic Neil?
Read flux and do some dose scaling - I don't think this is being done properly on i03 yet anyway?
Set transmission
Configure parameters on detector around beam position, enegry threshold - we should check how many of these we really need to set if we haven't changed energy or moved the detector

@neil-i03 can you check any questions above? I think, as a first pass, we can get it down to:

Configure and start arming detector
Move detector
Snapshots
Open detetctor shutter
Wait on xbpm feedback
Set transmission
Do rotation


[python-package] How can I use goss in the latest version 4.5

In the latest version the parameter "boosting_type" doesn't include "goss" anymore. How can I activate it in the LGBMRegressor

Thanks for using LightGBM.
As described at https://lightgbm.readthedocs.io/en/latest/Parameters.html#data_sample_strategy, GOSS can be specified via data_sample_strategy. That change was made in LightGBM #4827, as part of v4.0.0 (https://github.com/microsoft/LightGBM/releases/tag/v4.0.0).
Here's a minimal, reproducible example:
import lightgbm as lgb
from sklearn.datasets import make_regression

X, y = make_regression(n_samples=10_000, n_features=10)
reg = lgb.LGBMRegressor(
  n_estimators=10,
  data_sample_strategy="goss"
)
reg.fit(X, y)

If you do that, you'll see this in the logs:
[LightGBM] [Info] Using GOSS

got it! Thanks a lot.Now I have a new question:
In the doc LightGBM regressor includes following params:
init(boosting_type='gbdt', num_leaves=31, max_depth=-1, learning_rate=0.1, n_estimators=100, subsample_for_bin=200000, objective=None, class_weight=None, min_split_gain=0.0, min_child_weight=0.001, min_child_samples=20, subsample=1.0, subsample_freq=0, colsample_bytree=1.0, reg_alpha=0.0, reg_lambda=0.0, random_state=None, n_jobs=None, importance_type='split', **kwargs)
But no 'data_sample_strategy' inside.Why can it be directly changed?

But no 'data_sample_strategy' inside.Why can it be directly changed?

Any other parameters passed to the constructor of LGBMRegressor which don't match its keyword arguments will be collected together and sent to LightGBM's C++ library as additional parameters.
As it says at https://lightgbm.readthedocs.io/en/latest/pythonapi/lightgbm.LGBMRegressor.html:

**kwargs –
Other parameters for the model. Check http://lightgbm.readthedocs.io/en/latest/Parameters.html for more parameters.

By the way, I reformatted your follow-up question. If you're unsure how I did that, please see https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.


Complex number not supported for max() operation

Hi, thanks for adding complex support. However for my own dataset, I am getting the same error at
d = max(d, min(d_hat, d*growth_rate)) in dadapt_adam.py. Upon inspecting using the debugger, I found that d_hat is complex valued, hence the error.

We might be using different PyTorch versions, as the complex number support has changed over time. What version are you on? When I run the code you linked me to all the values passed into that operation are real valued. Can you tell which of sksq_weighted,  gsq_weighted and sk_l1 are complex?

Hi, both sksq_weighted and gsq_weighted are complex in my case. Before gsq_weighted becomes complex, g_sq is complex, hence gsq_weighted = beta2gsq_weighted + g_sq(dlr**2)*(1-beta2) results in a complex gsq_weighted.


TextInput.setStyle and TextInput.setEditableSizeAndTransform calls not handled in IOS/Android

Steps to Reproduce

As explained here: https://github.com/flutter/flutter/pull/39344#issuecomment-530987927 the text editing method calls added for web started creating errors in IOS.
I also expect to see them in Android.
Logs

/cc @aleor
We weren't able to reproduce it, with the latest master branch on IOS.
Can you please share the steps to reproduce?

Closing the issue. We are not able to replicate with the latest master branch on IOS and on Android.


Add comments to explain RPC client code

Added comments to the main function and helper functions to explain the purpose and functionality of each part of the RPC client code. Should help improve code readability and maintainability.

@Gudnessuche can you run cargo +nightly fmt --all?

Done


[AutoPR deviceprovisioningservices/resource-manager] typo: Microsoft.Devices

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/4684

This PR has been merged into https://github.com/Azure/azure-sdk-for-go/pull/3598


Add ASCE Rocky Mountain

Ah, woops. The new conference was added to the wrong file. It should be added to populate_conferences.py, not dev_populate_conferences.py.

I will fix this.

Oops, sorry about that.  Not sure why I got the wrong one this time.  Thanks for fixing.


Eval/feature/unified eval inputs

Creates a series of base classes for evaluators, and rewrites a bunch of them to use said base classes. Specifically almost all evaluators that can accept a conversation as an input are now derived from these classes.
Draft - Currently does the following:

Adds a bunch of base classes under _evaluators._common.
The base-est class is _BaseEval, which handles the async class wrapping, and contains some fancy kwarg manipulation that allows for only the __call__ method to need defined inputs.
_BaseRaiServiceEval Is for query/response evaluators that get their result by calling evaluate_with_rai_service. Individual content safety evaluators, Protected material, ECI, and XPIA evaluators all derive from this.
__BaseContextFlowEval Is for evaluators that require a context input, in addition to query/response, and which use a prompty-defined function to perform their evaluation.  The Groundedness, Relevance, fluency, and coherance evaluators extend from this.
Removes content safety chat evaluator.
Removes chat evaluator
Plucks the internal retrieval evaluator from the chat evaluator and publisizes it as its own evaluator.
Modifies e2e tests to also check the conversation inputs for all the non-base evaluators mentioned above.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-ai-evaluation

/check-enforcer override


Update request: freecad 0.21.2 → 1.0RC

Package name: FreeCAD
Latest released version: 1.0RC
Current version on the unstable channel: 0.21.2
Current version on the stable/release channel: 0.21.2
[x] Checked the nixpkgs pull requests

Notify maintainers
@viric
@gebner
@AndersonTorres
Relevant notes

https://blog.freecad.org/2024/09/10/the-first-release-candidate-of-freecad-1-0-is-out/
https://wiki.freecad.org/FreeCAD_1.0_Development_Cycle
https://github.com/FreeCAD/FreeCAD/tree/releases/FreeCAD-1-0

Expand to see list of minimum supported 3rd party library versions

It is unorthodox to request an RC (moving target) build but since there is 3rd party dependency complexity the thought of 'this may be a good moment to start porting FC to 1.0' on nix is relevant. The 1.0 release still has some release blockers. Perhaps the nix build will be ready in time for the 1.0 release if efforts start now?
Related:

#284524

Note for maintainers: Please tag this issue in your PR.

Add a :+1: reaction to issues you find important.

CC @pinpox
Thanks for your effort to package Ondsel, would you be interested in helping to build FreeCAD 1.0RC ?

CC @pinpox Thanks for your effort to package Ondsel, would you be interested in helping to build FreeCAD 1.0RC ?

Yes! I'm interested in freecad 1.0 as I plan on using it myself. I didn't follow up on the ondsel package as I never found out how to install the plugins (see comments), but maybe freecad 1.0 is easier do package.

Hi, I've had this working for a while, opened #343592 that fixes the build.

@pinpox I've started to work on packaging of freecad with modules, see #347776


Update and fix broken links in Core docs v4 overview

closes #1664

Cool...Thanks Mona! I have updated in and just checked the preview, and it works now 👍


feat: Add support for existing IAM role for enhanced monitoring

Description
Add support for using an existing IAM role to send RDS enhanced monitoring metrics to CloudWatch Logs.
Background:
If the module is used for provisioning multiple clusters in the same account, it will create one monitoring role for each, which isn't really necessary as they're identical - attaching the same AWS managed policy - AmazonRDSEnhancedMonitoringRole.
Also, when enabling via the console, from the docs:

The first time that you enable Enhanced Monitoring in the console, you can select the Default option for the Monitoring Role property to have RDS create the required IAM role. RDS then automatically creates a role named rds-monitoring-role for you, and uses it for the specified DB instance or Read Replica.

Testing:
Added the below to an existing cluster:
data "aws_iam_role" "default_aws_rds_monitoring_role" {
  name = "rds-monitoring-role"
}

module "ods2" {
  source                 = "terraform-aws-modules/rds-aurora/aws"
  (...)
  create_monitoring_role = false
  monitoring_interval    = 60
  monitoring_role_arn    = data.aws_iam_role.default_aws_rds_monitoring_role.arn
}

Generated these changes:
      ~ monitoring_interval = 0 -> 60
      + monitoring_role_arn = "arn:aws:iam::<REMOVED>:role/rds-monitoring-role"

@antonbabenko I rebased this using the latest master. Does this PR make sense?
Thanks,

Sorry to comment on this PR but we need this in place for also another reason as explained in https://github.com/terraform-aws-modules/terraform-aws-rds-aurora/issues/93 . Running enhanced monitoring in AWS CHINA with this module is impossible because the role policy is hardcoded with a specific partition and the role is not injectable. This PR would be a good workaround while we wait for a partition implementation.

Rebased this again, would you be able to give this an eye @antonbabenko? 🙏 and 🙇.

We need this as well because we have restrictions on IAM roles in our org that this module doesn't satisfy. Being able to supply our own IAM role for things would be great.

Rebased again, and updated commit title to pass semantic check.

@antonbabenko :+1:

Great!
v2.24.0 has been just released.


Theme submission - hugo-theme-dooz

Theme submission
Please make sure that you have read the theme submission guidelines before submitting a theme. The guidelines provide all relevant information and requirements that have to be fulfilled before the submission. Please tick the relevant boxes for your theme in the checklist below:
Link to my theme repository: https://github.com/hollson/hugo-theme-dooz
I made sure that...

[x] the repository contains a good README.md describing my theme
[x] an open source license has been added to LICENSE.md
[x] all metadata have been added to theme.toml
[x] screenshots have been added in the images/ folder with the required dimensions
[x] in case I'm using a customized demo via the exampleSite folder that

[x] https://example.com is set as base url in exampleSite/config.{toml, yaml, json} to avoid the abuse of unused domains
[x] I tested that my theme's demo works with the content directory of gohugoio/HugoBasicExample

[x] I tested my theme against the gohugoio/HugoBasicExample

[x] I've checked the developer tools' console in my browser for error messages

[x] in case my theme is using Hugo Pipes features like toCSS and PostCSS that I have committed the /resources directory with all generated assets, for my theme to work in the basic version of Hugo

N.B. By submitting a theme to the Hugo Themes Showcase you understand that you need to maintain your theme. You will need to keep an eye on whether your theme's demo generates on the Hugo website, whenever there is a new release. We are a very small team and we just cannot keep up opening issues in the various theme repositories to notify authors. Whenever a theme demo breaks and remains broken then at some point it will be removed from the list without prior warning. If you no longer wish to maintain a theme please let us know.
New themes will usually be promoted on Hugo's official Twitter account. If you would like to be mentioned in the tweet please add your Twitter username to this submission.
Link to my Twitter account (optional): REPLACE-WITH-URL
Feel free to ask questions. We're glad to help.

Hello @hollson
I have noticed the following issues with your theme submission:

You have to provide screenshots of your theme, see: https://github.com/gohugoio/hugoThemes/blob/master/README.md#media

You have to provide a description in [line 7(https://github.com/hollson/hugo-theme-dooz/blob/master/theme.toml#L17-L21) of theme.toml

You should remove empty parameters from theme.toml like the ones in lines 17-21

You have to remove all .DS_Store files from your theme's repo. These files contain personally identifiable info related to your Mac and they should not be made public in a GitHub repo.

Once you look into the above let me know.

I have patched them @onedrawingperday

Hello @hollson
We currently do not accept donation buttons in theme demos. You will need to remove layouts/partials/widget-reward.html and the associated JS from the theme repo. You may have a donation link in the README.
Also as stated in the README

We discourage the use of third party CDNs to serve assets. It is no longer a good practice in this day and age (fingerprinting, security risk etc) despite of the possible benefits of faster loading times.

The theme is full of scripts loaded through third party CDNs. You will need to host all those scripts directly from the theme repo, (except the Google fonts).
Also as stated in the README

An Example Site should not have third party tracking enabled. If you wish to provide configuration parameters to third party services (analytics, comments etc) then please do not enter a valid account ID or username.

You need to remove the tracking IDs lines 70-72 of the exampleSite/config.
You still need to remove the .DS_Store fie from the theme repo.
The provided images (screenshot.png and tn.png) are skewed horizontally. Please provide them in the required dimensions without the distortion.
Again as stated in the README

If you add screenshots to the README please make use of absolute file paths instead of relative ones like /images/screenshot.png. Relative paths work great on GitHub but they don't correspond to the directory structure of themes.gohugo.io. Therefore, browsers will not be able to display screenshots on the theme site under the given (relative) path.

You need to provide an absolute URL for the screenshot in the README i.e. https://raw.githubusercontent.com/hollson/hugo-theme-dooz/master/images/screenshot.png


Django or Flask?

User story

As a team member, I would like to know which framework would SDs like to implement between Django and Flask.

Acceptance criteria

Majority SD's agree on the framework which can be handled with ease

Definition of done

All members should vote for the best possible framework by the next sprint (21.04.2021)

Django has been accepted by the SD's.


fix(yaml): avoid validation error

What does this PR do?
I get error:
error: error validating "deploy/service_account.yaml": error validating data: ValidationError(ServiceAccount): unknown field "labels" in io.k8s.api.core.v1.ServiceAccount; if you choose to ignore these errors, turn validation off with --validate=false
labels are in metadata, not in root element
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#serviceaccount-v1-core
What issues does this PR fix or reference?
N/A
Is it tested? How?
launching make deploy

are the tests really working ?

/retest

/retest
/ok-to-test

/retest

I'm going to investigate these failure issue

/test v4-openshift-web-terminal-e2e

locally e2e tests passed. I'm merging this PR and will investigate test failure cause.


Direct Line API down

Hi all,
We're currently experiencing problems with the Direct Line API.
It stopped working and calls to the API only return the following:
HTTP 403:
{
"message": "BadArgument:Site missing or disabled"
}
Anyone else experiencing the same?

We have the same issue.

Yes same here too! It is happening on some bots not all of them.

+1 not happening on all bots, but I'm facing the same on one of my bots.

I'm experiencing issues with CORS can you guys also confirm this?

I'm getting almost the same error! Mine just says forbidden. The thing is, the token regen on direct line seems to not be working. I have tried to regenerete the secret multiple times but it just keeps giving the same secret. Might have something to do with this.

Hi @quaddamage87, @myarotskaya, @tjoudeh, @brene, and @erlendw, we have a now build out that should have everything working. Can you take a look and let me know if you're hitting any further issues?

Hi @dandriscoll , I just tested it and everything is working again! Thanks a lot, we really appreciate your quick support!

@myarotskaya, @tjoudeh, @brene, and @erlendw, please let me know if your related issues are also resolved so I can close this issue. Thanks!

@quaddamage87 @dandriscoll looks good for me too, thanks for following up.

Alright, I'm closing this issue.

Thanks @quaddamage87  😄


BackdropFilter lugs in fadeIn animation

Steps to Reproduce
I'm trying to use CachedNetwordImage package on iOS with placeholder and backdrop filter blur effect, but the backdrop filter lugs for a while during the transition from placeholder and image builder.
Screencast in slowed animations mode:

imageBuilder: (context, imageProvider) {
                      playSound();
                      return  Stack(
                        children: <Widget>[
                          Container(
                            decoration: BoxDecoration(
                              boxShadow: const <BoxShadow>[
                                BoxShadow(
                                    offset: Offset(0, 10),
                                    color: Color.fromRGBO(0, 0, 0, 0.7),
                                    blurRadius: 15,
                                    spreadRadius: -10),
                              ],
                              borderRadius: BorderRadius.circular(34),
                              image: DecorationImage(fit: BoxFit.cover, alignment: Alignment.center, image: imageProvider),
                            ),
                          ),
                          //
                          isChoiceMade
                              ? const SizedBox()
                              : ClipRRect(
                                borderRadius: BorderRadius.circular(34),
                                child: BackdropFilter(
                                  filter: ImageFilter.blur(sigmaX: 15, sigmaY: 15),
                                  child: Container(color: Colors.transparent),
                                ),
                              ),
                        ],
                      );
                    },

iOS 13.1.3
Release mode
iPhone 7
Logs

[✓] Flutter (Channel master, v1.10.15-pre.272, on Mac OS X 10.14.6 18G103, locale en-RU)
    • Flutter version 1.10.15-pre.272 at /Users/alectogeek/Documents/Programs/flutter
    • Framework revision 5bc7fb6835 (2 days ago), 2019-10-27 21:25:13 -0700
    • Engine revision 3ebf006904
    • Dart version 2.6.0 (build 2.6.0-dev.8.2 6354b0b97d)

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at /Users/alectogeek/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-29, build-tools 29.0.2
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.1, Build version 11A1027
    • CocoaPods version 1.8.0

[✓] Android Studio (version 3.5)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 39.0.3
    • Dart plugin version 191.8423
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)

[✓] Connected device (1 available)
    • Starlink • 2a1a85a3ec0891e413da9c4a9d5f311bd6a02abe • ios • iOS 13.1.3

• No issues found!

@BondarenkoStas Also same behavior for Android

/cc @liyuqian

Are there any news?

Removing the Skia tag pending further investigation.

From the gif, it's hard to tell if this is a rendering performance issue, or if the BackdropFilter is just incorrectly retained in the Widget tree (e.g., isChoiceMade is false while it should be true).
@alectogeek : can you please take another video screenshot with profile mode and performance overlay turned on so we'll know if this is a performance issue? Meanwhile, it would also be helpful if you can turn your snipped into a minimal main.dart file where we can copy paste it into a new flutter create project and reproduce your issue.

@liyuqian  main.dart code:
import 'dart:ui';

import 'package:cached_network_image/cached_network_image.dart';
import 'package:flutter/cupertino.dart';
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return CupertinoApp(
      title: 'Flutter Demo',
      home: MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  MyHomePage({Key key, this.title}) : super(key: key);

  final String title;

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Container(
      width: MediaQuery.of(context).size.width / 2,
      height: MediaQuery.of(context).size.width / 2,
      child: Center(
        child: Stack(
          children: <Widget>[
            CachedNetworkImage(
              fadeInDuration: Duration(seconds: 3),
              filterQuality: FilterQuality.medium,
              imageUrl: 'https://source.unsplash.com/random',
              fit: BoxFit.cover,
              alignment: Alignment.center,
              placeholder: (context, string) {
                return Container(
                  decoration: BoxDecoration(
                    border: Border.all(color: const Color.fromRGBO(255, 255, 255, 0.2)),
                    borderRadius: BorderRadius.circular(34),
                  ),
                  child: const Center(
                    child: CupertinoActivityIndicator(),
                  ),
                );
              },
              imageBuilder: (context, imageProvider) {
                return Stack(
                  children: <Widget>[
                    Container(
                      decoration: BoxDecoration(
                        boxShadow: const <BoxShadow>[
                          BoxShadow(
                              offset: Offset(0, 10),
                              color: Color.fromRGBO(0, 0, 0, 0.7),
                              blurRadius: 15,
                              spreadRadius: -10),
                        ],
                        borderRadius: BorderRadius.circular(34),
                        image: DecorationImage(fit: BoxFit.cover, alignment: Alignment.center, image: imageProvider),
                      ),
                    ),
                    Container(
                      child: ClipRRect(
                        borderRadius: BorderRadius.circular(34),
                        child: BackdropFilter(
                          filter: ImageFilter.blur(sigmaX: 15, sigmaY: 15),
                          child: Container(color: Colors.transparent),
                        ),
                      ),
                    ),
                  ],
                );
              },
            ),
          ],
        ),
      ),
    );
  }
}

the only thing you need to add to your pubspec file is:
cached_network_image: 2.0.0-rc

From my testing, I didn't see any specific slow frame in either UI or GPU thread that could cause such a discontinuity in the blur animation as shown in the GIF above. I think it's a mismanagement of the animation states (maybe something is not in sync). It could be either:

An issue in the CachedNetworkImage
An issue in some other widgets
An issue in the combined usage of CachedNetworkImage and some other Flutter widgets.

@HansMuller : as our animation expert, can you please try the reproduction app above and give some suggestions?

@liyuqian But I can reproduce it using the code above. I created a new project and there is nothing else besides the code above. Pay, please, attention to picture edges during fade-in animation.

@alectogeek : yes, I can reproduce the lug too. The problem looks exactly the same as your GIF posted above. My comment above only said that I didn't see a very slow frame in any threads. So the lug may be caused by something else like a misaligned animation state.

Oh, gotcha. But I didn't understand where exactly it could be misaligned, are talking about my code or framework? :)

I'm a little more suspicious about our framework. That's why I think @HansMuller could provide more insights. Also CC @flar who is recently working on BackdropFilter issues.

Is there any news?

I'm working to detect if we can cache the blurred background of a BackdropFilter, but that is a long term project and I have a number of PRs to finish (dependencies) before we can handle that. There is no short-term solution from these efforts.
With respect to diagnosis of what you are seeing, I have the same questions as @liyuqian with regards to what you are referring to by "lugs". Are the frames drawing slowly. Is it a high frame rate, but the progress between the two end states doesn't seem to move as linearly as you were expecting?

If you are referring to the sudden change that happens near the end of the fade in animation, it's because flutter doesn't know the size of the image you're trying to load beforehand. If you specify the size of the image explicitly the transition should be smooth.

@LongCatIsLooong I tried to specify image size in various vays, but it didn't help.

I got the same problem, and it seems the blur effect (frosted glass effect) will temporarily disappear when the fade transition active and it will return after the fade transition done.

@pqsky7 If a BackdropFilter is a child of an Opacity widget then the BackdropFilter will not have access to the background when the Opacity has a value of anything but 1.0. BackdropFilter widgets currently cannot work inside an Opacity widget unfortunately.
See this comment for more information.

@flar It worked! Thank you! Yeah, the problem was related with opacity, so I just have removed fadeInAnimation for image

@alectogeek : thanks for the confirmation. Can we close this issue now?

@liyuqian Sure, the workaround fits me for now. Thank you!


CFE is not properly inferring Object methods when the receiver is dynamic

This is a static error in Analyzer, which infers the static type of b as String.  CFE, however, infers it as dynamic and allows the code.
void main() {
  dynamic a = 5;
  var b = a.toString();
  b = 42;
}

This results in a runtime error on CFE in the following, where the Analyzer infers the type for map as String but CFE as dynamic.   With CFE, we get a runtime error when the list is implicitly downcast to List<String>.
void main() {
  List<dynamic> l = [1, "hello"];
  List<String> l2 = l.map((dynamic element) => element.toString()).toList();
}

@a-siva hit this in package:process.

@lrhn @leafpetersen - can you confirm which semantics we want?  The Analyzer does infer Object methods even when the receiver is dynamic.  CFE does not.
@kmillikin

Just to make sure that we start from the existing approach rather than a vacuum—the language specification has the following in 'Binding actuals to formals':
If the static type of $f$ is \DYNAMIC{} or the built-in class \FUNCTION{},
no further static checks are performed.

(which in the context means that all argument list shapes are accepted), and in 'Ordinary Invocation':
If $T.m$ does not exist, or if $F$ is not a function type, the static
type of $i$ is \DYNAMIC{}.

(which in the context means that when we call an entity of type dynamic, the returned result also has type dynamic).
This means that even invocations of methods on Object have so far been specified to permit arbitrary actual argument lists, and make no assumptions about the returned result.
It would make sense to consider names of methods on Object to refer to exactly those methods, but we still do not prevent things like this:
class A {
  String toString([Object o]) {}
}

This means that dynamic d = ...; d.toString(42); would not just be allowed at compile-time, it could also succeed at run-time. So we would take away the ability to dynamically invoke methods that override methods in Object in a way that extends the set of possible argument list shapes. Another way to achieve the same thing (that d.toString(42) or similar "impossible invocations of Object methods will actually succeed) would be via noSuchMethod and a suitable superinterface.
These situations may be considered marginal, but they are still examples of outlawing programs that use dynamic, and will work. This is in general be something that we may not want to do, at least not without even noticing it.
Lasse and I discussed this situation with Aske recently, and we discussed handling the above type of situation by introducing a notion of all possible overridings. In particular, d.toString(42) should be allowed because it is possible to override toString with something like String toString([Object o]). The static type of d.toString(42) would still be String because it is not possible to override toString in Object in such a way that it does not return a String.
Of course, these considerations would be relevant for arbitrary methods (and not just for the methods declared by Object) if we were to introduce a notion of dynamic<T> for arbitrary types T, in which case we would certainly need a general principle for computing the return type of "semi-dynamic" method invocations, and for checking their argument lists.

I'm not very keen on making these return dynamic.  This was a deliberate choice.  I understand the theoretical argument for allowing arbitrary calls, but it feels extremely theoretical to me.  In practice I've never seen any code that actually wants to add optional arguments to methods on Object, or use noSuchMethod to intercept calls with the wrong number of arguments.  On the other hand, there's lots of code which calls toString or hashCode on things of type dynamic, and not actually using the right type is basically deliberately not helping users with real code in order to preserve a corner case that I don't think anyone outside of the core Dart team ever even considered to exist.
So I'm definitely in the camp that the Object methods should always be inferred.
If there's strong disagreement with this, perhaps we could consider specifying this such that a valid invocation of the Object methods is inferred, but an invalid invocation is not.  I would hope that in that case the analyzer would still issue a hint anyway, at which point it feels fairly pointless to me - why get back in the business of providing the type system that users actually use via the hint system?

I'm not sure where the inference is entering this. We are calling methods on a receiver with static type dynamic, all the types are there, so there isn't any inference going on. (Or, I might be splitting hairs, but inferences is confusing, so I want to be very explicit about where and when it happens).
You are, if I understand it correctly, saying that such invocations should first statically check if the member exists on Object, and if so, treat it as a normal (non-dynamic) invocation of that member on something with type Object. Only if the member is not on Object, it's treated as a dynamic invocation on the receiver.
That's a restriction, but only really on noSuchMethod and toString, since the rest of the members are getters or operators that can't be overridden to be more callable than they already are.
From a purity stand-point, I'd like dynamic to mean that you can call any member that you know exists, without having to cast to the type that actually declares the member. That includes overrides of toString and noSuchMethods with more optional arguments or wider argument types.
The alternative you describe would check if the the entire invocation is a valid invocation of a member on Object (including types?), and if so, treat it as a non-dynamic invocation, otherwise treat it as a dynamic invocation. This matters for cases like print(dynValue.toString(16)); or dynValue.noSuchMethod(Object()).
If this was just about dynamic/Object, then I wouldn't really care, but if we ever want to introduce dynamic Foo (or dynamic<Foo> as Erik writes it, and I disagree with completely), then what we do here takes precedence as the behavior of dynamic Object.
A dynamic Widget would be able to hold any subclass of Widget and call any method on those that you know exists. I would like that to include methods extended with more parameters. You still get full static typing for valid invocations of Widget members, and dynamic invocation of invalid invocations.
So, I like this approach. The only thing that worries me is that I would like the result type to be available for dynamic invocations of known members with extra arguments.
So, my proposal:
If d has type dynamic, then for member accesses:

d.id(args):

If Object has a getter named id, then treat this as (d.id)(args) (below). (Does a setter interfere here?)
if Object has a method named id, then the static type of the expression is the return type of that method, and any actual parameter types of that method are used for inference of corresponding actual arguments. Further arguments have no context type.
Otherwise, the static type of  the expression is dynamic.

d.id:

If Object has a getter named id then the static type of the expression is the return type of that getter.
If Object has a method named id, then the static type is the function type of that method (and it's a tear-off).
Otherwise the static type of the expression is dynamic.

Basically, if Object has a declaration, trust that it's a getter or method, then trust the return type, but do allow invalid invocations. No hint, if you don't want dynamic behavior, don't use dynamic. Again, it's only toString and noSuchMethod that actually care about this, I can live with someone writing dynValue.toString(x) by mistake.
This doesn't try to make the invocation non-dynamic, it just uses the existing information to figure out the one type it can be certain of, and uses the argument type hints that it has. In practice, a fully valid invocation can avoid being dynamic at all, so you avoid the extra overhead of a dynamic invocation if the argument count and types match the known signature.
This approach generalizes to dynamic Widget. It allows a dynamic Widget w; to be called with any method that a subclass might have, but it helps you with all the the information that it does have.
WDYT?

Talked to @munificent who's also in the dynamic camp, so I seem to be in a very strong minority here.
I'll try running a presubmit internally and seeing how much code breaks.

This doesn't try to make the invocation non-dynamic, it just uses the existing information to figure out the one type it can be certain of, and uses the argument type hints that it has.

I'm not sure that it can actually be certain of it, unfortunately.  If we allow invalid invocations, then you have:
class Watsit {
  noSuchMethod(_) => 3
}
void main() {
  dynamic d = Watsit();
  String s = d.toString("Too ", " many ", " arguments "); // Goes to noSuchMethod, since wrong # of args
}

cc @jmesserly

There is a performance aspect to this as well - object calls on dynamic become more expensive.

As a concrete example of the impact of this, note that everything in the block starting at line 93 here:
https://github.com/dart-lang/matcher/blob/efcf386d6ae7b6553df11b63b564c4dd35969552/lib/src/pretty_print.dart#L93
is entirely statically typed if we infer the return type of toString, but is entirely unchecked otherwise.

In that example, Leaf, I think the code should have been written:
String _prettyPrint(Object object, int indent, Set seen, bool top) { ... }

The function accepts any and all objects, so Object is the right annotation for it. dynamic should mean either "The type system can't express the set of objects I accept here" or "I really want dynamism". If the function correctly allows all objects, Object is the way to signal that intent.

To the larger issue, I worry that statically checking members on dynamic if they happen to exist on Object could paint us into a corner in the future. If we later add non-Object value types, what happens when they get boxed to dynamic? What if those value types don't support toString()?

I'm not sure that it can actually be certain of it, unfortunately.

Gah. In that case we can only use the type when the arguments are statically known to be correctly structured, and we must assume dynamic as result of all dynamic invocations. I guess that's fair.
So, if Object has a getter or method id, then dynVar.id has the static type of that getter, and if Object has a method id that accepts args then dynVar.id(args) has the return type of that method as static type (which means String for toString and dynamic for noSuchMethod, so it's really just toString).
I'm worried about the future too, and I would want a dynamic Widget option to be viable and useful. It probably can be even if the inferred type is dynamic for everything, but it would introduce more cases where knowing the type on known valid calls is an advantage. I think it's worth it.
I hope we won't introduce something that is assignable to dynamic, but which won't have toString. That would make "$dynVar" undefined, which is not a good place to be.
Side note: The noSuchMethod issue also applies to our synthetic forwarders. They must remember to check the returned value against the expected return type, so:
abstract class I { int foo(); }
class C implements I { noSuchMethod(i) => "String!"; }

would introduce a forwarder on C like:
  int foo() => this.noSuchMethod(Invocation.method(#foo, const []));

which would throw at runtime if you call new C().foo() because "String!" is not assignable to int.

The function accepts any and all objects, so Object is the right annotation for it. dynamic should mean either "The type system can't express the set of objects I accept here" or "I really want dynamism". If the function correctly allows all objects, Object is the way to signal that intent.

Agree, but Dart's implicit-dynamic makes dynamic more convenient than Object. For example List is List<dynamic> rather than List<Object>, and a parameters declared as min(x, y) are (dynamic x, dynamic y) rather than (Object x, Object y). Dart 2 replaced many implicit dynamic things with inference, but there are some cases where implicit dynamic still kicks in.

To the larger issue, I worry that statically checking members on dynamic if they happen to exist on Object could paint us into a corner in the future. If we later add non-Object value types, what happens when they get boxed to dynamic? What if those value types don't support toString()?

Boxed value types can support all Object members. I feel like that's a fairly common design? I know C# works like that. And in Dart even null supports Object members.

Interestingly, the Dart 1 spec calls out that the type of a == b  is bool, regardless of anything else.  We could, I suppose make that choice here: just specify for a limited set of things (the object members) that any invocation of them has some specific type: any invocation that could potentially be a call to noSuchMethod then just gets a cast.

A couple of observations from looking at what would be involved in fixing code to make it statically typed again if we changed this:

There's no way to give the type of variables in a catch clause a type other than dynamic (that I can see).
Since instantiate to bounds uses dynamic (I know), you have to turn various uses of (e.g.) Map into Map<Object, Object>.

There's no way to give the type of variables in a catch clause a type other than dynamic (that I can see).

main() {
  T f<T>(T x) { print(T); return x; }
  try {
    throw 'hi!';
  } on Object catch (e, s) {
    // Prints Object, StackTrace
    e = f(e);
    s = f(s);
  }
  try {
    throw 'hello!';
  } catch (e, s) {
    // Prints dynamic, StackTrace
    e = f(e);
    s = f(s);
  }
}

The on SomeType catch(e) syntax was chosen because they didn't want "type annotations" to have any semantic effect in Dart 1, so the more traditional catch (SomeType e) was ruled out.

they didn't want "type annotations" to have any semantic effect in Dart 1, so the more traditional catch (SomeType e) was ruled out.

Which didn't even make sense at the time given that type annotations in functions are reified and have semantic effect even in unchecked mode if you do someFn is SomeFnType...

Oy.  Just when you think you've explored every dark corner... thanks!

Another code anthropology comment: the first example of code that I've found that actually mixed dynamic calls and Object methods was this:
https://github.com/dart-lang/csslib/blob/master/lib/src/validate.dart#L32
which goes out of its way to get out of dynamic on the toString call.

Lasse said:

Basically, if Object has a declaration, trust that it's a getter or method, then trust
the return type, but do allow invalid invocations

I like this approach!
I think I agree with the technical rules for the static analysis. I'm not quite sure what it means to 'treat this as (d.id)(args)' because trusting the return type means that d.id is not of type dynamic. But surely we can sort out the technical details.
The important properties of this approach (as far as I can see) are that (1) we do get the return type information (which is near-sound due to the enforcement of override rules) which will help inference and catch actual errors, and (2) with respect to the actual arguments, we do allow invocations that would not be allowed for a statically checked method call on a receiver of type Object.
We might strengthen the latter, e.g., by saying that an invocation of d.noSuchMethod() is an error because there is no valid overriding that accepts the empty list of actual arguments, but Leaf's example with noSuchMethod and toString shows that even that could be accepted at runtime (we have noSuchMethod forwarding, but dynamic invocations must still call noSuchMethod when there is no matching forwarding method). So every actual argument list shape is potentially accepted, and hence we might as well allow them all.
For the dynamic behavior, the use of noSuchMethod for dynamic invocations requires us to consider the returned result to be of type dynamic, so there may be some dynamic checks (even on String s = d.toString();), but I guess we can live with the discrepancy that static analysis promises a String and dynamic behavior may still fail at a dynamic type check.

Can this be moved out of the milestone, Siva?

Yes, the workaround CL has landed. I removed the milestone tag, not sure if another tag is needed.

Ok, it sounds like there is a proposal that:

If you have a property access of a getter or setter on Object:

then it has the static type of the property on Object

e.g. o.hashCode : int

This includes in the context of an invocation:

e.g. o.hashCode(3) is a static error

If you have a property access of a method on Object:

then it has the static type of the property on Object
e.g. o.toString : String Function()

If you have an invocation of a method on Object with the correct number of arguments:

then the invocation is checked using the static type of the method on Object

o.toString() has static type String
o.noSuchMethod(new Invocation()) has no errors, static type String
o.noSuchMethod(3) is a static error

If you have an invocation of a method on Object with the incorrect number of arguments:

then invocation is treated as a dynamic invocation, with no error checking

Is that the proposal?
I can live with it.  I predict that we will get bugs filed against us saying "I fat fingered o.toString(o) and got no errors, what gives?", but there are few enough things on Object that this should be sufficiently rare.

so there may be some dynamic checks (even on String s = d.toString();

This should not be the case, as I understand the proposal.  A valid call to toString cannot possibly go to noSuchMethod, and as such it can be trusted.

On Fri, Mar 9, 2018 at 12:41 AM, Leaf Petersen<EMAIL_ADDRESS>wrote:

Ok, it sounds like there is a proposal that:

If you have a property access of a getter or setter on Object:

... there are no setters, and their return type aren't relevant, but
otherwise, yes ...

then it has the static type of the property on Object

e.g. o.hashCode : int

This includes in the context of an invocation:

e.g. o.hashCode(3) is a static error

Yes, because it's interpreted as (o.hashCode)() .

If you have a property access of a method on Object:

then it has the static type of the property on Object
e.g. o.toString : String Function()

If you have an invocation of a method on Object with the correct
number of arguments:

then the invocation is checked using the static type of the
method on Object

o.toString() has static type String
o.noSuchMethod(new Invocation()) has no errors, static type
String

Static type "dynamic"

o.noSuchMethod(3) is a static error

Disagree on the third one. It's a potentially valid invocation on a
subclass of Object, so it's a valid dynamic invocation.
We do know the return type (it's dynamic for noSuchMethodError, so no big
advantage).

If you have an invocation of a method on Object with the
incorrect number of arguments:

then invocation is treated as a dynamic invocation, with no error
checking

Is that the proposal?

No, but close.
Any invocation is allowed on dynamic if it's potentially allowed by a
subclass of Object.
The invocation is always dynamic. In some cases we can know the static type
of the result, but the invocation is allowed even if we don't know that the
arguments have the correct type.
I don't remember if we disallow setters and methods with the same base name
now, we didn't use to. If we do, then we can statically disallow a setter
invocation if there is a method declaration, so no dynVar.toString = 42.
Also, we can currently disallow invocations with named parameters if the
function already has optional positional parameter, and vice versa, but
it's probably not worth it.

I can live with it. I predict that we will get bugs filed against us
saying "I fat fingered o.toString(o) and got no errors, what gives?", but
there are few enough things on Object that this should be sufficiently rare.

Don't fat-finger when you use "dynamic" as type - it is still a way to turn
type-checking off.
/L

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dart-lang/sdk/issues/32414#issuecomment-371663496,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEo9B1hb8eCFa2gjCK6cHjvrEHGlRavmks5tccGOgaJpZM4ScKQd
.

--
Lasse R.H. Nielsen -<EMAIL_ADDRESS>'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K

Denmark - CVR nr. 28 86 69 84

Any invocation is allowed on dynamic if it's potentially allowed by a
subclass of Object.

This essentially means "Any invocation is allowed on dynamic" full stop, right?.  There's no need to say anything about subclass of Object.
If too few arguments are passed, then you could have made some of the them optional.
If too many, NSM.
If the right number, then contra-variance means the types could be right.
I guess if any of the methods on Object took optional parameters, then you could disallow things with named parameters?
All of that mechanism seems way overkill just to catch that one error.
I'd say if we really want to allow all this, just keep it simple: all of the getter setter stuff stays the same, and for invocations:

If you have an invocation of a method on Object with the correct number of arguments:

then the invocation is given the return type of the method on Object

o.toString() has static type String

If you have an invocation of a method on Object with the incorrect number of arguments:

then invocation is treated as a dynamic invocation, with no error checking

It seems pretty pointless to me, but I don't really object that much given the paucity of things on object.

I don't remember if we disallow setters and methods with the same base name
now, we didn't use to.

We don't disallow it, should we?  It will likely make life difficult for us at some point in the future.

I don't remember if we disallow setters and methods with the same base name
now, we didn't use to.

We don't disallow it, should we? It will likely make life difficult for us at some point in the future.

FWIW, Analyzer strong mode disallows it:
class C {
  set m(x) => print('c.m=($x)');
  // [error] Class 'C' declares instance method 'm', but also has a setter with the same name from 'C'
  void m(x) => print('c.m($x)');
}

main() {
  var c = new C();
  c.m(1);
  c.m = 2;
}

DDC also relies on that restriction.

Hmm, interesting.  The override case doesn't induce an error though:
class A {
    void m(x) => print('c.m($x)');
}
class C extends A {
  set m(x) => print('c.m=($x)');
}

We should probably make these consistent.  I'd be inclined to disallow this.

Here's a proposal for how to specify the types of members of dynamic. It uses the approach which is rather forgiving: Invocations matching a statically known declaration are given the statically known return type, other invocations get return type dynamic (because they might go to noSuchMethod which can return anything); and argument types are never checked. Checks on argument types do not matter much for the members of Object, but it does make a difference in that d.noSuchMethod('Hello, world!') is OK.

I'm ok with the proposal.  Concretely to the issue at hand - I think we're in close enough agreement that if this is a blocking issue then bringing the CFE into agreement with the analyzer will move us to a point which is forward compatible with the final proposal.


Help in setting up clairctl

Hi,
i have faced difficulties in setting up with clairctl. i have followed the commands as stated:
$ git clone git@github.com:jgsqware/clairctl.git $GOPATH/src/github.com/jgsqware/clairctl
$ cd $GOPATH/src/github.com/jgsqware/clairctl
$ docker-compose up -d postgres
ERROR: Version in "./docker-compose.yml" is unsupported. You might be seeing this error because you're using the wrong Compose file version. Either specify a version of "2" (or "2.0") and place your service definitions under the services key, or omit the version key and place your service definitions at the root of the file to use version 1. For more on the Compose file format versions, see https://docs.docker.com/compose/compose-file/
Here is the docker-compose.yml :
version: '2.1'
services:
postgres:
image: postgres:9.6
restart: unless-stopped
volumes:
- ./docker-compose-data/postgres-data/:/var/lib/postgresql/data:rw
environment:
- POSTGRES_PASSWORD=ChangeMe
- POSTGRES_USER=clair
- POSTGRES_DB=clair
clair:
image: quay.io/coreos/clair:v2.0.0
restart: unless-stopped
volumes:
- ./docker-compose-data/clair-config/:/config/:ro
- ./docker-compose-data/clair-tmp/:/tmp/:rw
depends_on:
postgres:
condition: service_started
command: [--log-level=debug, --config, /config/config.yml]
clairctl:
image: jgsqware/clairctl:latest
restart: unless-stopped
environment:
- DOCKER_API_VERSION=1.24
volumes:
- ./docker-compose-data/clairctl-reports/:/reports/:rw
- /var/run/docker.sock:/var/run/docker.sock:ro
depends_on:
clair:
condition: service_started
changing the version number to '2.0' or '2' result in :
services.clairctl.depends_on contains an invalid type, it should be an array
services.clair.depends_on contains an invalid type, it should be an array
Can anyone advise me what is wrong and what should i do?  Thanks
Additional information:
$ docker version
Client:
Version:      1.12.4
API version:  1.24
Go version:   go1.6.4
Git commit:   1564f02
Built:        Tue Dec 13 00:08:34 2016
OS/Arch:      linux/amd64
Server:
Version:      1.12.4
API version:  1.24
Go version:   go1.6.4
Git commit:   1564f02
Built:        Tue Dec 13 00:08:34 2016
OS/Arch:      linux/amd64
$ go version
go version go1.8 linux/amd64

Hello, which version of docker-compose are you using ?

hi
this is the  docker-compose version i am using :
$ docker-compose -v
docker-compose version 1.8.0, build unknown

docker-compose 1.8.x is over a year old. Please update docker-compose.


Chef-15 fixes for node[:chef_guid]

The public API for this now has nothing to do with the DataCollector.

In Chef-15 the `node[:chef_guid]` is created for every single Chef-15
node, doesn't matter if the node is using the data collector or not.

The DataCollector then consumes that.

All the internals of the DataCollector have changed and reading the
guid out of the DataCollector is no longer a public UI of the DC.

The crazysauce with the multiple metadata files is also gone, along with the
data_collector_metadata.json file itself (which the prior PR #67 here
independently discovered).

Included backcompat here for Chef < 15.0 implementations which still
have the Chef::DataCollector::Messages class.

⚠ i have no idea how to test this ⚠

https://github.com/chef/chef/pull/8063

Yeah the chef_guid was first persisted in the data_collector_metadata.json then in https://github.com/chef/chef/pull/7016 the Chef::Config[:chef_guid_path] aka "/etc/chef/chef_guid" was introduced in such a way that "/etc/chef/chef_guid" became primary, while both would typically be created (in a confusing mess of spaghetti).  Chef-15 now fixes that so that only "/etc/chef/chef_guid" is used.  It looks like 7016 went into v14.0.152 so anyone upgrading from released 14.x to 15.x will be backwards compatible.  anyone upgrading from 13.x directly to 15.x, skipping 14.x will see the chef_guid change since the 15.x code no longer reads the old filename at all.
But that's all an issue with the chef/chef PR anyway....  In either way, just reading node[:chef_guid] is the stable API to use here for Chef >= 15.0.

anyone upgrading from 13.x directly to 15.x, skipping 14.x will see the chef_guid change since the 15.x code no longer reads the old filename at all.

That sounds problematic. I'll ask around to be sure

note that doesn't have any affect at all on this PR since we're no longer talking to filenames at all.  that is already merged changes to core chef that have that behavior.

(if you tried to fix that here you'd just wind up with this code disagreeing with the guid that chef-client itself was using -- and we were already seeing that in Chef 14.x which is why the prior PR was the one that removed parsing from the file directly)


forceUpdate is not defined

Reproduction demo
None at present.
Steps to reproduce the problem

Create virtual element to reference (not sure this matters)
On the inner popper component, which is passed the props from  <Popper />, try to access this.props.forceUpdate - it will be undefined

What is the expected behavior?
forceUpdate should exist as per PopperJS v2 docs.
What went wrong?
this.props.forceUpdate is undefined

Packages versions

Popper.js: 2.2.0
react-popper: 2.0.0

The docs still need some work to reflect the Popper 2 update ☹

@FezVrasta thanks for your reply! I'm a bit confused, React-Popper should expose forceUpdate(), right? v1.x passed both scheduleUpdate and update as props if I'm not mistaken.

Yes I’m confused too 😂 I’ll take a look tomorrow.

2.1.0 exposes forceUpdate

@FezVrasta thanks for the prompt attention! Unfortunately the issue persists for me with react-popper and @popperjs/core each at 2.2.0. Thoughts?

May you please provide a reproduction example on codesandbox or codepen please?

Hey @FezVrasta I won't have time to put together something more robust, but here's sort of our usage looks like:
export const PopperRoot = props => {
  return (
    <Popper
      {...props}>
      {({ ref, ...popperProps }) => (
        <InnerPopper innerRef={ref} {...props} {...popperProps} />
      )}
    </Popper>
  );
};

export class InnerPopper extends React.Component {
  componentDidMount() {
    const { forceUpdate, registerPopperFunctions } = this.props;
    //  Register functions for popper management in parent
    registerPopperFunctions({
      forceUpdatePopper: forceUpdate, //  forceUpdate will not be defined at this time
    });
  }
}

So instead we're now checking if forceUpdate is defined in componentDidUpdate and running our registerPopperFunctions at the point forceUpdate is available. It takes like 15 lines instead of 3 and has to run on every update, but it's still pretty lightweight and it works well enough.


Support for SVG in CSS files

Shall resolve the issue mentioned in https://github.com/boopathi/react-svg-loader/issues/149
There is one extra option added, which needs to be defined.

@boopathi Can you PLEASE merge this PR. This is the most annoying issue with this library by far. It needs fixing.


HWY-288: Avoid redundant requests caused by the Highway synchronizer. (dev port)

Once all Highway dependencies are resolved, the synchronizer forgets about a proposed block and gives it to HighwayProtocol for inclusion into the protocol state. However, nonempty blocks are not immediately added: They are kept in the pending_values map while the block validator is downloading the deploys and checking the block limits. During that period, the synchronizer will request the same block again, if any dependent unit is added.
This PR should fix both the redundant requests for the block itself as well as the redundant requests to the block validator.
https://casperlabs.atlassian.net/browse/HWY-288
Port of https://github.com/casper-network/casper-node/pull/1381.

bors merge


.tag("cat") method not found in SafebooruClient?

Idk if im retarded but i think .tag should be usable in safebooruclient right? My code for test things was this thing cuz i don't understand the docs
use booru::{safebooru::SafebooruClient, Client};

#[tokio::main]
async fn main() {
    let post = SafebooruClient::builder()
        .limit(1)
        .build()
        .tag("cat")
        .await
        .expect("Error en la respuesta de booru.");

    println!("{:?}", post);
}

i noticed my error .tag should be before build right? also i forgot .get


Proxy for existing users

I want this to be in main to have docker images pushed. Let's go with post-review cc @funbringer @patins


Gimbal - Design and Manufacture Mount for Camera

Design and manufacture mount for a rpi camera to bolt to gimbal that is capable of being counter waited to properly balance the gimbal with minimum weight.
rpi Camera Mechanical Specifications
The mount should allow for the placement of weights along the top and right side of the mount, these weights will be used to bring the gimbal into equilibrium so that external accelerations did not impose significant torque on motors.
The mount will likely be 3d printed.
The raspberry pi will not be mounted on the gimbal instead the flex cable will out the right side of the mount and reach to rpi mounted on mast. The raspberry pi will be hooked up to gimbal controller in the hope that pitch control can be established in the future.

Can you format the first comment using markdown to help separate the list of bullet point requirements so its easier to read. Right now its kinda a blob of text.

Is the idea that the RPI Zero camera would be the device that controls the mast gimbal?
I think the original idea for this was to have the Arm board control the mast positions as this should be rather simple.
Here are some attributes for this decision

Code in Arm is already prepared and ready for communication with mission control, so adding more commands is little effort
With the introduction of the RMD-X7 motors, only CANBUS and I2C, for the IMUs, are utilized, meaning we have a bunch of available pins for controlling pitch and roll.
Pitch and roll tend to be controlled using RC servo signals and do not require monitoring, meaning, we just set the PWM and leave it be.

Some of the CONS of the arm board approach

You would need to wire GND and PWM signals (single-ended signal) all the way from the Arm board up to Mast which is a bit far away, potentially up to 1 meter away.

A counter to this though is that the signal integrity should be fine at this distance. Personally, I've seen PWM signals go from a small lab of 10 meters and end up on the other side without much degradation.

Some of benefits of using the RPI Zero

Isolate mast control from Arm Controller
Makes more logical sense to have the mast camera control the mast

Some CONS for the RPI Zero

Would require the team to learn how to write software for the RPI Zero which utilizes a different language, and adds to the set control system design complexity. Where we originally had just 1 language, 1 API and two boards to control, now we have 2 languages, 2 APIs and 3 boards to control.

Counter to this is that  can be done with python and is overall pretty easy to learn and work with.


throwing ws error after upgrading ws version

i use upstream master, and getting error after this commit https://github.com/cyrus-and/chrome-remote-interface/commit/4b8dcee765f5ae6232a2f289c1a8264fdb5dfb28
Error: Unexpected server response: 404
    at ClientRequest.req.on (/demor/node_modules/chrome-remote-interface/node_modules/ws/lib/websocket.js:535:5)
    at ClientRequest.emit (events.js:182:13)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:546:21)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:109:17)
    at TLSSocket.socketOnData (_http_client.js:432:20)
    at TLSSocket.emit (events.js:182:13)
    at addChunk (_stream_readable.js:283:12)
    at readableAddChunk (_stream_readable.js:264:11)
    at TLSSocket.Readable.push (_stream_readable.js:219:10)
    at TLSWrap.onread (net.js:638:20)

Doing what exactly...?

during creating new tab, i think it throws for any samples

I cannot reproduce this. Please try to come up with a minimal standalone example that cases this issue.

for example,
const CDP = require('chrome-remote-interface');

async function navigateInANewTab(url) {
    const options = { host: 'host', port: 443, secure: true, useHostName: true, local: false };
    const tab = await CDP.New(options);
    const client = await CDP(Object.assign(options, {tab}));
    await CDP.Close(Object.assign(options, {id: tab.id}));
}

navigateInANewTab('https://github.com');

Is it reproducible even without secure and useHostName?

i can't reproduce it locally without these options

sent message to your email

Hi sorry for the late reply (and thanks for the email) so apparently this is either a bug in ws or your backend because even using wscat fails with 404:
wscat -c wss://YOURBACKEND/devtools/page/3103E3E5955B472A4FDC9DCEE7AC817A

But as you say, the fact is that old versions of ws work... let me try to debug it.

OK so the difference is in the port of the host header of the request:

Response HTTP/1.0 404 The page you're looking for doesn't exist., host header field in request:
  Host: YOURBACKEND:443

Response HTTP/1.1 101 WebSocket Protocol Handshake, host header field in request:
  Host: YOURBACKEND

Also note the HTTP version. I suspect this is a bug in your backend, double check you configuration and let me know.

As a heads up, most HTTP clients (curl, Chrome, Firefox, ruby, AsyncHttpClient for Scala, and recently request for Node) have started dropping the port suffix from the header. This is still RFC compliant.
This thread includes a few relevant links - https://github.com/request/request/issues/2894


remove a repo from the project

Hi,
I accidentally added a repo with hundreds of binary/verbose backup file commits in it, it all added very well and kudos to your project for handling it, but now a lot of my stats are.. bad.
Can I set an exclude */ glob and update project? Is update only for future commits since last update or does it check the history to make sure all lines up?
Is there a way I can remove the one repo without corrupting the other, like 50, repos I added to the same project? If not as a module parser then possibly is there a delete query I could run if I conn up to the sqlite db?
Thanks and sorry for the trouble, this project is great and I'm glad it exists.

Hi,
Currently update project processes only new commits, it doesn't redo existing commits even if the configuration has changed. Being able to reprocess the existing commits is a feature I'd like to have, so it'll eventually happen.
There is also no ready functionality for removing a repository from a project, but that also seems useful to have. I think you have two options to edit the database to remove a repository from a project:

Find the id of the repository you want to remove from the repositories table and delete, from the projectrepository table, the row with that repository id and your project name. This will detach the repository from the project, but all the data collected from that repository will still be in the database.
If you also want to delete the repository, not just remove it from the project, you will need to delete it from the repositories table as well. I'm not sure what will happen to the commits. I think the repository deletion should cascade to delete the commits as well, but to be sure, you might want to delete manually from the commits table the commits with the appropriate repository_id. And actually, you probably need to delete the rows referring to those commits from the authorcommit table too. So it's quite a bit of manual work if the deletion cascade doesn't work.

thank you!! this was super helpful for when i update this again if i need to make changes. I ended up moving the .sqlite db starting a new script and letting it run through all the repos again. Next time I might try modifying the database using this info. 😅


Update webpack version for examples

Background

Keep our examples fresh

Change List

Upgrade to webpack 4
Upgrade to react 16.3
Update package.json/webpack configs
Use html-webpack-plugin and remove index.html in a couple of non react-map-gl stylesheet dependent examples

@jianhuang01 Running yarn test examples I get a (minor) render test failure on ScatterplotLayer. Not sure if introduced by this PR.

@ibgreen not your issue, it is from mapbox base map, the text rendering changed a little bit.

@jianhuang01 Thanks for investigating. Any chance you could prepare a new golden image?
I would love a clean run of test-examples before landing this. test-example is really the perfect test for this type of PR.

@jianhuang01 I saw you already fixed it in your other PR!


FPS on cpu i5 is not high

Hi @RangiLyu, thank you for your work.
 But when I did benchmark onnx model on my computer Mac pro cpu core i5, the model got only 32 fps. I used code in demo_ncnn/python/demo_ncnn.py
I wondered it was not high and it will got higher if I convert onnx to mnn model, right?
Because your model had small enough size, so I thought that your model could get higher fps than 32.

To get better performance on Intel CPU, please use openvino.

@RangiLyu How many fps you could get when running MNN on arm chipset of NanoDet-m model?

Hi @RangiLyu, I ran MNN model on my arm device having 6 threads and got only 9 fps instead of 97 in your README.md. I used your demo_mnn code to compute fps. Had I was wrong in which step?

兄弟,请将语言由python改为c++,在测试推理速度

@superbayes Thanks for your suggestion.
Which device did you test speed using cpp script? And how many fps did you get? Thank you.

@superbayes Thanks for your suggestion. Which device did you test speed using cpp script on? And how many fps did you get? Thank you.

97fps is benchmarked on Arm A76 4 threads with ncnn fp16 inference.


Add Cause : when entity trample farmland

Hi,
Can you create a new cause when player trampled farmland for event "ChangeBlockEvent.Place" and "ChangeBlockEvent.Break".

You can listen to ChangeBlockEvent.Post to get the trampled farmland destruction and cancel it that way. Since it's still a player, you can use some simple logic to figure out whether it's "trampling" of land etc.
To be more precise to the issue itself, causes are an implementation thing, not an API thing (as to what goes in the cause is from the implementation).


disable Item JSON template

https://github.com/antleaf/nims-mdr-development/issues/326

@Steven-Eardley Thank you!


Fix the sizing of text across all PDFs

I think the best way to do this is to leave auto-sizing on for the text, but limit the height to the height of each text box to equivalent height of 12 pt text

Not necessarily urgent but will be important to improve the visual quality of the output.

Font size in AIW was addressed in earlier branch but I don't see it. Was it merged already @nonprofittechy ? If so, this can be closed.

Yes, merged!


"Chunk mismatch" whenever I attempt to upload a document (in .pdf or .txt format)

I'm getting the error "Chunk mismatch" whenever I attempt to upload a document (in .pdf or .txt format)
For example:
Chunk mismatch for a8693929-fb7e-4d74-9f23-c659e58b9d74 0 != 516
The numbers following the != have been both 2 digit and 3 digit numbers.
Verba is running locally via Docker.

Screenshot:

Fixed this. My OpenAI API key was incorrect. Fixed that and it fixed the problem! Sorry to bother you,


[proposal] New method to generate JWT payload

Is your feature request related to a problem? Please describe.
Veramo is a framework with different plugins. When creating a verifiable credential or verifiable presentation, Veramo generate signing input and finds private key to sign it. This creates two problems:

There is only a single place to retrieve key. (Veramo agent set up).
If there are several private key store, they need to be defined in veramo agent set up.

Describe the solution you'd like
When creating JWS, signer options can be omitted. If omitted, result returns only signing input. External system can use their key to sign it themselves.
OR we can have a seperate function to only generate signing input.

Thank you for reporting this.
The problem with choosing a key has been addressed in #899.
There is now a keyRef parameter that can be used to pick one of the keys associated with the DID.
The initial goal was to allow you to simplify your workflow as long as the veramo agent is properly aware of the key stores that you use. You only have to know the DID that you want as the issuer, and Veramo takes care of finding a key to sign.
For this purpose, @veramo/credential-w3c has been designed to pick the first matching signing key associated with a DID when creating a credential. One of the fixes from #899 allows you to have finer control of the key that will be used.

The other proposal, to generate only the signing input, is a fair request. I'd like to gather some opinions from the community to figure out if this deserves to be a core plugin.
Until that time, you are free to create a plugin that does what you propose and show it off in the discussions page or on our discord.
We also have a github template project that you can use to get you started creating your own plugin.

I'm closing this since there is already a solution, but feel free to reopen and provide more details if you think I misunderstood.


Since ustc crates source is not stable, we use the official source as default

Ref #389, #390.

I want to update the document, but it's blocked by previous PR (that PR haven't update document, yet):

USTC Mirror Help for Rust Crates
Source Replacement for Rust Crates
How to map a configuration file into docker

but it's blocked by previous PR

I will fix it.


Quoted Identifier error: hover failed with message: InvariantError: should never be reached

Description
Hovering over function signatures has an error when the identifier is not correct.
Expected Behavior

Actual Behavior
It doesn't silently log like other errors. You get a popup:

[Trace - 5:12:28 PM] Received response 'textDocument/hover - (40)' in 0ms. Request failed: Request textDocument/hover failed with message: InvariantError: should never be reached (-32603).
[Error - 5:12:28 PM] Request textDocument/hover failed.
  Message: Request textDocument/hover failed with message: InvariantError: should never be reached
  Code: -32603

Steps to reproduce
Create a new file, then hover over the Numbers function.
let
   #"Stuff" = List.Numbers(1, 1, 1)
in
    #"Stuff

Fix
Close the quote on the final identifier.
let
   #"Stuff" = List.Numbers(1, 1, 1)
in
    #"Stuff"

error log - short.log

This seems to be fixed with #68


allow 'conditional' import at first?

I personally groups my imports in usual order; npm module, components, local modules, and other.
import { ... } from 'electron'
import { ... } from 'vuex'

import ... from<EMAIL_ADDRESS>import ... from<EMAIL_ADDRESS>
import ... from<EMAIL_ADDRESS>import { productName, version } from<EMAIL_ADDRESS>
so, the problem was, I need to modify this component for both of electron and web. null-loader not work here.
const { ipcRenderer } = process.env.IS_WEB? {} : require('electron')

import/first throws me away since electron import was ordered at first line, but I want to keep my 'grouping' rules without turning it off.
May import/first can provide support for this? or, what can I do with configuration?

I’m not sure about electron norms but usually one uses the browser field in package.json to control what loads on the web, rather than a conditional require.

Also, regardless, imports are always hoisted - so they’ll happen before all your code runs no matter what order you put them in.

hoisting isn't really problem since all imports already on (nearly) top, just for consistent of orders.

I don't think it makes sense for the "import order" rule to have an exception for a non-import.

Sorry, this is just what first is for: ensuring nothing else comes..first. 😁


Fix retrieveMultipleUsersWithUserNames()

Fix a bug in retrieveMultipleUsersWithUserNames().
BTW, using strings.Join() is more simple and fast.  I also update for this.

Sorry to response. Ah, This PR is failed of CI, but your commit is so good. I'll add more test case to improve code coverage and to be more safety. After that, I'll merge this PR, so please wait 😄

This PR fixed critical section, so I merge it.


Always on functionality?

# __init__.py

def main(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('Python HTTP trigger function processed a request.')

    return "Done"

azure-functions==1.0.0a4
azure-functions-worker==1.0.0a4
grpcio==1.14.2
grpcio-tools==1.14.2
protobuf==3.6.1
six==1.11.0

-->

@ahmelsayed Specifically it was/is a EastUSLinuxDynamicPlan which I think is the default if you follow the guides. I was able to get this working redeploying to a new Linux App Serivce plan in the (PremiumV2: 1 Small) tier. I had to completely redeploy the function to make that switch however, as I could not find a good way to trigger a switch from the portal or cli. Probably working as intended but overall the whole app service plan method was pretty confusing and the documentation that I was seeing had a lot of conflicting info. Thanks for looking into this!

Yes, as you pointed out Always On is only available for dedicated app service plans, not consumption a.k.a: dynamic. You also can't move a Linux app between dedicated and consumption since the underlying resources are very different. I'm actually not sure if you can do that for the Windows apps, I'll have to check.
Recreating the application as dedicated like you did is the right way to go, and you should be able to see Always On in the settings (in fact I think it should be enabled by default as well)


feat: Chainlink oracle

TODO:

[x] - Adds chainlink oracle
[ ] - fix fuzz tests

Sorry @r0ohafza, but we already have a chainlink oracle. Feel free to revive this branch if you think it is worth it.


feat: persist extension

Hey. I tried to implement persist layer https://github.com/mswjs/data/issues/49 . This PR is based on  https://github.com/mswjs/data/pull/87
You can see example of usage in my pet project: https://github.com/noveogroup-amorgunov/nukeapp/blob/90a0f75f57f877d4889033456f3628c5d1e34699/src/shared/lib/server/serverDb.ts#L49-L51 (PR: https://github.com/noveogroup-amorgunov/nukeapp/pull/14)
If this approach is OK, I am going to write tests.

Hey @noveogroup-amorgunov I'm looking to implement persistence for mock data on my server-side usage of msw.  Can you see a way to make the persistence layer abstract?   I.e., we could use use a Redis client or session storage.

@kettanaito would you please take a look on this?

Is it possible to merge it?

According to this https://github.com/mswjs/data/issues/285 no new features will be merged. I have modified @noveogroup-amorgunov 's code to be used outside of mswjs-data internal code.
import debounce from 'lodash/debounce';
import {
  DATABASE_INSTANCE,
  ENTITY_TYPE,
  PRIMARY_KEY,
  type FactoryAPI,
  type Entity,
  type ModelDictionary,
  type PrimaryKeyType,
} from '@mswjs/data/lib/glossary';
import {
  type SerializedEntity,
  SERIALIZED_INTERNAL_PROPERTIES_KEY,
} from '@mswjs/data/lib/db/Database';
import { inheritInternalProperties } from '@mswjs/data/lib/utils/inheritInternalProperties';

const STORAGE_KEY_PREFIX = 'mswjs-data';

// Timout to persist state with some delay
const DEBOUNCE_PERSIST_TIME_MS = 10;

type Models<Dictionary extends ModelDictionary> = Record<
  keyof Dictionary,
  Map<PrimaryKeyType, Entity<Dictionary, any>> // eslint-disable-line @typescript-eslint/no-explicit-any
>;

type SerializedModels<Dictionary extends ModelDictionary> = Record<
  keyof Dictionary,
  Map<PrimaryKeyType, SerializedEntity>
>;

// eslint-disable-next-line @typescript-eslint/no-explicit-any
export default function persist<Dictionary extends ModelDictionary>(
  factory: FactoryAPI<Dictionary>,
) {
  if (typeof window === 'undefined' || typeof sessionStorage === 'undefined') {
    return;
  }

  const db = factory[DATABASE_INSTANCE];

  const key = `${STORAGE_KEY_PREFIX}/${db.id}`;

  const persistState = debounce(function persistState() {
    // eslint-disable-next-line @typescript-eslint/dot-notation, @typescript-eslint/consistent-type-assertions
    const models = db['models'] as Models<Dictionary>;
    // eslint-disable-next-line @typescript-eslint/dot-notation, @typescript-eslint/consistent-type-assertions
    const serializeEntity = db['serializeEntity'] as (
      entity: Entity<Dictionary, any>, // eslint-disable-line @typescript-eslint/no-explicit-any
    ) => SerializedEntity;

    const json = Object.fromEntries(
      Object.entries(models).map(([modelName, entities]) => [
        modelName,
        Array.from(entities, ([, entity]) => serializeEntity(entity)),
      ]),
    );

    sessionStorage.setItem(key, JSON.stringify(json));
  }, DEBOUNCE_PERSIST_TIME_MS);

  function hydrateState() {
    const initialState = sessionStorage.getItem(key);

    if (initialState) {
      // eslint-disable-next-line @typescript-eslint/consistent-type-assertions
      const data = JSON.parse(initialState) as SerializedModels<Dictionary>;

      for (const [modelName, entities] of Object.entries(data)) {
        for (const entity of entities.values()) {
          db.create(modelName, deserializeEntity(entity));
        }
      }
    }

    // Add event listeners only after hydration
    db.events.on('create', persistState);
    db.events.on('update', persistState);
    db.events.on('delete', persistState);
  }

  if (document.readyState === 'loading') {
    document.addEventListener('DOMContentLoaded', hydrateState);
  } else {
    hydrateState();
  }
}

function deserializeEntity(entity: SerializedEntity) {
  const { [SERIALIZED_INTERNAL_PROPERTIES_KEY]: internalProperties, ...publicProperties } = entity;

  inheritInternalProperties(publicProperties, {
    [ENTITY_TYPE]: internalProperties.entityType,
    [PRIMARY_KEY]: internalProperties.primaryKey,
  });

  // eslint-disable-next-line @typescript-eslint/consistent-type-assertions, @typescript-eslint/no-explicit-any
  return publicProperties as Entity<any, any>;
}

Usage:
import { factory, primaryKey } from '@mswjs/data';
const db = factory({ ... });
persist(db);

You can see it being used in this project https://github.com/Kamahl19/react-starter/blob/main/src/mocks/persist.ts . I will keep the most up-to-date version there.

@Kamahl19 thanks so much for this! I'm using @msw/data to help our sales team run more effective product demos, and your persist has unlocked a lot of helpful functionality.
One thing I've found: collocating updates when a model has a manyOf relationship is broken after the page reloads and the database is rehydrated. E.g. my user model had expenses: manyOf('expense'), and creating a new expense while updating a user's expenses would start throwing an "invariant" error only after reloading the page. I've worked around this by storing less on the user and adding user id to the various other models. It works just as well, but thought I'd call this out here in case anyone else runs into the same issue.


Make it build with ghc-9.10

Also update the version of tar being used.

@newhoggy Now do I add ghc-9.10 to tbe CI build matrix? Would also love to see a new release to Hackage.