1.23.0-dev.11.0: Lot's of "The type of 'X' can't be inferred because type arguments were not given for 'Y'"

https://travis-ci.org/dart-lang/angular2/jobs/217641293#L272

dartanalyzer . | grep error | sort | uniq
    error • The type of 'AppView' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:83:30 • strong_mode_top_level_type_arguments
    error • The type of 'ChangeDetectionStrategy' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:132:46 • strong_mode_top_level_type_arguments
    error • The type of 'ChangeDetectorRef' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:97:40 • strong_mode_top_level_type_arguments
    error • The type of 'ChangeDetectorState' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:148:42 • strong_mode_top_level_type_arguments
    error • The type of 'ComponentFactory' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:102:39 • strong_mode_top_level_type_arguments
    error • The type of 'ComponentRef' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:108:35 • strong_mode_top_level_type_arguments
    error • The type of 'DebugAppView' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:85:35 • strong_mode_top_level_type_arguments
    error • The type of 'DebugContext' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:139:35 • strong_mode_top_level_type_arguments
    error • The type of 'EMPTY_ARRAY' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:189:34 • strong_mode_top_level_type_arguments
    error • The type of 'EMPTY_MAP' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:193:32 • strong_mode_top_level_type_arguments
    error • The type of 'ElementRef' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:90:33 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_ANCHOR_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:260:42 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_AREA_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:264:40 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_AUDIO_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:266:41 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_BUTTON_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:268:42 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_CANVAS_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:270:42 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_COMMENT_NODE' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:247:11 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_DIV_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:263:11 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_DOCUMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:251:11 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:253:11 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_EVENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:301:11 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_FORM_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:272:40 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_HTML_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:254:40 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_IFRAME_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:274:42 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_IMAGE_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:276:41 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_INPUT_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:278:41 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_MEDIA_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:282:41 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_MENU_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:284:40 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_NODE' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:303:11 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_OLIST_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:288:41 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_OPTION_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:286:42 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_SELECT_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:290:42 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_SHADOW_ROOT_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:257:11 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_TABLE_COL_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:296:45 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_TABLE_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:292:41 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_TABLE_ROW_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:294:45 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_TEXTAREA_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:280:44 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_TEXT_NODE' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:249:11 • strong_mode_top_level_type_arguments
    error • The type of 'HTML_ULIST_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:298:41 • strong_mode_top_level_type_arguments
    error • The type of 'Injector' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:120:31 • strong_mode_top_level_type_arguments
    error • The type of 'KEYWORDS' can't be inferred because type arguments were not given for 'Set' at lib/src/compiler/expression_parser/lexer.dart:477:20 • strong_mode_top_level_type_arguments
    error • The type of 'NG_FOR_DIRECTIVE' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:200:11 • strong_mode_top_level_type_arguments
    error • The type of 'NG_IF_DIRECTIVE' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:198:11 • strong_mode_top_level_type_arguments
    error • The type of 'OPERATORS' can't be inferred because type arguments were not given for 'Set' at lib/src/compiler/expression_parser/lexer.dart:451:21 • strong_mode_top_level_type_arguments
    error • The type of 'QueryList' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:110:32 • strong_mode_top_level_type_arguments
    error • The type of 'RenderComponentType' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:104:42 • strong_mode_top_level_type_arguments
    error • The type of 'SVG_ELEMENT' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:259:11 • strong_mode_top_level_type_arguments
    error • The type of 'SimpleChange' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:146:35 • strong_mode_top_level_type_arguments
    error • The type of 'StaticNodeDebugInfo' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:136:42 • strong_mode_top_level_type_arguments
    error • The type of 'TEXT_CSS_SELECTOR' can't be inferred because IndexExpressionImpl expressions aren't supported at lib/src/compiler/template_parser.dart:71:27 • strong_mode_top_level_unsupported
    error • The type of 'TemplateRef' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:113:34 • strong_mode_top_level_type_arguments
    error • The type of 'TemplateSecurityContext' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:142:46 • strong_mode_top_level_type_arguments
    error • The type of 'ValueUnwrapper' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:116:37 • strong_mode_top_level_type_arguments
    error • The type of 'ViewContainer' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:87:36 • strong_mode_top_level_type_arguments
    error • The type of 'ViewContainerRef' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:94:39 • strong_mode_top_level_type_arguments
    error • The type of 'ViewEncapsulation' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:124:40 • strong_mode_top_level_type_arguments
    error • The type of 'ViewType' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:128:31 • strong_mode_top_level_type_arguments
    error • The type of '_completer' can't be inferred because type arguments were not given for 'Completer' at lib/src/testing/internal_injector.dart:95:26 • strong_mode_top_level_type_arguments
    error • The type of '_resolveToFalse' can't be inferred because type arguments were not given for 'Future' at lib/src/router/router.dart:16:27 • strong_mode_top_level_type_arguments
    error • The type of '_resolveToNull' can't be inferred because type arguments were not given for 'Future' at lib/src/router/route_registry.dart:25:26 • strong_mode_top_level_type_arguments
    error • The type of '_resolveToTrue' can't be inferred because type arguments were not given for 'Future' at lib/src/router/directives/router_outlet.dart:24:26 • strong_mode_top_level_type_arguments
    error • The type of '_resolveToTrue' can't be inferred because type arguments were not given for 'Future' at lib/src/router/router.dart:15:26 • strong_mode_top_level_type_arguments
    error • The type of '_viewEncapsulationMap' can't be inferred because type arguments were not given for 'Map' at lib/src/transform/common/type_metadata_reader.dart:946:11 • strong_mode_top_level_type_arguments
    error • The type of 'appViewUtils' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:79:35 • strong_mode_top_level_type_arguments
    error • The type of 'baseExceptionIdentifier' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at test/compiler/output/output_emitter_util.dart:37:35 • strong_mode_top_level_type_arguments
    error • The type of 'castByValue' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:185:34 • strong_mode_top_level_type_arguments
    error • The type of 'checkBinding' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:152:35 • strong_mode_top_level_type_arguments
    error • The type of 'controlChange' can't be inferred because type arguments were not given for 'EventEmitter' at test/core/linker/integration_test.dart:2188:27 • strong_mode_top_level_type_arguments
    error • The type of 'customEvent' can't be inferred because type arguments were not given for 'EventEmitter' at test/core/linker/integration_test.dart:2102:25 • strong_mode_top_level_type_arguments
    error • The type of 'devModeEqual' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:156:35 • strong_mode_top_level_type_arguments
    error • The type of 'enumIdentifier' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at test/compiler/output/output_emitter_util.dart:32:26 • strong_mode_top_level_type_arguments
    error • The type of 'event' can't be inferred because type arguments were not given for 'EventEmitter' at test/core/linker/integration_test.dart:2394:19 • strong_mode_top_level_type_arguments
    error • The type of 'eventEmitterIdentifier' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at test/compiler/output/output_emitter_util.dart:28:34 • strong_mode_top_level_type_arguments
    error • The type of 'externalModuleIdentifier' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at test/compiler/output/dart_emitter_test.dart:14:36 • strong_mode_top_level_type_arguments
    error • The type of 'interpolate' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:181:34 • strong_mode_top_level_type_arguments
    error • The type of 'interpolate0' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:169:35 • strong_mode_top_level_type_arguments
    error • The type of 'interpolate1' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:173:35 • strong_mode_top_level_type_arguments
    error • The type of 'interpolate2' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:177:35 • strong_mode_top_level_type_arguments
    error • The type of 'looseIdentical' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:158:37 • strong_mode_top_level_type_arguments
    error • The type of 'ngAnchor' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:81:31 • strong_mode_top_level_type_arguments
    error • The type of 'pureProxies' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:203:9 • strong_mode_top_level_type_arguments
    error • The type of 'pureProxies' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:207:9 • strong_mode_top_level_type_arguments
    error • The type of 'pureProxies' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:211:9 • strong_mode_top_level_type_arguments
    error • The type of 'pureProxies' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:215:9 • strong_mode_top_level_type_arguments
    error • The type of 'pureProxies' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:219:9 • strong_mode_top_level_type_arguments
    error • The type of 'pureProxies' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:223:9 • strong_mode_top_level_type_arguments
    error • The type of 'pureProxies' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:227:9 • strong_mode_top_level_type_arguments
    error • The type of 'pureProxies' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:231:9 • strong_mode_top_level_type_arguments
    error • The type of 'pureProxies' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:235:9 • strong_mode_top_level_type_arguments
    error • The type of 'pureProxies' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:239:9 • strong_mode_top_level_type_arguments
    error • The type of 'sameModuleIdentifier' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at test/compiler/output/dart_emitter_test.dart:12:32 • strong_mode_top_level_type_arguments
    error • The type of 'testDataIdentifier' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at test/compiler/output/output_emitter_util.dart:23:30 • strong_mode_top_level_type_arguments
    error • The type of 'throwOnChanges' can't be inferred because type arguments were not given for 'CompileIdentifierMetadata' at lib/src/compiler/identifiers.dart:165:37 • strong_mode_top_level_type_arguments
    error • The type of 'update' can't be inferred because type arguments were not given for 'EventEmitter' at lib/src/common/forms/directives/ng_control_name.dart:96:20 • strong_mode_top_level_type_arguments
    error • The type of 'update' can't be inferred because type arguments were not given for 'EventEmitter' at lib/src/common/forms/directives/ng_form_control.dart:78:20 • strong_mode_top_level_type_arguments
    error • The type of 'update' can't be inferred because type arguments were not given for 'EventEmitter' at lib/src/common/forms/directives/ng_model.dart:71:20 • strong_mode_top_level_type_arguments

Here's another example - https://github.com/dart-lang/test/pull/580/files

Seems to be fixed – or at least downgraded to a hint w/ 1.23.0-dev.11.1
Will wait for a release before closing...

@kevmoo So if we don't ship until the milestone 1.23 issues are closed, and we don't close this issue until 1.23 ships... :-)

Waiting to verify the dev release 😄

FYI, these hints are producing a lot of noise for my projects, and they haven't helped me find any new bugs. Asynchronous classes like Completer et al often have generic types that are omitted in cases where they're just used to signal an event rather than to pass a value. Requiring the user to explicitly annotate all such cases to be hint-clean adds a lot of boilerplate without a lot of corresponding value.

We discussed this in Denmark w/ @leafpetersen and @stereotype441 – we're getting this fixed, right guys?

Depends whether you're asking about the new front end or the old one.  For the new front end, yes--this is already fixed.  For the old front end (analyzer-based type inference), I'm not aware of any plans to fix it.

I'm not aware of any plans to fix it.

Meaning we'll continue to see the sea of these hints until we move off?

Correct, unless we change plans :)
(That's what I thought we agreed to when we talked about this while you and Leaf were in Denmark, but maybe I misunderstood.  Unfortunately, due to the way top level type inference is implemented in analyzer, getting parity between top level and local type inference in analyzer would be way more work than it was in the front end.  We might be able to address specific corner cases like this one, though.  If you think we need to do that, we should talk)

I'm okay with waiting for the unified frontend to get correct analysis here, but can we turn off these hints in the meantime?

You can always add a xyz_error: ignore section your analysis_options.yaml file

Not in this case. But even if you could, we know these hints are bogus—why force our users to endure or opt out of them?

@stereotype441 I guess that's the question – could we just eliminate this class of hints entirely in the "legacy" frontend?

I would have no objection but it's probably more of a question for @leafpetersen.

There's no reason to have these hints in there any more - sorry, with all of the travel I was under the vague impression that someone had already turned them off.  I'll work up a CL eliminating them if nobody beats me to it.


chore(packages): add @summary and @deperecated tags to hook functions

Status
READY
Description
In SWR and React-Query, JSDoc @summary and @deprecated tags given to Operation are also set to hook functions.
issued:

https://github.com/anymaniax/orval/issues/609

Examples
schema (added summary and deprecated tags):
paths:
  /pets:
    get:
      summary: List all pets
      operationId: listPets
      deprecated: true

    post:
      summary: Create a pet
      operationId: createPets
      deprecated: true

output:
// samples/react-query/basic/src/api/endpoints/petstoreFromFileSpecWithTransformer.ts

/**
 * @deprecated
 * @summary List all pets
 */
export const listPets = (
    params?: ListPetsParams,
    version= 1,
 signal?: AbortSignal
) => {
      return customInstance<Pets>(
      {url: `/v${version}/pets`, method: 'get',
        params, signal
    },
      );
    }

/**
 * @deprecated
 * @summary Create a pet
 */
export const createPets = (
    createPetsBody: CreatePetsBody,
    version= 1,
 ) => {
      return customInstance<Pet>(
      {url: `/v${version}/pets`, method: 'post',
      headers: {'Content-Type': 'application/json', },
      data: createPetsBody
    },
      );
    }

// samples/react-query/hook-mutator/endpoints.ts

/**
 * @deprecated
 * @summary Create a pet
 */
export const useCreatePetsHook = () => {
        const createPets = useCustomInstance<Pet>();

        return (
    createPetsBody: CreatePetsBody,
 ) => {
        return createPets(
          {url: `/pets`, method: 'post',
      headers: {'Content-Type': 'application/json', },
      data: createPetsBody
    },
          );
        }
      }

// samples/react-app-with-swr/src/api/endpoints/petstoreFromFileSpecWithTransformer.ts

/**
 * @deprecated
 * @summary List all pets
 */
export const listPets = (
    params?: ListPetsParams,
    version= 1,
 ) => {
      return customInstance<Pets>(
      {url: `/v${version}/pets`, method: 'get',
        params
    },
      );
    }

@anymaniax
Could you please review it?
Thank you for the awesome library.

Hello @d-mato, can you add it also to the useMutation?

@d-mato I tested locally to add the deprecate flag to a post and the custom hook useMutation doesn't have the comment propagated. I think you also need to add it at the line 1146 no?


Issue on indexDbBlazor.ts when adding new record with dbManager

Hello, first of all I want to thank for this excellent library, I have```
a problem when trying to add a record using these lines:
await dbManager.AddRecord (myNewRecord);

Can some one help me with the fix of this issue?.
Thanks in advance.

Have added a check to determine if the err parameter is defined or not.

Not sure, but this seems the same issue

Or do I need to create a new issue report for it ?
This issue is still open after a year ?
Does this mean I can ignore this error ?

Not sure, but this seems the same issue

Or do I need to create a new issue report for it ?
This issue is still open after a year ?
Does this mean I can ignore this error ?


multiple directives not working

i'm trying to use one directive for uploading images and another for uploading videos to my s3 bucket.
when i have both of them defined, whichever one is last overrides the others.
eg. with the current setup, if i try to upload an image, i get an error telling me it's not an allowed type and the video mimetypes are listed in the error.
it may just be the fileRestrictions but i can't figure out what i'm doing wrong:
in /lib/upload-config.js:
// image upload file restrictions setup
Slingshot.fileRestrictions('image-uploads',{
  allowedFileTypes: ['image/png', 'image/jpeg', 'image/gif'],
  maxSize: null // unlimited!  maybe we'll change this later...
})

// video upload file restrictions setup
Slingshot.fileRestrictions('video-uploads',{
  allowedFileTypes: ['video/mp4', 'video/mpeg', 'video/quicktime', 'video/x-ms-wmv'],
  maxSize: null // unlimited!  maybe we'll change this later...
})

in /server/lib/upload-config.js
// image upload directive
var settings = Meteor.settings.aws.s3,
  s3_upload_settings = {
    maxSize: null, // unlimited for now!
    bucket: settings.bucket,
    region: settings.region,
    AWSAccessKeyId: settings.client.id,
    AWSSecretAccessKey: settings.client.secret,
    acl: "public-read",
    authorize: function(){
      //Deny uploads if user is not logged in.
      if( !this.userId ){
        var message = "Please login before posting files"
        throw new Meteor.Error("Login Required", message)
      }
      return true
    },
    key: function( file ){
      //Store file into a directory by the user's username.
      var user = Meteor.users.findOne(this.userId)
      return user._id + '/' + file.name
    }
  }

Slingshot.createDirective('image-uploads', Slingshot.S3Storage, _.extend(s3_upload_settings, {
  allowedFileTypes: ['image/png', 'image/jpeg', 'image/gif'],
  key: function( file ){
    var user = Meteor.users.findOne(this.userId)
    return user._id+'/images/'+file.name
  }
}))

Slingshot.createDirective('video-uploads', Slingshot.S3Storage, _.extend(s3_upload_settings, {
  allowedFileTypes: ['video/mp4', 'video/mpeg', 'video/quicktime', 'video/x-ms-wmv'],
  key: function( file ){
    var user = Meteor.users.findOne(this.userId)
    return user._id+'/videos/'+file.name
  }
}))

in my react component:
  _upload(e){
    var file = e.target.files[0],
      directive = (e.target.id == 'imageUpload') ? 'image-uploads' : 'video-uploads',
      uploader = new Slingshot.Upload(directive),
      self = this

    uploader.send(file, function(err, downloadUrl){
      if( err ){
        if( uploader.xhr ){
          console.error(uploader.xhr.response)
        }
        console.error(err)
      } else {
        console.log('success!')
        console.log('download url: '+downloadUrl)
      }
    })
  }

This is because you are using _.extend() which will merge the second and subsequent arguments into the first.
i.e.
var myObj = {a: "a", "b"};
var mergedObj = _.extend(myObj, {c: "c"});
mergedObj === myObj; // True
myObj.c === "c"; // True

You avoid changing your source object you could use this:
var myObj = {a: "a", "b"};
var mergedObj = _.defaults({c: "c"}, myObj);
mergedObj === myObj; //False
myObj.c === "c"; //False
mergedObj.c === "c"; //True

But if you want to apply cloud specific defaults you can use this:
_.extend(Singlinshot.S3Storage.directiveDefault, {
    bucket: settings.bucket,
    region: settings.region,
    AWSAccessKeyId: settings.client.id,
    AWSSecretAccessKey: settings.client.secret,
    acl: "public-read"
    //ETC
});

argh.  silly mistake.  THANK YOU!
for anyone else finding this thread, here's what i did (works like a charm):
// image upload directive
var settings = Meteor.settings.aws.s3,
  s3_upload_settings = {
    maxSize: null, // unlimited for now!
    bucket: settings.bucket,
    region: settings.region,
    AWSAccessKeyId: settings.client.id,
    AWSSecretAccessKey: settings.client.secret,
    acl: "public-read",
    authorize: function(){
      //Deny uploads if user is not logged in.
      if( !this.userId ){
        var message = "Please login before posting files"
        throw new Meteor.Error("Login Required", message)
      }
      return true
    },
    key: function( file ){
      //Store file into a directory by the user's username.
      var user = Meteor.users.findOne(this.userId)
      return user._id + '/' + file.name
    }
  },
  image_upload_settings = {
    allowedFileTypes: ['image/png', 'image/jpeg', 'image/gif'],
    key: function( file ){
      var user = Meteor.users.findOne(this.userId)
      return user._id+'/images/'+file.name
    }
  },
  video_upload_settings = {
    allowedFileTypes: ['video/mp4', 'video/mpeg', 'video/quicktime', 'video/x-ms-wmv'],
    key: function( file ){
      var user = Meteor.users.findOne(this.userId)
      return user._id+'/videos/'+file.name
    }
  }

// add the default settings to each settings object
_.defaults(image_upload_settings, s3_upload_settings)
_.defaults(video_upload_settings, s3_upload_settings)

Slingshot.createDirective('image-uploads', Slingshot.S3Storage, image_upload_settings)
Slingshot.createDirective('video-uploads', Slingshot.S3Storage, video_upload_settings)


Add support for ImageTexture3D serialization

Fixes #80866
In the issue comment, @clayjohn posted a partially working diff to support ImageTexture3D serilization. I took it and modifed the code to make it work correctly (at least in the MRP provided).
But as I mentioned in the issue comment, the code still triger two errors in editor console because of some resource init code will read the texture array's info before it actually deserilize it —— ResourceLoaderText::load will call Variant get_value = resource->get(assign, &is_get_valid) which will eventually call texture3d's _get_images and get_data, but the texture3d is not inited with its data yet ; and after it, the _set_image will be called at resource->set(assign, value) so it will be inited correctly.
So consider this a draft as I'm trying to deal with the above editor errors. But if anyone needs this function, feel free to take it and help test this code. I would appreciate any feedback or alternative suggestions.

Those errors might come when the binary or text resource loader tries to get the property default value (ClassDB::class_get_default_property_value()). Adding a simple test to _get_images() might be enough as we are lazily allocating texture RID's and returning an empty array is fine. So it would become like this:
TypedArray<Image> ImageTexture3D::_get_images() const {
	TypedArray<Image> images;
	if (texture.is_valid()) {
		Vector<Ref<Image>> raw_images = get_data();
		ERR_FAIL_COND_V(raw_images.is_empty(), TypedArray<Image>());

		for (int i = 0; i < raw_images.size(); i++) {
			images.push_back(raw_images[i]);
		}
	}
	return images;
}

ImageTextureLayered might possibly need a similar check if used in a same manner as the ImageTexture3D in the issue code snippet, but that would need some more testing and is a bit out of scope of this PR.
Kind of speculating here, so needs testing for confirmation.

Thanks! It solved my problem.

Thanks!


[BUG] Kubevirt patch version 0.40.0-hp-0 fails to create VM

Describe the bug

When trying to create a image template VM with Kubevirt version 0.40.0-hp-0 it fails
To Reproduce
Steps to reproduce the behavior:

Setup Kubevirt patch version on Rancher
Create new VM in harvester with image template
Define default password and SSH key in cloud config
Click create
Expected behavior

It should create
Support bundle

harvester-supportbundle_046bfe97-0e0e-45e2-b9e2-6ed767e0aa1d_2021-05-21T17-42-59Z.zip
Environment:

Harvester ISO version: master-c13c2a35-head

Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): bare metal DL360G9

Additional context

@guangbochen can someone take a look at this?

@ngildersleeveSUSE which image and template are u using for the validation, can u please check if it works without replacing the kubevrit img first.
The image and hot-plugin feature works on my custom v0.2.0 environment, the validation steps are:

replace kubevirt with patched 0.40.0-hp-0 image
enable the hotVolumePlugin feature of kubevirt, refer to https://github.com/harvester/harvester/issues/283#issuecomment-800843117
create a VM image e.g with ubuntu image
Create a volume on the Volumes page
Attach the volume via API call or my WIP change to virtctl.
The new-created volume should be available in the instance.
Detaching volume works too.

status:
  volumeStatus:
  - name: cloudinitdisk
    target: vdb
  - name: disk-0
    target: vda
  - hotplugVolume:
      attachPodName: hp-volume-qxw8g
      attachPodUID: 98681def-a8f9-4168-8f45-d5f0477a6531
    message: Successfully attach hotplugged volume foo to VM
    name: foo
    phase: Ready
    reason: VolumeReady
    target: sda

However, the live-migration is still not supported yet with this custom image.
admission webhook "migration-create-validator.kubevirt.io" denied the request: Cannot migrate VMI, Reason: HotplugNotLiveMigratable, Message: VMI has hotplugged disks

Live migration is still a working in progress. This new image starts to use one pod for all hot-plugged volumes instead of one pod per volume, which is a step forward in the right direction.

I wanted to verify. This should be getting tested on harvester 0.2.0, correct?

Yes

Tested in 0.2.0

Install with ISO from Github Releases
Set versions for images to following

    > registry.suse.com/harvester-beta/virt-api:0.40.0-hp-0
    > registry.suse.com/harvester-beta/virt-controller:0.40.0-hp-0
    > registry.suse.com/harvester-beta/virt-handler:0.40.0-hp-0
    > registry.suse.com/harvester-beta/virt-launcher:0.40.0-hp-0
    > registry.suse.com/harvester-beta/virt-operator:0.40.0-hp-0

Wait for upgrade to complete
Create VM from raw image template with http://cloud-images.ubuntu.com/releases/focal/release/ubuntu-20.04-server-cloudimg-amd64-disk-kvm.img as image and set password via cloudconfig
Create VM
When running run health check on VM
Verified as fixed.


postgres:13 docker-entrypoint.sh is broken

$ docker run -ePOSTGRES_PASSWORD=foo postgres:13 -d
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

Success. You can now start the database server using:

    pg_ctl -D /var/lib/postgresql/data -l logfile start

initdb: warning: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
waiting for server to start....postgres: invalid argument: "listen_addresses="
Try "postgres --help" for more information.
pg_ctl: could not start server
Examine the log output.
 stopped waiting

When not running with -d this does not happen.

My bad - I was missing the last postgres argument.

Did you mean to pass the -d argument to the docker run, or to postgres?
# passed to posgres via entrypoint:
$ docker run -ePOSTGRES_PASSWORD=foo postgres:13 -d

# passed to docker run:
$ docker run -ePOSTGRES_PASSWORD=foo -d postgres:13


[iOS] Wi-fi disconnected when turning on Outline

ios 12.0
outline app: 1.1.3
I dont want to share my personal info about Outline server and WiFi so i send video to<EMAIL_ADDRESS>with subject: iOS Outline Client Github Issue #296

btw Windows Client works fine in this WiFi network.

@lgg I've just installed Outline 1.1.3 on iOS 12.0 on 6s, the same Outline ver. also on 5s with iOS 11.4.1, tested with two servers one local box Ubuntu 18.04 with port forwarded on the router DryTek 2820 WiFi (WPA2 AES personal) and one on DigitalOcean both working fine so far have not noticed any disconnections issue.
Tested also connecting to Meraki MR33 AP Guest WiFi no-encryption, with a weak signal - devices listed above no disconnections issues, so far.
It also stays constantly connected even when a device goes to sleep and after wakeup is connected to the WiFi and Outline.
Could it be an Apple device or/and WiFi combination? If it does disconnects while testing to various WiFi AP I'd assume it's Apple Device specific?

Thank you for the reports @lgg and @mveplus. I'll

@mveplus thank you, other WiFi networks works fine. I will check my problem network more carefully.

For those who faced with the same issue: I don't know what exactly helps but try this:

reboot router
delete and add again Outline Server config in iOS app
reboot iOS device


Remove remaining utf-16 encoded runtime names from components

Follows #610 to remove remaining utf-16 strings from component binaries.

/azp run


Azure Files "is" a feature that supports building and managing file shares

Is "Azure Files" a feature that uses the plural Files, but it takes a single verb form?
Yes. And one derives that an Azure Files file share could be either SMB or NFS protocol. And these file shares could be either Azure file shares or Azure Files file shares.
In the attached snippet of the first page of https://docs.microsoft.com/en-us/azure/storage/files/storage-files-introduction
There are capitalization and use errors in the referenced page.The attached file show the first 3 errors in a screengrab of the first few paragraphs.
If the "feature" is " Azure Files" then the following terms are acceptable
Azure Files file shares
Azure file shares
But these uses are typos in the referenced page:
Azure File SMB file shares
Azure File Share
Improper uses have been marked with red pencil in the attached file.

Use this logic throughout a full edit of the page.

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

ID: b46c09cf-2ce5-b822-7b07-40b809256e72
Version Independent ID: 124a9438-9a25-e118-591e-4415373402c9
Content: Introduction to Azure Files
Content Source: articles/storage/files/storage-files-introduction.md
Service: storage
Sub-service: files
GitHub Login: @roygara
Microsoft Alias: rogarana

Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.

@jenellea Thanks for reaching out and bringing this to our attention, we appreciate it! I've gone ahead and updated the article, the changes should be live early next week.
Accordingly, I'll close this out.
#please-close


Advanced doc search for patient

 [E4.4] As a patient I want to be able to do an advanced search through medical record, so that I can better narrow down my search. [3]

 (0) PR Advanced doc search for patient


[incubator/zookeeper] Fix passing secrets (#9519)

What this PR does / why we need it:
Fix for #9519, passing in secret(s) to values.yaml causes a yaml parse error.  Typo on indentation??
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #9519

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x ] DCO signed
[x ] Chart Version bumped

/assign @kow3ns

/assign @kow3ns @lachie83

@kow3ns @lachie83 ping.  I'm sure you guys are busy at Kubecon, if you have some spare time please could you review this. Thanks, I appreciate your time and chart!

🙏

/ok-to-test


Return type of generic function interface allows object literals to have unknown properties.

TypeScript Version:  2.4.0
Code
type MyState = { foo: number; };
type Reducer<T> = (state: T) => T;

const reducer1: Reducer<MyState> = (state) => {
  return { foo: 123, bar: 123 }; // works.
};

const reducer2 = (state: MyState) : MyState  => {
  return { foo: 123, bar: 123 }; // fails.

  // Type '{ foo: number; bar: number; }' is not
  // assignable to type 'MyState'.
  // Object literal may only specify known properties,
  // and 'bar' does not exist in type 'MyState'.
};

Expected behavior:
The implementations for reducer1 and reducer2 have the same behavior.
Actual behavior:
The implementations for reducer1 and reducer2 have different behavior.

Please see https://github.com/Microsoft/TypeScript/issues/7547


Add information for single ticket purchase on Gala page

Feature
Why is this feature being added?
Requested by Dave Molina during OC Gala planning call on August 7, 2017
What should your feature do?
Display the information and links to purchase a single ticket for the Gala.

We'll need more details to complete this. @davidmolina do you have copy and links needed?


Upgrade to latest DocFx version

This is a major jump, because of the new versions of Material etc.

Reference to #200 - Updates/rewrite to the plugin needed

This is a work in progress on a project outside this repo. Check out https://pkbullock.github.io/pnp-docfx-theme/
at repo: https://github.com/pkbullock/pnp-docfx-theme


Release process sometimes fails to create pin PRs

As seen in this run,
[submariner-operator]$ GOPROXY=direct go get<EMAIL_ADDRESS>verifying<EMAIL_ADDRESS>checksum mismatch
	downloaded: h1:RDklbk79AGWmwhnvt/jBztapEOGDOx6ZbXqjP6csGnQ=
	go.sum:     h1:ahVqZF4n1W4NqwvVnZzC4es67xsW9uR/RRf2RRxieJU=

SECURITY ERROR
This download does NOT match an earlier download recorded in go.sum.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

https://github.com/submariner-io/releases/pull/193 recently added GOPROXY=direct to skip the golang proxy to alleviate an issue where the proxy didn't find the tagged dependency. The prevailing theory is that tag hadn't yet propagated to the proxy after creation. However bypassing the proxy sometimes results in a checksum mismatch for some problematic dependencies.
It seems the best solution is to use the proxy but keep retrying the operation for a period of time.

This actually has to do with a 3rd party dependency and not the released library (which is owned by us and is fine), and is somehow related to the use of GOPROXY=direct

This actually has to do with a 3rd party dependency and not the released library (which is owned by us and is fine), and is somehow related to the use of GOPROXY=direct

Right - adding GOPROXY=direct to bypass the proxy introduced this issue. That was to fix the original issue where we suspect our new tag hadn't yet propagated to the proxy after creation.  Hence retries were added. Perhaps you have another theory/solution...


SqlRSSetup: Document that the properties ProductKey and Edition is mutually exclusive

Details of the scenario you tried and the problem that is occurring
When i run it the script wants the edition and Product key. It does not state they are mandatory fields.
Verbose logs showing the problem
Suggested solution to the issue
The DSC configuration that is used to reproduce the issue (as detailed as possible)
# insert configuration here

SQL Server edition and version the target node is running
Sql 2016
SQL Server PowerShell modules present on the target node
5.1
The operating system the target node is running
windows server 2016
Version and build of PowerShell the target node is running
N/A
Version of the DSC module that was used ('dev' if using current dev branch)
n/a

Neither is mandatory because you can use either to install. Edition to install a free edition, and the ProductKey to install a licensed edition.
https://github.com/PowerShell/SqlServerDsc/blob/0a91a406611d7fd6ee8a6d5a571d14d39b460d98/DSCResources/MSFT_SqlRSSetup/MSFT_SqlRSSetup.psm1#L292-L304
This could be documented better, I label this issue as documentation and help wanted so that someone in the community can resolve this in the documentation.

This is my code
SqlRSSetup 'InstallDefaultInstance'
{
Action                = "Install"
InstanceName          = 'SSRS'
IAcceptLicenseTerms   = 'Yes'
SourcePath            = $node.SourcePath + "\SQLServerReportingServices.exe"
PsDscRunAsCredential  = $Node.InstallerServiceAccount
}
but it fails asking for Product key and version

When you compile the configuration it will not ask for additional parameters. You need to provide them in the configuration with the rest of the parameters. See the example here https://github.com/PowerShell/SqlServerDsc/blob/dev/Examples/Resources/SqlRSSetup/1-InstallReportingServices.ps1

that is the same as my code except for the edition parameter. The edition parameter is not a required parameter so not sure why it is complaining

The Edition or ProductKey parameter is a mutually exclusive mandatory parameter, it is just not a mandatory parameter in the schema. The code is throwing an error saying you need to provide either Edition or ProductKey, right?

Yes both


How to generate UML diagrams?

This feels like a silly question but I was not able to find a guide anywhere on how to initiate the process of generating the diagrams...

Ah thank you very much. It seems that the files were just being hidden away by my IDE for some reason. I found them now tho >< sorry for bothering.


i18n(it): Translated tutorial introduction

What kind of changes does this PR include?

Translated content

Description

Added page tutorial/0-introduction/index.mdx translated in Italian

Hi @csarnataro! I can see you've started to translate the tutorial!
With the tutorial only, we can't accept individual pages translated one at a time. We want to make sure someone is not going to have to switch language from page to page while they're trying to learn Astro! :sweat_smile:
So, we have to let @Yan-Thomas know that you'd like to start the tutorial, and he will make your own branch for the tutorial in Italian, and then all translations should be PR'd to that branch. When the ENTIRE tutorial has been translated, reviewed and is ready to go, then we will merge that tutorial branch into main so it will be published into docs.
Just letting you know what happens next here!

Ok @sarah11918 , thank you for the info. I will close this PR and open a new one with all the sections as soon as everything is ready.

Closing in favor of a single PR with all the tutorial sections.


fix(pr): make reviewer a different token input

since protected branches can't be reviewed by the pr author, we need an option to provide a
different token for the review user

:tada: This PR is included in version 1.3.1-beta.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

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

:tada: This PR is included in version 1.4.0-beta.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Removed unused 'extra_data' arg

Small PR to fix issue #70 . Removes the unused argument.

📚 Documentation preview 📚: https://arviz-plots--73.org.readthedocs.build/en/73/

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 85.78%. Comparing base (1298e42) to head (b6b462d).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #73      +/-   ##
==========================================
- Coverage   85.85%   85.78%   -0.07%
==========================================
  Files          17       17
  Lines        1951     1949       -2
==========================================
- Hits         1675     1672       -3
- Misses        276      277       +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Use the XML exception tag in doc comments (F#)

Changes:

Adds proper XML tags for any exceptions previously mentioned within the summary tag.
Enables warning of malformed F# doc comments (FS3390) as an error.

A few things to note:

At this time, only F# Tools 11.0.0 supports XML doc comment validation (release notes).
Code references don't seem to be validated yet, even by 11.0.0 (i.e. an incorrect cref won't be caught).
Parameter name reference validation actually works :)

Ref #699

Hi @kevinhartman, sorry for the delay in reviewing this! I'll take a look on Monday. Also, #769 created some merge conflicts here - although that PR didn't actually change any of the doc comments, so the conflicts shouldn't be too bad to resolve. Since #769 was my fault, I'll resolve the merge conflicts for you unless you want to handle them. :)

No worries, @samarsha! I'm happy to resolve them :D I should be able to get to in the next day or two.

Thanks for working on this and for resolving the merge conflicts! The compiler checks for invalid doc comments sound great. :)

Thanks! :) Sorry about all of the param refs I'd missed. I'm used to Scala's multiple parameter lists for currying, but F#'s curried syntax without parenthesis threw me off!

/azp run

/azp run


it returns error when Scan to a none empty slice with empty Result for package gdb

Codecov Report
Patch coverage: 62.50% and project coverage change: +0.08% :tada:

Comparison is base (243fe73) 79.17% compared to head (88a4442) 79.26%.
Report is 2 commits behind head on master.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2858      +/-   ##
==========================================
+ Coverage   79.17%   79.26%   +0.08%
==========================================
  Files         634      627       -7
  Lines       52423    52132     -291
==========================================
- Hits        41506    41320     -186
+ Misses       8855     8777      -78
+ Partials     2062     2035      -27

Flag
Coverage Δ

go-1.18-386
79.22% <62.50%> (-0.03%)
:arrow_down:

go-1.18-amd64
?

go-1.19-386
?

go-1.19-amd64
?

go-1.20-386
79.20% <62.50%> (+<0.01%)
:arrow_up:

go-1.20-amd64
?

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

Files Changed
Coverage Δ

os/gfpool/gfpool_pool.go
78.37% <ø> (ø)

internal/empty/empty.go
75.73% <53.12%> (+0.92%)
:arrow_up:

database/gdb/gdb_type_result.go
90.83% <100.00%> (+0.48%)
:arrow_up:

frame/g/g_func.go
85.71% <100.00%> (ø)

... and 14 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Compatibility issue with matplotlib

Package is facing compatibility issue with matplotlib (v3.1.0) and importing ShapRFECV is throwing an error.
ValueError: variadic keyword parameters cannot have default values

Hi @priyanshj
Can you try using the latest version of matplotlib ? v3.1.0 is almost 2 years old, the latest version is v.3.4.3. You can upgrade using pip install --upgrade matplotlib
If that doesn't solve it.. what version of python are you on? (python -V) and what version of probatus (pip list | grep probatus)?

@priyanshj is this still an issue? Otherwise will close it.

Please feel free to make another issue when this is encountered again. I believe it should be fixed in the latest version.


Support offset argument in the GROUP BY time(...) call

An offset of time(1m, now()) will anchor the offset to the start time
of the query. The default offset is 0s which is the current default
anyway.
This fixes #2074 by making time zone offset support unnecessary. Time
comparisons can use timezones inside of the time clause and the offset
needed for non-hour timezone differences can be used as part of the
offset argument.

@pauldix @jwilder
I think this does what we talked about and should make timezone support beyond the normal time parsing code unnecessary. If we want, we can possibly add support later for specifying the offset as a string in the offset column. Any formatting of the output can be handled on the client side.

Some more work may need to be done though for supporting things like 1 day though. I limited the specified offset to something lower than the duration, but after reading the other issue, I'm not sure that's good enough for solving this ticket completely.

@benbjohnson

@jsternberg Overall it lgtm. However, why is there a limitation on the offset to be less than the time duration? You should be able to offset -7h for a time zone but you have 1h intervals.

@benbjohnson I wasn't sure about that. My reasoning was that the offset is only useful for moving the buckets and moving the bucket more than the interval doesn't make a lot of sense because of modulo math. If you want to limit the time based on a time zone, then you can just use the timezone in the time field like this:
SELECT mean(value) FROM cpu WHERE time >= '2010-01-01T00:00:00Z-07:00' AND time < '2010-01-02T00:00:00Z-07:00' GROUP BY time(1h)

The time when a timezone offset is useful is when you're calculating an aggregate when grouping by day and this works:
SELECT mean(value) FROM cpu WHERE time >= '2010-01-01T00:00:00Z-07:00' AND time < '2010-01-07T00:00:00Z-07:00' GROUP BY time(1d, -7h)

This will shift the buckets by 7 hours so that it starts at midnight in the MST time zone.

7h is a poor example since it would line up with a 1h bucket. However, for time zones that don't align to an hour then I could see users wanting to simply put the number of minutes for the offset and not worry about trying to mod by the bucket.
For example, Nepal has a UTC+05:45 offset. It would be nice to just put GROUP BY time(1h, 345m) for the offset.
I don't think that limiting the offset gains us anything.

It's possible we could just do the mod ourselves for user-friendliness. The time positions are still going to be limited by the duration. So you could say time(1h, 345m) and it would translate the offset to 45m.

I've modified the commit to perform the modulo automatically.
> select * from cpu
name: cpu
---------
time                            host            value
2016-04-29T13:35:16.204223091Z  server02        2

> select count(value) from cpu where time > now() - 4h group by time(1h, 345m)
name: cpu
---------
time                    count
2016-04-29T10:45:00Z    0
2016-04-29T11:45:00Z    0
2016-04-29T12:45:00Z    1
2016-04-29T13:45:00Z    0
2016-04-29T14:45:00Z    0

:+1:

This needs an InfluxQL docs change.
@pauldix can you take a look as well?

There's also an ongoing discussion about the use of the word now() since the now() that can be used has no relation to the actual time, but actually relates to the start time of the query. I had a talk with @benbjohnson somewhere else about using start() instead, but there was concern that people would think start() could then be used in other parts of the query.

The discussion of start() can be moved to a separate issue. It doesn't seem like a blocker since now() should be supported as well if we do also use start().

I disagree with that. If we support now(), I think it should refer to the current time rather than the start time. We can support both, but I don't think they should be aliases.

I updated the PR to have now() get filled in with the now time instead of the start time and we can later extend it to allow start().

LGTM 👍

Does the right thing happen when my query is half in and half out of DST? I'm going to assume not -- and that should be made clear in the documentation. So if I query Friday March 11 to Monday March 14 (march 13, 2016 dst started) my UTC offset will be (in the eastern time zone) -5 and then at 2am Sunday March 13 it switches to -4.

This doesn't really assess timezones specifically. All outputs are still in UTC and it's up to the client to determine how to output the value. This is mostly for offsetting the buckets to facilitate buckets that don't fall neatly in non-UTC timezones such as India which is at UTC+05:30. You can do GROUP BY time(1h, 30m) to get the appropriate bucketing of intervals.


Give baseprofile tests time for reconciliation

What type of PR is this?
/kind failing-test
What this PR does / why we need it:
The current e2e tests are failing even within prow. This PR is an approach to fix this.
Which issue(s) this PR fixes:

None
Does this PR have test?
Yes

Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

None

This is now ready for review.

/lgtm


Update delegate-app-roles.md

Highlight 'application developer role' a bit more considering this is the role users should be assigned to

@rolyon
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Hi @yuazhou
Thanks for taking the time to contribute to the docs. We'll get your update merged.
thanks

#sign-off


[Docs] Rectify Misspelling

Current State
In the User Experience ( GUI vs CLI) section in the docs - contributing to mesheryctl page, mesheryctl is misspelled as mesherctl.
Desired State
It should be mesheryctl.

Contributor Guides and Handbook

📚 Instructions for contributing to documentation

Meshery documentation site and source

🛠 Meshery Build & Release Strategy
🎨 Wireframes and designs for Meshery UI in Figma
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

Hey there! I would like to work on this issue if its okay

Thank you, gents.


Application does not create zelda3_assets.dat

While I was able to launch the application (which needs .NET framework), the process did not create a zelda3_assets.dat based on the correct ROM. I am not sure why it did not compile it from zelda3.sfc.
I had issues creating the same thing with MSYS64 (dependencies required, it was a big mess), but the launcher from what I've read is supposed to do all this automatically.

Did it present you with any error messages? Can you provide the log file from where you attempted to compile?

I've fiddled around with some stuff so the error log will have records of that but the most recent from this morning should show the latest.
zelda3.log

Nothing stands out immediately, so I'll need to double-check the original project and see if the build process has been changed in a way that would make the launcher out-of-date.

I just downloaded a clean copy of the launcher from GitHub and ran the process which worked as expected. In comparing our logs though, I am seeing some differences, notably in regards to how the version of python the launcher downloads. All of the python calls are entirely empty in your log where mine is actually returning the messages from those commands.
This leads me to believe that you may be having a problem download that version of python as its possibly being blocked by some firewall, device security, or it may have even just been down when the download was attempted. Please check the /tables folder for a python.exe to see if it is present.

There is a python.exe with the modification date of 9/5/2022.
I remember when trying to build Super Mario 64 and its builder it had issues with Avast.

I decided to whitelist it from Avast, rebuild it again, and got python.exe - System Error.
"The program can't start because api-ms-win-core-path-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem."

What version of Windows are you running? Some quick searching indicates that your error may be due to your Windows version being no longer supported by the version of python I download and use.

Windows 7, which msys64 no longer officially supports...I had to go back to an old version when I was using the SM64 builder. I didn't see system requirements, and .NET framework still worked, so I assumed it was valid. I'm surprised I'd be the first to find that out that way.

Consider attempting with the new v<IP_ADDRESS> release as the python version was updated. It may actually have been related to that all along.


Version 3.0 when to release ?

Version 3.0 when to release ?

After all issues and PR's associated with 3.0 are either resolved or rescheduled for further version. We don't have an estimate about that it's going to happen. We're working in 2.8 at this moment.


10262 Add APIDocs Swagger UI upload as part of back end deploy (Staging)

This PR:
Added github action steps to upload apidocs swagger ui content to azure storage account "swaggeruiapidocsstg" (currently manually provisioned, will be terraformed by DevOpSec in the future)
Test Steps:

Will pass CI checks firstly

Changes

Added upload az commands to upload swagger ui apidocs content built from backend build flow to the azure storage account 'swaggeruiapidocsstg' static web folder

Checklist
Testing

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

Process

[ ] Are there licensing issues with any new dependencies introduced?
[ ] Includes a summary of what a code reviewer should test/verify?
[ ] Updated the release notes?
[ ] Database changes are submitted as a separate PR?
[ ] DevOps team has been notified if PR requires ops support?

Linked Issues

Fixes #issue

To Be Done
Create GitHub issues to track the work remaining, if any

#issue

Specific Security-related subjects a reviewer should pay specific attention to

Does this PR introduce new endpoints?

new endpoint A
new endpoint B

Does this PR include changes in authentication and/or authorization of existing endpoints?
Does this change introduce new dependencies that need vetting?
Does this change require changes to our infrastructure?
Does logging contain sensitive data?
Does this PR include or remove any sensitive information itself?

If you answered 'yes' to any of the questions above, conduct a detailed Review that addresses at least:

What are the potential security threats and mitigations? Please list the STRIDE threats and how they are mitigated

Spoofing (faking authenticity)

Threat T, which could be achieved by A, is mitigated by M

Tampering (influence or sabotage the integrity of information, data, or system)
Repudiation (the ability to dispute the origin or originator of an action)
Information disclosure (data made available to entities who should not have it)
Denial of service (make a resource unavailable)
Elevation of Privilege (reduce restrictions that apply or gain privileges one should not have)

Have you ensured logging does not contain sensitive data?
Have you received any additional approvals needed for this change?

@jeremy-page @arnejduranovic the demo1 deploy actually went beyond the az commands that upload the swagger ui contents, log fragment attached, let me know if this is good proof so we can merge?
`build/generated/sources/headers/java/main/
Run az storage blob delete-batch --account-name swaggeruiapidocsstg -s '$web'
az storage blob delete-batch --account-name swaggeruiapidocsstg -s '$web'
az storage blob upload-batch --account-name swaggeruiapidocsstg -s ./build/swagger-ui -d '$web'
shell: /usr/bin/bash --noprofile --norc -e -o pipefail 0
env:
VPN_ENV: demo1
AZURE_HTTP_USER_AGENT:
AZUREPS_HOST_ENVIRONMENT:
RESOURCE_GROUP: prime-data-hub-demo1
TERRAFORM_ENV: demo1
ACR_NAME: pdhdemo1containerregistry.azurecr.io
IMAGE_REPO: pdhdemo1
IMAGE_SWAGGER_UI_REPO: swaggeruiapidocsstg
TAG: 1ccb7c1db1b7ce42964b9ddbcd3c4851e5429497
FUNCTION_APP: pdhdemo1-functionapp
WARNING:
There are no credentials provided in your command and environment, we will query for account key for your storage account.
It is recommended to provide --connection-string, --account-key or --sas-token in your command as credentials.
You also can add --auth-mode login in your command to use Azure Active Directory (Azure AD) for authorization if your login account is assigned required RBAC roles.
For more information about RBAC roles in storage, visit https://docs.microsoft.com/azure/storage/common/storage-auth-aad-rbac-cli.
In addition, setting the corresponding environment variables can avoid inputting credentials in your command. Please use --help to get more information about environment variable usage.
WARNING:
There are no credentials provided in your command and environment, we will query for account key for your storage account.
It is recommended to provide --connection-string, --account-key or --sas-token in your command as credentials.
You also can add --auth-mode login in your command to use Azure Active Directory (Azure AD) for authorization if your login account is assigned required RBAC roles.
For more information about RBAC roles in storage, visit https://docs.microsoft.com/azure/storage/common/storage-auth-aad-rbac-cli.
In addition, setting the corresponding environment variables can avoid inputting credentials in your command.
Login Succeeded
Run nick-fields/retry@943e742917ac94714d2f408a0e8320f2d1fcafcd
#0 building with "default" instance using docker driver
#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 1.07kB done
#1 DONE 0.0s
#2 [internal] load .dockerignore
#2 transferring context: 65B done
#2 DONE 0.0s
#3 [internal] load metadata for mcr.microsoft.com/azure-functions/java:4-java17-appservice
#3 DONE 0.3s
`

rerun passed:


Dose not Support Sklearn gaussian process

The current version of shape.KernelExplainer  (and other classes) does not support Sklearn gaussian process.
It raises following error:
TypeError: 'GaussianProcessRegressor' object is not callable

https://github.com/muandet-lab/ExplainingGaussianProcess


Refactor before next release

Added https://github.com/cli-table/cli-table3/
Added binary validator
Removed pull-funds command
Texts consistency has been reviewed.
Command parameters are now in camelCase.
Fixed the "receipts" formatter.
Refactored "account info "command using forkJoin.
New generic command class announce.transaction.

Pull Request Test Coverage Report for Build 224

0 of 0   changed or added relevant lines in 0 files are covered.
5 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-1.0%) to 91.667%

Files with Coverage Reduction
New Missed Lines
%

build/src/model/profile.js
1
91.67%

build/src/service/mosaic.service.js
1
97.37%

build/src/validators/mosaic.validator.js
3
62.5%

Totals

Change from base Build 216:
-1.0%

Covered Lines:
112

Relevant Lines:
124

💛  - Coveralls


Template for default.nix

To fix build on Coq 8.9 and Coq 8.10 for https://github.com/coq-community/coq-bits, this needed to be added to default.nix:
installPhase = ''
    make -f CoqMakefile COQLIB=$out/lib/coq/${coq.coq-version}/ install
  '';

See https://github.com/coq-community/coq-bits/pull/3

I have no idea if this is the right way to do it, I think we need someone with Nix expertise to comment. I thought it always sufficed to have make install to support Nix fully?
cc: @Zimmi48 @vbgl

The usual coq-makefile wants to install third-party libraries next to Coq standard library. This is incompatible with the immutability of the nix store. So indeed, it is common practice to explicitly tell coq-makefile where to install this library.
It is also possible to only set installFlags to avoid repeating make and install and co.

@vbgl but I thought the location problem was already handled by the following line in @anton-trunov's default.nix:
installFlags = "COQLIB=$(out)/lib/coq/${coq.coq-version}/";

See https://github.com/coq-community/bits/blob/master/default.nix#L29
I was at least under the impression that coq_makefile respected the COQLIB variable and that saying explicitly installPhase = ... would therefore be redundant.

Thanks for clarifying. Indeed, setting the COQLIB variable in the installFlags should be enough. Is there a failing example to look at?

@vbgl Here you go: https://github.com/coq-community/bits/pull/8/checks?check_run_id=424943595. I removed that snippet and now it builds on Coq 8.7 and 8.8, but fails on 8.9 and 8.10.

So apparently only builds with Coq 8.9 and later are failing, e.g., https://travis-ci.com/coq-community/bits/jobs/283318683
Example:
install flags: SHELL=/nix/store/715fljdrspphbdk255r729zxp4w7lcgk-bash-4.4-p23/bin/bash COQLIB=\$\(out\)/lib/coq/8.9/ install
coq_makefile -f _CoqProject -o CoqMakefile
Fatal error: exception Sys_error("/nix/store/gj1li5l0r5c56796f6m3ld72dham244r-bits/lib/coq/8.9//tools/CoqMakefile.in: No such file or directory")

I'm thinking this could be some weird Makefile-Nix interaction issue. @anton-trunov can you reproduce this error when using another delegating Makefile like this one? https://github.com/coq-community/huffman/blob/master/Makefile

@palmskog Indeed you are right about the Chapar Makefile: https://github.com/coq-community/bits/runs/424973800

Looks like this should be reported as a Coq issue. Because the Coq reference manual suggests using the original template: https://coq.github.io/doc/v8.11/refman/practical-tools/utilities.html#reusing-extending-the-generated-makefile

As pointed out by @vbgl, switching to
installFlags = "COQMF_COQLIB=$(out)/lib/coq/${coq.coq-version}/";

also solves the issue (this does not require changing Makefile)

OK, this is still a very strange error to me, but I guess we can change the default.nix.mustache template to replace COQLIB with COQMF_COQLIB.

I haven't followed this issue closely. What does COQMF_COQLIB means?

Maybe Enrico can shed some light on this issue.
Ping @gares.

I don't have time to read all linked material. All the variables part of Makefile.coq.conf are prefixed by COQMF_ so that you can include that makefile (containing only variables coming from coqtop -config roughly) in other makefiles. Internally Makefile.coq uses shorter names, eg COQLIB that take as default value what is in Makefile.coq.conf.
Makefile.coq already provides a variable to "redirect" the installation root, and is probably called DESTDIR or PREFIX I don't recall. If you need to override the name coq in that path, I suggest you introduce a new variable (and temporarily hijack COQMF_COQLIB, if that works).
But I don't get one thing. If you install stuff in non-standard places, Coq has still to find them.
Are you saying you did not change its paths via ./configure but you are exporting COQLIB in the user shell? In case, please don't do it, since coq users are used to that variable and may tamper with it (even under nix). If you really want to do it via the env add a specific, not for the user, variable.

Thanks for clarifying the difference between COQLIB and COQMF_COQLIB.
If the purpose DESTDIR is what you describe, then it’s probably broken:
COQLIBINSTALL = $(call concat_path,$(DESTDIR),$(COQLIB)user-contrib)

Suppose I use a local Coq installation (in $HOME/local/lib/coq/) to build a library that I want to install into /path/usr/lib/coq/user-contrib; how should I set DESTDIR? Something like /path/usr/ seems reasonable but won’t work…
So, coq-makefile always want to install into $DESTDIR/$COQLIB, so overriding $COQLIB is mandatory (by design of coq-makefile) if we want to choose the installation directory.
But rest assured that this overriding is local to the call to make install.

The way Coq finds these libraries is via $COQPATH, which is set when entering a nix-shell. This is a pretty common practice across a large variety of languages.

Yes, I know, but while, say, JAVAHOME existed since day one with that meaning, COQLIB has a different meaning. To my understanding was supposed to be used by the user to override the coq default. In some sense it is legitimate to write "whatever COQLIB=this" while in the nix world only "whatever COQLIB+=extra" really makes sense.
If you want to take over COQLIB, I'm fine with it, but you (nix guys) should tell coq users and document it. I think I've had the same complaint on OCAMLPATH with @vgbl (because setting it is supposed to be legit, and in nix is is not, you can only append).

Are you mixing COQLIB and COQPATH?
The COQPATH variable is used as per its documentation in nix packages.
The COQLIB variable is some implementation detail of coq-makefile; overriding it while calling make install is the only way I know to chose the target directory when installing a library that uses coq-makefile. If there is a better way, please let me know.

Maybe it is not documented, but Coq uses COQLIB
https://github.com/coq/coq/blob/c6e89e2b13d7fa99aaaaf02fc3430ae6c5f00beb/lib/envars.ml#L97
for example we use it in the test suite, sphinx and CI to override where Coq looks for the stdlib, that depends on the build system for example. But yes, in my nix-rant I did confuse it with COQPATH that seems to be legit to use.
I looked at CoqMakefile.in and I believe it is safe if you call "make install" alone, but the variable is also used elsewhere, so if one calls "make all install" (which is wrong in many ways, but how many Coq users know it?) overriding COQLIB make things will go wrong.
So, as I suggested earlier, I prefer you override COQLIB only as a temporary solution and add a new variable, say COQLIB_INSTALL, so that overriding it has only the expected effect (and document it in the refman, since version 2 of coq_makefile I tried to document  the variables that are supposed to be overridden by the user, which is not the totality of variables). Would that work for you?

I believe this issue can be closed now.


Fix gitlab-ci icon association

Fixes #404
Changes proposed:

[ ] Add
[ ] Prepare
[ ] Delete
[x] Fix

Things I've done:

[x] I've pulled the latest master branch.
[ ] I've run npm install to install all the dependencies.
[ ] I've run ESLint.
[x] My pull request fixes an issue, I referenced the issue.
[ ] I've run npm run build to build the extension.

GitLab CI filenames begin with a . Similar to the name .travis.yml, it is .gitlab-ci.yml.

you're absolutely right! Thanks @neoeinstein!!


Enable result sets in webviews

Adds a new button the execute dropdown to run the statement in a new view.
This will run the statement in a brand new tab instead of the standard webview.

Two comments:

For longer running SQL statements, I could not see the SQL cancel button when using the enhancement
It would be nice to give users a method to control the name of the tab/window that is being opened


MUT allows import of email address with spaces and other illegal characters

Takes the import literally - should fail and log if there are spaces in a computer or device assigned user.  Im sure that it also used to check if the user existed in LDAP as well

I'm a bit torn on this one, because if the API accepts the data, I'm not sure if MUT should be limiting what we can do with the API.
Do you get an API error when submitting the invalid data? Or does the API accept it?
As for the LDAP stuff, if you have the LDAP sync option checked under inventory updates in Jamf Pro settings, then LDAP syncing will happen on inventory update. So you can assign a username to a device with MUT and then the next time that device checks in, Jamf Pro will pull other data (like full name, etc) from that LDAP record and put it on the device.


FileNotFoundError

Hello, I encountered a problem while running the code. I downloaded the two folders, train_img and val_img, based on your provided link. Where can I download the rest of the files?
FileNotFoundError: [Errno 2] No such file or directory: '../plane_data/train.txt'

Hi, @Xinghong-jxnu
Thanks for your attention.
The file 'train.txt' will be generated by planeAE when you run its data processing code (https://github.com/svip-lab/PlanarReconstruction/blob/master/data_tools/convert_tfrecords.py)


Uncaught Error: Could not find module...

I attempted to use this add on against an installation of https://github.com/softlayer/sl-ember-translate.  Without its use the tests at :4200/tests run just fine, but with this add on this is displayed in the browser:
global failure (1, 0, 1)
Uncaught Error: Could not find module sl-ember-translate/index
Source:
/assets/vendor.js:65
and this In the console:
Uncaught Error: Could not find module sl-ember-translate/index loader.js:58
requireModule loader.js:58
reify loader.js:41
requireModule loader.js:69
oldLoader blanket-loader.js:31
_blanket.extend.utils.processFile blanket.js:5241
blanketLoader blanket-loader.js:24
(anonymous function) blanket-loader.js:45
I started digging around into these errors but I'm hoping that they make more immediate sense to you and you can provide some guidance.

I get the same error when trying to use https://github.com/RSSchermer/ember-spectrum-color-picker, for what it's worth; that one is trivial, it's (basically) a single file that wraps an existing JS library, so there's no custom loader there.

For what it's worth, a workaround in this particular case is to add:
loaderExclusions: ["spectrum-color-picker"]
to blanket-options.js.
I'm still not sure what makes the loader so unhappy -- the spectrum-color-picker wrapper is very tiny so there's something pretty fundamental here.
For what it's worth, my guess is that the loader gets confused because spectrum-color-picker has, in addon/components/spectrum-color-picker.js:
import Ember from 'ember';
export default Ember.Component.extend({
classNames: 'spectrum-color-picker',
tagName: 'input',
... then the rest of the wrapper ...
});
and in app/components/spectrum-color-picker.js:
import SpectrumColorPickerComponent from 'ember-spectrum-color-picker/components/spectrum-color-picker';
export default SpectrumColorPickerComponent;
and something in the loader is getting confused because there's two files with the same name and it's lost track of which file it's trying to load.
Looking at the first post in this thread, sl-ember-translate has the same structure (addon/components/sl-translate.js and app/components/sl-translate.js with the same sorts of things inside them, so I suspect this problem will arise with any other addon that uses this structure.

Thanks for the additional details - I'll create a test project with the spectrum-color-picker and attempt to resolve this.  We have a number of addons in our project, but it's possible that none use that structure.

I get the same error too for the following modules
ember-cli-bootstrap
ember-cli-datepicker
ember-cli-jquery-ui
ember-idx-forms
this can be reproduced by a blank app after installing the above modules and run its generator

@hwwan80 @notmessenger Looking into this now.  The scope of the code coverage may need to be scaled back to handle these situations.  Currently every module is run through the instrumentation so that a full picture of the project's code coverage is displayed.  I need to find a way to exclude addons from the instrumentation since the code coverage for those should be done in their own projects, not in the projects that use the addons.

@hwwan80 @notmessenger I believe I've resolved the first portion of this issue.  The blanket-loader will now avoid instrumentation of any modules that don't contain the project's modulePrefix.  I've confirmed this against ember-spectrum-color-picker and sl-ember-translate.
Unfortunately, I haven't determined a way to distinguish between modules in the app directory that originated from an addon versus those actually present in the app directory, so the addon modules are still part of the coverage report.  At least the coverage doesn't break at this point though.
This is available in 0.2.4.

Closing in favor of #17


Keeping track of credentials on ThriftClient to avoid reauthentication

Keeping track of credentials while using ThriftClient in order to avoid reauthentication.
see https://github.com/rantav/hector/pull/292

Can you please rebase this patch with master and avoid re-formating the code ?
There are a lot of diffs that correspond with splitting the line into two. Let's try to respect the current style so that the only changes that show up in the diff file are the ones that correspond to this patch.

this was automatic


Propose Polygon.equals implementation

I'm also looking into how to implement a more general 'equivalent' method that works regardless of differences in rotation/translation.


Custom Document Name Handler

Description
For existing collections where document names cannot be easily modified, the Meilisearch extension fails because certain characters are not allowed.
It would be good to enable an option to either automatically sanitize this document name or use a GUID for each document.
Unfortunately, this issue is preventing me from using the Meilisearch extension.
Basic example
Document names contain the "\" character.  We'd be fine replacing them with "_" or "-" or another allowed character.
Other
The ability to write and specify a custom handler or function would be helpful as well.

Is it okay to replace all the invalid characters with valid ones?


Use the 'debug' module

Currently, we use console.log for outputting debug information. It's better to use the debug for this functionality.

Closed by #8


Fix get-workspaces command for eww

Closes #298

As of that commit, the output of hyprctl workspaces -j would print adding workspaces as the first line, resulting in the error mentioned in https://github.com/hyprwm/contrib/pull/54#issuecomment-1673602883. sed '1d' was meant to delete that first line, fixing the error and allowing the workspace script to function normally. I was not aware it was a bug, and assumed it was simply a deliberate change in the output. Seeing as this issue has been resolved directly in the hyprland code, I'll close this issue


PIE810 gives wrong suggestions

Hey! Given the code:
import sys

if __name__ == "__main__":
    x = ("hello", "world")
    y = "foo"

    msg = "abracadabra"

    if msg.startswith(x) or msg.startswith(y):
        sys.exit(1)

Ruff suggests (ruff check x.py):
x.py:9:8: PIE810 Call `startswith` once with a `tuple`

The problem is x is a tuple and the expression cannot be combined to msg.startswith((x, y))
Ruff settings
[tool.ruff]
line-length = 120
target-version = "py311"
exclude = ["*migrations*"]
select = [
    "E", # pyflakes
    "F", # pycodestyle errors
    "W", # pycodestyle warnings
    "UP", # pyupgrade
    "I", # isort
    "C4", # flake8-comprehensions
    # pytest
    "PT018", # Assertion should be broken down into multiple parts
    "PT022", # No teardown in fixture {name}, use return instead of yield

    "T10", # flake8-debugger
    "SIM", # flake8-simplify
    "ISC", # flake8-implicit-str-concat
    "FA", # flake8-future-annotations
    "PIE", # flake8-pie
    "T20", # flake8-print
    "RET", # flake8-return
    "FLY", # flynt
]
ignore = [
    "E741", # Ambiguous variable name
    "SIM115", # Use context handler for opening files
    "SIM116", # Use a dictionary instead of consecutive `if` statements
    "RET501", # Do not explicitly return None in function if it is the only possible return value
    # broken ones in RET:
    "RET505", # Unnecessary `elif` after `return` statement
    "RET506", # Unnecessary `elif` after `raise` statement
    "RET507", # Unnecessary `elif` after `continue` statement
    "RET508", # Unnecessary {branch} after break statement
]

Ruff version
ruff 0.1.6 (f460f9c5c 2023-11-17)

I can, but the point is ruff suggests invalid code that will throw.
btw, doing msg.startswith(x + (y,)) means to create extra tuple (and make extra allocations) each time the code being called. I don't think it's a good idea neither it's faster than two separate str.startswiths joined by or

Makes sense, thanks!

I guess one solution would be to avoid raising the violation if we're sure that it's a collection type like the mentioned code:
x = ["a", "b"]
y = "c"

msg.startswith(x) or msg.startswith(y)

But, if there are more than 1 startswith calls which has non-collection type or an unknown type, then we can raise an error:
x = ["a", "b"]
y = "c"
z = "d"

msg.startswith(x) or msg.startswith(y) or msg.startswith(z)
#                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#                    Raise here

I can take a look at this if the current rule could be improved to deal with this scenario.

Closed by https://github.com/astral-sh/ruff/pull/9661.