Run checkdoc/package-lint

Both of these programs will bring your code more in line with Elisp convetions/requirements for publishing in repositories such as MELPA.
package-lint
161 issues found:

1:0: error: package.el cannot parse this buffer: Search failed: ";;; color-tools.el ends here"
1:64: warning: You should depend on (emacs "24.1") if you need lexical-binding.
7:3: warning: You should include standard keywords: see the variable `finder-known-keywords'.
9:0: error: Expected (package-name "version-num"), but found dash.
9:0: error: Expected (package-name "version-num"), but found hsluv.
18:10: error: You should depend on (emacs "24.1") if you need `color'.
22:0: error: Aliases should start with the package's prefix "color-tools".
23:0: error: Aliases should start with the package's prefix "color-tools".
24:0: error: Aliases should start with the package's prefix "color-tools".
26:0: error: "ct/always-shorten" doesn't start with package's prefix "color-tools".
26:0: error: `ct/always-shorten' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
31:0: error: "ct/shorten" doesn't start with package's prefix "color-tools".
31:0: error: `ct/shorten' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
36:7: error: You should depend on (emacs "24.1") if you need `color-name-to-rgb'.
37:8: error: You should depend on (emacs "24.1") if you need `color-rgb-to-hex'.
40:0: error: "ct/maybe-shorten" doesn't start with package's prefix "color-tools".
40:0: error: `ct/maybe-shorten' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
46:0: error: "ct/name-to-lab" doesn't start with package's prefix "color-tools".
46:0: error: `ct/name-to-lab' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
49:5: error: You should depend on (emacs "24.1") if you need `color-name-to-rgb'.
50:12: error: You should depend on (emacs "24.1") if you need `color-srgb-to-xyz'.
52:12: error: You should depend on (emacs "24.1") if you need `color-xyz-to-lab'.
54:0: error: "ct/lab-to-name" doesn't start with package's prefix "color-tools".
54:0: error: `ct/lab-to-name' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
57:12: error: You should depend on (emacs "24.1") if you need `color-lab-to-xyz'.
58:12: error: You should depend on (emacs "24.1") if you need `color-xyz-to-srgb'.
61:12: error: You should depend on (emacs "24.1") if you need `color-rgb-to-hex'.
64:0: error: "ct/is-light-p" doesn't start with package's prefix "color-tools".
64:0: error: `ct/is-light-p' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
67:0: error: "ct/greaten" doesn't start with package's prefix "color-tools".
67:0: error: `ct/greaten' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
71:7: error: You should depend on (emacs "24.1") if you need `color-lighten-name'.
72:7: error: You should depend on (emacs "24.1") if you need `color-darken-name'.
74:0: error: "ct/lessen" doesn't start with package's prefix "color-tools".
74:0: error: `ct/lessen' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
78:7: error: You should depend on (emacs "24.1") if you need `color-darken-name'.
79:7: error: You should depend on (emacs "24.1") if you need `color-lighten-name'.
81:0: error: "ct/iterations" doesn't start with package's prefix "color-tools".
81:0: error: `ct/iterations' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
92:0: error: "ct/iterate" doesn't start with package's prefix "color-tools".
92:0: error: `ct/iterate' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
96:0: error: "ct/tint-ratio" doesn't start with package's prefix "color-tools".
96:0: error: `ct/tint-ratio' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
103:0: error: "ct/luminance-srgb" doesn't start with package's prefix "color-tools".
103:0: error: `ct/luminance-srgb' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
110:16: error: You should depend on (emacs "24.1") if you need `color-name-to-rgb'.
116:0: error: "ct/contrast-ratio" doesn't start with package's prefix "color-tools".
116:0: error: `ct/contrast-ratio' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
123:0: error: "ct/lab-change-whitepoint" doesn't start with package's prefix "color-tools".
123:0: error: `ct/lab-change-whitepoint' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
127:0: error: "ct/name-distance" doesn't start with package's prefix "color-tools".
127:0: error: `ct/name-distance' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
131:10: error: You should depend on (emacs "24.1") if you need `color-cie-de2000'.
134:0: error: "ct/transform-lab" doesn't start with package's prefix "color-tools".
134:0: error: `ct/transform-lab' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
141:0: error: "ct/transform-lch" doesn't start with package's prefix "color-tools".
141:0: error: `ct/transform-lch' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
147:14: error: You should depend on (emacs "26.1") if you need `color-lch-to-lab'.
150:36: error: You should depend on (emacs "26.1") if you need `color-lab-to-lch'.
151:60: error: You should depend on (emacs "26.1") if you need `color-lab-to-lch'.
157:0: error: "ct/transform-hsl" doesn't start with package's prefix "color-tools".
157:0: error: `ct/transform-hsl' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
159:8: error: You should depend on (emacs "24.1") if you need `color-name-to-rgb'.
160:12: error: You should depend on (emacs "24.1") if you need `color-rgb-to-hsl'.
174:12: error: You should depend on (emacs "24.1") if you need `color-hsl-to-rgb'.
175:12: error: You should depend on (emacs "24.1") if you need `color-rgb-to-hex'.
178:0: error: "ct/transform-hsluv" doesn't start with package's prefix "color-tools".
178:0: error: `ct/transform-hsluv' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
181:12: error: You should depend on (emacs "24.1") if you need `color-rgb-to-hex'.
191:0: error: "ct/transform-prop" doesn't start with package's prefix "color-tools".
191:0: error: `ct/transform-prop' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
200:0: error: "ct/transform-hsl-h" doesn't start with package's prefix "color-tools".
200:0: error: `ct/transform-hsl-h' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
201:0: error: "ct/transform-hsl-s" doesn't start with package's prefix "color-tools".
201:0: error: `ct/transform-hsl-s' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
202:0: error: "ct/transform-hsl-l" doesn't start with package's prefix "color-tools".
202:0: error: `ct/transform-hsl-l' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
204:0: error: "ct/transform-hsluv-h" doesn't start with package's prefix "color-tools".
204:0: error: `ct/transform-hsluv-h' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
205:0: error: "ct/transform-hsluv-s" doesn't start with package's prefix "color-tools".
205:0: error: `ct/transform-hsluv-s' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
206:0: error: "ct/transform-hsluv-l" doesn't start with package's prefix "color-tools".
206:0: error: `ct/transform-hsluv-l' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
208:0: error: "ct/transform-lch-l" doesn't start with package's prefix "color-tools".
208:0: error: `ct/transform-lch-l' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
209:0: error: "ct/transform-lch-c" doesn't start with package's prefix "color-tools".
209:0: error: `ct/transform-lch-c' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
210:0: error: "ct/transform-lch-h" doesn't start with package's prefix "color-tools".
210:0: error: `ct/transform-lch-h' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
212:0: error: "ct/transform-lab-l" doesn't start with package's prefix "color-tools".
212:0: error: `ct/transform-lab-l' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
213:0: error: "ct/transform-lab-a" doesn't start with package's prefix "color-tools".
213:0: error: `ct/transform-lab-a' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
214:0: error: "ct/transform-lab-b" doesn't start with package's prefix "color-tools".
214:0: error: `ct/transform-lab-b' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
216:0: error: "ct/getter" doesn't start with package's prefix "color-tools".
216:0: error: `ct/getter' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
225:0: error: "ct/get-lab" doesn't start with package's prefix "color-tools".
225:0: error: `ct/get-lab' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
226:0: error: "ct/get-lab-l" doesn't start with package's prefix "color-tools".
226:0: error: `ct/get-lab-l' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
227:0: error: "ct/get-lab-a" doesn't start with package's prefix "color-tools".
227:0: error: `ct/get-lab-a' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
228:0: error: "ct/get-lab-b" doesn't start with package's prefix "color-tools".
228:0: error: `ct/get-lab-b' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
230:0: error: "ct/get-hsl" doesn't start with package's prefix "color-tools".
230:0: error: `ct/get-hsl' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
231:0: error: "ct/get-hsl-h" doesn't start with package's prefix "color-tools".
231:0: error: `ct/get-hsl-h' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
232:0: error: "ct/get-hsl-s" doesn't start with package's prefix "color-tools".
232:0: error: `ct/get-hsl-s' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
233:0: error: "ct/get-hsl-l" doesn't start with package's prefix "color-tools".
233:0: error: `ct/get-hsl-l' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
235:0: error: "ct/get-hsluv" doesn't start with package's prefix "color-tools".
235:0: error: `ct/get-hsluv' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
236:0: error: "ct/get-hsluv-h" doesn't start with package's prefix "color-tools".
236:0: error: `ct/get-hsluv-h' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
237:0: error: "ct/get-hsluv-s" doesn't start with package's prefix "color-tools".
237:0: error: `ct/get-hsluv-s' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
238:0: error: "ct/get-hsluv-l" doesn't start with package's prefix "color-tools".
238:0: error: `ct/get-hsluv-l' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
240:0: error: "ct/get-lch" doesn't start with package's prefix "color-tools".
240:0: error: `ct/get-lch' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
241:0: error: "ct/get-lch-l" doesn't start with package's prefix "color-tools".
241:0: error: `ct/get-lch-l' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
242:0: error: "ct/get-lch-c" doesn't start with package's prefix "color-tools".
242:0: error: `ct/get-lch-c' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
243:0: error: "ct/get-lch-h" doesn't start with package's prefix "color-tools".
243:0: error: `ct/get-lch-h' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
246:0: error: "ct/lab-lighten" doesn't start with package's prefix "color-tools".
246:0: error: `ct/lab-lighten' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
249:0: error: "ct/lab-darken" doesn't start with package's prefix "color-tools".
249:0: error: `ct/lab-darken' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
252:0: error: "ct/pastel" doesn't start with package's prefix "color-tools".
252:0: error: `ct/pastel' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
264:0: error: "ct/gradient" doesn't start with package's prefix "color-tools".
264:0: error: `ct/gradient' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
269:31: error: You should depend on (emacs "24.1") if you need `color-rgb-to-hex'.
270:12: error: You should depend on (emacs "24.1") if you need `color-gradient'.
271:14: error: You should depend on (emacs "24.1") if you need `color-name-to-rgb'.
272:14: error: You should depend on (emacs "24.1") if you need `color-name-to-rgb'.
276:26: error: You should depend on (emacs "24.1") if you need `color-rgb-to-hex'.
277:7: error: You should depend on (emacs "24.1") if you need `color-gradient'.
278:9: error: You should depend on (emacs "24.1") if you need `color-name-to-rgb'.
279:9: error: You should depend on (emacs "24.1") if you need `color-name-to-rgb'.
283:0: error: "ct/make-color-meta" doesn't start with package's prefix "color-tools".
283:0: error: `ct/make-color-meta' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
288:0: error: "ct/make-hsl" doesn't start with package's prefix "color-tools".
288:0: error: `ct/make-hsl' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
289:0: error: "ct/make-hsluv" doesn't start with package's prefix "color-tools".
289:0: error: `ct/make-hsluv' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
290:0: error: "ct/make-lab" doesn't start with package's prefix "color-tools".
290:0: error: `ct/make-lab' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
291:0: error: "ct/make-lch" doesn't start with package's prefix "color-tools".
291:0: error: `ct/make-lch' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
293:0: error: "ct/rotation-hsluv" doesn't start with package's prefix "color-tools".
293:0: error: `ct/rotation-hsluv' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
298:0: error: "ct/rotation-hsl" doesn't start with package's prefix "color-tools".
298:0: error: `ct/rotation-hsl' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).
303:0: error: "ct/rotation-lch" doesn't start with package's prefix "color-tools".
303:0: error: `ct/rotation-lch' contains a non-standard separator `/', use hyphens instead (see Elisp Coding Conventions).

checkdoc
 color-tools.el    12     info            Name emacs should appear capitalized as Emacs (emacs-lisp-checkdoc)
 color-tools.el    22     info            You should have a section marked ";;; Code:" (emacs-lisp-checkdoc)
 color-tools.el    32     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el    41     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el    41     info            Argument ‘color’ should appear (as COLOR) in the doc string (emacs-lisp-checkdoc)
 color-tools.el    47     info            Argument ‘white-point’ should appear (as WHITE-POINT) in the doc string (emacs-lisp-checkdoc)
 color-tools.el    55     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el    55     info            Argument ‘white-point’ should appear (as WHITE-POINT) in the doc string (emacs-lisp-checkdoc)
 color-tools.el    65     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el    68     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el    68     info            Argument ‘percent’ should appear (as PERCENT) in the doc string (emacs-lisp-checkdoc)
 color-tools.el    75     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el    75     info            Argument ‘percent’ should appear (as PERCENT) in the doc string (emacs-lisp-checkdoc)
 color-tools.el    97     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   104     info            You should convert this comment to documentation (emacs-lisp-checkdoc)
 color-tools.el   117     info            You should convert this comment to documentation (emacs-lisp-checkdoc)
 color-tools.el   124     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el   124     info            First line should be capitalized (emacs-lisp-checkdoc)
 color-tools.el   124     info            Argument ‘name’ should appear (as NAME) in the doc string (emacs-lisp-checkdoc)
 color-tools.el   128     info            You should convert this comment to documentation (emacs-lisp-checkdoc)
 color-tools.el   135     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el   135     info            Argument ‘color’ should appear (as COLOR) in the doc string (emacs-lisp-checkdoc)
 color-tools.el   142     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el   142     info            Argument ‘c’ should appear (as C) in the doc string (emacs-lisp-checkdoc)
 color-tools.el   157   1 warning         Use of deprecated ((lambda (hsl) ...) ...) form (emacs-lisp)
 color-tools.el   157   1 warning         Use of deprecated ((lambda (hsl) ...) ...) form (emacs-lisp)
 color-tools.el   158     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el   158     info            Argument ‘transform’ should appear (as TRANSFORM) in the doc string (emacs-lisp-checkdoc)
 color-tools.el   179     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el   179     info            Argument ‘c’ should appear (as C) in the doc string (emacs-lisp-checkdoc)
 color-tools.el   192     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   200     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   201     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   202     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   204     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   205     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   206     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   208     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   209     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   210     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   212     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   213     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   214     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   216   1 warning         argument ‘_’ not left unused (emacs-lisp)
 color-tools.el   217     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   225     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   226     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   227     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   228     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   230     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   231     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   232     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   233     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   235     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   236     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   237     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   238     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   240     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   241     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   242     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   243     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   247     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   250     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   265     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el   265     info            Argument ‘with-ends’ should appear (as WITH-ENDS) in the doc string (emacs-lisp-checkdoc)
 color-tools.el   284     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   288     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   289     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   290     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   291     info            All variables and subroutines might as well have a documentation string (emacs-lisp-checkdoc)
 color-tools.el   294     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el   294     info            First line should be capitalized (emacs-lisp-checkdoc)
 color-tools.el   294     info            Argument ‘c’ should appear (as C) in the doc string (emacs-lisp-checkdoc)
 color-tools.el   299     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el   299     info            First line should be capitalized (emacs-lisp-checkdoc)
 color-tools.el   299     info            Argument ‘c’ should appear (as C) in the doc string (emacs-lisp-checkdoc)
 color-tools.el   304     info            First sentence should end with punctuation (emacs-lisp-checkdoc)
 color-tools.el   304     info            First line should be capitalized (emacs-lisp-checkdoc)
 color-tools.el   304     info            Argument ‘c’ should appear (as C) in the doc string (emacs-lisp-checkdoc)
 color-tools.el   308     info            The footer should be: (provide 'color-tools)\n;;; color-tools.el ends here (emacs-lisp-checkdoc)
 color-tools.el   309   1 warning         the function ‘-rpartial’ is not known to be defined. (emacs-lisp)

@progfolio thanks, that's very helpful. TIL the / separator is considered an error-level raise (for package-lint, anyway)

@progfolio do you know how I can set the prefix to ct rather than color-tools?

ah, it's derived from the provide

ah, it's derived from the provide


Transitive dependencies are gone in version 4.1.0

Hi there,
it seems that 4.1.0 does not declare some (or most) of the dependencies making us declare them on our own explicitly. Would you mind explaining if not publishing the information on dependencies was intentional and if there was any reasoning behind that? We know, we could use the shaded version of the client dependency but we would not like the idea.
Regards,
a new client ;)

I also came to the point where we could not execute code creating an ApiClient() for example without specifying the shaded classifier.
Explanation much needed :)

Actually, the dependencies are gone in 3.23.0. The list of dependencies in the README might be a little bit misleading since it does not map the version of the library to the dependency version. However, I wonder why the required dependencies are not transitive in the first place 🤔

Actually, the dependencies are gone since 3.19 because they obviously created 'a lot of version conflicts for a lot of users'. (https://github.com/docusign/docusign-esign-java-client/issues/234). Instead, the 'shaded' artifact came into place which is in fact a Fat Jar - without relocation though, it seems, so it still leads to version conflicts at least in server environments and many dependencies were outdated, some had known security issues and so on. Let's not go further into this. For us, the Fat Jar is no option.
Luckily, the code is open source, so you can get the dependency list from the project's pom.xml (at the bottom). That's what we use and simply redeclared those dependencies we don't already use in our own project, which enables us to override versions in case of conflicts or required security upgrades. There are Gradle build files as well, but these seem to be outdated and TBH JUnit 4 is too.
Note that since version 4, the client uses Jakarta instead of JEE 8 libraries now, so that may not be a simple drop-in replacement. In case of Spring Boot, it also requires a switch to Version 3+ and JDK 17 which is no minor task. Some kind of announcement would have been nice, but well.

Thank you @cbollmeyer for taking care to answer and pointing the #234. I can imagine that maintaining a library might be challenging but it seems to me that a dependency-less version suits no one, doesn't it? In case there is no conflict, clients should be able to use as-is or re-declare dependencies enforcing a particular version - dependency management tools allow us to declare whatever we please. However, if there is a conflict hiding dependencies does not help at all. Regarding vulnerabilities and bumping dependencies up it is up to the maintainer to check if everything works fine and is compatible.
BTW, regarding versions we were probably both right - I checked  3.22.0 and the dependencies are declared so I stopped verifying. However, wiping them out before publishing is probably a custom step that sb forgot to do.
Actually, it is a pity that for almost a year (since #234) the topic got almost no attention besides some trivial explanation and I think we would better proceed with a custom HTTP client on a stack we maintain anyway.

IIRC the developers said somewhere the reappearance of the dependencies in 3.22 was in fact a mistake. Indeed it's a little odd, but believe me, you had to redeclare most of the stuff including Jackson 2.12 or Jersey 2 anyway, as those were outdated and had known security bugs. Not to mention the json.org dependency the attic-ized apache oltu lib uses (it still does) which was from 2014. Idk, it is as it is. As you mention it, we too went migrating to a custom HTTP client for some of our projects, reusing only the model component for JSON serialization, but then, you have to deal with the API changes on your own. That pull request for the Refresh Token support (which the client still lacks) is pending review since...2021?

So far we seem lucky to use just authentication flow and one envelope call and we could give custom implementation a try.  Moreover, we do work in a BE-to-BE manner and we did not suffer from the lack of refresh tokens yet. The talk was really insightful and helpful 😌  but I'm going to close the issue because it seems unlikely I get something more.
Take care.

Closing as it is way too difficult to get some answers and we've finally decided to switch to a custom implementation.


Add flag for --no-execution to disable tx exec

This change allows running a full node that doesn't execute transactions.
Transaction execution is disabled in two ways:

Mempool won't populate its deque with transactions, but only persists them to the storage. This way, transactions will never become available for Scheduler.

Provider is configured with NoExecProvider implementation, that is complete no-op implementation for VM execution.

With these changes, a node can be run in such a way that it provides full functionality to the network but doesn't require special HW. Main use case for this is a combined JSON-RPC + Archive node instance, that can be also used as a P2P bootstrap node.

This is a draft for now. I'll test this a little bit later once I have built basic terraform setup for this. Ready for review however.

I think you can do it differently. Tx vlaidation, Tx exec and Storage are 3 separate domains. You need only the Tx validation and Storage. So the other possibility is to remove the Tx execution.
To do that, you use directly the:
txvalidation::TxEventSender::<txvalidation::TxResultSender>::build(tx_sender.clone())
in an async loop to get the Tx from it and store them in the database.

Where would I use that?

This way you skip the execution, you don't start it and more important you don't have to modify it because of a more general need.
Execution layer don't have to know that want to execute a full archive node.
In this model, we skip the mempool because it's too linked to the Execution layer and do nothing, just keep Tx until the scheduler get them.

If mempool is skipped, how does the transaction gets persisted?

The better way is to define a mempool that get validated Tx, propagate them if needed (tx propagation is part of the mempool domain) and make them available to the other domain: Tx execution / Storage / ... using stream.
This way you can activate Tx execution, Storage or not depending on the global needs. Each layer don't have to know how they are used.

I don't fully understand your suggestion at concrete level, but it sounds like you'd have a simpler / better solution than I have. Can you elaborate a bit so I can get on the same page :slightly_smiling_face:

This second revision should be now pretty much the same change that you suggested in your PR.


💡 Have a mode or configuration option that allows for monorepos that install deps at the root

Suggest an idea for this project
My preferred style of monorepo is one in which deps are installed only at the root. (This is the "Google-style" of monorepo, which ensures that the whole company uses the same versions of dependencies.) Unfortunately, it seems that Knip does not support this style of monorepo.
Example
monorepo/
├── package.json (containing `"react": "^18.0.0"` and `"angular": "^18.0.0"`)
├── node_modules/
|   └── [etc]
└── packages/
    ├── foo/
    |   └── package.json (containing `"react": "^18.0.0",`)
    └── bar/
        └── package.json (containing `"react": "^18.0.0",`)

In this example, Knip will report both "react" and "angular" as being unused, because it doesn't understand that dependencies are supposed to be installed at the root of the monorepo.
However, if we just tell Knip to ignore all dependencies at the root of the monorepo, that kind of sucks, because now there is no way to find that the "angular" dependency is completely unused.
Thus, this is a feature request for Knip to support monorepo format.

Duplicate of #345.

My preferred style of monorepo is one in which deps are installed only at the root. (This is the "Google-style" of monorepo, which ensures that the whole company uses the same versions of dependencies.)

How is that ensured?
And what happens if a dependency is installed in one of the workspaces' package.json, but not in the root package.json?

How is that ensured?

It's ensured because dependencies are installed at the root. In other words, a "package.json" file can't both have React 17 and React 18, it can only have one or the other. Hopefully that makes sense.

And what happens if a dependency is installed in one of the workspaces' package.json, but not in the root package.json?

By "workspace", do you mean "package subdirectory"? There is no concept of a workspace in a Google-style monorepo. So I think you are asking what would happen if someone new to the monorepo accidentally types "npm install foo --save" inside of a package subdirectory, which would create a duplicate "node_modules" folder, which would be a mistake because now two "node_modules" directories would exist, one at the root and one inside of the package subdirectory. I think what would happen at that point is that everything would work fine for the local dev who made the mistake. But as soon as they pushed a commit, CI would fail to build the project, because CI only runs npm install at the root of the monorepo and not the package subdirectory, so when CI goes to build the project, TypeScript would complain that the new dependency does not exist. Thus, it would be obvious at that point for the developer that they made a mistake.

Thanks for your explanations.
I was asking, since I'd expect the dependency versions can get out of sync (even though the root package.json is leading). Also, dependencies can be removed from a package subdirectory package.json - while it's still in use in that directory - and CI wouldn't complain? Would there be something to point out such issues?
Overall it feels brittle to do package management this way. Maybe I'm missing something, I would expected there to be more checks or linting in place? Perhaps your approach is documented somewhere?
My point is: before I would start to consider a feature like this I need to understand the value and use case of your approach better. Sorry, I still fail to see it. We've discussed the exact same thing almost a year ago, what has changed?

With the combination of the syncpack list-mismatches and the import-x/no-extraneous-dependencies rule, I don't think it is brittle.

Indeed, that certainly are great options. I guess I was trying to figure this out with my questions. Thanks for clearing that up. Going to close this one as well then.


[DataSpreadsheets] Needs null checks to prevent crashes

Package
Carbon for IBM Products
Description
Needs null checks

Component(s) impacted
Data spreadsheets
Browser
Chrome
@carbon/ibm-products (previously @carbon/ibm-cloud-cognitive) version
2.38
Severity
Severity 2 = Aspects of design is broken, and impedes users in a significant way, but there is a way to complete their tasks. Affects major functionality, has a workaround.
Product/offering
IBM
CodeSandbox or Stackblitz example
N/A
Steps to reproduce the issue (if applicable)
No response
Release date (if applicable)
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

I will fork the repo and make the changes myself because this is something that we need for DataStage

Null check has been merged in, thanks!


Adds poetry dependency management on fabric CLI

What this PR does

dependencies for the fabric cli are now managed via poetry.
fabric can be called directly as a CLI from the activated python virtualenv without the need to call it as python fabric.py.
updates Fabric CLI install instructions.
partially solves #27.

Why so big?

Poetry.lock maintains the hashes of all actually resolved dependencies. It's generated when one installs dependencies with poetry add foo automatically.

What's in it for this project

Deterministic dependencies pull and reproducibility: Since dependencies are resolved, locked and committed to source control, collaborators of this project can work on the same exact Python environment regardless of which OS they use and when they pulled dependencies.
Isolated packages: Poetry helps avoid version conflicts in Python files and projects by isolating packages from the OS.
Single configuration file: Poetry uses a pyproject.toml file to manage all dependencies, replacing multiple files like setup.py, requirements.txt, setup.cfg, and Pipfile.
Accessible project metadata: Project metadata is easy to access and understand from the pyproject.toml file.

What will the install actually look like

What's next:
Do this for the Flask server app if accepted.

awaiting @danielmiessler to restore repo to a stable state before submitting new PR with these changes.


Tracking issue to revert https://github.com/cquery-project/cquery/pull/558

https://github.com/cquery-project/cquery/pull/558

There's a "revert" button on the github UI. Anyone with repo write access can revert the patch.

It doesn't work :)

Should we put in the FAQ why precompiled headers may not work?

Sounds good - would you be willing to write it up?

I would, but I don't have time this morning.


How to pass an argument parameter without defining a value?

I am trying to achieve three scenarios for a command. Is there a way to do this ?

az postgres server create                                        (no argument parameter passed)
az postgres server create --public-access               (no value passed for argument parameter --public-access)
az postgres server create --public access  ( a valid value is passed to argument parameter --public-access).

Is there a way to do (2) that is pass a parameter without a value ? I am running into the below error :
az postgres server create: error: argument --public-access: expected one argument.
If this is do-able, how should I differentiate between (1) and (2) that is whether the parameter is completely missing or is present with a missing value ?

postgres

@arde0708 what are the sample values of --public-access? What is the behavior for 2?
We have get_three_state_flag arg_type that can achieve 2 and 3, but it only support boolean values.

We would want to define three kind of values for --public-access

No value. Just the parameter is passed. Ex : 'az postgres flexible-server create --public-access' ( Adds neither a Vnet, nor a firewall rule)
Single IP. Ex :  'az postgres flexible-server create --public-access <IP_ADDRESS>' (Behavior : Adds single firewall rule)
Multiple IP. Ex :  'az postgres flexible-server create --public-access <IP_ADDRESS>-<IP_ADDRESS>' (Behavior : Adds range of firewall rules)
Don't pass the parameter itself 'Ex : az postgres flexible-server create' (Behavior : Adds Vnet, Subnet)

@yonzhan Single Server is being retired. We won't be fixing this at this point in time. Please, close this issue. Thanks!


[QUESTION] Is Zulip compatible with Debian bullseye?

Hi,
Could anyone tell me whether Zulip server is compatible with Debian 11 (bullseye)?

I tried and got it run successfully on Debian 11.
Thanks.

Thanks for the report!
It looks like the state of this is that we've added support in the code, but haven't documented it: see #17863. Closing this in favor of further updates there.


Add gitlab_custom_server_config

After #105 was merged, you are able to add extra settings like these via that parameter. (Though some of the extra filtering may get a little awkward in the nested dict, so it can be a little bit of a bother to make sure the settings get all the way through correctly—use |- and >- judiciously!).


Issue with Archery

By default without any combat settings the way archery is supposed to work is that you cannot shoot while moving, but your swing does build up while you move. then whenever you stand still you have to wait for 1 second if you have a full swing built up, and you can shoot your arrow. and the prcocess can repeat.
Right now moving at all completely resets the archery swing. by far one of the biggest issues with combat is that archery is completely broken by this and no one uses it.
https://user-images.githubusercontent.com/17236327/148721709-a74af051-d652-4deb-99ca-784362a0dc84.mp4
you can see here I move right as the animation for the swing is about to start, this is correct that it should not shoot the arrow, but the next moment I stand still for 1 second it should shoot that arrow. and a new swing begins.

I had this issue and solved it at some point. Will take a look at it. Subscribed to resolve it later on the week.

Can you share your CombatFlags?

CombatFlags=01|040|080|0100|01000|08000

still an issue, confirmed recently. moving while using archery should not cancel your swing, if you do NOT have COMBAT_STAYINRANGE toggled on.  OR if you have COMBAT_SWING_NORANGE enabled.


feat: load signedurl filter by default

Hi,
PR helps to reduce one step of the filter usage method.
However, you can safely pass this PR.
Thank you for package.

I wasn't sure if I wanted a filter to be autoloaded, but after all, it's not a bad idea.
Thanks!


NIFI-1028 initial commit of NiFi In Depth documentation

@JPercivall
great commit. Very good to have a clear and concise source to understand what happens under the nice and friendly web UI. :-)

@olegz addressed the comments in a new commit

+1. I am going to merge this unless there are objections. Documentation is an ongoing task, so I am sure there will be updates to it in the future, and will be addressed incrementally.


refactor: improve MCD (Module Circular Dependency) metric of the code

Pull Request
Description
Currently, the source code has several MCD (Module Circular Dependency) that can be fixed to improve the overall LPVS architecture.
Current PR contains the refactoring the code to separate LPVSConflict to the independent class.
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[X] Code cleanup/refactoring
[ ] Documentation update
[ ] This change requires a documentation update
[ ] CI system update
[X] Test Coverage update

Testing
Tested using unit tests.
Checklist:

[X] My code follows the style guidelines of this project
[X] My code meets the required code coverage for lines (90% and above)
[X] My code meets the required code coverage for branches (80% and above)
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[X] My changes generate no new warnings
[X] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes

Codecov Report
Attention: Patch coverage is 97.22222% with 1 line in your changes missing coverage. Please review.

Please upload report for BASE (main@149c5a0). Learn more about missing BASE report.

Files with missing lines
Patch %
Lines

src/main/java/com/lpvs/entity/LPVSConflict.java
88.88%
0 Missing and 1 partial :warning:

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #615   +/-   ##
=======================================
  Coverage        ?   93.88%
  Complexity      ?      622
=======================================
  Files           ?       52
  Lines           ?     2126
  Branches        ?      247
=======================================
  Hits            ?     1996
  Misses          ?       57
  Partials        ?       73

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


FIX: make Joi default() function work in jsonApi.define()

PR for Issue: #84

Something odd seems to be going on here.
On the CI server, the tests fail with different date formats:
-    "timestamp": "2017-06-29T00:00:00.000Z"
+    "timestamp": "2017-06-29"

On my local machine, the same tests fail but they're an hour different:
-    "timestamp": "2017-06-28T23:00:00.000Z"
+    "timestamp": "2017-06-29"

This timestamp field is defined in example/resources/comments.js:13
  timestamp: jsonApi.Joi.date().format("YYYY-MM-DD")

After poking around a bit, I've found we're passing around a date-string formatted as "2017-06-29" - this goes through Joi and gets converted to a javascript Date, which eventually gets converted back to JSON as it leaves the API, thus appearing as a full JSON timestamp regardless of the requested format. I'm guessing the time difference I'm seeing is timezone related?

also noticed that, firstly I think it's maybe moment.js lib issue,
https://github.com/hapijs/joi/blob/master/lib/date.js#L74
but don't go deep at that moment.
if ISODate maybe it's will be OK?

For reference - I'm in the UK, so I'm currently in the GMT timezone (GMT === UTC). During the summer months of the year we move into the BST timezone (BST === UTC+1). The difference in time is caused by the input date not containing a timezone (it's "2016-06-29", not "2016-06-29T00:00:00.000Z+000").

Assuming the date's are correct, my next question is "why do the Date()s not conform to the requested format?".
Maybe the timestamp attribute should be re-typed to be string? It would at least prevent the type conversion from taking place. This might end up being a documentation note around what to expect when using the Joi.date() type. Or maybe we should steer clear of allowing Joi to convert types all together?
It's getting really late over here, I'm going to sleep on this one.

so moment.js convert user input into ISO Date
http://momentjs.com/docs/#/displaying/as-javascript-date/
Joi use it as below:
moment('2017-06-29', 'YYYY-MM-DD', true).toDate()
the result output is 2017-06-28T23:00:00.000Z from the CI server according the timezone.
Date & time is complicated, so maybe it's better to pass it to Joi+Moment.js to manage and convert user input into more standard format?

I'm in China, the output is Thu Jun 29 2017 00:00:00 GMT+0800 (HKT), the same input date string, but if added to different timezone, it's different time.

I think you're right, what it's doing is correct, it's the Joi validation defined in the comment resource that is wrong. Could you change the validation from a date to a string? It'd be great to add a new attribute (or alter an existing attribute) to contain a default value, then tweak one of the tests to ensure the default value is being applied correctly.

change to string() triggered many test case problems, so maybe solve the CI problems later.


add registration page

Adds a simple html registration page, available at the /register endpoint .

This is a nice registration page, do we want to go the extra steps to allow for removing and editing entries that are already in the database?

Editing entries might be useful. I could work on adding that along with endpoints to access the data.


turn the watch cache on

Summary
requires https://github.com/kcp-dev/kubernetes/pull/73
Related issue(s)
Fixes #

/retest

/test all

/lgtm
/approve

/lgtm


Deleting projects and engagements admin side

Admin side:
SO can only delete a project or engagement if a request has been made. This wire shows a project with a deletion request, and some copy indicating all engagements below that would also be deleted.
https://www.figma.com/file/AXufBnFAVHvGdsxnQMVhNF/The-Accessibility-Exchange-Wireframes?node-id=3099%3A93970&t=891wYnYOiymznMwz-1
If you click the link, you come to this screen:
https://www.figma.com/file/AXufBnFAVHvGdsxnQMVhNF/The-Accessibility-Exchange-Wireframes?node-id=5595%3A110022&t=891wYnYOiymznMwz-1
Admin should also get an email saying this project has a deletion request, and links it to this page: https://www.figma.com/file/AXufBnFAVHvGdsxnQMVhNF/The-Accessibility-Exchange-Wireframes?node-id=5595%3A110022&t=Rjx4EYErtc6fimAO-3

Relates to #1338

When a project or engagement is deleted there should be notifications to individuals and CCs who are signed up for engagements.
Send a notification to the org about whether it was deleted or denied.
If denied, the deletion request goes away on the project page.


Unsupproted industry enginehouse_princess causing track to not load

Attach the save file
Lake.zip
Describe the bug
Uncaught (in promise) Error: Unsupproted industry enginehouse_princess when loading save on lake map. This causes the track to not load.
Shown when loading map on lake
To Reproduce
Steps to reproduce the behavior:
Select Map in main screen.
Look in console
Expected behavior
Track should load,

OS: Windows 11
Browser Firefox
Version 120.0.1

Further testing shows this is present on pine valley as well.
test.zip

I am confirming this has also happened to me on a Lake Valley map too. Attached is my affected Lake Valley save.
LakeValley.zip

Fixed in #90


fix: bump projen and cdk

Fixes #

Codecov Report

Merging #353 (2c9335a) into main (02f6041) will decrease coverage by 1.46%.
The diff coverage is 86.20%.

@@            Coverage Diff             @@
##             main     #353      +/-   ##
==========================================
- Coverage   94.33%   92.87%   -1.47%
==========================================
  Files           6        7       +1
  Lines         424      505      +81
  Branches      126      143      +17
==========================================
+ Hits          400      469      +69
- Misses         21       33      +12
  Partials        3        3

Impacted Files
Coverage Δ

src/transformer/cdk-transformer.ts
98.23% <ø> (ø)

src/transformer/schema-transformer.ts
84.92% <65.38%> (-5.47%)
:arrow_down:

src/transformer/custom-vtl-transformer.ts
93.87% <93.87%> (ø)

src/appsync-transformer.ts
94.25% <100.00%> (+0.35%)
:arrow_up:

Continue to review full report at Codecov.

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


Search only for "Artist - Topic"-like channels on ytsearch

Related or not to my previous question, Youtube began to upload high-quality music in channels similar to this one, named like this: Artist name - Topic. I assume its for Youtube Music.
Is possible to make ytsearch to only search for videos uploaded in these channels?
Thanks a lot!

read the decumentation.

Where's the documentation? The link on official website just redirect to the Readme of this repository which is just youtube-dl --help with fancy markdown formatting.

Where's the documentation? The link on official website just redirect to the Readme of this repository which is just youtube-dl --help with fancy markdown formatting.

no, it's not.
the answer is actually there in OPTIONS section.

--default-search?

not, at all.
simply it's not possible, and you would've been able to know that if you looked at Video Selection Options and in particular --match-filter option.
there is already a feature request for wildcard filtering of video metadata.
it would be better next time to actually fill the issue template properly, read the documentation and search for similar issues before submitting an issue.

 Anyway thanks for point me to --match-filter option


Added new checker and general cleanup

Added a new checker, What, which uses PyWhat
https://github.com/bee-san/pyWhat

This is a more advanced regex checker and will let Ciphey work on URLs, IP addresses, emails and more!
I also removed dead code in the brandon checker.
Also, I added my github sponsors link. This is because I pay for the servers out-of-pocket, and the only way my company will let me receive money is if I was paid it personally (they don't let you start another business).
The servers cost around £11 / month and I currently make £2.80 / month from sponsorships. You can view the costs of the servers anytime. If I make more than the servers than I plan to give it out, like so:
Give_out = total - server_costs / contributors
Where a contributor is defined as "someone who has contributed 30 PRs in the last 5 months, or one large PR in the last month.". This means that the core team can not receive money if they do not contribute, and allows anyone to contribute and earn money if they wish.

Forgot to say. The:

30 PRs / 1 big PR

the exact numbers can change whenever we want. Currently ciphey does not make money nor is it likely to in the future unless our popularity picks up again, those numbers are just guesses. We can talk about this later 😄


Missing newline rules to achieve consistent trailing comma handling

There are some missing rules in this repository regarding "newline", which are part of ESLint.

function-paren-newline
object-curly-newline
array-bracket-newline
array-element-newline

All those rules are needed to have a consistent "Additional trailing comma" handling in our code.
Is there a reason why those rules are missing or a plan to add them? If not, is there an alternative to achieve the trailing comma handling?

I've been using https://palantir.github.io/tslint/rules/trailing-comma/, and this is how I have configured it so that it can achieve the same style as airbnb.
"trailing-comma": [
      true,
      {
        "multiline": "always",
        "singleline": "never",
        "esSpecCompliant": true
      }
    ],

It does have a bug though:
https://github.com/palantir/tslint/issues/3870
Is there something in that rule that doesn't allow you to have code style your project needs?

Ah, I see what you are saying now. Yeah, the rules you mentioned above are necessary. PRs are welcome to any of these rules.


Icon: Add plus icon

Icon: Add plus icon

This update adds 2 new plus icons, as well as a handy npm run update:icons script.

@knicklabs I plan on adding svgo there as well.. when I figure out the best settings. It's a start tho!

Coverage remained the same at 100.0% when pulling f7b2d7c3a9bce462ef1f67b47b2abad6db85c034 on icon-plus into bab4ab08f3314d4e0d085e48c779a9921786f975 on master.


comment line

Current dependencies on/for this PR:

main

PR #9   👈

This stack of pull requests is managed by Graphite.


auto complete does not deduce types of parameters of functions

auto complete does not deduce types of parameters of functions
python3
import turtule
bob=turtule.Turtle()

def function(bob)
    bob.f... << auto complete here dos not work

bob.f.. auto complete here works

function(bob)

That's to be expected. How the function would know that bob (parameter) is an Turtle object. Because as far as python is concerned in this case, bob as a parameter for the function is not the same bob defined outside the function.
You can use type annotation to have autocomplete work as you desire in this case:
import turtule
bob=turtule.Turtle()
def function(bob: turtule.Turtle)
bob.f

@shimondoodkin Please inform if you're using Jedi or Language server, i.e check the value of python.jediEnabled in settings. Also please make sure to fill the issue template next time.

Environment data
[Window Title]
Visual Studio Code
Version: 1.42.1 (system setup)
Commit: c47d83b293181d9be64f27ff093689e8e7aed054
Date: 2020-02-11T14:45:59.656Z
Electron: 6.1.6
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Windows_NT x64 10.0.17763

Extension version 2020.2.63072 (12 February 2020)

Python version: Python 3.6.4

Type of virtual environment used : N/A

Relevant/affected Python packages and their versions: N/A

Relevant/affected Python-related VS Code extensions and their versions: N/A

Jedi or Language Server? (i.e. what is "python.jediEnabled" set to; more info #3977): No

Value of the python.languageServer setting: "python.languageServer": "Microsoft"


High CPU usage with 0.12.0

Environment

Elixir & Erlang versions (elixir --version):

Erlang/OTP 25 [erts-13.0.4] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit]

Elixir 1.14.1 (compiled with Erlang/OTP 25)

Elixir Language Server version: 0.12.0
Operating system: MacOS 13.0.1
Editor or IDE name: VSCode
Editor Plugin/LSP Client name and version: Elixir-LS 0.12.0

Current behavior
VSCode starts to feel sluggish, my CPU (MacBook Pro, M1) is at 90C all the time and I receive many unnecessary completions, e.g., for the Application token:

Expected behavior
Here's how it looks with Elixir LS 0.11.0:

My CPU is not melting and I don't receive unnecessary completions.
Note
For testing this, I compiled both v0.12.0 and v0.11.0 and replaced the bundled elixir-ls in the VSCode extension.

Duplicate of https://github.com/elixir-lsp/elixir-ls/issues/772
@Defman21 can you try master? The issue should be fixed already

master branch is broken for me:
[Error - 12:27:21 AM] GenServer ElixirLS.LanguageServer.Experimental.SourceFile.Store terminating
** (Protocol.UndefinedError) protocol Enumerable not implemented for %ElixirLS.LanguageServer.Experimental.SourceFile.Document{lines: {{:line, "defmodule REDACTED do", "\n", 1, true}, {:line, "  @moduledoc false", "\n", 2, true}, {:line, "", "\n", 3, true}, {:line, "  use Supervisor", "\n", 4, true}, {:line, "", "\n", 5, true}, {:line, "  def start_link(opts) do", "\n", 6, true}, {:line, "    Supervisor.start_link(__MODULE__, :ok, opts)", "\n", 7, true}, {:line, "  end", "\n", 8, true}, {:line, "", "\n", 9, true}, {:line, "  @impl Supervisor", "\n", 10, true}, {:line, "  def init(:ok) do", "\n", 11, true}, {:line, "    Applicat", "\n", 12, true}, {:line, "    config = Application.fetch_env!(:music_spit, REDACTED "\n", 13, true}, {:line, "", "\n", 14, true}, {:line, "    children = [", "\n", 15, true}, {:line, "      {Plug.Cowboy,", "\n", 16, true}, {:line, "       scheme: :http, plug: REDACTED options: [port: Keyword.fetch!(config, :port)]},", "\n", 17, true}, {:line, "      REDACTED "\n", 18, true}, {:line, "      REDACTED "\n", 19, true}, {:line, "    ]", "\n", 20, true}, {:line, "", "\n", 21, true}, {:line, "    Supervisor.init(children, strategy: :one_for_one)", "\n", 22, true}, {:line, "  end", "\n", 23, true}, {:line, "end", "\n", 24, true}}, starting_index: 1} of type ElixirLS.LanguageServer.Experimental.SourceFile.Document (a struct). This protocol is implemented for the following type(s): Date.Range, File.Stream, Function, GenEvent.Stream, HashDict, HashSet, IO.Stream, Jason.OrderedObject, List, Map, MapSet, Range, Stream
    (elixir 1.14.1) lib/enum.ex:1: Enumerable.impl_for!/1
    (elixir 1.14.1) lib/enum.ex:230: Enumerable.slice/1
    (elixir 1.14.1) lib/enum.ex:4379: Enum.slice_forward/4
    (elixir 1.14.1) lib/enum.ex:468: Enum.at/3
    (language_server 0.12.0) lib/language_server/experimental/source_file/document.ex:36: ElixirLS.LanguageServer.Experimental.SourceFile.Document.fetch_line/2
    (language_server 0.12.0) lib/language_server/experimental/source_file/conversions.ex:73: ElixirLS.LanguageServer.Experimental.SourceFile.Conversions.to_elixir/2
    (language_server 0.12.0) lib/language_server/experimental/source_file/conversions.ex:28: ElixirLS.LanguageServer.Experimental.SourceFile.Conversions.to_elixir/2
    (language_server 0.12.0) lib/language_server/experimental/source_file.ex:138: ElixirLS.LanguageServer.Experimental.SourceFile.apply_change/2
Last message (from ElixirLS.LanguageServer.Experimental.Server): {:update, "file:///Users/defman/Projects/REDACTED", #Function<1.80531545/1 in ElixirLS.LanguageServer.Experimental.Server.State.apply/2>}
State: %ElixirLS.LanguageServer.Experimental.SourceFile.Store.State{source_files: %{"file:///Users/defman/Projects/REDACTED" => %ElixirLS.LanguageServer.Experimental.SourceFile{uri: "file:///Users/defman/Projects/REDACTED", path: "/Users/defman/Projects/REDACTED", version: 10, dirty?: false, document: %ElixirLS.LanguageServer.Experimental.SourceFile.Document{lines: {{:line, "defmodule REDACTED do", "\n", 1, true}, {:line, "  @moduledoc false", "\n", 2, true}, {:line, "", "\n", 3, true}, {:line, "  use Supervisor", "\n", 4, true}, {:line, "", "\n", 5, true}, {:line, "  def start_link(opts) do", "\n", 6, true}, {:line, "    Supervisor.start_link(__MODULE__, :ok, opts)", "\n", 7, true}, {:line, "  end", "\n", 8, true}, {:line, "", "\n", 9, true}, {:line, "  @impl Supervisor", "\n", 10, true}, {:line, "  def init(:ok) do", "\n", 11, true}, {:line, "    Applicat", "\n", 12, true}, {:line, "    config = Application.fetch_env!(:music_spit, REDACTED "\n", 13, true}, {:line, "", "\n", 14, true}, {:line, "    children = [", "\n", 15, true}, {:line, "      {Plug.Cowboy,", "\n", 16, true}, {:line, "       scheme: :http, plug: REDACTED options: [port: Keyword.fetch!(config, :port)]},", "\n", 17, true}, {:line, "      REDACTED "\n", 18, true}, {:line, "      REDACTED "\n", 19, true}, {:line, "    ]", "\n", 20, true}, {:line, "", "\n", 21, true}, {:line, "    Supervisor.init(children, strategy: :one_for_one)", "\n", 22, true}, {:line, "  end", "\n", 23, true}, {:line, "end", "\n", 24, true}}, starting_index: 1}}}}
Client ElixirLS.LanguageServer.Experimental.Server is alive

    (stdlib 4.0.1) gen.erl:256: :gen.do_call/4
    (elixir 1.14.1) lib/gen_server.ex:1035: GenServer.call/3
    (language_server 0.12.0) lib/language_server/experimental/server/state.ex:24: ElixirLS.LanguageServer.Experimental.Server.State.apply/2
    (stdlib 4.0.1) timer.erl:235: :timer.tc/1
    (language_server 0.12.0) lib/language_server/experimental/server.ex:76: ElixirLS.LanguageServer.Experimental.Server.apply_to_state/2
    (language_server 0.12.0) lib/language_server/experimental/server.ex:66: ElixirLS.LanguageServer.Experimental.Server.handle_notification/2
    (language_server 0.12.0) lib/language_server/experimental/server.ex:41: ElixirLS.LanguageServer.Experimental.Server.handle_cast/2
    (stdlib 4.0.1) gen_server.erl:1120: :gen_server.try_dispatch/4
[Warn  - 12:27:21 AM] ** (exit) exited in: GenServer.call(ElixirLS.LanguageServer.JsonRpc, {:packet, %{"id" => 45, "jsonrpc" => "2.0", "method" => "textDocument/documentSymbol", "params" => %{"textDocument" => %{"uri" => "file:///Users/defman/Projects/REDACTED"}}}}, 5000)
    ** (EXIT) no process: the process is not alive or there's no process currently associated with the given name, possibly because its application isn't started
    (elixir 1.14.1) lib/gen_server.ex:1027: GenServer.call/3
    (elixir 1.14.1) lib/stream.ex:481: anonymous fn/4 in Stream.each/2
    (elixir 1.14.1) lib/stream.ex:1651: Stream.do_element_resource/6
    (elixir 1.14.1) lib/stream.ex:1811: Enumerable.Stream.do_each/4
    (elixir 1.14.1) lib/stream.ex:689: Stream.run/1
    nofile:1: (file)
    (stdlib 4.0.1) erl_eval.erl:748: :erl_eval.do_apply/7
[Info  - 12:27:25 AM] Connection to server got closed. Server will restart.


"QWORD" data type not defined with 64 bit compiler

src/rawinput_buffered.cpp(87): error C2065: 'QWORD': undeclared identifier

Workaround:
using QWORD = UINT64;

Related:
https://github.com/MysteriousJ/Joystick-Input-Examples/blob/e2f196877de59134ac1499351d8e7391f4c6a3e0/src/rawinput_buffered.cpp#L1

Thanks, uncommented that line.


Java: using resource name of() instead of create()

Note: discogapic will need to be fixed after this change.
cc @andreamlin

Codecov Report

Merging #1670 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1670   +/-   ##
=========================================
  Coverage     85.52%   85.52%
  Complexity     4290     4290
=========================================
  Files           405      405
  Lines         16863    16863
  Branches       1760     1760
=========================================
  Hits          14422    14422
  Misses         1854     1854
  Partials        587      587

Continue to review full report at Codecov.

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


"Application error: a client-side exception has occurred" when removing an icon

Environment
Docker
Version
0.12.3
Describe the problem
When editing an app and clicking the "X"-Button in the "App symbol" input, next.js crashes and displays a black page with the words Application error: a client-side exception has occurred (see the browser console for more information)..
Changing the icon of an app is not possible at all.
Browser console:
TypeError: e is undefined
    NextJS 77
[framework-73b8966a3c579ab0.js:9:69816](https://homarr.tld/_next/static/chunks/framework-73b8966a3c579ab0.js)
    NextJS 63
TypeError: e is undefined
    NextJS 77
[main-10444cdf50d705d6.js:1:9025](https://homarr.tld/_next/static/chunks/main-10444cdf50d705d6.js)
    NextJS 65
A client-side exception has occurred, see here for more info: https://nextjs.org/docs/messages/client-side-exception-occurred [main-10444cdf50d705d6.js:1:9042](https://homarr.tld/_next/static/chunks/main-10444cdf50d705d6.js)
    NextJS 65

There's also this line inside the docker container logs. Although I am not sure if it has something to do with this problem, as I was not able to reproduce it:
Error: 'sharp' is required to be installed in standalone mode for the image optimization to function correctly. Read more at: https://nextjs.org/docs/messages/sharp-missing-in-production

Steps to reproduce:

Deploy homarr 0.12.3 via Docker, following the guide in the documentation
Run sudo chmod -R 755 /path/to/icons (with correct path to the folder that is mounted)
Add an app, switch to "appearance" tab and click the "X"-Button
App crashes with the errors above

Additional information:

I am running homarr behind a reverse proxy (NGINX Proxy Manager)

Logs
Browser console:
TypeError: e is undefined
    NextJS 77
[framework-73b8966a3c579ab0.js:9:69816](https://homarr.tld/_next/static/chunks/framework-73b8966a3c579ab0.js)
    NextJS 63
TypeError: e is undefined
    NextJS 77
[main-10444cdf50d705d6.js:1:9025](https://homarr.tld/_next/static/chunks/main-10444cdf50d705d6.js)
    NextJS 65
A client-side exception has occurred, see here for more info: https://nextjs.org/docs/messages/client-side-exception-occurred [main-10444cdf50d705d6.js:1:9042](https://homarr.tld/_next/static/chunks/main-10444cdf50d705d6.js)
    NextJS 65

Docker container:
Error: 'sharp' is required to be installed in standalone mode for the image optimization to function correctly. Read more at: https://nextjs.org/docs/messages/sharp-missing-in-production

Context
No response
Please tick the boxes

[X] I confirm that I attached the proper logs
[X] I've read the docs
[X] I've checked for duplicate issues
[X] I've tried to debug myself

Same bug here. No reverse proxy just in docker on unraid


Contribution flow: add selected payment method in URL params

Followup on https://github.com/opencollective/opencollective/issues/5721
Selected payment method is not currently included when sharing the URL. We should set it as paymentMethod=${stepPayment.key}.

Resolved by https://github.com/opencollective/opencollective-frontend/pull/8508


feat: fixed quiz functionality and deleted unnused folder

Changes

fixed quiz functionality
deleted unnused folder
updated small quiz questions text details

checkpoint quiz question options are not clickable.

Thanks for noticing it!
It's fixed in the last commitm, please re-review :smiley:

checkpoint quiz options is bugged.
clicking multiple options does not de-select the previous selected option.
i think, only one option should be selectable except for multi-choice questions. i.e selecting another option de-selects the previously selected option.

Hey @peteruche21 thanks for the feedback.
I tested it again and it works fine on my end, I recorded this small video to show it.
The first behaviour tested is the one you mentioned about not being able to de-select a previous selected answer in a multi-choice question.
https://vimeo.com/909557569/afe50bad5e
Let me know any update please, and thanks!

Oh okay, the current behavior in the video is what I actually meant.
I mean clicking on option (only one option can be selected at once in a given question)
Clicking on another option (same question) while there's a previous selection automatically deselects the already selected option and selects a new one.
Was it intended to be manually deselected like you did in the video?


Service Principal owners cannot revoke permissions

Please update documentation to call out that owner of the service principal cannot revoke permissions using PowerShell commands

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

ID: a35d8227-9a4b-57a3-dd9b-31d577451c73
Version Independent ID: 9cb13a07-8fe0-4478-7ca0-ddbb1fa87d6c
Content: Review permissions granted to applications - Microsoft Entra
Content Source: articles/active-directory/manage-apps/manage-application-permissions.md
Service: active-directory
Sub-service: app-mgmt
GitHub Login: @Jackson-Woods
Microsoft Alias: jawoods

@hahazeMSFT
Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.

#assign:omondiatieno

@hahazeMSFT, thank you for the feedback. We have raised a PR #204724 to address your feedback. Will close the issue for now. Feel free to reach out if you have any other concerns.

#please-close


syscall: int 0x80 is still used by syscalls in Linux

int 0x80 is deprecated and extremely slow, new x86 software should be using sysenter, you can find the calling convention on this SO answer

Which platform are you talking about?  As far as I know on amd64 we always use the SYSCALL instruction.

386 (aka x86) https://github.com/golang/go/blob/master/src/syscall/asm_linux_386.s

Current Minimum Go CPU requirement for 386 is Pentium MMX which does not support sysenter.
Therefore changing this for all supported Go archs would need a test for the specific CPUID bit and a bump in minimum CPU requirements. https://golang.org/doc/install/source#environment
See https://github.com/golang/go/blob/c6f9321b5a46e4af3233417d068c0efb4113d8e7/src/runtime/sys_linux_386.s#L13 for why int 0x80 is used:
// Most linux systems use glibc's dynamic linker, which puts the
// __kernel_vsyscall vdso helper at 0x10(GS) for easy access from position
// independent code and setldt in runtime does the same in the statically
// linked case. However, systems that use alternative libc such as Android's
// bionic and musl, do not save the helper anywhere, and so the only way to
// invoke a syscall from position independent code is boring old int $0x80
// (which is also what syscall wrappers in bionic/musl use).
//
// The benchmarks also showed that using int $0x80 is as fast as calling
// *%gs:0x10 except on AMD Opteron. See https://golang.org/cl/19833
// for the benchmark program and raw data.

Are there new benchmarks showing Go to better off not using int 0x80 with an alternative supported with bionic, musl and position independent code? This would be interesting especially on CPUs that dont support amd64 as the newer ones are likely better of to use amd64 target at any rate.


About the color of the title bar

I liked the old Classic theme because of the rich colors of Windows.
Is there any way to recreate it?
My current situation↓.

I want to do this↓.

Or is there an entry in the registry to change the color?
Also, do you plan to add a setting to exclude only certain processes?
And since I'm Japanese and not good at English, I use Deepl translation.

You must configure the colors.
Use that : https://github.com/WinClassic/SimpleClassicTheme/blob/master/SimpleClassicTheme/Resources/deskn.cpl
Or that : https://github.com/Superfly-Inc/SMACC
Or that : https://archive.org/details/themak5_3

tha


Support Database SSL config from Env

Why

Similar to #3787, it would be nice to be able to configure Database SSL from ENV values

What

Implemented the same way, the key we do an object check on is ssl - when the key is ssl we JSON.parse() before setting the value

Annoyingly, I can't address the edits by maintainers issue - due to: https://github.com/orgs/community/discussions/5634
This setting doesn't exist for org forks... I guess we'll open PRs from personal forks in the future


Added ability to look past incremental deploys

Description
Early review request to agree on the method used.
closes  #5493
Self Check:
Strike through any lines that are not applicable (~~line~~) then check the box

[x] Attached issue to pull request
[x] Changelog entry
[x] Type annotations are present
[x] Code is clear and sufficiently documented
[x] No (preventable) type errors (check using make mypy or make mypy-diff)
[x] Sufficient test cases (reproduces the bug/tests the requested feature)
[x] Correct, in line with design
[ ] End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )
[ ] If this PR fixes a race condition in the test suite, also push the fix to the relevant stable branche(s) (see test-fixes for more info)

Still https://github.com/inmanta/inmanta-core/pull/6344#discussion_r1284212187 unresolved comment.

Race condition

Processing this pull request

Merged into branches master in c9fdf3740076a71f501f1713863537860b3a752b

Processing #6361.


virtq: don't expose TransferTokens to the drivers

TransferTokens carry the control descriptor that represents the indirect descriptor table in them, which is not of the same type for split queues and packed queues. This type difference is currently hidden behind the type erasing MemDescr type, but when we change the structure to use the actual type for it, we will need to make TransferToken generic. An actually typed TransferToken would not work for driver code that decides the type of queue to use at runtime, as we cannot make a boxed slice (which control descriptors represent) work with dynamically-sized elements.
Furthermore, TransferTokens are tied to a particular type of queue, as it would be an error to dispatch a TransferToken that has a control descriptor that is suitable for a PackedVq through a SplitVq. To ensure dispatch through the correct type of queue, BufferTokens are created through queues and have a reference to the queue that created them, which forces the use of Rc, when a regular Box would likely suffice.

There is a lot of code that has been moved in the PR. I highly recommend the VS Code extension Semantic Diff to show moved blocks (I didn't have much luck with the experimental "Show Moves" option in VS Code), particularly with the option "Compare Moved Code".

The commit failed yesterday when I was testing something else. I am making the PR a draft until I figure out what the problem is.


add example for connectkit-nextjs-siwe

Add an example for connectkit-nextjs-siwe based on this. This is a full working example to help users bootstrap their app.

thanks @cctdaniel! i'll have a review of this in the upcoming days


[WIP] Update JSON to support binary file retrieval

Ref #180

I'm marking this as WIP, because I think there may be an alternative approach which is better.

Closing in favor of #213


Language verification testing and general feedback - Hindi

Background on the problem the feature will solve/improved user experience
The Five Fifths Voter site has been translated into twelve languages. The project is looking for you to verify the translated strings for Hindi on the website. Multiple contributors are welcome to participate.
Describe the solution you'd like
Click through the site and verify correctness in Hindi
Tasks

Create an issue for corrections required.
Take a screenshot of the error and add to the issue.
Describe the error in the issue and recommended changes.

Acceptance Criteria
The fix address any grammatical issues and spelling mistakes in the translations.

awesome! We'd love to have you help us! @S3umish


ValueError: Audio file is not long enough

restore jukebox/models/5b/prior_level_2.pth.tar
Restored from jukebox/models/5b/prior_level_2.pth.tar
0%|                                                                                | 0/60 [00:35<?, ?it/s]
Traceback (most recent call last):
File "main.py", line 177, in
representation = get_acts_from_file(input_path, hps, vqvae, top_prior, meanpool=True)
File "main.py", line 86, in get_acts_from_file
z = get_z(audio, vqvae)
File "main.py", line 32, in get_z
raise ValueError('Audio file is not long enough')
ValueError: Audio file is not long enough

Sorry for the late response. You can see exactly why this gets raised (https://github.com/p-lambda/jukemir/blob/96d67b9af0d62f39ac0cd656d09ea63a08a13b31/representations/jukebox/main.py#L31). The API asks for audio of at least ~24 seconds.

How can I adopt the repo to short audio

I'd recommend taking a look at the colab notebook. The notebook code supports this capability.


Updated Image

sorry but the point is to change the readme file image so I'm unable to accept your pull request
thankyou


Invalid Regular Expression in splitWords

Running fresh install of v9.4.0 yo liferay-theme (and also tried on 9.3.0) got the prompt for "what would you like to call your theme"  entered a string and then the generator just hung.  Hit Ctrl-C and got the following.
SyntaxError: Invalid regular expression: /[ _-]|(?<=[a-z])(?=[A-Z])/: Invalid group
    at splitWords (/Users/orin/.nvm/versions/node/v8.9.4/lib/node_modules/generator-liferay-theme/generators/common/splitWords.js:16:21)

Running on Mac system.
npm -v
6.11.3

yo --version
2.0.2

gulp -v
[16:08:40] CLI version 2.0.1

This version of the liferay-js-themes-toolkit (9.3.0)
can create a liferay-theme:app for Liferay DXP and Portal CE v7.2

Looks like your version of NodeJS is choking on the negative lookbehind. What version are you on?

We've just migrated this project to the liferay-frontend-projects monorepo in the name of consolidation. As this issue is quite old now, I'm not going to transfer it automatically. If you consider it to be still relevant, please create a fresh issue over in the new repo.


Can we set SUID on ptouch-print to avoid sudo?

To achieve this, we need to:

set the SUID flag (it's sufficient to set it for "user" - "group" and "other" is not needed)
change owner of the file to root

$ sudo chmod u+s build/ptouch-print
$ sudo chown root:root build/ptouch-print


$ could also be the first char of a var

$ could also be the first char of a var.

Nice catch. Thanks!


Importing Library

There was a previous feedback that was closed around the library reference.
It was brought up that the correct library to import should be azure.ai.anomalydetector instead of azure.cognitiveservices.anomalydetector.
The issue was closed but this error is still present on the page.

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

ID: 884b5e88-48eb-c3ad-1995-7cd87339783b
Version Independent ID: e06cfd58-46d0-200a-5967-c6a1a7276997
Content: Quickstart: Anomaly detection using the Anomaly Detector client library - Azure Cognitive Services
Content Source: articles/cognitive-services/Anomaly-Detector/quickstarts/client-libraries.md
Service: cognitive-services
Sub-service: anomaly-detector
GitHub Login: @mrbullwinkle
Microsoft Alias: mbullwin

@zxpek Thank you for your feedback! We will review and update as appropriate.

@zxpek I think you are referring to the python code snippet and the recent change refers to .net code snippet. It looks like the sample works fine with azure-cognitiveservices-anomalydetector package but the install command refers to pip install --upgrade azure-ai-anomalydetector
@mrbullwinkle Could you please confirm which package needs to be installed? If azure-ai-anomalydetector package needs to be installed then the imports will fail.

It looks like the change to the pip install instructions for azure-ai-anomalydetector was made on September 4th https://github.com/MicrosoftDocs/azure-docs/commit/21e9738e0b74bbaaf73747e1ca82d22664754e49#diff-7454699fdc7fa50ceb4f73eafc0448e6fa8e5a4299085129baf1f17a664137faR52 but as @RohitMungi-MSFT correctly points out the rest of the code samples are still relying on the old import statements as well as outdated naming that was part of the breaking changes introduced in the 3.0.0b2 release.
In the interim you can access fully up-to-date samples directly on the Azure SDK repo: https://github.com/Azure/azure-sdk-for-python/blob/a35eb57c4bd6ed2cb7d341a28a21ffd8d78ddf5a/sdk/anomalydetector/azure-ai-anomalydetector/samples/README.md.
I will create a workitem to get the article fully updated on the docs.microsoft.com side this week. Thank you for bringing this to our attention. Adding @yingqunpku for awareness,

The fix for this issue is now merged.

#please-close


SHOULD support Python 3.8

AppVeyor doesn't support Python 3.8 out of the box.

GitMate.io thinks possibly related issues are https://github.com/tvmaze/tvmaze/issues/5 (MUST support Python 3.7), https://github.com/tvmaze/tvmaze/issues/4 (MUST support Python 3.6), https://github.com/tvmaze/tvmaze/issues/2 (MUST support macOS), https://github.com/tvmaze/tvmaze/issues/1 (MUST support Linux), and https://github.com/tvmaze/tvmaze/issues/3 (MUST support Windows).


[firebase_auth] Reset Password Email Not Localized

In my Android app, using the FirebaseAuth.instance.setLanguageCode to set the language code successfully changes the language for email verification emails, but does not change the language for password reset emails.

@kevin-induro
Can you provide flutter doctor -v, flutter pub deps -- --style=compact and a complete minimal reproducible code sample that shows this issue ?
Thanks.

While easy to provide the requested outputs, it will take longer to get the minimal reproducible example as I only have so much time to work on this project.
flutter-doctor.txt
pub-deps.txt

Hi @kevin-induro
What language did this issue occur with? I can't reproduce it on firebase_auth: ^2.0.0. Both email are in the desired language.
Thank you

I believe I was trying in French and Spanish, but I can't imagine this being language dependent.
That said, as my pub-deps said, I'm running firebase_auth: 1.1.3. Since it sounds like this has been fixed in later versions, I can certainly try to upgrade.

Let me know if it persists on the latest version, I'll close this for now since I couldn't reproduce it


[BUG?] Translations are not shown on the admin area for a templateselect field

Hi!
First of all, if this is not a bug and it's my fault.. sorry :(
I just installed the extension and try to translate my pages contenttype.
These pages have a templateselect field that is is_translateable. So when I go to the pages admin area I see a template tab where I can set the template variables, and I can set a different value for each locale. The translated value it's saved correctly, and if I go to the frontend page I can see the translation.
But the problem comes when I reload the pages admin area, and I go again to the template tab. Then the translation value it's not loaded, instead I see the value of the default locale, so if I save again the page the translated value it's overrided with the default one.
Details

Translate Version: 4.0.5
Install type: Extension Repository
Bolt Version: v3.2.9
PHP version: 7.1.3
Used webserver: Apache/2.4.25 (Ubuntu)

Reproduction
Translate config file:
locales:
    ca_ES:
        label: Català
        slug: ca
    es_ES:
        label: Español
        slug: es

The Pages contenttype:
pages:
    name: Pages
    singular_name: Page
    fields:
        locale:
            type: locale
            group: content
        cadata:
            type: hidden
        caslug:
            type: locale_data
            index: true
        esdata:
            type: hidden
        esslug:
            type: locale_data
            index: true

        title:
            type: text
            class: large
            group: content
            is_translateable: true
        slug:
            type: slug
            uses: title
            is_translateable: true
        image:
            type: image
        body:
            type: html
            height: 300px
            is_translateable: true
        template:
            type: templateselect
            filter: 'page*.twig'
            is_translateable: true
#    taxonomy: [ groups ]
    recordsperpage: 100

I dunno if it's necessary, but here is the templatefields of the theme used in the pages. In concrete I'm trying the translation with a page that is using a 'page-manifest.twig' template.
templatefields:
    page-manifest.twig:
        title:
            type: text
            label: Título
        subtitle:
            type: text
            label: Subtítulo
        images:
            type: imagelist
            label: Imágenes
    page-resources.twig:
        resources:
            type: repeater
            label: Recursos
            fields:
                title:
                    type: text
                    label: Título
                url:
                    type: text
                    label: Enlace
    page-news.twig:
        news:
            type: repeater
            label: Noticias
            fields:
                title:
                    type: text
                    label: Título
                date:
                    type: date
                    label: Fecha
                url:
                    type: text
                    label: Enlace
                origin:
                    type: text
                    label: Medio de comunicación

Here some images to illustrate the problem:

First time that I set the translation:

The translation it's shown in the frontend:

When I reload the admin area the translation it's not showing:

But in the database the data it's correct:

Hi! I am having the same issue as above. I have set the template select field to is_translateable: true and the saved changes appear on the frontend but reloading the edit page the changes do not appear to be saved.
Bolt Version:  Bolt 3.2.11
Translate Version: 4.0.6

Same issue here. Admin does not show different data for each locale - but it shows correct on front end (as long as not saved over accidentally).
Bolt version: 3.2.7
Translate version: 4.0.6
Labels version: 3.0.7
It's a simple one page website. Here is my content type definition:
sections:
    name: Sections
    singular_name: Section
    fields:
        locale:
            type: locale
            group: meta
        name:
            label: 'Section Name'
            type: text
            class: large
            readonly: true
        slug:
            type: slug
            uses: name
        template:
            type: templateselect
            is_translateable: true
            filter: '*_section.twig'
        frdata:
            type: hidden
        frslug:
            type: locale_data
            index: true
        endata:
            type: hidden
        enslug:
            type: locale_data
            index: true
        rudata:
            type: hidden
        ruslug:
            type: locale_data
            index: true
    sort: datecreated
    default_status: published
    viewless: true
    searchable: false
    icon_many: "fa:newspaper-o"
    icon_one: "fa:newspaper-o"

And my translate.animal.yml:
locales:
    en_GB:
        label: English
        slug: en
    fr_FR:
        label: Francais
        slug: fr
    ru_RU:
        label: русский
        slug: ru

routing_override: false
menu_override: false
url_generator_override: false
translate_slugs: false
use_accept_language_header: false

This is fixed in the latest release via #127 / #132
Please reopen if I'm wrong :)


How do you install this?

Hi
How do you install this?

I run it as a Docker container, you should be able to compile and run it as a Linux demon or windows service.

There is a Docker compose example in the readme file


Adding swagger for endpoint certificates

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific langauge SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[x] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

/azp run

@zhenglaizhang
it seems this is a new Sdk lint error in LintDiff check: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=1259820&view=logs&j=0574a2a6-2d0a-5ec6-40e4-4c6e2f70bea2&t=b17d53b8-8799-5fc8-d76a-1d962d18e711
can you help to take a look? thanks!

/azp run

It's because of

@zhenglaizhang it seems this is a new Sdk lint error in LintDiff check: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=1259820&view=logs&j=0574a2a6-2d0a-5ec6-40e4-4c6e2f70bea2&t=b17d53b8-8799-5fc8-d76a-1d962d18e711
can you help to take a look? thanks!

It's due to at the global parameter space, BlobAuditingPolicyNameParameter is duplicated in both resource-manager/Microsoft.Sql/preview/2021-11-01-preview/EndpointCertificates.json and sql/resource-manager/Microsoft.Sql/preview/2021-11-01-preview/BlobAuditing.json but with different definition. You can fix it by using the same name or share them if they could be exactly the same.

It's because of

@zhenglaizhang it seems this is a new Sdk lint error in LintDiff check: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=1259820&view=logs&j=0574a2a6-2d0a-5ec6-40e4-4c6e2f70bea2&t=b17d53b8-8799-5fc8-d76a-1d962d18e711
can you help to take a look? thanks!

It's due to at the global parameter space, BlobAuditingPolicyNameParameter is duplicated in both resource-manager/Microsoft.Sql/preview/2021-11-01-preview/EndpointCertificates.json and sql/resource-manager/Microsoft.Sql/preview/2021-11-01-preview/BlobAuditing.json but with different definition. You can fix it by using the same name or share them if they could be exactly the same.

@zhenglaizhang I addressed the issue you mentioned in this comment, so there are no more LintDiff errors. Still there are 2 SDK errors that seem are not related to my change. Do you have an insight how can I resolve them?

@zhenglaizhang can you help to take a look about this PR? if there is no other issue, please help to merge it to dev branch? thanks!

Signed off with comments from ARM perspective.


Cannot access timetable api

Seems the implementation is broken.

Unfortunately, seems I am simply not autorized for this method at the moment:
|> get_course_timetable(canvas, sample_course)
        status                                    message
1 unauthorized user not authorised to perform that action


Implement Build Automation (Cake)

Needs to be able to:

Build for multiple target platforms
Execute unit tests on each target platform
Push unit test results and code coverage to SonarQube
Build and publish NuGet under specific conditions

It should not build and publish the NuGet every time
Only if specified test suites pass
Only on the master branch
Only when tagged as a release

Hello, I've been trying for the past few hours to implement a build system with Cake, but I'm stuck the compiler error CS0426 "The nested type ExtendedProtectionSelector does not exist on type System.Net.HttpListener " in files RestServer.cs and IHttpListener.cs
I'm trying to make this work on Arch Linux using mono version 4.4.1

Currently, Grapevine only targets the .NET 4.0 platform. There are open tickets to target the newer platforms, but they are a few weeks out from being implemented.

The ExtendedProtectionSelector exists in the Mono implementation. I'd gladly test and run the project on linux when you guys are ready with that. Meanwhile I'll dig around, and see if I can do that Cake build system.

@emanuelmd Shoot me an email if you'd like to get a hold of you when we are ready for that.


Revert "Update metadata.csv (#8099)"

This reverts commit a256a4064676af1b891544f31104a0f95e359b37.

@coignetp Out of curiosity, what's the motivation for reverting?


feat(elasticsearch): use 7.10.2 cluster for production

to be merged after indices are all created