Error: Cannot find module 'eslint-plugin-react'

With a fresh install, running gulp gives me the following error. I'm running node v.6.2.1 and gulp 3.9.1.
[leibovic@margaret-mbp:~/code/wiki-near-me]$ gulp
[10:11:00] Requiring external module babel-register
[10:11:01] Using gulpfile ~/code/wiki-near-me/gulpfile.babel.js
[10:11:01] Starting 'clean'...
[10:11:01] Finished 'clean' after 4.94 ms
[10:11:01] Starting 'default'...
[10:11:01] Starting 'styles'...
[10:11:03] styles all files 3 kB
[10:11:03] Finished 'styles' after 1.51 s
[10:11:03] Starting 'lint'...
[10:11:03] Starting 'html'...
[10:11:03] Starting 'scripts'...
[10:11:03] Starting 'images'...
[10:11:03] Starting 'copy'...
module.js:341
    throw err;
    ^

Error: Cannot find module 'eslint-plugin-react'
    at Function.Module._resolveFilename (module.js:339:15)
    at Function.Module._load (module.js:290:25)
    at Module.require (module.js:367:17)
    at require (internal/module.js:16:19)
    at /Users/leibovic/code/wiki-near-me/node_modules/eslint/lib/cli-engine.js:125:26
    at Array.forEach (native)
    at loadPlugins (/Users/leibovic/code/wiki-near-me/node_modules/eslint/lib/cli-engine.js:116:21)
    at processText (/Users/leibovic/code/wiki-near-me/node_modules/eslint/lib/cli-engine.js:204:5)
    at CLIEngine.executeOnText (/Users/leibovic/code/wiki-near-me/node_modules/eslint/lib/cli-engine.js:686:26)
    at verify (/Users/leibovic/code/wiki-near-me/node_modules/gulp-eslint/index.js:20:23)
    at Transform._transform (/Users/leibovic/code/wiki-near-me/node_modules/gulp-eslint/index.js:68:18)
    at Transform._read (_stream_transform.js:167:10)
    at Transform._write (_stream_transform.js:155:12)
    at doWrite (_stream_writable.js:301:12)
    at writeOrBuffer (_stream_writable.js:287:5)
    at Transform.Writable.write (_stream_writable.js:215:11)
    at write (/Users/leibovic/code/wiki-near-me/node_modules/vinyl-fs/node_modules/readable-stream/lib/_stream_readable.js:623:24)
    at flow (/Users/leibovic/code/wiki-near-me/node_modules/vinyl-fs/node_modules/readable-stream/lib/_stream_readable.js:632:7)
    at DestroyableTransform.pipeOnReadable (/Users/leibovic/code/wiki-near-me/node_modules/vinyl-fs/node_modules/readable-stream/lib/_stream_readable.js:664:5)
    at emitNone (events.js:80:13)
    at DestroyableTransform.emit (events.js:179:7)
    at emitReadable_ (/Users/leibovic/code/wiki-near-me/node_modules/vinyl-fs/node_modules/readable-stream/lib/_stream_readable.js:448:10)

After running npm install eslint-plugin-react, this error goes away, but I run into another issue:
[leibovic@margaret-mbp:~/code/wiki-near-me]$ gulp
[10:22:39] Requiring external module babel-register
(node:68287) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
[10:22:40] Using gulpfile ~/code/wiki-near-me/gulpfile.babel.js
[10:22:40] Starting 'clean'...
[10:22:40] Finished 'clean' after 11 ms
[10:22:40] Starting 'default'...
[10:22:40] Starting 'styles'...
[10:22:41] styles all files 3 kB
[10:22:41] Finished 'styles' after 1.71 s
[10:22:41] Starting 'lint'...
[10:22:41] Starting 'html'...
[10:22:42] Starting 'scripts'...
[10:22:42] Starting 'images'...
[10:22:42] Starting 'copy'...
[10:22:42] 'lint' errored after 541 ms
[10:22:42] ESLintError in plugin 'gulp-eslint'
Message:
    Definition for rule 'react/jsx-quotes' was not found
Details:
    fileName: app/scripts/main.js
    lineNumber: 20
[10:22:42] 'default' errored after 2.25 s
[10:22:42] Error in plugin 'run-sequence(lint)'
Message:
    lint stream
[10:22:42] html basic.html 1.32 kB
[10:22:42]
app/scripts/main.js
  20:1  error  Definition for rule 'react/jsx-quotes' was not found  react/jsx-quotes

app/scripts/sw/runtime-caching.js
  24:1  error  Definition for rule 'react/jsx-quotes' was not found  react/jsx-quotes

✖ 2 problems (2 errors, 0 warnings)

[10:22:42] html index.html 14.98 kB
[10:22:42] html all files 16.3 kB
[10:22:42] scripts all files 1.32 kB
[10:22:42] Finished 'html' after 587 ms
[10:22:42] Finished 'scripts' after 486 ms
[10:22:42] images all files 7.39 kB
[10:22:42] Finished 'images' after 481 ms
[10:22:42] copy all files 45.8 kB
[10:22:42] Finished 'copy' after 368 ms

This was an issue with an upstream dependency at one point but should be resolved with eslint itself. Can you try npm install --save-dev eslint eslint-plugin-react against WSK and see if that fixes things?

This works fine with a fresh install of web-starter-kit 0.6.4. Thanks for taking a look!


Update yap.rb

Added patch to make stable version compile again.
Updated devel version.
Added HEAD version.
Dependencies and brew options still need improvements, but this should be a good start to get yap out of the boneyard.

Closing as we've deprecated Homebrew/boneyard but thanks for the PR anyway!


Update cycles to reset battery doesn't work as expected

Describe the bug
Sometimes battery energy counters reset before update count reaches the "Update cycle to resets" value.
In debug log, only 5 pool cycle with "Battery Export Energy went backwards: 0 < 242478" exist, while in integration settings threshold set to "40".
In past, i can see up to 11 cycles without reset in logs, so it looks like this floating bug and possible somehow related to ModBus connection error just before that.
Expected behavior
Energy counters should be reset only after reach "update cycle to resets" threshold.
Screenshots

Diagnostic File
config_entry-solaredge_modbus_multi-dd1018dc8fc1c298fc03bc4e7311a826.json(2).txt
Logs
2023-07-14 09:44:08.713 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 16.244 seconds (success: True)
2023-07-14 09:44:08.720 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.sensor] Battery Export Energy went backwards: 0 < 242478
2023-07-14 09:44:08.720 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.sensor] Battery Import Energy went backwards: 0 < 246965
2023-07-14 09:44:08.722 WARNING (MainThread) [homeassistant.components.utility_meter.sensor] Utility B4 Energy Export received an invalid new state from sensor.solaredge_b1_energy_export_3 : unknown
2023-07-14 09:44:08.722 WARNING (MainThread) [homeassistant.components.utility_meter.sensor] Utility B4 Energy Import received an invalid new state from sensor.solaredge_b1_energy_import_3 : unknown
2023-07-14 09:44:23.469 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 30
...
2023-07-14 09:44:27.662 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 4.192 seconds (success: True)
2023-07-14 09:44:27.666 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.sensor] Battery Export Energy went backwards: 0 < 242478
2023-07-14 09:44:27.666 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.sensor] Battery Import Energy went backwards: 0 < 246965
2023-07-14 09:44:42.471 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 30
...
2023-07-14 09:44:47.321 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 4.850 seconds (success: True)
2023-07-14 09:44:47.325 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.sensor] Battery Export Energy went backwards: 0 < 242478
2023-07-14 09:44:47.325 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.sensor] Battery Import Energy went backwards: 0 < 246965
2023-07-14 09:45:02.469 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 30
...
2023-07-14 09:45:05.972 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 3.503 seconds (success: True)
2023-07-14 09:45:05.976 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.sensor] Battery Export Energy went backwards: 0 < 242478
2023-07-14 09:45:05.976 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.sensor] Battery Import Energy went backwards: 0 < 246965
2023-07-14 09:45:20.470 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 30
...
2023-07-14 09:45:24.170 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 3.700 seconds (success: True)
2023-07-14 09:45:24.174 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.sensor] Battery Export Energy went backwards: 0 < 242478
2023-07-14 09:45:24.174 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.sensor] Battery Import Energy went backwards: 0 < 246965
2023-07-14 09:45:39.469 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 30
...
2023-07-14 09:45:42.946 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 3.476 seconds (success: True)
2023-07-14 09:45:57.469 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 30

Debug Logs
home-assistant_solaredge_modbus_multi_2023-07-14T19-17-56.636Z_trimmed.log
Home Assistant (please complete the following information):

Home Assistant Core Version: 2023.7.1
solaredge-modbus-multi Version: v2.3.5-pre.1
Installation Type: HACS

v2.3.5-pre.1 will not be developed; change to v2.4.0-pre.1

Do you think problem would not reproduced with 2.4.0-pre.1 version? I don't see any changes for this feature in release notes and commits.

I can add cycle count to the debug log, otherwise I'm not sure why it wouldn't go the full count unless the integration was reloaded or HA restarted. Cycle count can't persist across an integration reload or restart though. Also remember that changing options for an integration causes HA to reload that integration, which will clear the internal count as well and start it from values read at integration startup.
Any work I do now will be based on the 2.4.x releases, there will not be a v2.3.5 release and no more fixes or updates to any 2.3.x releases.

otherwise I'm not sure why it wouldn't go the full count unless the integration was reloaded or HA restarted. Cycle count can't persist across an integration reload or restart though.
HA or integration was not restarted, and settings wasn't changed also, but there is errors with connection refused probably caused by internal solaredge inverter bugs and multiple tracebacks exists in debug recently before that.

Connection error should not be able to reset the cycle counter, which is internal to the entity.
At this point the only thing I can do is add more debug logging so I'll do that under a pre-release.

Thx, i'll keep an eye on next updates and left debug always on in case this problem repeat again.

I'm trying it in my modbus simulator first, if there's something obvious to fix.

Release v2.4.0-pre.2 contains the additional debug logging for battery energy reset cycles.

I was not able to duplicate any issues with my simulator and the cycle counter was maintained across inverter communication failures.

Hello, I checked code and did not found any reset for variable self._count when modbus counter report normal value and doesn't went backwards. Look like variable resets to zero only at integration init and always increasing until reach reset cycle limit? I think this is the reason, the counter has a cumulative effect from the previous wrong values reported by the inverter since integration/ha restart.

Sure, I can make it set the count to 0 on normal value.

Fixed in Release v2.4.0-pre.3


Several questions after implementing

Having just implemented support for notifications in CSS, I thought it might be interesting to share any thoughts and questions I had. Wasn't sure what the best way was, so feel free to split this up over new/other issues should some of it be relevant there.
While not explicitly stated every time, most questions have as additional goal to make the answer be part of the specification, because otherwise clients can't depend on that being the case.
Which events
I understand the specification wants to be general to allow many kinds of notifications,
but I do think it would help if there was a more extensive description of specific notifications,
while allowing server to expand upon this.
Because now a server can fully support the notification spec without ever actually sending out a notification.
The CSS implementation has the Create/Update/Delete activities. In the case of Delete there already was the issue that there is no state field to send along since the resource no longer exists, so that would break with the required data model from the spec.
Which permissions
Similar to the above, clearer guidelines would help there, as I see the editor's draft is going to remove the requirement to have Read permissions.
An additional issue is how to handle changing permissions on a resource. Is the server expected to do something then? Specifically, a user has Read permissions on a resource and subscribes to receive notifications on that resource. Afterwards, someone changes the ACL so they lose those permissions. But since authorization is only checked when subscribing they will still keep receiving notifications (until the subscription expires).
What to return on GET/HEAD/OPTIONS

Servers MUST accept GET, HEAD and OPTIONS requests targeting the subscription resource.

I actually missed this while implementing so the CSS version currently would not conform to that,
but what exactly should a server return as a response to those requests? The same as what was found in the resource used to discover it?
Accept feature
What exactly is the reason for this feature to exist? It feels like this is a very specific feature and most clients would be fine with just JSON-LD.
There is no way to advertise for a server which values it accepts for this field. It is also not clear when the server should error if the format is unsupported.
State feature
What activity should be used when sending out this notification? Since it's not really something that happens but just a status update. Unless the last activity that was sent out needs to be used. An additional issue is if in the meantime the target resource was removed, since it doesn't have a state then. Or the reverse, the client does not have a state value since the resource didn't exist yet when they checked, but want to receive the state notification if in the meantime it was created.
For the WebSocket implementation we send out a notification the first time a WebSocket connection is made for that subscription. But what in the case of, for example, WebHooks? Should it immediately be sent out? Can it be sent out before the server even sent its response as an answer to a subscription request (because during processing the request it notices it should send out a state notification)?
JSON-LD context
Since the https://www.w3.org/ns/solid/notification/v1 context does not exist yet, I created one internally for the server. But is it possible to create a context so that the state/rate/expiration strings in the JSON-LD discovery example are actually interpreted as URIs? The only way I could get that working is if they were prefixed.
JSON-LD discovery
There already is an issue about the JSON-LD format so won't go into that. An additional confusion is how the JSON-LD response should look like when targeting the storage description resource for discovery. Depending on the other contents in that document, it might just be impossible to have the expected format as shown in the spec, since an @graph statement might be necessary if other resources are also described in there.

FYI https://github.com/solid/vocab/pull/62 includes a draft of JSON-LD context

Thank you for implementing and providing feedback. Please note that there had been a number of changes since Version 0.1.0. See http://solid.github.io/notifications/protocol#change-log of the ED that's. Version 0.2.0 publication is currently pending approval in solid/specification. Most of the changes are data model related, and some clarifications on the discovery path, along with request to publish the Notification vocabulary and the JSON-LD context.
In https://solid.github.io/notifications/protocol#classes-of-products you'll note specific groups of conforming implementations. We're gathering feedback here on implementations for now: https://github.com/solid/notifications/issues/141 . Please update the table as you see fit for CSS or other implementations that you are aware of, or let me know, and I can.
I'll follow-up with updates based on the following:

it would help if there was a more extensive description of specific notifications

Noted.

Because now a server can fully support the notification spec without ever actually sending out a notification.

I suppose. It just means it is not particularly useful. The NotificationSender always has that right - to send notifications at its own discretion. Although, that's beside your main point, we can clarify this.

there is no state field to send along since the resource no longer exists, so that would break with the required data model from the spec.

state is one of the optional #notification-features, and even when the #NotificationSender supports the feature, it is not required to be part of the notification-message. As you say, in some cases, it needs to be left out and this is covered by definition.

An additional issue is how to handle changing permissions on a resource.

Good consideration. A Note will help here.

what exactly should a server return as a response to those requests?

Updated to emphasise that #subscription-resource is described with the #subscription-resource-data-model .

It feels like this is a very specific feature and most clients would be fine with just JSON-LD.

I generally agree with respect to concrete RDF syntaxes. It may be useful for notifications that are preferable in other formats. However, that's still problematic considering that the #notification-message-data-model requires specific RDF vocabularies, so not sure if/how realistic it'd be to expect that to conform in non-RDF formats. Having said that, the feature can be dropped if there isn't sufficient implementations - I'd be in favour of dropping it.

It is also not clear when the server should error if the format is unsupported.

It need not error. #NotificationServer will take the suggestion into account.

State feature

Optional feature. At the moment it seems that it can be used with a single topic resource, but multiple topic resources doesn't seem well represented with a single (unstructured) value. Features may be used in any notification, but may not necessarily be applicable for each #notification-channel-type. Having said that, state is still under further discussion. We need more implementation feedback, such as yours.

For the WebSocket implementation we send out a notification the first time a WebSocket connection is made for that subscription.

Notification onopen socket / connection established is not defined in the spec, so not required. But out of curiosity, can you share an example of that notification?

JSON-LD context

Current vocab/JSON-LD context proposal is here: https://github.com/solid/vocab/pull/85 . For example, state in JSON-LD context is defined with http://www.w3.org/ns/solid/notifications#state.

JSON-LD discovery

The expectation in the #description-resource would include a statement where a subject has notify:subscription or notify:channel properties. Would the graph matter? In the case where the subject is the storage resource ( https://solidproject.org/ED/protocol#storage-resource ) , we'd see subscription/channel properties. Ultimately a subscription-request could use a different value for topic - I think this applies to the storage resource where the topic resource is one of the resources in the storage. In the describedby case, the topic is more likely to be the same as the subject resource that advertises describedby.

Thanks for the extensive reply. I might have more comments after going through the 0.2 specification and updating the CSS implementation accordingly, but this issue can be closed for me if there is no further discussion.

But out of curiosity, can you share an example of that notification?

The format would be the same as any other notification. At the time the socket is opened we check the status of the resource. If it exists we send out an Update notification, if it does not we send out a Delete notification.

Current vocab/JSON-LD context proposal is here: solid/vocab#85 .

I learned something new about how to write JSON-LD contexts since that does indeed fix my problem.


Restrict template literal interpolation expressions to strings

Search Terms
"template literal"
There are many hits, some which seem related, but everything I could find was a much bigger ask or wider in scope
Suggestion
Add a compiler option to enforce using only strings in ES6 string template literals
Use Cases
When using string literals, any variables are coerced to strings, which can lead to undesirable behavior.
As far as I can tell there's no way to avoid this behaviour. In the spirit of tying everything, I'd prefer that only actual string types are permissible for use in string templates to avoid accidental coercion by passing null, undefined or object types that may have unexpected string representations, and force users to explicitly convert them to strings.
Examples
For example:
function formatName(name: string | null): string {
   return `Name is: ${name}`;
}

formatName(null)  === "Name is: null"

Ideally the compiler would fail  since name can be null.
Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

So `Step ${i} of ${count}` would have to be written as `Step ${i.toString()} of ${count.toString()}`?
I actually think this is a context where coercion to string is clearly expected, and it makes template literals easier to read and work with.
If you want the build to fail if name is null, then why in your example is name explicitly nullable? Perhaps the example could be clearer to show a compelling situation.
If its just about output format, you could write something like return `Name is: ${name || 'not supplied'}`;.

This is a contrived example; obviously I wouldn't write a function like this. In real work, we deal with complex data structures that have many fields of differing types. We process data that is far removed from its type definitions. That's the whole point of static typing.
While I wouldn't write a function so narrowly purposed that allowed null, of course, but I might have a React component that takes a lot of props, some of which can be null or are optional, but I will still eventually use string templates to format data involving those fields.
The point of type safety is to protect you from mistakes. If people always correctly grokked the type of every variable they used in practice, then we wouldn't need typescript at all. But people don't. I might have a structure:
type Name = {
   firstName: string;
   lastName?: string;
   middleName: string;
   address: Address;
}

If I did this:
const info = `${data.firstName} ${data.middleName} ${data.lastName} lives at ${data.address}`

I get
"Joe undefined Blow lives at [Object object]"
This would be a very easy mistake to make.
Personally, there's never a time when I want type coercion. I don't see why this is a place you'd want it. any more than you'd want it when assigning anything else to a variable of type string.

Regarding this:
So `Step ${i} of ${count}` would have to be written as `Step ${i.toString()} of ${count.toString()}`?

I'd be fine with this - thought I'd probably say  Step ${String(i)} of ${String(count)}
But I think it would also be reasonable to accept both number and string types, and perhaps boole , since their string equivalent is well defined and purposeful.
But I would never want null, undefined, or object.

I agree that implicit coercion of null, undefined, and object types to string is almost always an error in the code. But even then there are exceptions - such as when the object defines its own toString method, or when the template literal is tagged.

I also agree that there can be situations where you intentionally want to do that. But in practice, mistakes happen far more than those use cases.
I'd much rather say address.toString() if I really wanted that, then have no type checking for any string templates, just like I would have to anywhere else in my code that I wanted to convert address to a string.
Refactoring is really where it becomes a killer. When I went through the exercise today of having to manually inspect every bit of code that consumed the structure I'd refactored, and also wondering if there were any derived usages I missed, it felt like a big hole.

The core problem here is that people add custom toString methods with "good" output with reasonable frequency. The "real" solution would be a way to mark either blessed or cursed toString methods so that e.g. we can detect that Object#toString is a bad call but MyCustomPointWithNiceToString#toString is a good call.

The usage of good toString() seems like it is in conflict with general good practice in typescript. You can't do this:
let x: string = '';
x = someObjectThatHasToString;

You'd have to say:
x = someObjectThatHasToString.toString()

I don't see why you'd want to treat string templates any differently as part of a comprehensive static typing system. This is the only place you're allowed to not explicitly call toString() in order to get the output of that method in typescript.
I don't really like "toString()"  anyway as part of production code - while it's handy for console logging or debugging, I wouldn't want to use it for real output. Overriding the generic method   provides engineers with no information about what's actually being output for the object.  Anything that's not trivial almost certainly has more than one possible format in which it's output could appear, so I think it's much better to use expressive names for string formatting methods.
Again - I'd much rather be required to explicitly invoke a method when using an object in a string template. In my perfect TypeScript world there's no "good" toString
I certainly understand some people might feel differently, but at the same time I think the notion of being able to disable coercion for string templates has value and would benefit users who prefer better type safety over convenience.

Here's something else interesting related to this. In designing classes, we'd actually like to forbid the use of string coercion. It seems like this should be possible:
class Foo {
  private value: string;
  constructor(value: string) {
    this.value = value;
  }
  toString(): never {
    throw new Error();
  }
  toNamedFormat(): string {
    return this.value;
  }
}

const foo = new Foo('abc');
const x = `foo is ${foo}`;

But TypeScript has no problem with this. Probably I just don't understand the totality of how never works. Is there any way to create a method with a return type that would be forbidden by string templates?

I ran into this with something like:
console.log(`Name is ${name}`);

Name was not defined in my scope, but in lib.dom.d.ts it was defined as:
declare const name: never;

So my code compiled but at runtime I got:
ReferenceError: name is not defined

Result: https://github.com/firebase/firebase-tools/pull/1241

We had a similiar issue. We have split shared code into libs, which are used in several services. Every lib is used in at least 2 services. Someone expanded an interface, replacing a string with an object.
In our code we used a string template like this \Foo ${bar}`, where barchanged to an object. So what I expected was, that the compiler throws an error. Instead we had anobject Objectin production. I think, if you have a customtoString` method, it's okay to call it in this context instead of intransparently breaking code.

on node:
const moment = require( 'moment' );
console.info( `show: [${ moment.utc() }]` )

//output: 'show: [Wed Oct 30 2019 11:30:00 GMT+0000]'

on ts-node:
const moment = require( 'moment' );
console.info( `show: [${ moment.utc() }]` )

//output: 'show: [1572435290801]'

But If you use "target": "es2015" then you will have native template literals
how to change this behavior on other target?

I've also run into some frustration with this. Not only with template strings, but similarly with the + operator. 'hi ' + {} does not complain.
One possible solution would be to add a way to disable implicit coercion on individual types defined in TS (as opposed to native ones)? Just a thought.

Just hit this issue myself. It's very easy to start relying on the compiler to catch silly stuff, and miss something inane like forgetting to call a function; it even made it through review unnoticed.
In my case, our CI acceptance tests were failing with a very peculiar looking output... turns out the template literal was coercing a function, per the above.
If you've got the following:
const fn = (): string => 'a string';
const x = `/blah/blah/${fn()}`;

And you forget to call fn, instead interpolating ${fn}, the compiler really should flag it up. I'd posit it's far more likely to be accidental than not, and if someone really wants to toString their function for some reason - surely a very rare use case? - then they can always do so manually.
In terms of safety, flexibility, and being as helpful as possible to as many developers as possible, I think this warrants a fix.

I need this too

typescript-eslint has a restrict-template-expressions rule to catch this

This is also a problem for us where we have a lot of methods and getters for building template literals. If the arguments are omitted we get runtime errors. Following is my naive attempt:
const neverString =
    <T extends (...args: any[]) => any>(fn: T) =>
        fn as T & { toString: never };

let f = neverString((x: number) => `${2 * x}`);

`${f(5)}`; // OK as expected
`${f.toString()}`; // Error as expected
`${String(f)}`; // OK - should be error
`${f}`; // OK - should be error

This seems to me like one of the weakest links in TypeScript's type system – in the weak–strong sense related to the presence and semantics of implicit type coercion (not static–dynamic, explicit–inferred, expressive–inexpressive or any other type-system-defining dimensions that are often confused with each other or used ambiguously).
What often happens for me in practice is this:
text.ts:
export default {
    url: `https://example.com`,
} as const;

main.ts:
import T from "./text";

console.log(`Your URL: ${T.url}`);

Then I refactor/add a new feature/whatever such that text.ts looks like this instead:
export default {
    url: (user: string) => "https://example.com/" + user,
} as const;

Or perhaps this:
export default {
    url: {
        external: "https://foo.bar",
        profile: "https://example.com/" + user,
    },
} as const;

main.ts now prints something like Your URL: user => "https://example.com/" + user or Your URL: [object Object] – and the type checker doesn't help me to detect this at all, even though it could have. Especially when looking at this from a Haskell perspective, I really expect a type error, as I'm used to being protected against implicit and/or nonsensical stringification in that language:
$ ghci
> "" ++ id

<interactive>:1:7: error:
    • Couldn't match expected type ‘[Char]’ with actual type ‘a0 -> a0’
    • Probable cause: ‘id’ is applied to too few arguments
      In the second argument of ‘(++)’, namely ‘id’
      In the expression: "" ++ id
      In an equation for ‘it’: it = "" ++ id

> "" ++ show id

<interactive>:2:7: error:
    • No instance for (Show (a0 -> a0)) arising from a use of ‘show’
        (maybe you haven't applied a function to enough arguments?)
    • In the second argument of ‘(++)’, namely ‘show id’
      In the expression: "" ++ show id
      In an equation for ‘it’: it = "" ++ show id

(GHC even points out the actual cause of the problem in these cases, namely that I haven't applied id.)

I would extend this suggestion to also include string concatenation with the + operator.
That said in addition to the rule @ark120202 mentioned, this ESLint rule that specifically handles objects without a meaningful toString() method in both template literal and + operator cases exists:
https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-base-to-string.md

I'd like to add a much worse example of this:
let a = ["one", "two"];

let s = `<ul>` + a.map(v => `<li>${v}</li>`) + `</ul>`;

It's not immediately obvious that there's anything wrong with this code, and TS doesn't think so either.
The rendered result, however, includes commas between the <li> elements, because I forgot to .join("") the array.
I was quite surprised that this is allowed in the first place? While arrays and objects are capable of coercion via toString(), an array or object is not a string, and these coercions rarely result in anything meaningful. (notable exception may be number)
I would propose adding a new compiler option to prevent implicit object to string conversions - and consider making it default for strict mode.
I think there's an inspection for this in ESLint? I don't use ESLint and haven't felt the need - since I've decided to use TS for type-hecking, it would be nice if I didn't need additional tooling for something that is essentially just a type-check.

@mindplay-dk

I think there's an inspection for this in ESLint?

There is! In fact, there are two that can cover it: @typescript-eslint/restrict-template-expressions is the most directly applicable rule, but @typescript-eslint/no-base-to-string also covers it. It would be nice to have this built into TS itself, but doing it in ESLint works quite well, too.

I've decided to use TS for type-hecking

Mood.

Heck, I might even use it for type-checking.

I just fixed an annoying bug that would have been caught by this. I was doing string interpolation to construct an URL in CSS. I can't imagine anyone ever intends to load url(undefined). Thanks @Peeja for the eslint rule links.

If you want a workaround here using TypeScript, here's a function:
function s (strings: Readonly<string[]>, ...values: Readonly<string[]>): string {
  let str = ''
  let i = 0
  for (; i < values.length; i++) {
    str += strings[i]
    str += values[i]
  }

  return str + strings[i]
}

s`${undefined}` // => Argument of type 'undefined' is not assignable to parameter of type 'string'.

I agree this behavior should be some sort of tunable strict option for the compiler. You can special case number but you know what I don't want to display to end-users? 1.7976931348623157e+308 or NaN.

I would not want to limit it to strings.
I would just want to ban undefined and any object that has not overridden the default .toString()
If an object has overridden the default toString(), then it's fine for template literals, and concatenation.
for objects:
shouldBeAllowed = objectInQuestion.toString !== {}.toString

since there was a shortage of good motivating examples at the beginning of this thread:
async function get_f() {
    return "f";
}

(async function main() {
    const f = get_f();  // oops, forgot the `await`

    const oo = "oo";

    const foo = f + oo;  // or `${f}${oo}`

    console.log(foo);  // [object Promise]oo
})();

It's obvious that it's a type error where someone just forgot to await the promise.

@beauxq How does that need a template?
const f = get_f();  // oops, forgot the `await`

It's obvious that it's a type error where someone just forgot to await the promise.

That's what a linter is for.

@beauxq How does that need a template?

Did I suggest that anything needs a template.

That's what a linter is for.

It's a type error. That's what a static type analyzer is for. This is the first thing on the list of TypeScript design goals.

It's obvious that it's a type error where someone just forgot to await the promise.

It's perfectly valid and reasonable to use promises without async/await sugar. The problem is coercion.

It's perfectly valid and reasonable to use promises without async/await sugar. The problem is coercion.

That's correct. In this example, it's obvious that it's a type error where someone just forgot to await the promise. And the coercion is the reason the type error isn't found.

In this example, it's obvious that it's a type error where someone just forgot to await the promise.

No, because the Promise value could have been (intended to be) used somewhere else. It's too presumptive and prescriptive to pin the problem on the lack of await.

No, because the Promise value could have been (intended to be) used somewhere else. It's too presumptive and prescriptive to pin the problem on the lack of await.

No one is "pinning the problem on the lack of await". You're not reading the sentence that I've already posted twice so that you can read it more carefully. I have always been completely aware that a promise can be intended to be used without await.

When I created this issue I tried to show a common cases involving coercion, but out of context it's easy for them to be dismissed as contrived. I think the promise one is good, but maybe slightly confusing also because of the lack of context?
There are really two separate issues, though, that I don't think I thought through when I initially made the issue and probably should be considered separately. One is coercion of non-string values such as null and undefined, and possibly numbers and booleans, in a string-only context. It think there's room for debate about whether these should be automatically coerced. My preference remains that "null" and "undefined" at least should not be; I'd prefer having to wrap something in String() then not being able to write code that's guaranteed to only handle strings.
The other is the automatic use of native toString() method. This is the case with Promise objects, as well as anything that inherits Object.prototype. Promises have a toString() method that returns "[object Promise]".  POJOs return "[object Object]". This is almost never what you want, and I don't think a type checker should ever allow use of the native toString() method in a string context.
There are good linting solutions to this problem now, so honestly I don't care as much as I did 3 years ago, though I do still think it's within the goals of Typecript to forbid this usage, and I also think it's more consistent with typechecking in other contexts.
-- toString() is not automatically used when assigning something to an existing string variable
-- toString() is automatically used when concatenating strings, or within string templates
To me, this is inconsistent and confusing.
Examples:
class Thing {
 count(): number { ... }
}

const thing = new Thing();
// not what you wanted
console.log(`The count is: ${thing.count}`)
> "count() { return 2 }"

// correct
console.log(`The count is: ${thing.count()}`)

let bar: string=""
bar = thing.count;
// Type '() => number' is not assignable to type 'string'.ts(2322)

bar = "" + thing.count;
// no problem here!

I'd just like to mention that code examples become more readable with syntax highlighting. :slightly_smiling_face: It's easy to achieve in Markdown:
```ts
console.log("Hello, World!")
```

Result:
console.log("Hello, World!")

This is a common source of bugs for us - and Typescript seems like the right place to be preventing them.
I really hope that the Typescript team implement this and #42983 with a compiler flag to enable it.

I found a temporary workaround with Typescript v4.0.3 using Tagged templates.
export function s(strings: TemplateStringsArray, ...values: string[]): string {
  return strings.reduce(
    (result, string, index) => result + string + (values[index] ?? ""),
    ""
  );
}
let myString = s`hello world ${123} yo ${"lo"}`;
console.log(myString)

The above code will yield the following error:
temp.ts:7:32 - error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'.

7 let myString = s`hello world ${123} yo ${"lo"}`;
                                 ~~~

This works because the type of ...values is restricted to string[].
The downside however is of course you have to import s and tag it with every template literal in the codebase.
Nonetheless, that can be automated using the Typescript parser found in Typescript ES Tree.
I'm not going to give every detail about the automation as it can be too lengthy. Let me know if you're interested.

Why even bother with this rule?

Why even bother with this rule?为什么还要打扰这个规则？

Why even bother with this rule?

A string variable is interpolated. You refactor and it's now something else. You almost certainly want to change how it's being interpolated, but the compiler doesn't flag it.
So, the same as why (among other reasons) you want static type safety everywhere else.

Why even bother with this rule?

A string variable is interpolated. You refactor and it's now something else. You almost certainly want to change how it's being interpolated, but the compiler doesn't flag it.
So, the same as why (among other reasons) you want static type safety everywhere else.

What I understand is that I'm refactoring the variable, but when I use a template string, it should be forced to be converted to string now. Can you give me an example in response to what you said?

What I understand is that I'm refactoring the variable, but when I use a template string, it should be forced to be converted to string now. Can you give me an example in response to what you said?

This thread already includes many examples, have you read it from the beginning? The central purpose of TypeScript, at a very high level, is that we want to prevent "forcing" conversion of one type to another and allow engineers to require such conversions to be explicit.

What I understand is that I'm refactoring the variable, but when I use a template string, it should be forced to be converted to string now. Can you give me an example in response to what you said?

This thread already includes many examples, have you read it from the beginning? One of the central purposes of TypeScript, at a very high level, is that we want to prevent "forcing" conversion of one type to another and allow engineers to require such conversions to be explicit.

Have read it from the beginning, but not very carefully. I ran into a problem as follows:
types/index.ts
export type Params = Partial<{
  questionnaireId: string
}>

components/chat-page/test.tsx
import {FC} from 'react'

import {Params} from '@/types'

interface IProps {
  params: Params
}
const Test: FC<IProps> = props => {
  const {params} = props
  if (!params) return null
  if (!params.questionnaireId) return null
  const url = `xxx${params.questionnaireId}}`
  return <>{url}</>
}

export default Test

The error is reported as shown:

In this case, the string has already been inferred, so why is there an error?

Have read it from the beginning, but not very carefully. I ran into a problem as follows:

Please read it carefully if you want to understand this proposal.

In this case, the string has already been inferred, so why is there an error?

It's really not possible to know why the lint rule isn't working as expected without further context including your eslint and tsconfig files, typescript version, and so on. This exact same example works fine for me trivially.
More generally, though, this is not a support forum. You might try asking this question on stack overflow.

Have read it from the beginning, but not very carefully. I ran into a problem as follows:

Please read it carefully if you want to understand this proposal.

In this case, the string has already been inferred, so why is there an error?

It's really not possible to know why the lint rule isn't working as expected without further context including your eslint and tsconfig files, typescript version, and so on. This exact same example works fine for me trivially.
More generally, though, this is not a support forum. You might try asking this question on stack overflow.

You're right. Thank you.

In template literal types, interpolations are required to be string | number | bigint | boolean | null | undefined:
type A = `before${unknown}after` // error
type B = `before${string | number | bigint | boolean | null | undefined}after` // ok

If a compiler option to require using only strings in template literal interpolations feels too restrictive, perhaps the compiler option could instead require string | number | bigint | boolean | null | undefined, which should catch most mistakes and would nicely align the rules for type-level and value-level literals.

Some URLs here are broken.
The related typescript-eslint solution URLs are below:
https://typescript-eslint.io/rules/restrict-template-expressions/
https://typescript-eslint.io/rules/no-base-to-string/


chore(main): release 1.1.2

:robot: I have created a release beep boop
1.1.2 (2024-08-20)
Bug Fixes

main package.json field (b80330d)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v1.1.2
:sunflower:


Unable to open large files (543 MB)

VSCode Version: Code 1.6.1 (9e4e44c19e393803e2b05fe2323cf4ed7e36880e, 2016-10-13T16:21:53.542Z)
OS Version: Windows_NT ia32 10.0.14393
Extensions: ms-vscode.csharp-1.4.1

Steps to Reproduce:

I wanted to compare two .reg files (exported registry files. One file was 400+MB other file 500MB+
I'm only be able to open it in Visual Studio 2015 and run the Tools.DiffFiles (which takes ages) but even notepad or notepad++ is unable to open these big registry files (and it is only 556 848 KB).

Erm, half a gigabyte is not "only", I'm surprised you've found a single program capable of opening it, really. All Shakespeare writings should take around 5 394 968 bytes so you could fit it 100 times in your file! ;)
Sources:
http://www.opensourceshakespeare.org/stats/
http://www.wolframalpha.com/input/?i=average+english+word+length

We are 2016, not 1616.

It is not so unusual to have such big files.  I'm not talking about 1GB or more data files.
If we could not open these big files on Windows XP or Vista, I would agree. We can send space crafts to mars but unable to open a 500MB file.

Have you tried using software specifically made for comparing files, especially command line based ones? They have far less things to worry about than doing-it-all tools like VSCode or Npp.

Comparing the files was optionally. the ticket I've created is about the first step, opening a file that fails. I didn't create a ticket about the comparing files functionality, only described what I did, or wanted to do, which failed at the first step.)
So more general: VS Code is unable to open big files. and I reported this in the hope either somebody would fix it or give a decent reply on why this is technically not possible instead of talking about Shakespeare or other personal reasons why you don't open big files.
(If you want that people give feedback on a product, just don't start asking why other people want to do something their way or give these b*llshit Shakespeare comments. I just want to open a big file, which is in my eyes not that big. ok?).
I almost starting to regret that I've posted feedback.

@wstaelens Please don't be upset, @wojtekmaj was only trying to help you out with your problem. You have to keep in mind that this is an open source project and the Github issues are not "support tickets" in the classical way, so normal users like you and me chime in to comment on stuff too, they are not all Microsoft representatives. I'm sure your feedback will be heard, no reason to regret anything.
We are all just trying to move this project further down the road because its obvious that its quite a challenge for the VSCode team to keep up with all the open issues here. :)
About the technical limitations when opening big files:
This is not an easy problem to solve. Code editors are build in a way where they need to read the whole file at once and keep it all in memory. If you open 2 files with 500MB each, that would be a full GB of RAM for the file data alone. But unfortunately that's not the final memory size, the editor needs to attach lots of meta data (for example to make things like syntax highlighting possible) that use even more memory.
Even in 2016, it will take too long to open the file and the whole application will freeze or doesn't respond to anything when its open –  at least if you don't massively optimise for such a task.
That's why specialised tools like command line pagers and diff tools are way better at this. For example, they can read files line by line and "throw away" what they already seen, keeping only the information they need. This way they need only a fraction of the memory a code editor would need.

@kaiwood  I understand, but it would be great if VSCode could open big files.
Most people who work with big files have already 8GB or 16GB of ram. They understand that it takes a lot of memory and sometimes they don't care to wait 10minutes before the file is loaded.
Most devs/admins want to keep the amount of tools to install on a pc or server as small as possible. Opening/configuring everything with VS Code is great, but also viewing a log file (yes IIS for example still produces a sh*tload on data ;-) ) is something that happens very often.
Having to install another tool only for this is yet another annoying thing.
So would be great to see this in VS Code.

Absolutely, I'd love to see support for big files too.
I checked the other issues about the topic, looks like the team already have it on their radar if you read the comments here: https://github.com/Microsoft/vscode/issues/9832

Let's track in #9832


VSTS instance name is not used in 'work item show' command, even after instance was given at login

I specified token and instance arguments when logging in, but still I need to specify instance when executing the following command:
vsts work item show --id <some_existing_id>

The argument '--instance' is not specified as a required argument in the help documentation for show command, as seen below:
Command
    vsts work item show : Show details for a work item.

Arguments
    --id [Required] : The ID of the work item.
    --detect        : When 'On' unsupplied arg values will be detected from the current working
                      directory's repo.  Allowed values: off, on.
    --instance -i   : The URI for the VSTS account (https://<account>.visualstudio.com) or your TFS
                      project collection.
    --open          : Open the work item in the default web browser.

Global Arguments
    --debug         : Increase logging verbosity to show all debug logs.
    --help -h       : Show this help message and exit.
    --output -o     : Output format.  Allowed values: json, jsonc, table, tsv.  Default: json.
    --query         : JMESPath query string. See http://jmespath.org/ for more information and
                      examples.
    --verbose       : Increase logging verbosity. Use --debug for full debug logs.

The error message does give advice on how to set default instance.
--instance must be specified. The value should be the URI of your VSTS account, for example: https://<account>.visualstudio.com or your TFS project collection. You can set a d
efault value by running: vsts configure --defaults instance=https://<account>.visualstudio.com. For auto detection to work (--detect on), you must be in a local Git directory
that has a "remote" referencing a VSTS or TFS repository.

However, this does not make the command-line interface very user friendly. Also, I have not found any documentation that advises a user to set a default instance, even though user only logs in to one single instance.

@mjalas Thanks a lot for feedback!
I agree adding this info in the getting started  would have helped.
As you found out from the error message --default instance can be specified, which is why instance is not a required parameter in the command.
If you are inside a git repository path in your terminal, instance, project and repository can also be detected from the git remote url.

@atbagga are the supported default keys documented somewhere? At least I wasn't able to find any that would have included the 'instance' key. The help text for --default option for the configure command only mentioned a couple of keys.

@mjalas Supported default keys are instance, project and output (for output format).
I have raised a PR to add it to help text explicitly and also in docs.
Thanks for your feedback.

@geverghe  Please take a look at this requirement/feedback.
I have taken care of the documentation and help text update.
The other confusion here and in one other reported issue was regarding the use of login instance to be used in commands as default instance since there is single login.
e.g. A user executes -
vsts login --instance  --token
and then expects that the organization url will be auto-detected from login in all future commands.

@mjalas - would the following help-
vsts login --instance --token : this logs you into the instance and checks if there is a default instance. If there is no default instance set, the login instance will be set as default instance. If there is an instance already set, then post login to change is made to defaults.
vsts logout : This will log out the user from all instances. In case a user wants to logout from a specific instance, then use vsts logout --instance.

@mjalas thank you for your contribution!


Strange release number: v4.3.1 > v4.3.2 > v1.4.3 ?

Hi.
is it normal that the latest release be 1.4.3 in releases after 4.3.2?

Oh, you mean the GH releases page? That is quite literally sorted by date tagged, and there isn’t really a way for us to change that AFAICT.
We legitimately had need to release a patch version of the super old 1.x branch a couple weeks ago, and haven’t released a 4.x again since....

No problem! Closing (since it isn’t an issue
per we)...


Base_url_absolute always has the port number

Hi!
Not sure if it is on purpose, but now base_url_absolute always have the portnumber.
I also used to use: $this->grav['uri']->base() but it now displays the port number too.
The only way to have an url without it would be to make it like this:
$this->grav['uri']->scheme() . $this->grav['uri']->host();

Thanks!
Paul

My nderstsnding is that if the port is non standard it should display.  Else not.
@mahagr did fix a bug related to this, but maybe it’s not fixed entirely?

Yeah 80 and 443 shouldn’t be really showing as they are implicit.

age standard port 443 and 80?
cant say for 80 but 443 is displayed on all my install

Looks like it therefore breaks all image which use absolute urls, which prevent sharing with opengraph or twitter metadata.

@mahagr is going to look at it as both djamil and myself are traveling today.

It looks like Uri::init() line 264 does this.

Should be fixed now. The issue was caused by code being moved around, looks like I forgot to add the default port check into the new location.

I'm having the same issue, on my server $_SERVER['HTTPS'] is on, but $_SERVER['SERVER_PORT'] is 80. So the check in hasStandardPort() returns false and the port 80 gets added to the URI.
force_ssl is true in my system.yaml.

@fucx What happens if you turn force ssl off?

Then it doesn't include the port number any more. I could still force TLS through the .htaccess, I suppose?

But in the sitemap (through the plugin with the same name), the port numbers still get included.

This is because of 80 isn't the default port for https.

Which is why the links don't work, since the server isn't serving HTTPS from port 80.

Yes, it looks like a bug. I'll check it out.

Is this still issue for you as I've not been able to reproduce the issue.

I found this ticket as I was searching for an issue I had. It turns out this ticket describes my issue entirely.
I have set up a website for a client in my workplace, which is hosted at one.com. When the website is served over https then canonical tags and any other tag which uses absolute paths includes the port number 80 in the URL. If you want to take a look then you can do so at frankinstituteofsports.com.
I currently have force_ssl set to false, but it was previously set to true. Neither setting fixes this issue.
I contacted one.com about this, because I have not experienced this issue on any of the other instances of Grav we have set up on the host UnoEuro. The engineers from one.com gave me the following response:

We have received updates from our Technical team and confirmed that the plugin tinyseo is generating the meta tags where the value of SERVER_PORT is 80, even if actual URL is working over HTTPS and using the port 443.

You can either fix the PHP script user/plugins/tinyseo/tinyseo.php to use PORT 443 on HTTPS connection, or you can use the following to fix SERVER PORT detection on HTTPS:

if(isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO']=='https') {
$_SERVER['SERVER_PORT'] = 443;
}

I think they misunderstood the role of the tiny seo plugin. While it is true it generates some meta tags, it is not responsible for generating the URL itself as it uses Grav functions to do so ( url(true) ).
If you need me to perform tests of any kind to help you narrow down the issue then please let me know. I am very eager to have this fixed so I can properly enforce SSL on the domain.
Thank you.

Closing due to inactivity and the fact that @Blazeflack told that his issue had already been fixed in #1827

I appear to be having the same issue as @fucx with my site that is also has $_SERVER['HTTPS'] on

I appear to be having the same issue as @fucx with my site that also uses HTTPS, running Grav v1.5.4

Pretty sure this is fixed in 1.6 beta? Can you guys please test that?


Update react-native-drawer-layout-polyfill to 1.3.1

<EMAIL_ADDRESS>fixes a bug which failed to clear interactions meaning that functions invoked through InteractionManager.runAfterInteractions were never called.
For this reason it is currently not possible to do the "render inexpensive component until navigation is done"-trick in a DrawerNavigator.
See react-native-drawer-layout#16

Cc @skeva @satya164

Can you send a PR for that?

Moved to #1716


Add missing submodule

Add a reference to the bootstrap submodule and remove branch.
closes #577

Hey, @stcz , thanks for digging in and finding this archeology sample. It needs to be removed, see #582 .


DOC():Put DEV Parameter in install commands

Normally, Puppeteer is used for development =P

If someone knows what --dev does, they can decide whether or not to use it themselves. If they don't, this could lead to problems for them. Puppeteer isn't exclusively used as a dev dependency.


Replace Poetry with UV

coverage: 29.383% (+0.05%) from 29.329%
when pulling eb7f45512f80f0ef2835e576041bac9d1db5aa12 on feature/replace-poetry
into 7b4769989a45793ca6eb69a8e251ba61b910b15d on main.


Defer websocket connect()

Describe your changes
The start() function of the charge_point could be blocking until a connection timeout occured when connection the websocket for the first time. This change defers the call to the connect() function so that the start() function does not block anymore.
Additionally introduced thread_mutex protecting access to threads of libwebsockets when the ~WebsocketLibwebsockets destructor was called it attempted to acquire a lock for the connection_mutex and joins the websocket_thread . But the websocket_thread runs the client_loop that also requires the lock when calling on_conn_fail, so the client_loop which could result in a deadlock
Issue ticket number and link
Checklist before requesting a review

[x] I have performed a self-review of my code
[ ] I have made corresponding changes to the documentation
[ ] If OCPP 2.0.1: I have updated the OCPP 2.0.1 status document
[x] I read the contribution documentation and made sure that my changes meet its requirements

@marcemmers please have another looks at the recent changes

@marcemmers please have another looks at the recent changes

Hi @marcemmers , we are looking into it and considering some more changes to the WebsocketLibwebsockets class, so you can wait with the review for this one

Closed in favor of https://github.com/EVerest/libocpp/pull/896


File renamed deploy/psp :sa :cassie.yaml

#8 To resolve the git clone issue on windows the file is renamed to
psp-sa-cassie.yaml

@ahmedjami can you rebase from master and push again to correct the pipeline ?

@dharmjit can you rebase from master and push again to correct the pipeline ?

This is done, Thanks

@allamand please merge.


[featureRequest] Rational field as default fielt for model element.

Rational
One of common usecases is to get an answer on the question "Why did we do that?", meanwhile architecture description element documentation could be a heavy large text, while rational itself could be as a link to meeting agenda, analysis document, or just a few words.
Currently it's hard to distinguish between model element description and model element rational by query, it requres additional code to be supplied and hardens document generation.
As well architecture rational is a common part of ISO 42010 Architecture description metamodel, separated from model element.
Do you think it is reasonable to add a separate field to contain "Rational" for model element such as a:

Relationship
View
Concept
Grouping

What you describe is simply one of the use-cases of ArchiMate Language Customization.
We do plan at some point to support a such customization mecanism inline with ArchiMate specifications in Archi, but this if not for the near future. For the moment, I suggest you to look at Herve's specialization plugin which implement something very similar.
As we're not going to implement such "Rational" field outside of this more generic contexte. I'm closing this issue.


[test] add makeStyles playground

Added a little playground for the hook version of @material-ui/styles. This is not meant to be merged. Just here so that potential fixes can be tested against this branch.
Deployed version

@eps1lon Thanks, I will look into it.


Xfce4 panel plugins

Motivation for this change
Update some XFCE plugins
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Needless reformatting doesn't matter, but it hides dropping of one plugin at least – why did you do that?

I picked the other commit at least.


Compatible with the latest RactiveJS version 0.5.x?

@Rich-Harris any chance you could bump stuff here too soon? thanks man

I was also buffled with the callback function used with ractive.set(...) in the example code. First I thought, I missed something in the docs but later realized that callback argument was deprecated and now you can do the same with Promises. @Rich-Harris, if you want I can try to fork it and change the example to work with the latest Ractive.js.


Methods

Current dependencies on/for this PR:

main

PR #3083

PR #3084   👈

This comment was auto-generated by Graphite.


Remove references to "clickhouse.table.name" - not used

"clickhouse.table.name" configuration variable is not used and its confusing to the user, all references should be removed from the code and the documentation.

Fixed in #72


Create integrations.md

Responds to https://github.com/kubecost/docs/issues/630 to create a list of supported OpenCost integrations
Relevant integration/config docs are linked where they already exist. We can work on developing specific integration guides for everything else over time

I'm pretty sure I grabbed every URL from the frontend, not GH. In certain cases (in Kubecost docs), these links direct you to the platform you are currently browsing. ie, browsing docs in GH will link you to more GH docs, but browsing docs in the frontend links you to other frontend docs.

The Vercel preview shows the links going to GitHub, maybe the Kubecost docs work differently when rendered.
https://opencost-website-git-bstuder99-patch-3-kubecost.vercel.app/docs/integrations

Okay, everything's been manually corrected

Thanks!


error.message "expected str"

Hello, if I want to register the Integration, the error message "expected str" appears immediately. What am I doing wrong?
Best regards
Frank

now works now! thanks

just for curiosity -  how did you solve it?


Fixed spacing and typo issues in code comment descriptions

[env]:Fixed spacing and typo issues in code comment descriptions
[FS]:Fixed spacing and typo issues in code comment descriptions

Please remove Gerrit ID

@pkarashchenko  Done.Please review the new commit message, thank you.

Please remove Gerrit ID

@pkarashchenko Done.Please review the new commit message, thank you.

Please remove Gerrit ID

but Change-ID still exist in the commit message.

@pkarashchenko Done.Please review the new commit message, thank you.

Please remove Gerrit ID

but Change-ID still exist in the commit message.

Sry for that and have upload.
Please help to review the new patch, thanks.


Does not work on Mac (DllNotFoundException)

Exception: System.DllNotFoundException: sunvox
  at (wrapper managed-to-native) SunVox:sv_init (string,int,int,int)
  at SunVoxExample1.Start () [0x00019] in /github/SunVox-Unity/Assets/Scripts/SunVoxExample1.cs:33

Unity 2018.2.2f1
macOS 10.13.6
While it certainly works on Windows 8.1 with Unity 2018.2.1f1
Something's wrong with library, I suppose

Hello, thanks for the comment!
Right now there is no opportunity to test for Mac, I hope I can fix it in the next few days.


How to use runhouse on my local server

Please provide example about how to launch runhouse on my local server
Instead of use AWS, GCP cloud etc, I don't have any of these cloud account, but I have  GPU V100 on my local server.
I would like to know how to setup on the server/client sides and how to interactive, I have been trying all examples from:
https://github.com/run-house/tutorials, but none of them worked.
please give more setup instructions and guidances.
Here is what I hit when I was trying to setup on-prem cluster:
$cat rh.py
import runhouse as rh
from diffusers import StableDiffusionPipeline
def sd_generate(prompt):
model = StableDiffusionPipeline.from_pretrained("stabilityai/stable-diffusion-2-base").to("cpu")
return model(prompt).images[0]
gpu = rh.cluster( ips=['<IP_ADDRESS>'],
ssh_creds={'ssh_user': 'htang', 'ssh_private_key':'/home/htang/.ssh/id_rsa'},
name='rh-cluster')
sd_generate = rh.function(sd_generate).to(gpu, reqs=["./", "torch", "diffusers"])
img = sd_generate("An oil painting of Keanu Reeves eating a sandwich.")
print(type(img))
img.save("sd.png")
img.show()
$ python rh.py
INFO | 2023-05-28 04:11:35,284 | Loaded Runhouse config from /home/ytang/.rh/config.yaml
INFO | 2023-05-28 04:11:36,858 | Running command on rh-cluster: ray start --head
INFO | 2023-05-28 04:11:37,663 | Running command on rh-cluster: mkdir -p ~/.rh; touch ~/.rh/cluster_config.yaml; echo '{"name": "~/rh-cluster", "resource_type": "cluster", "resource_subtype": "Cluster", "ips": ["<IP_ADDRESS>"], "ssh_creds": {"ssh_user": "ytang", "ssh_private_key": "/home/ytang/.ssh/id_rsa"}}' > ~/.rh/cluster_config.yaml
INFO | 2023-05-28 04:11:37,773 | Setting up Function on cluster.
INFO | 2023-05-28 04:11:38,044 | Connected (version 2.0, client OpenSSH_8.9p1)
INFO | 2023-05-28 04:11:38,105 | Authentication (publickey) successful!
INFO | 2023-05-28 04:11:38,361 | Running command on rh-cluster: ray start --head
INFO | 2023-05-28 04:11:39,023 | Running command on rh-cluster: mkdir -p ~/.rh; touch ~/.rh/cluster_config.yaml; echo '{"name": "~/rh-cluster", "resource_type": "cluster", "resource_subtype": "Cluster", "ips": ["<IP_ADDRESS>"], "ssh_creds": {"ssh_user": "ytang", "ssh_private_key": "/home/ytang/.ssh/id_rsa"}}' > ~/.rh/cluster_config.yaml
INFO | 2023-05-28 04:11:39,137 | Copying local package scripts to cluster
INFO | 2023-05-28 04:11:39,327 | Installing packages on cluster rh-cluster: ['./', 'torch', 'diffusers']
Traceback (most recent call last):
File "/home/ytang/scripts/./rh.py", line 15, in
sd_generate = rh.function(sd_generate).to(gpu, reqs=["./", "torch", "diffusers"])
File "/home/ytang/.local/lib/python3.10/site-packages/runhouse/rns/function.py", line 119, in to
new_function.system.install_packages(new_function.reqs)
File "/home/ytang/.local/lib/python3.10/site-packages/runhouse/rns/hardware/cluster.py", line 205, in install_packages
self.client.install_packages(to_install)
File "/home/ytang/.local/lib/python3.10/site-packages/runhouse/servers/grpc/unary_client.py", line 59, in install_packages
server_res = self.stub.InstallPackages(message)
File "/home/ytang/.local/lib/python3.10/site-packages/grpc/_channel.py", line 946, in call
return _end_unary_response_blocking(state, call, False, None)
File "/home/ytang/.local/lib/python3.10/site-packages/grpc/_channel.py", line 849, in _end_unary_response_blocking
raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNAVAILABLE
details = "failed to connect to all addresses"
debug_error_string = "{"created":"@1685247106.845643418","description":"Failed to pick subchannel","file":"src/core/ext/filters/client_channel/client_channel.cc","file_line":3134,"referenced_errors":[{"created":"@1685247106.845642647","description":"failed to connect to all addresses","file":"src/core/lib/transport/error_utils.cc","file_line":163,"grpc_status":14}]}"

You're doing it right, for some reason the server is not starting on your remote box. Can you try sshing in and running python -m runhouse.servers.grpc_server and let me know if you get an error?
For the record we actually just totally refactored this flow to make it simpler and more robust, we just haven't released it yet. We're testing it a bit more and will release it shortly.

Thanks @dongreenberg  for the quick reponse,
I tried
python -m runhouse.servers.grpc_server
INFO | 2023-05-28 16:22:02,690 | Loaded Runhouse config from /home/ytang/.rh/config.yaml
/usr/bin/python: No module named runhouse.servers.grpc_server

Hi @htang2012 can you try changing the command slightly to: python -m runhouse.servers.grpc.unary_server?

python ./rh1.py
INFO | 2023-05-29 00:19:14,575 | No auth token provided, so not using RNS API to save and load configs
INFO | 2023-05-29 00:19:20,463 | Running command on rh-cluster: ray start --head
INFO | 2023-05-29 00:19:27,213 | Running command on rh-cluster: mkdir -p ~/.rh; touch ~/.rh/cluster_config.yaml; echo '{"name": "~/rh-cluster", "resource_type": "cluster", "resource_subtype": "Cluster", "ips": ["<IP_ADDRESS>"], "ssh_creds": {"ssh_user": "ytang", "ssh_private_key": "/home/ytang/.ssh/id_rsa"}}' > ~/.rh/cluster_config.yaml
INFO | 2023-05-29 00:19:29,908 | Setting up Function on cluster.
INFO | 2023-05-29 00:19:30,224 | Connected (version 2.0, client OpenSSH_8.9p1)
INFO | 2023-05-29 00:19:30,285 | Authentication (publickey) failed.
INFO | 2023-05-29 00:19:30,294 | Connected (version 2.0, client OpenSSH_8.9p1)
INFO | 2023-05-29 00:19:30,383 | Authentication (publickey) successful!
2023-05-29 00:19:30,384| ERROR   | Problem setting SSH Forwarder up: Couldn't open tunnel :50052 <> <IP_ADDRESS>:50052 might be in use or destination not reachable
ERROR | 2023-05-29 00:19:30,384 | Problem setting SSH Forwarder up: Couldn't open tunnel :50052 <> <IP_ADDRESS>:50052 might be in use or destination not reachable
INFO | 2023-05-29 00:19:30,705 | Connected (version 2.0, client OpenSSH_8.9p1)
INFO | 2023-05-29 00:19:30,809 | Authentication (publickey) failed.
INFO | 2023-05-29 00:19:30,817 | Connected (version 2.0, client OpenSSH_8.9p1)
INFO | 2023-05-29 00:19:30,949 | Authentication (publickey) successful!
INFO | 2023-05-29 00:19:31,205 | Copying local package work to cluster
and hangs

Thanks @dongreenberg, I finally got it working:
here is what I did:
on the server side:

ray start --head
python -m runhouse.servers.grpc.unary_server
runhouse login

Excellent! We're actually about to push a release which will address this exactly.


Proto.Remote 0.33.0 can't talk to 1.1.0

When we upgraded a portion of our servers to 1.1.0 from 0.33.0, we noticed that the two can't communicate with each other anymore.
I believe this is because of the newly added request_id field to PID proto. That should be marked as optional and IMO shouldn't even exist as a part of the proto as it doesn't make sense to serialize that.

As pointed out by Üstün on the slack channel, protobuf3 fields are all optional. So I am not so confident now that it is related to that new field.

This is the call stack I get on the side of the 0.33.0. Looking at the error message and stack trace, it looks like it is because of the PID protobuf struct. I assume when 0.33.0 receives that request_id field, it tries to add it to UnknownFields set, and something goes wrong there which causes this error.

I managed to spot the probem.
i am very confident it is because of this chnage:

This was a part of this commit: https://github.com/asynkron/protoactor-dotnet/commit/af14b118db42292d504bbd10f2d173a08e0987e8
I guess there wont be any easy way to fix this. Next version will either break 1.1.0 compatibility or 0.33.0 older compatibility.
@rogeralsing Are there any plans to put more attention to backwards compatibility, at least when it comes to proto.remote? It should be pretty easy as long as field type-id pairs never change. Because of this issue we are essentially stuck forever with 0.33.0.

Do you have any suggestions on how to describe this to the community in a more clear way?
I know this is not the answer you want, but this is my reasoning up to 1.0:
Do not expect compatibility between alpha/beta versions, the framework design were not set in stone and is evolving.
Going from 0.x to 1.x is a major version bump and signals that the API is not compatible.
From start to 1.0 there have been a lot of protocol changes. e.g. structure of remote protocol, request-id added to PID. changes in cluster gossip protocol etc.
Going forward, API and wire protocol should be compatible for the life span of 1.x.

Because of this issue we are essentially stuck forever with 0.33.0.

Is this due to your deployment model? e.g. are there multiple micro-services that rely on Proto.Remote as the means of communication?

I was incorrectly assuming that Proto.Remote must have been stable.
I think simply having a changelog that includes a "breaking changes" section would greatly help.
Yes, the issue is with our deployment model. We have a group of servers that communicates with another group of servers directly via Proto.Remote. If those two groups of servers can't communicate, the product doesn't work. We can't just restart the first group of servers, as it has stateful connections that last up to 30 mins. So, we do a rolling deployment for those. While at 0.33.0, we could switch to another communication system between those servers, update all, then update to 1.1.0, and switch to Proto.Remote back again for that.
For the second group, we use Proto.Cluster, and we shut those down all at once and bring the new versions back up, so there is no need for rolling deploys there. However, I can imagine many businesses wanting to do rolling deploys for Proto.Cluster instances too.
Maybe making sure that sequential minor versions are compatible with each other when it comes to Proto.Remote would be nice. Endpoints could exchange their version codes upon connection and send the struct that receiving end understands when communicating. I guess the same guarantee could be extended to Proto.Cluster too with a bit more effort.
Feel free to close this issue, I don't think there is an easy and immediate solution to our problem.


Allow for setting of Bayesian priors (pseudocount_base and pseudocount_match)

Right now, the prior parameters pseudocount_base and pseudocount_match are hard-wired into the OpenAuditTool.py code.  It should be possible to modify these parameters on a per-mid basis.


scoreMaker

Add new questions to scoreMaker function using scoring metric developed yesterday. (group project!)

Mob programmed with the whole group!


Merge response types InitResponse, HandleResponse and MigrateResponse into the new Response.

This was done in CosmWasm, let's merge these (now identical) here as well (which will update wasmd as well)

Done in #194


Request for correction of the exception message

https://github.com/timescale/pg_prometheus/blob/c3bf029dfba982c4d4e8c5e327ce7c213ff10200/sql/prometheus.sql#L163
I found a wrong exception message in the function prometheus.insert_view_sample().
My suggestion is like this ...
        RAISE EXCEPTION 'insert_view_sample requires 1 parameter';

@y2sarakawa thanks for reporting this. Can you please create a PR to fix this.

@niksajakovljevic Sorry. I have no authority to agree to the CLA on behalf of my organization yet.
Can anyone make a PR?

No problem. I'll take care of fix it in the next PR.


Fatal error

Shopware: 5.5.2
PHP 5.6
Error at bin/console plentyconnector:backlog:process

The issue was fixed and was a error of exists article translation, because the namespace of the connector was chanced.

This is the pr for this issue:
https://github.com/plentymarkets/plentymarkets-shopware-connector/commit/88d135047aeb051e03bfd0be61bc0acc099f19c6

@sorinpopescu #401 and #399 fixed this behaviour. Does the migration correct your problem or are there still some products with this error?

@jochenmanz - all goes ok now - thanks.
I still have some issues with Prices and Orders - should I open them in a separate tikets?

separate tickets would be perfect, thank you! :)


Can't run main_videosr_deploy_2x3f.py

I can run main_videosr_deploy_4x3f.py and get the results, but I can't run main_videosr_deploy_2x3f.py. The error is:
Testing path: ./data/test/calendar
of testing frames: 0
And I want to ask whether the bellow code is wrong:
def init(self):
self.num_frames = 3
self.scale_factor = 4
def test(self, dataPath=None, scale_factor=2, num_frames=3):
I change the third line to self.scale_factor = 2, but the error is still there.
Please help me, thank you!

It seems that there is no image in that folder.
Please make sure there are png images in  ./data/test/calendar/input2
Sorry for the inconvenience.

@jiangsutx Thank you very much!

Hello， i changed "DATA_TEST" to './data/test/city/input4/' but i got still nothing like that:
Testing path: ./data/test/city/input4/
of testing frames: 0
SR results path: ./data/test/city/input4/_SR_2018-03-23_06-35-05
Maybe there are some solutions?


[clean] reader.tsx around queryParam

proposal to clean queryParam in reader.tsx

Regression in this PR: R2 navigator uses the localhost / <IP_ADDRESS> URL instead of the special URL protocol which isolates per-publication domain.
See:
https://github.com/readium/readium-desktop/pull/513/files#r383369057

Regression fixed in https://github.com/readium/readium-desktop/commit/36fbca41c4307b4a0703164cd9873bc7364d47ea


Wrong documentation about signature calculation

Hello,
I have customers for which I implemented both Signin/SignUp+Product delegation through the old portal. Switching to the new portal breaks it!  You document this:
HMAC(salt + '\n' + productId + '\n' + userId)

and this is indeed how it worked with the old portal. With the new portal, I get a different signature, but if I do this:
HMAC(salt + '\n' + userId + '\n' + productId)

Then I get the same signature. Somehow, the new portal has inverted both variables. Now, since I do not know upfront whether the old or new portal is used by customers (and I should be agnostic of that), I have to do this:
case "Subscribe":
                    signature = Convert.ToBase64String(encoder.ComputeHash(Encoding.UTF8.GetBytes(salt + "\n" + productId +"\n" + userId)));
                    //fallback because of the bug introduced by the new DEV portal which inverts the variables
                    if(signature != Request.QueryString["sig"])
                    {
                        signature = Convert.ToBase64String(encoder.ComputeHash(Encoding.UTF8.GetBytes(salt + "\n" + userId + "\n" + productId)));
                    }
                    break;

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

ID: 1ca841cb-5a8f-ca9a-ec92-d088f43e0401
Version Independent ID: a56f0f32-4fb5-55b5-54d4-d26b39384316
Content: How to delegate user registration and product subscription
Content Source: articles/api-management/api-management-howto-setup-delegation.md
Service: api-management
GitHub Login: @vladvino
Microsoft Alias: apimpm

Hi @stephaneey Thanks for your feedback. We will review and update as appropriate.

@vladvino Any inputs in this ?

@vladvino Just following up again in case missed the previous communication.

@mikebudzynski please take a look.

Thanks for raising this. We'll reverse the order of the parameters in the developer portal code - you can track our progress with the GitHub issue: https://github.com/Azure/api-management-developer-portal/issues/552
ETA of deployment: second half of April.

@mikebudzynski Thanks for the update.
@stephaneey For now I will proceed with closure of this and If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Exporting service and endpoints port attributes

Issue #, if available: Closes aws/aws-cloud-map-mcs-controller-for-k8s#37
Description of changes: Exporting service's Port, TargetPort, Protocol; and endpoint's Port to the Cloumap as an Attributes. Also, create the derived service and endpoint slices using these ports information. Improve reconcile service logic. Also, add the new tests.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Codecov Report

Merging #78 (6403815) into main (1a831be) will increase coverage by 14.89%.
The diff coverage is 77.41%.

@@             Coverage Diff             @@
##             main      #78       +/-   ##
===========================================
+ Coverage   61.44%   76.34%   +14.89%
===========================================
  Files          13       14        +1
  Lines        1149     1230       +81
===========================================
+ Hits          706      939      +233
+ Misses        403      226      -177
- Partials       40       65       +25

Impacted Files
Coverage Δ

pkg/cloudmap/client.go
77.57% <0.00%> (ø)

pkg/controllers/utils.go
74.46% <74.46%> (ø)

pkg/controllers/cloudmap_controller.go
66.66% <75.92%> (+66.66%)
:arrow_up:

pkg/model/types.go
68.00% <76.81%> (-5.34%)
:arrow_down:

pkg/controllers/serviceexport_controller.go
46.37% <100.00%> (+2.43%)
: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 1a831be...6403815. Read the comment docs.

Codecov delta looks good, this change hits our coverage target for the next release.


Fixing issue #326

Description
FIxed issue, now when simulation is paused the music pauses along with it.
Fixes:  #326
Type of change

[x] 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)
[ ] This change requires a documentation update

Checklist:

[x] I have made this from my own
[ ] I have taken help from some online resourses
[x] My code follows the style guidelines of this project
[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

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK

@Jasleen1210
There is an issue after pausing the music, if you change the music, it starts playing

Resolved! @sk66641

@Jasleen1210
there is bug, if we try to pause after changing the music, music doesn't get paused
To reproduce:

change the music
try to pause


[mkldnn-v1.0] Add MKL-DNN int8 fc

@pengzhao-intel @TaoLv @ciyongch @ZhennanQin @rongzha1
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at https://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

CI has passed. @pengzhao-intel please help review/merge. Thanks.


DATE_TRUNC result is incorrectly localized when a timezone is set

When no timezone is active, hour is zero as expected:
> CREATE TABLE "timezones_event" ("id" integer NOT NULL PRIMARY KEY DEFAULT unique_rowid(), "dt" timestamptz NOT NULL);
> INSERT INTO "timezones_event" ("dt") VALUES ('2011-01-01T01:30:00+00:00'::timestamptz);
> SELECT DISTINCT DATE_TRUNC('year', "timezones_event"."dt") AS "datetimefield" FROM "timezones_event" WHERE "timezones_event"."dt" IS NOT NULL ORDER BY "datetimefield" ASC;
        datetimefield
+---------------------------+
  2011-01-01 00:00:00+00:00

But when a timezone is active ('Africa/Nairobi' is UTC+3), the hour of the result is localized:
> SET TIME ZONE 'Africa/Nairobi';
> SELECT DISTINCT DATE_TRUNC('year', "timezones_event"."dt") AS "datetimefield" FROM "timezones_event" WHERE "timezones_event"."dt" IS NOT NULL ORDER BY "datetimefield" ASC;
        datetimefield
+---------------------------+
  2011-01-01 03:00:00+03:00

I believe this is a bug in cockroachdb.
The relevant Django test:
======================================================================
FAIL: test_query_datetimes (timezones.tests.LegacyDatabaseTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/tim/code/django/tests/timezones/tests.py", line 180, in test_query_datetimes
    self.assertSequenceEqual(Event.objects.datetimes('dt', 'year'), [datetime.datetime(2011, 1, 1, 0, 0, 0)])
AssertionError: Sequences differ: <QuerySet [datetime.datetime(2010, 1, 1, 3, 0)]> != [datetime.datetime(2011, 1, 1, 0, 0)]

First differing element 0:
datetime.datetime(2010, 1, 1, 3, 0)
datetime.datetime(2011, 1, 1, 0, 0)

- <QuerySet [datetime.datetime(2010, 1, 1, 3, 0)]>
+ [datetime.datetime(2011, 1, 1, 0, 0)]

This seems to be expected.

In PostgreSQL, in both cases the hour is zero. In cockroach, the hour changes (i.e. is not zero).

Ah, my mistake. I'll file an issue.


Try something else for flaky timing spec

Aiming at helping https://travis-ci.org/studentinsights/studentinsights/builds/458182204#L2665.

selfie


feat: allow passing custom env file path

Through --dart-define
As discussed here.
I'll submit a PR for documentation if you want.

Wow, this is great! Thanks so much for the PR @jeremyhalin
I'll definitely be using this 🚀
If you've got any other ideas to collab on feel free to write a new post in Discussions.
Thanks, Anthony


Add LEDU file and token logo

Kindly upload token json file and token logo

Contract details should be added here - https://github.com/MetaMask/contract-metadata/blob/master/contract-map.json

@MRabenda kindly check please. i added the json to the contract-map json. its a BEP20 token. hope its fine. kindly review. Thanks

Please remove 0x887D9c01FFf04022da9c6D64a65a481a9e5D1FCa/info.json file and not used logo

@MRabenda DELETED as you requested

@MRabenda Please kindly respond to this

@MRabenda @jflatow @mcmire @tc
Kindly respond to this PR please. Thanks

At this stage this repo do not supports BSC chain contracts


Add pricing form

Add a template for the pricing form. The markup and SCSS is mostly taken
from the admin app. This differs from other form templates in that
it is made up of multiple form elements and therefore requires multiple
default values. This is expected to be handled in macros in the
frontends. eg.
{% macro pricing(question_content, service_data, errors) -%}
  {%
    with
    name=question_content.id,
    priceMin=service_data.priceMin,
    priceMax=service_data.priceMax,
    priceUnit=service_data.priceUnit,
    priceInterval=service_data.priceInterval,
    hint=question_content.hint,
    error=errors.get(question_content.id)['message']
  %}
    {% include "toolkit/forms/textbox.html" %}
  {% endwith %}
{%- endmacro %}

:+1:
I you want to close https://github.com/alphagov/digitalmarketplace-frontend-toolkit/pull/125 and fold all of these into one version I would be OK with that.


Cannot get ssh-keys to work with Docker container running as sibling container

It's fairly common to run Jenkins as a container - jenkins/jenkins:lts, ran like so:
docker run -v /var/run/docker.sock:/var/run/docker.sock  jenkins/jenkins:lts

so any container launched within Jenkins jobs, is running as "a container in a container", in reality though they should be sibling containers both launched by the host fs.
However, even so, I can't seem to get my ssh keys into the gitleaks container using the docker --volume option. Has anyone else reported this probem to you? Not really a problem with gitleaks perse, although it would be nice to document a solution here.

gitleaks is not responsible for cloning in v8+


Bluetooth: Mesh: Various fixes impacting qualification

Most of these are backported from nimble. List of Qualification tests affected:
MESH/NODE/PROV/BV-10-C
MESH/NODE/PROV/BI-03-C
MESH/NODE/PROV/BV-12-C
MESH/NODE/PROV/BI-13-C
Johan Hedberg (8):
      Bluetooth: Mesh: Fix missing protocol error timeout
      Bluetooth: Mesh: Fix Public Key mismatch error handling
      Bluetooth: Mesh: Rename reset_link() to reset_adv_link()
      Bluetooth: SMP: Make public key handling more robust
      Bluetooth: Fix public key callback management
      Bluetooth: Mesh: Generate new public key for each provisioning session
      Bluetooth: Mesh: Fix rejecting invalid remote public key
      Bluetooth: Mesh: Fix provisioning send error handling

 subsys/bluetooth/host/hci_core.c  |   9 +-
 subsys/bluetooth/host/mesh/prov.c | 207 +++++++++++++++++++++----------------
 subsys/bluetooth/host/smp.c       |  18 ++--
 3 files changed, 131 insertions(+), 103 deletions(-)

Fixes #17057

@szymon-czapracki @andrzej-kaczmarek FYI

@michal-narajowski FYI

@tedd-an once you have time could you run the auto-pts tests against this PR? What I'm wondering is why these weren't caught by us but were caught by Codecoup. At there's at least one test failure in our latest run that matches one of the four cases this PR fixes, however the other tree aren't part of the report at all - is that because Codecoup is using a newer PTS version which has these tests while ours doesn't? If so we need to update and do the run with the very latest PTS version.

@jhedberg We are using PTS 7.4.1 build 2 which is the latest version.
Those missing test cases are not implemented in the AutoPTS.
@MariuszSkamra @szymon-czapracki Do you have an update for those test cases?

@jhedberg We are using PTS 7.4.1 build 2 which is the latest version.
Those missing test cases are not implemented in the AutoPTS.

@tedd-an thanks for the info. How many other such test cases are there for the protocols & profiles we support? We still need to run them and provide the test results for the qualification listing.

@jhedberg I just confirmed that this PR fixes MESH/NODE/PROV/BV-10-C

@tedd-an thanks for the info. How many other such test cases are there for the protocols & profiles we support? We still need to run them and provide the test results for the qualification listing.

@jhedberg Let me go through the PTS to get the missing TC. (Assume current ICS is up-to-date and valid).


Error output mess

Why do I get all this mess from one simple Permission error? Pretty anoying if you ask me. I use PM2 on my ubuntu VPS.
MusikBot > [ERROR:bot] Error in play: PermissionsError: You don't have permission to use that command.     MusikBot > Reason: You have reached your enqueued song limit (4) MusikBot > Traceback (most recent call last):                                                              MusikBot >   File "/home/nodeath/MusicBot/musicbot/bot.py", line 2495, in on_message MusikBot >     response = await handler(**handler_kwargs) MusikBot >   File "/home/nodeath/MusicBot/musicbot/bot.py", line 1256, in cmd_play MusikBot >     "You have reached your enqueued song limit (%s)" % permissions.max_songs, expire_in=30      MusikBot > musicbot.exceptions.PermissionsError: You have reached your enqueued song limit (4)
All I want is a cleaner console output like:
[PERMISSION ERROR] %user% don't have permissions to use that command. %reason%.
Or something like that

Logging implemented


Multiple issues with handling external filesystem changes

Changes to file contents are not detected by Godot engine and therefore cannot be handled easily. Best option is likely to refresh states from the filesystem on the editor gaining focus in the OS if that's an event we can track. We'd still be hosed if updates are pulled in the background but that can just go into an FAQ or known issues list or something
The following scenarios should work though:

User renames or deletes an AtlasTexture that's associated with the currently selected source

Including when that AtlasTexture is the one selected for modification in QuickAtlas

User renames or deletes a source texture that's currently being used
User renames anything relevant that isn't currently selected

This is handled decently WRT changes to the AtlasTexture instances but changes to the base texture aren't handled. That's been spun into its own issue #27

This is handled decently WRT changes to the AtlasTexture instances but changes to the base texture aren't handled. That's been spun into its own issue #27


REDDEV-568 refactor bucketBy select

Load only the fields used by the selected report. Check report fields
against data dictionary to ensure they are of categorical type.
Unit tests.

Screenshots:


common-grpc: return requests to allow abort()

As brought up in #1961, we weren't allowing active gRPC requests to be aborted.

Looks good to me! Thanks a lot for taking this over so quickly!


update sample gist on trendet usage

As trendet has been updated the update of trendet gist is proposed, since country param has been added to identify_trends() and identify_all_trends(), and a new function has been added identify_df_trends().
Documentation needs to be checked and updated before releasing trendet 0.5.

Gist has been properly updated in order to fit trendet's 0.5 release: https://gist.github.com/alvarob96/98f94dcfec59f78a16ad2edbf464ce75


Add sorl_thumbnail_tags templatetag library that mirrors traditional thumbnail

Add sorl_thumbnail_tags templatetag library that mirrors traditional thumbnail.
This allows usage of sorl-thumbnail in templates by {% load sorl_thumbnail_tags %} instead of traditional {% load thumbnail %}. It's specifically useful in projects that do make use of multiple thumbnailer libraries (for instance easy-thumbnails alongside sorl-thumbnail).
Works fine in my fork. If you, in principle, have nothing against addition of sorl_thumbnail_tags mirror, I'll add tests and update the documentation prior making a pull request.

I think that's a good idea. Having a name as generic as thumbnail is too likely to conflict with other thumbnail libraries like easy-thumbnails.

@mariocesar:
Are you interested in fix from my side (and thus a pull-request) or rather do it yourself?

Since it's moved to JazzBand, I ask again, is there anyone interested in fix from my side (and thus a pull-request) or rather do it yourself?

@barseghyanartur Make a PR.


Cartographer output cannot allign frames.

Hi,
We tried cartographer with a handheld single velodyne 32c and an IMU. Unless there's very little movement or the lidar is static the slam is very messy and appears to be a disorganized “blob,” as can be seen in the attached image. We think there could be an issue in the .urdf file and We're trying to update the values to reflect our setup. We are wondering if anything in the .launch file or .lua file isn't setup properly.
Bag file
.urdf file
slam.launch file
slam.lua file
These are the files we used to generate the point cloud and images:
localization.launch file
localization.lua
Here is the repository we used to work on the .launch files and .urdf files
Pictures:
Static:

With movement:

I modified urdf and lua to make it work slightly
ingenium.zip

Thank you for answering! We ended up fixing the problem a while ago, the problem ended up being with the urdf, we had the imu pointed upside down and the lidar not rotated properly. @trevgilk I suggest closing this issue.


Why is there a generic parameter definition TUser for PasswordHasher when it is not used?

Not sure if this is the place for this type of question, but I'm curious as to why TUser generic type parameter is used in PasswordHasher class when TUser is not used internally in the class anywhere.
https://github.com/aspnet/Identity/blob/master/src/Core/PasswordHasher.cs#L17
TUser is used to define a parameter here and here, but those parameters are never used.

They allow for custom implementations to use them.