Polymer Catalog -- link-related usability issue

The demo buttons look like links but they don't behave like links. Clicking on a link while holding CTRL would normally opens up a new tab. It doesn't for the demo buttons (the ones with the eye icon).
Also back buttons after clicking on a link will normally get you back to the same place you departed from (same page, same spot on the page). It doesn't work with the demos.
Can't the demo buttons just be normal links?

Should be posted in https://github.com/Polymer/polymer-element-catalog/issues.

Apologies. Will cut & paste.


[NETBEANS-2389] Missing source level 11 and 12 in a NetBeans module project

https://issues.apache.org/jira/browse/NETBEANS-2389

Umm, it seems that Travis CI doesn't work.


Portuguese versioning not working

Neither of these links (which I think should work) are displaying anything in Portuguese on the site.
http://www.inaturalist.org/observations?locale=pt
http://www.inaturalist.org/observations?locale=pt-br
For comparison, these languages DO work:
http://www.inaturalist.org/observations?locale=es
http://www.inaturalist.org/observations?locale=id (less translated than Brazilian Portuguese).
Changing my account setting did work to display in Portuguese. Am I doing something wrong?

its http://www.inaturalist.org/observations/2984852?locale=br-pt


Pipeline flow control

Hi guys.
Is there a way to specify flow control in a pipeline?
I have looked through the documentation but haven't been able to find anything relevant.
To provide more context, what I am interested in is creating a pipeline in which some step(s) would only be executed if a certain condition holds. The condition would have to be dynamic in that it would depend on the output of a previous step. For example, let's say I am running a pipeline in which the first step is to run a model to detect whether the input (which is an image) includes the face of a person and the output would be a cropped area of the image where the face was detected. The next step in the pipeline would only execute if a face was detected (and thus a cropped image was generated), otherwise a different step would execute, and so on.
If there is no way currently to do something like that in the pipeline specification, what would be a best practice to achieve something like this using pachyderm?
Thanks!

Hi @vasilak,
There are a couple of standard ways of accomplishing this with Pachyderm:

Build the control flow into your pipeline. Your upstream code would output either its cropped face to /pfs/out/face or something else to /pfs/out/other then your downstream pipeline would do something different based on whether the file it finds is called face or something_else these names can be changed to your liking so that multiple faces don't conflict with each other.

Have separate pipelines consume different directories. Your upstream code would output faces to /pfs/out/faces/face and other things to /pfs/out/others/other. You could then have 2 downstream pipelines, one with a glob pattern of /faces/* that would handle faces and one with /others/* that would handle the others.

Which one you use depends on how granular you want control over the 2 operations to be. If you want to be able to update one without updating the other, have different resources requests for them, have one get scaled down while the other is up and running, etc. then 2 different pipelines is the better choice. If those things aren't necessary the simplicity of a single pipeline is probably

Generally speaking you'll get faster responses to support questions like this in our users channel: slack.pachyderm.io. GitHub issues are better used for reporting bugs and feature requests.

Hi @jdoliner and thanks for responding.
About the 2nd option you describe: understanding when the pipeline is done (for a particular input) can still be accomplished using flush-commit, right? I am asking since in this case you basically have 2 different "end" steps.

@vasilak sorry for the delay. Yes, it sounds like you should be able to achieve what you're looking for with flush commit -- I believe it waits for all downstream commits by default


Need to support events on path/line and label

Hi,
Thank you for building such a useful utility to draw lines, appreciated.
I have a scenario where I need to perform some actions upon clicking a label or path/line. Need to support events on path/line and labels.

Hi @Umer-Hayyat, thank you for your comment.
These may help you:
https://github.com/anseki/leader-line/issues?q=is%3Aissue+event+listener

Hi @Umer-Hayyat, thank you for your comment.
These may help you:
https://github.com/anseki/leader-line/issues?q=is%3Aissue+event+listener

Hi Aneski,
thank you for replying. I have multiple lines then how to differentiate those if I add event by SVG DOM

A line is added to the end of the list of children of the <body> element.
For example:
var line1 = new LeaderLine(elmStart1, elmEnd1),
  elmLine1 = document.querySelector('body>.leader-line:last-of-type'),
  line2 = new LeaderLine(elmStart2, elmEnd2),
  elmLine2 = document.querySelector('body>.leader-line:last-of-type');

Note that these are not supported as I said in past issues.

Hi Anseki,
is it possible for you to provide support onclick event on label text?

No, that should never be supported as I said repeatedly.
If you really want that, you can use SVGDOM#addEventListener to add event listeners to the labels.

No reply came, then I close this abandoned issue.


Fix glog build on OS X (which has an ancient version of bash) [phab:D1139]

Created by shahms at 2016-11-07 17:56:58:
Fix glog build on OS X (which has an ancient version of bash)

salguarnieri accepted this revision at 2016-11-07 18:02:26

shahms wrote at 2016-11-07 18:16:36:

Remove vestigial source files and use cp rather than mv

salguarnieri wrote at 2016-11-07 18:19:48:
LGTM, using bazel build //kythe/release --genrule_strategy=standalone --spawn_strategy=standalone --verbose_failures this builds for me

shahms closed via commit e826be8f032f72a80de49a81389f93b183494000 at 2016-11-07 18:20:45


Fire onresizestop after complete resizing

When resizing a widget, the dimensions snap to the grid after the handle is released. This is great. :)

However, it seems that onresizestop() is triggered before that process is finished so if you try to get the widgets dimension, you get them 'wrong'.
Is there a way to get an event that is triggered after the full resizing process?

for a quickfix you can use your caclulation inside setTimeout call with appropriate timeout. More reliable would be using debouncing technique.

+1 for fixing this issue.

I came here to open an issue saying the same thing.
I would like to get el.dataset.gsHeight and el.dataset.gsWidth in my resizestop event handler, but it fires early before the data-gs-height and data-gs-width attributes have been updated.
I'm digging through gridstack.js to locate the source of this out-of-order event or race condition. Any pointers as to where to make the fix would be helpful!
Thanks!

I've dug into it some more. For whatever reason, the resizestop functions here $._data($(".grid-stack")[0], "events") fire first, then the stop function here $($("."+$(".grid-stack").data("gridstack").opts.item_class).get(0)).data("ui-resizable").options fires second (aka, GridStack.prototype._prepare_element's on_end_moving).
This firing behavior seems backwards to me. I would expect the .grid-stack-item's stop to fire before .grid-stack's resizestop, but that isn't the case. I'm trying to determine why this is the case, but the code is a bit murky.

This bug report (http://bugs.jqueryui.com/ticket/9580) helped me to identify the problem. Basically, callbacks inside options structures are not event callbacks, they are pure callbacks. The event is fired and all event callbacks are executed, then all options callbacks are executed. The solution is to bind on_end_moving in _prepare_element as an event callback instead of passing it as an options callback. I may issue a pull request to fix this.

Hi all,
I 'm new user of the Gridstack, I have the same problem as amelzer. Is there a new fix of this issue ?

@tazeroualti - @derekm was kind enough to build a fix for this, which has since been merged into gridstack v0.2.5-dev. Though this build is not necessarily stable, it incorporates many bug fixes, and I'd recommend giving it a go to see if it fixes your issue.

This morning I downloaded the releases zip which includes gridstack 0.2.6.  It appears as though the same issue exists.  I was under the impression that his had been merged in...what am I missing?  Is still in dev only?

I have this issue in 0.3.0.  Looks like the fix went into the 0.2.x branch, and the code in the 0.3.0 is sufficiently different.
I'm using the gsresizestop callback and need to use a settimeout to get the new height/width using jquery (not ideal).


VScode force changes the locale to en_US.UTF-8 for git commit hooks in dev-container

Does this issue occur when all extensions are disabled?: Yes/No -> Cannot disable all extensions because WSL and Dev-Container is required to reproduce.

VS Code Version: 1.80.1
OS Version: Windows 11 22H2 -> WSL Debian 12 Bookworm/podman -> python:3.11-slim-bullseye base Container

Steps to Reproduce:

Use python:3.11-slim-bullseye as a base container and install git.
Create a pre-commit hook that echos the locale.

You will observe, that the container uses C.UTF-8 which is fine. But when the vscode extension host triggers git which starts the pre-commit hook script, it seems to force en_US.UTF-8 which is not even installed in the container.
I already tried setting "terminal.integrated.detectLocale": "off" with no effect.
Example
When using the integrated terminal (inside the dev container) you get the following result:
 root $ /workspaces/testrepo # git -c user.useConfigOnly=true commit --quiet
+ locale -a
C
C.UTF-8
POSIX
+ locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=
+ INSTALL_PYTHON=/usr/local/bin/python3
+ ARGS=(hook-impl --config=.pre-commit-config.yaml --hook-type=pre-commit)
...

When using the UI and trying to commit, my pre-commit hooks fail with the following output:
> git -c user.useConfigOnly=true commit --quiet --allow-empty-message --file -
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
+ locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory
C
C.UTF-8
POSIX
+ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8
+ INSTALL_PYTHON=/usr/local/bin/python3
+ ARGS=(hook-impl --config=.pre-commit-config.yaml --hook-type=pre-commit)

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.81.0. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

I'm facing the same issue as well. I've been using dev containers for a while now. I started setting up pre-commit hooks using the pre-commit package. When I install the hooks using the pre-commit install command and commit a file, I get this popup

and this command output I get:
> git -c user.useConfigOnly=true commit --quiet --allow-empty-message --file -
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
[WARNING] Unstaged files detected.
[INFO] Stashing unstaged files to /root/.cache/pre-commit/patch1693895304-20939.
Trim Trailing Whitespace.................................................Failed
- hook id: trailing-whitespace
- exit code: 1
- files were modified by this hook

Fixing app/views.py

Fix End of Files.........................................................Failed
- hook id: end-of-file-fixer
- exit code: 1
- files were modified by this hook

Fixing app/views.py

Check Yaml...........................................(no files to check)Skipped
[INFO] Restored changes from /root/.cache/pre-commit/patch1693895304-20939.

When I uninstall the pre-commit hooks using the pre-commit uninstall command. I face no issues with committing files. To me, this looks like the pre-commit hooks is making the necessary changes, but the files aren't being committed because of this warning. Is there any configuration I can change somewhere to either suppress this warning or update my locale settings?
Here's my devcontainer.json file for reference:
{
	"name":  "Django App",
	"image": "python:3.10.8",
	"runArgs": ["--env-file",".keys.env"],
	"workspaceMount": "source=${localWorkspaceFolder},target=/app,type=bind,consistency=cached",
	"workspaceFolder": "/app",
	"postCreateCommand": "pip3 install -r app/requirements.txt",
	"customizations": {
		"vscode": {
			"extensions": [
				"ms-python.python",
				"ms-python.flake8",
				"ms-python.black-formatter",
				"ms-python.isort",
				"ms-toolsai.jupyter",
				"batisteo.vscode-django",
				"atlassian.atlascode",
				"esbenp.prettier-vscode"
			],
			"settings": {
				"[python]": {
					"editor.defaultFormatter": "ms-python.black-formatter"
				},
				"python.formatting.provider": "none",
				"python.linting.flake8Args": [
					"--max-line-length=88",
					"--max-doc-length=79"
				]
			}
		}
	}
}

And this is my .pre-commit-config.yaml file
# See https://pre-commit.com for more information
# See https://pre-commit.com/hooks.html for more hooks
default_language_version:
  python: python3.10.8
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
  rev: v3.2.0
  hooks:
    - id: trailing-whitespace
    - id: end-of-file-fixer
    - id: check-yaml

I have the same issue. Can't use git in VSCode when developing in devcontainers that don't have the en_US.UTF-8 available.
I tried forcing python to use utf-8 using env variables. But that didn't solve the issue.

I can't commit using vscode UI, but the command line works

So an update on this from my end. My commit works if all files in staging pass all the pre-commit checks, If any one of them fails, I see the warning popup. So I guess the popup just picks up the first warning message instead of the actual error message thrown from pre-commit hook?

I'm experiencing this exact issue, only the fact vscode tries changing the locale is what is causing my pre-commit check to fail. My pre-commit check runs ansible-lint and that command fails on the fact the shell it's spawned within has a broken locale. The way I've fixed this for now is uncommenting en_US.UTF-8 UTF-8 in the container's /etc/locale.gen and running locale-gen.

I found this while using ansible-lint like @debben explained. My workaround is to install and generate the locale like this:
"postCreateCommand": "apt update && apt install -y --no-install-recommends locales; echo \"en_US.UTF-8 UTF-8\" >> /etc/locale.gen; locale-gen",

I am experiencing the same issue, which seems to be caused by this code :
https://github.com/microsoft/vscode/blob/9cf4ff992127a0d2e1e1b25de52bfc1846af34c1/extensions/git/src/git.ts#L652
You can see there that the call to assign includes the setting of LC_ALL and LANG to en_US.UTF-8 via the last argument.
I do not know whether this code is intended to provide a fallback or to override the user configuration. In either case, I do not think it is the role of VSCode to modify the environment variables pertaining to localization as long as there is no specific configuration variable that allows the user to override those.

That's a good find @wsourdeau!
Funnily this was introduced in https://github.com/microsoft/vscode/commit/0b7f4425ef0fee913f9bfeafd29fee43a446075c#diff-293b11f03fd680420c853878a68b23ef1ea51799d7e052d582f175cd9e511f43L389 to fix a pre-commit bug.
Most minimal environments have a C and POSIX locale installed. Nowadays C.UTF-8 is also there and this should be the correct thing to do here as this locale is intended to be used when no human localized interaction is required (e.g. in containers).
It would be great if one of the developers (@lszomoru) could pick this up and change en_US.UTF-8 to C.UTF-8 as this would make it compatible with the rest of the world not having en_US installed unless there are some reasons unknown to me which would break other things.

Funnily this was introduced in 0b7f442#diff-293b11f03fd680420c853878a68b23ef1ea51799d7e052d582f175cd9e511f43L389 to fix a pre-commit bug.

It was introduced earlier, in 63a69695f7e0e6aeb803bb4d3c7e736eff2becd0 and 04a4fb0c879d393535435e9eb58615ef2bb45786.

That's a good find @wsourdeau!
Funnily this was introduced in 0b7f442#diff-293b11f03fd680420c853878a68b23ef1ea51799d7e052d582f175cd9e511f43L389 to fix a pre-commit bug.
Most minimal environments have a C and POSIX locale installed. Nowadays C.UTF-8 is also there and this should be the correct thing to do here as this locale is intended to be used when no human localized interaction is required (e.g. in containers).
It would be great if one of the developers (@lszomoru) could pick this up and change en_US.UTF-8 to C.UTF-8 as this would make it compatible with the rest of the world not having en_US installed unless there are some reasons unknown to me which would break other things.

I think the best is to leave it unchanged at all. Any value you set there must refer to a locale that has been explicitly generated on the system vscode is running on + the environment variables pertaining to localization are either set system-wide or a not set at all. VSCode should thus leave those variables alone and instead, just comply with them if it can or stick to plain US English messages output in plain ASCII if it cannot.

That's a good find @wsourdeau!
Funnily this was introduced in 0b7f442#diff-293b11f03fd680420c853878a68b23ef1ea51799d7e052d582f175cd9e511f43L389 to fix a pre-commit bug.
Most minimal environments have a C and POSIX locale installed. Nowadays C.UTF-8 is also there and this should be the correct thing to do here as this locale is intended to be used when no human localized interaction is required (e.g. in containers).
It would be great if one of the developers (@lszomoru) could pick this up and change en_US.UTF-8 to C.UTF-8 as this would make it compatible with the rest of the world not having en_US installed unless there are some reasons unknown to me which would break other things.

I think the best is to leave it unchanged at all. Any value you set there must refer to a locale that has been explicitly generated on the system VSCode is running on + the environment variables pertaining to localization are either set system-wide or not set at all. VSCode should thus leave those variables alone and, instead, either comply with them if it can or, if it cannot, stick to plain US English messages output in plain ASCII, which all charsets are compatible with anyway.

I believe you are missing the point. A specific locale needs to be explicitly set to make git's output more predictable. This allows VS Code to parse it and act accordingly. VS Code can't afford to maintain git's output parsing for all possible languages. Sticking with English messages is a logical choice, but using en_US locale for this - isn't, because it comes with "extras" such as US date format etc. And en_US is not universally available on all the systems. C locale is a better choice, because it is the default locale for all applications on Linux (at least before they call setlocale() to initialize locale from environment variables), so it is pretty much guaranteed that this locale is available.

FYI, on Debian, locales that are configured to be generated are defined in /etc/locale.gen. Some systems may define them all by default (I believe Ubuntu does), but some systems don't.

I believe you are talking about a "full-size" Ubuntu distro, it may afford to generate all locales. But official Ubuntu Docker image is optimized for size and provides only C.UTF-8. VS Code needs to take dev container use case in mind, so using C.UTF-8 is the obvious choice.

I found this while using ansible-lint like @debben explained. My workaround is to install and generate the locale like this:
"postCreateCommand": "apt update && apt install -y --no-install-recommends locales; echo \"en_US.UTF-8 UTF-8\" >> /etc/locale.gen; locale-gen",

Thank you for the workaround! In my case container uses non-root user, so I had to modify the command slightly:
    "onCreateCommand": "sudo apt update && sudo apt install -y --no-install-recommends locales && sudo sh -c 'echo \"en_US.UTF-8 UTF-8\" >> /etc/locale.gen' && sudo locale-gen",

Also note that postCreateCommand and onCreateCommand can be used interchangeably in this case.

I think the best is to leave it unchanged at all. Any value you set there must refer to a locale that has been explicitly generated on the system VSCode is running on + the environment variables pertaining to localization are either set system-wide or not set at all. VSCode should thus leave those variables alone and, instead, either comply with them if it can or, if it cannot, stick to plain US English messages output in plain ASCII, which all charsets are compatible with anyway.

I believe you are missing the point. A specific locale needs to be explicitly set to make git's output more predictable. This allows VS Code to parse it and act accordingly. VS Code can't afford to maintain git's output parsing for all possible languages. Sticking with English messages is a logical choice, but using en_US locale for this - isn't, because it comes with "extras" such as US date format etc. And en_US is not universally available on all the systems. C locale is a better choice, because it is the default locale for all applications on Linux (at least before they call setlocale() to initialize locale from environment variables), so it is pretty much guaranteed that this locale is available.

You are right that I "missed" that point. But among the approaches that you could use there is :

the one you suggest, which will be compatible with any environment with the downside that people who are not fluent in English will get all their messages in English anyway
unless I am mistaken, it is a matter of charset. Therefore I think, since I am pretty sure the JS engine used by vscode uses UTF-8 nativey, it would also be reasonable to check if the value of LANG or LC_ALL ends with "UTF-8" (case insensitive). If this is so, leave the locale unchanged.
you can also trust the user to have specified the right settings to his system : when you run VSCode on Linux, the graphic toolkit is already taking the locale variables into account and is configuring the display of text accordingly.

FWIW, my order of preferences between the approaches listed above would be 3, then 2, then 1.
The solution to the problem you suggest breaks the principle of "it it's not broken, don't fix it" and begs the question : is this supposed to fix and actual issue that was reported or is this only in anticipation?

@wsourdeau as I stated above it is not about human interaction. Those should be localized, I absolutely agree.
The point here is that the locale is set to en_us for internal, non user facing, git operations. Those do not need to be localized but they need to work in all environments and thus require a common base locale which is the C locale.

@wsourdeau as I stated above it is not about human interaction. Those should be localized, I absolutely agree.
The point here is that the locale is set to en_us for internal, non user facing, git operations. Those do not need to be localized but they need to work in all environments and thus require a common base locale which is the C locale.

I think I see the difference we see... How I noticed the issue is by testing the behaviour of VSCode using git commit hooks, where feedback can be given back to the user. Thus, potentially, that feedback can be affected by the localization variables. Thus I guess "C" is ok as a first step, but I would not assume that there is no value in allowing git messages or git hook messages to be localized.

I encountered this problem with VS Code on a normal, full German Debian 11 installation, so there is nothing container-specific here. All locales installed on my system (output of locale -a): C, C.UTF-8, de_DE.utf8, POSIX

@wsourdeau, I understand your point and in the perfect world it would make a lot of sense to localize as much as possible. But there is obviously some kind of technical limitation that made VS Code developers to enforce a specific output language.
If you check the git history, you will see that VS Code wasn't setting any locale for git command, just as you suggest. Over time they started forcing en_US.UTF-8 locale. Was it actually to set UTF-8 encoding, output in English or the American Dream? Unfortunately, git logs are not verbose enough to say for sure.
The following is my speculation. UTF-8 is default on most Linux systems, so encoding is a highly unlikely source of problems. Most likely the intention was to have output in English (that can be parsed and acted upon by VS Code) and US part was kind of unintentional (I hope) "collateral damage".
In my view enforcing en_US.UTF-8 should be changed to enforcing C.UTF-8, because it better aligns with the intention of having a parse-able output without destructive side effects. This is a trivial bugfix. And it will improve the situation dramatically - it is much better to get non-localized output from git hooks than having them in a completely broken state.
After the primary issue is addressed, we can get back to discussing your suggestion. This will likely be a new feature with potentially significant development costs.

@wsourdeau, I understand your point and in the perfect world it would make a lot of sense to localize as much as possible. But there is obviously some kind of technical limitation that made VS Code developers to enforce a specific output language.
If you check the git history, you will see that VS Code wasn't setting any locale for git command, just as you suggest. Over time they started forcing en_US.UTF-8 locale. Was it actually to set UTF-8 encoding, output in English or the American Dream? Unfortunately, git logs are not verbose enough to say for sure.
The following is my speculation. UTF-8 is default on most Linux systems, so encoding is a highly unlikely source of problems. Most likely the intention was to have output in English (that can be parsed and acted upon by VS Code) and US part was kind of unintentional (I hope) "collateral damage".
In my view enforcing en_US.UTF-8 should be changed to enforcing C.UTF-8, because it better aligns with the intention of having a parse-able output without destructive side effects. This is a trivial bugfix. And it will improve the situation dramatically - it is much better to get non-localized output from git hooks than having them in a completely broken state.
After the primary issue is addressed, we can get back to discussing your suggestion. This will likely be a new feature with potentially significant development costs.

I think that is not necessary. The "C" locale is already supposed to provide English messages and ASCII encoding, which is ciompatible with UTF-8 (the first 127 char codes of unicode are the same as the first char codes of ASCII).
I am not quite sure what you mean by "significant development cost", because what I suggest is to remove code, not to add more, but as long as VSCode does not require me to install a locale I do not have and should not have, I am fine.
What I was writing was moslty a suggestion, with a focus on standard unix development.

To me it looks like changing those two lines might actually be enough.
https://github.com/microsoft/vscode/blob/1cc266cc82838981034c2baa637f357a83711d5d/extensions/git/src/git.ts#L658-L659
@lszomoru is there a chance you can pick this up?

@gone-for-coding, do you mind submitting a pull request with the exact change that you are proposing?

@gone-for-coding, do you mind submitting a pull request with the exact change that you are proposing?

@lszomoru, I took the liberty to create a PR. Please see #210506.
@gone-for-coding, I hope you don't mind. I will happily add you as a co-author if you provide required info.

@i-ky
Thanks for picking this one up. Highly appreciated! I'm just too busy to go through the PR process myself.
There is no need to add me as a co-author, but thanks for the offer!

~/.zshrc
export LANG=zh_CN.UTF-8
export LC_ALL=zh_CN.UTF-8
iTerm:
echo $LANG // zh_CN.UTF-8
echo $LC_ALL // zh_CN.UTF-8
version: 1.89.1 (Universal)
commit: dc96b837cf6bb4af9cd736aa3af08cf8279f7685
vscode git hook log：
echo $LANG // en_US.UTF-8
echo $LC_ALL // en_US.UTF-8
==============
jest error
expect(new Date().toString()).toBe('Mon Jun 03 2024 08:00:00 GMT+0800 (中国标准时间)')
git hook: 'Mon Jun 03 2024 08:00:00 GMT+0800 (China Standard Time)'

~/.zshrc export LANG=zh_CN.UTF-8 export LC_ALL=zh_CN.UTF-8
iTerm: echo $LANG // zh_CN.UTF-8 echo $LC_ALL // zh_CN.UTF-8
version: 1.89.1 (Universal) commit: dc96b83 vscode git hook log： echo $LANG // en_US.UTF-8 echo $LC_ALL // en_US.UTF-8
============== jest error expect(new Date().toString()).toBe('Mon Jun 03 2024 08:00:00 GMT+0800 (中国标准时间)') git hook: 'Mon Jun 03 2024 08:00:00 GMT+0800 (China Standard Time)'

The following example works fine:
// package.json
"test:o": "jest --onlyChanged",
.husky/pre-commit
export LC_ALL=zh_CN.UTF-8
pnpm run test:o

and setting the LC_ALL variable alone works for node's Date.toString

I encountered this error in my WSL Ubuntu distribution using VS Code. Fixed it by executing the following command:

locale-gen en_US.UTF-8


Installing PowerToys version 0.70.0 disables the ability to switch the input method editor (IME) using the keyboard.

Microsoft PowerToys version
0.70.0
Installation method
GitHub, PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
General
Steps to reproduce
Install PowerToys version 0.70.0.
✔ Expected Behavior
No response
❌ Actual Behavior
When installing version 0.70.0, the ability to switch between Japanese and English input using Ctrl + Space key combination becomes disabled. Restarting the computer does not resolve the issue. Clicking on the icon in the bottom right allows you to switch the input method editor (IME) on and off. This symptom occurs with both Microsoft IME and Google Japanese Input. Uninstalling PowerToys resolves the issue.
The environment used is as follows:
OS: Windows 10 22H2
PowerToys: Version 0.70.0
Input interface: English keyboard (US)

Other Software
Google Japanese IME (ver. 2.28.5050.0)

You can try disabling Peek or changing shortcut key to another, may resolve this issue.

There's the suggested workaround.
Going to dedup against other issue relating Ctrl+Space being used on other apps.
/dup #26150


Unable to "git push" my local commits to my remote branch

Whenever I try to git push anything, It runs for a long time saying, Writing Objects.. until approx 2GiB and then I gives me strange error after tha.

I can NOT push my local "develop" commits to the remote "develop" branch.
I thought that was because the sam_vit_h_4b8939.pth file was 2.39 Gib and it was in my local and remote branches. So I tried to move the file at some local location in my pc. But, after that too it did not work. Please help

After encountering issues that couldn't be resolved, the decision was made to delete the problematic "develop" branch. Following this, the user successfully pulled the latest version of the main branch from the MLDSAI/puterbot repository onto their own main branch. The result was a fully functional system, indicating a successful resolution to the previous issues.


A bug in the job method

Describe the bug
The bug about Chinese still exists, just like the  https://github.com/DiUS/java-faker/ library
To Reproduce
import net.datafaker.Faker;
import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;

import java.util.Locale;

@SpringBootTest
class SpringBootStudyApplicationTests {

    @Test
    void testFaker() {
        Faker faker = new Faker(Locale.CHINA);
        System.out.println(faker.name().name());
        System.out.println(faker.job().field());
        System.out.println(faker.job().position());
        System.out.println(faker.job().title());
    }
}

result

Versions:

OS: windows
JDK 8
Faker 1.6.0

Sorry, but what is the bug exactly? What did  expect to see instead?

Sorry, but what is the bug exactly? What did expect to see instead?

I have set Chinese, so it should be that all the output is Chinese like the name method

There is unfortunately no translated job information in the zh-CN.yml file. The only translations we have is in hy.yml, pt-BR.yml`, and the default English.
We'd absolutely love contributions in this. My understanding of the Chinese language is poor, but If you'd be willing to help translate this data, or a subset of it, we'd be very happy to include it in the library.
These are the fields which need translating:
    job:
      field: [Marketing, IT, Accounting, Administration, Advertising, Banking, Community-Services, Construction, Consulting, Design, Education, Farming, Government, Healthcare, Hospitality, Legal, Manufacturing, Marketing, Mining, Real-Estate, Retail, Sales, Technology]
      seniority: [Lead, Senior, Product, National, Regional, District, Central, Global, Customer, Investor, Dynamic, International, Legacy, Forward, Internal, Chief, Direct, Corporate, Future, Human, Principal]
      position: [Supervisor, Associate, Executive, Liaison, Officer, Manager, Engineer, Specialist, Director, Coordinator, Administrator, Architect, Analyst, Designer, Planner, Orchestrator, Technician, Developer, Producer, Consultant, Assistant, Facilitator, Agent, Representative, Strategist]
      key_skills: [Teamwork, Communication, Problem solving, Leadership, Organisation, Work under pressure, Confidence, Self-motivated, Networking skills, Proactive, Fast learner, Technical savvy]
      employment_type: [Full-time, Part-time, Temporary, Contract, Internship, Commission]
      education_level: [Associates, Bachelor, Master, Doctorate]

My English is not good either, but I think I should be able to find translations that are obviously wrong.
Let me first check the existing fields you mentioned.

@Gandhi-gd any chance to look at the above?

I'll close this one for now. Please let me know if this is still an issue and if you want to have it fixed.


about Multi-admin，Passcode how is it generated (CON-247)

Run a command similar to the following, the tool will return the setup payload and manual code. I only pass the discriminator, how the passcode is generated
./chip-tool pairing open-commissioning-window <node_id> <option> <window_timeout> <iteration> <discriminator>

The Passcode is generated randomly with the spake2+ verifier at https://github.com/project-chip/connectedhomeip/blob/master/src/controller/CommissioningWindowOpener.cpp#L110

Closing as the question is answered


Additions

permissions list and permissions if none exist already
ability for user to only controll their particles
ui?
permission based ui (if you have perms for the particle you can use the ui, would probably need a rewrite based on the little ive seen but since 1.15 particles are there and its only written for 1.13 yeah)
thats it

Hello!
A list of permissions are available on the Spigot page! The permission arrowtrail.force allows someone to change another person's effects. You can just not give other players that permission to disable forcing particles. I am thinking about adding a UI in the future if I keep supporting this plugin.


port: several files from category_theory

Also ports the reassoc attribute.

[ ] depends on: #755

This PR/issue depends on:

leanprover-community/mathlib4#755
By Dependent Issues (🤖). Happy coding!

This PR/issue depends on:

leanprover-community/mathlib4#755
By Dependent Issues (🤖). Happy coding!

bors merge


Logic App Character Limits are unclear

The section "Character Limits" states:
"Expression evaluation limit
131,072 characters
The @concat(), @base64(), @string() expressions can't be longer than this limit."
How about other string functions like: @base64ToString(), @substring(), @json() ?
At the specific function page no limit is mentioned:
https://docs.microsoft.com/en-us/azure/logic-apps/workflow-definition-language-functions-reference#base64ToString
If this limit is in place for all String functions, then example how to do String operations of a large Body of a HTTP request?

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

ID: 845c4db9-1f3a-26d1-5061-c018cb1fe336
Version Independent ID: c2a03981-a0aa-64a5-2659-e10202e5bb14
Content: Limits and configuration - Azure Logic Apps
Content Source: articles/logic-apps/logic-apps-limits-and-config.md
Service: logic-apps
GitHub Login: @ecfan
Microsoft Alias: estfan

Hi @abalogh Thanks for reaching out. We will review and update as appropriate.

@abalogh You can Set up chunking over HTTP. If an endpoint has enabled chunking for downloads or uploads, the HTTP actions in your logic app automatically chunk large messages.

https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-handle-large-messages#set-up-chunking-over-http
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.

@DixitArora-MSFT Thanks for the reply. I would like to know also if the String limitations described in the doc (131,072 characters) applies to all String operations and functions.
If yes can you explain a bit this limit?


Exit status: 65 Building app with Gym and Xcode Automatic signing

Question Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Question Subject
I am trying to build and sign an app using Gym and Xcode's automatic ad hoc signing. I have the app built, signed using XCODE'automatic provisioning and signing feature. but couldn't do it with Gym.
Question Description
My fastlane file
lane :distribute_ota do
    build_numb = get_build_number()
    version = get_version_number()
    update_info_plist( # Change the Display Name of your app with t-num.version.num.build
        plist_path: "plutus/Configs/szb/Info.plist",
        #display_name: "b#{version}(#{build_numb})"
    )

    gym(
       scheme: "app Beta",
       configuration: "Beta",
       export_method: "ad-hoc",
       output_directory: "build",
       output_name: "app Beta.ipa",
       xcargs: "-allowProvisioningUpdates",
       include_bitcode: true,
       clean: true,
       export_xcargs: "-allowProvisioningUpdates",
       verbose: true
     )

    github_release = set_github_release(
      repository_name: "alouanemed/OTA",
      api_token: ENV["GITHUB_TOKEN"],
      name: "Super New actions",
      tag_name: "v0.0.1",
      description: (File.read("changelog") rescue "No changelog provided"),
      commitish: "master",
      upload_assets: ["build/App Beta.ipa"]
    )

    send_msg_to_slack
  end

▸ Running script 'R.swift'
▸ Running script 'PLUTUS Generate Apollo GraphQL API'
** ARCHIVE FAILED **

The following build commands failed:
PhaseScriptExecution PLUTUS\ Generate\ Apollo\ GraphQL\ API /Users/alouanemed/Library/Developer/Xcode/DerivedData/plutus-hcgydxapjqidfmaldslmgpvdjrff/Build/Intermediates.noindex/ArchiveIntermediates/app\ Beta/IntermediateBuildFilesPath/plutus.build/Beta-iphoneos/app.build/Script-4C46965622CE4BE000196BAA.sh
(1 failure)
[14:25:37]: Exit status: 65

+---------------+-------------------------+
|            Build environment            |
+---------------+-------------------------+
| xcode_path    | /Applications/Xcode.app |
| gym_version   | 2.126.0                 |
| export_method | ad-hoc                  |
| sdk           | iPhoneOS12.2.sdk        |
+---------------+-------------------------+

[14:25:37]: ▸ find: /Users/alouanemed/Library/Developer/Xcode/DerivedData/plutus-hcgydxapjqidfmaldslmgpvdjrff/Build/Intermediates.noindex/ArchiveIntermediates/app: No such file or directory
[14:25:37]: ▸ find: Beta/BuildProductsPath/Beta-iphoneos: No such file or directory
[14:25:37]: ▸ /Users/alouanemed/Library/Developer/Xcode/DerivedData/plutus-hcgydxapjqidfmaldslmgpvdjrff/Build/Intermediates.noindex/ArchiveIntermediates/app Beta/IntermediateBuildFilesPath/plutus.build/Beta-iphoneos/app.build/Script-4C46965622CE4BE000196BAA.sh: line 11: cd: /Users/alouanemed/Projects/iOS/app: No such file or directory
[14:25:37]: ▸ /Users/alouanemed/Library/Developer/Xcode/DerivedData/plutus-hcgydxapjqidfmaldslmgpvdjrff/Build/Intermediates.noindex/ArchiveIntermediates/app Beta/IntermediateBuildFilesPath/plutus.build/Beta-iphoneos/app.build/Script-4C46965622CE4BE000196BAA.sh: line 12: /Users/alouanemed/Library/Developer/Xcode/DerivedData/plutus-hcgydxapjqidfmaldslmgpvdjrff/Build/Intermediates.noindex/ArchiveIntermediates/app: No such file or directory
[14:25:37]: ▸ Command PhaseScriptExecution failed with a nonzero exit code
[14:25:37]:
[14:25:37]: ⬆  Check out the few lines of raw `xcodebuild` output above for potential hints on how to solve this error
[14:25:37]: 📋  For the complete and more detailed error log, check the full log at:
[14:25:37]: 📋  /Users/alouanemed/Library/Logs/gym/v Beta-app Beta.log
[14:25:37]:
[14:25:37]: Looks like fastlane ran into a build/archive error with your project
[14:25:37]: It's hard to tell what's causing the error, so we wrote some guides on how
[14:25:37]: to troubleshoot build and signing issues: https://docs.fastlane.tools/codesigning/getting-started/
[14:25:37]: Before submitting an issue on GitHub, please follow the guide above and make
[14:25:37]: sure your project is set up correctly.
[14:25:37]: fastlane uses `xcodebuild` commands to generate your binary, you can see the
[14:25:37]: the full commands printed out in yellow in the above log.
[14:25:37]: Make sure to inspect the output above, as usually you'll find more error information there
[14:25:37]:
+------------------+--------------------+
|             Lane Context              |
+------------------+--------------------+
| DEFAULT_PLATFORM | ios                |
| PLATFORM_NAME    | ios                |
| LANE_NAME        | ios distribute_ota |
| BUILD_NUMBER     | 4                  |
| VERSION_NUMBER   | 0.0.2              |
+------------------+--------------------+
[14:25:37]: Error building the application - see the log above

+------+--------------------+-------------+
|            fastlane summary             |
+------+--------------------+-------------+
| Step | Action             | Time (in s) |
+------+--------------------+-------------+
| 1    | default_platform   | 0           |
| 2    | setup_circle_ci    | 0           |
| 3    | get_build_number   | 0           |
| 4    | get_version_number | 2           |
| 5    | update_info_plist  | 0           |
| 💥   | gym                | 221         |
+------+--------------------+-------------+

[14:25:37]: fastlane finished with errors

[!] Error building the application - see the log above

The bug  was related to graphql new build system https://github.com/apollographql/apollo-ios


Not possible to connect

When I'm trying to setup this integration I get this error.
Note: this integration was working well until now.
"Cannot connect to host www.ariston-net.remotethermo.com:443"
Log trace:
Unexpected exception
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/aiohttp/connector.py", line 1152, in _create_direct_connection
hosts = await asyncio.shield(host_resolved)
File "/usr/local/lib/python3.10/site-packages/aiohttp/connector.py", line 874, in _resolve_host
addrs = await self._resolver.resolve(host, port, family=self._family)
File "/usr/local/lib/python3.10/site-packages/aiohttp/resolver.py", line 33, in resolve
infos = await self._loop.getaddrinfo(
File "/usr/local/lib/python3.10/asyncio/base_events.py", line 863, in getaddrinfo
return await self.run_in_executor(
File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/local/lib/python3.10/socket.py", line 955, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -3] Try again
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/ariston/ariston_api.py", line 390, in async_connect
response = await self._async_post(
File "/usr/local/lib/python3.10/site-packages/ariston/ariston_api.py", line 711, in _async_post
return await self.__async_request("POST", path, None, body)
File "/usr/local/lib/python3.10/site-packages/ariston/ariston_api.py", line 685, in __async_request
response = await session.request(
File "/usr/local/lib/python3.10/site-packages/aiohttp/client.py", line 536, in _request
conn = await self._connector.connect(
File "/usr/local/lib/python3.10/site-packages/aiohttp/connector.py", line 540, in connect
proto = await self._create_connection(req, traces, timeout)
File "/usr/local/lib/python3.10/site-packages/aiohttp/connector.py", line 901, in _create_connection
_, proto = await self._create_direct_connection(req, traces, timeout)
File "/usr/local/lib/python3.10/site-packages/aiohttp/connector.py", line 1166, in _create_direct_connection
raise ClientConnectorError(req.connection_key, exc) from exc
aiohttp.client_exceptions.ClientConnectorError: Cannot connect to host www.ariston-net.remotethermo.com:443 ssl:default [Try again]
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/config/custom_components/ariston/config_flow.py", line 68, in async_step_user
reponse = await ariston.async_connect(
File "/usr/local/lib/python3.10/site-packages/ariston/init.py", line 46, in async_connect
return await self.api.async_connect()
File "/usr/local/lib/python3.10/site-packages/ariston/ariston_api.py", line 403, in async_connect
raise ConnectionException() from error
ariston.ariston_api.ConnectionException

This is not an issue with this integration


[BUG]

dart run msix:create
Building package executable... (4.0s)
Built msix:create.
running "flutter build windows"...     10.9s
building msix files...                 /Unhandled exception:
PathNotFoundException: Directory listing failed, path = 'C:\projects\myapp\build\windows\x64\runner\Release\Images*' (OS Error: The system cannot find the path specified.
, errno = 3)

@jbridgenet your path has a * in it -- which configuration option were you using, and have you tried replacing it with the exact name of the folder or file instead?


build: do not close tracking issues

Description

What is the purpose of this pull request?

This pull request:

modifies the generate_pr_commit_message script to not close tracking issues.
checks for (tracking issue) in the issue title, or a Tracking issue label.

Related Issues

Does this pull request have any related issues?

None.
Questions

Any questions for reviewers of this pull request?

No.
Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.
Checklist

Please ensure the following tasks are completed before submitting this pull request.

[x] Read, understood, and followed the contributing guidelines.

@stdlib-js/reviewers

@gunjjoshi Thanks for opening this PR; however, there may be legitimate instances where we do want a commit/PR to close a tracking issue.
I think the actual workaround is that @Planeshifter needs to be more diligent about not closing tracking issues and first checking the linked issue(s) in the OP before further review/merge. This has been a too frequent occurrence recently.
In general, verifying linked issues is on the reviewer. For example, it is fairly common for me to manually update an OP to ensure that certain issues are not closed.

If I'm not wrong, this just changes the final commit message right? GitHub automatically closes linked issues (linked using keywords like "Resolves") when a pull request is merged (ref).
Maybe we can follow the GitHub flow and create sub-issues (a new feature ig). Each PR resolves a sub issue. This will also fix the problem of manually having to update a list of checkboxes.

That could be possible. Also, as we already have tracking issues setup in place, I believe we can think of sub-issues when we create new tracking issues in the future.

@kgryte Thanks for the suggestions. We might require closing the tracking only a single time, while the sub-tasks would be more often. For this, can we add a custom keyword (different from ones such as "Closes", "Resolves", etc)? We can add that custom keyword in the OP, if the PR completes the last task in the tracking issue. If that custom keyword is mentioned in the OP, we can then add "Closes" in the commit message.
But I am not sure if we should do this.

We can investigate using sub-issues going forward, but this will still be helpful in the meantime.
However, Snehil raises an important point: if the PR post contains a "Resolves #", then even merging the PR with a different commit message still auto-closes the tracking issue.
In light of this, it would be good if we could add a sentence to the posted comment that informs the reviewer of the tracing issue and instructs them to edit the opening PR post.
Would you be able to add that please, @gunjjoshi?
Can you also change the current behavior to only check for the label and not the issue title? @kgryte and I discussed the PR quickly and landed on that as a cleaner alternative.
Last but not least, it would be good for us to update the pull request template, which currently has a "Resolves #" placeholder, with a comment on how to reference issues    properly depending on the circumstances.

Landing. Thanks @gunjjoshi for suggesting this improvement!


Allow to use macro calls in enum definitions

Feature request:
macro make_foo x
  {{x}}_u32 * 3
end

enum Foo
  A = make_foo 0
  B = make_foo 1
end

Bonus: allow the macro definition inside the enum.

Related to #429 and #236

I can probably fix this for 0.18.0 too


feat: design-system translations [NP-974]

This is a draft, don't go too heavy on the code review right now (if at all) but do feel free to check it out and try it out.
This PR introduces a language switcher to the design system, and more importantly rails translations to the hall templates.
What's not here:

documentation
handling code transformations in the right place (should we use a json loader after the haml one?
better way of importing haml templates - would be nice to have a default for templates that contain no translations? (maybe?)
better haml.rb code structure. it was fine when it was a scrappy little script but it'd be nice to make it act like an adult. little more structure, some help text, error messages. that sort of thing.
tests

This looks great! Glad the approach we sketched out actually works! Couple of things I noticed whilst playing around:

The default property comes back as a buffer, rather than a string. I think we want this to be raw text so we can use it to get the source code view working.
Maybe we could write our own little wrapper around Story. Might take a little configuration, but I think the doc blocks are little React components so we could have something like:

import { Story } from '@storybook/addon-docs/blocks';
import { translate } from '../../../scripts/story-helpers';

const HamlStory = ({ haml, ...storyProps }) => {
  return (
    <Story {...storyProps}>{(_, options) => translate(haml, options)}</Story>
  );
};

export default HamlStory;

This looks great so far though!

Maybe we could write our own little wrapper around Story. Might take a little configuration, but I think the doc blocks are little React components so we could have something like:

So... I added a version as both a decorator and a component. I think either works... the component hides a lot of complexity automating the docs side of things, I'm not 100% sure I like it. Using the decorator leads to more explicit code which might work in the projects favour in the future.

Quite a few changes to the build to get this to pass:

docker ignore vendor/bundle (this caused nokogiri and ffi gem failures).
properly configure nokogiri installation.
install ruby-bigdecimal which is needed for activesupport to run on alpine.
build and then serve the styleguide rather than use webpack hot loader
serve docs from 6006 so test urls match up.

Maybe we could write our own little wrapper around Story. Might take a little configuration, but I think the doc blocks are little React components so we could have something like:

Replying here for future reference. We looked into creating a nicer API for writing stories that contain HAML but there's a fair amount of complexity in writing a DocBlock component that goes beyond creating a simple wrapper. We've decided to park it until there's a clearer understanding of what's required.

I'm going to try out the instructions and npm link this to public website to confirm I can get translations working there. Will report back.

For our future selves. I tested this using npm link and adding = t('cads.example.body') to a template.
Needed to move the i18n config out of config/application.rb and into config/initializers/locales.rb with the following config:
# frozen_string_literal: true

I18n.available_locales = [:en, :cy]

# Add design-system locales to the load path
I18n.load_path += Dir[
  Rails.root.join("node_modules/@citizensadvice/design-system/locales/*.yml"),
]

That allowed our design-system translations to a) load correctly and b) be overridable by the application if needed.


Installing helper binaries failed (Mac Homebrew)

--- Creating vim config symlinks
~/.vimrc -> /Users/ed/.config/haskell-vim-now/.vimrc
~/.vim   -> /Users/ed/.config/haskell-vim-now/.vim
--- Installing plugins using vim-plug...
--- Setting up GHC if needed...
Stack bin path: /Users/ed/.local/bin
Stack global path: /Users/ed/.stack
Stack global config location: /Users/ed/.stack/global-project/stack.yaml
Stack resolver: lts
/Users/ed/.config/haskell-vim-now/.stack-bin -> /Users/ed/.local/bin
--- Installing helper binaries...
Plan construction failed.
*** Binary installation failed with error 1.
*** Aborting...

This sounds like a possible LTS-4 issue, perhaps similar to #193
Can you tell me which LTS version you are using? (Should be listed in Users/ed/.stack/global-project/stack.yaml)

Looks like I'm using lts-6.2.

Same problem with lts-7.0

I'll investigate tonight or tomorrow night.

Cool, thanks.

I think I have the same/similar issues on Mac OS with Homebrew
--- Installing helper binaries...
While constructing the BuildPlan the following exceptions were encountered:

--  Failure when adding dependencies:
      machines-directory: needed (>=<IP_ADDRESS> && <0.3), stack configuration has no specified version (latest applicable is <IP_ADDRESS>)
    needed for package codex-<IP_ADDRESS>

--  While attempting to add dependency,
    Could not find package machines-directory in known packages

Recommended action: try adding the following to your extra-deps in /Users/eugenezhulenev/.stack/global-project/stack.yaml
- machines-directory-<IP_ADDRESS>

You may also want to try the 'stack solver' command

*** Binary installation failed with error 1.
*** Aborting...

After I added dependencies to extra-deps I got this error:
--- Installing helper binaries...

--  While building package codex-<IP_ADDRESS> using:
      /Users/eugenezhulenev/.stack/setup-exe-cache/x86_64-osx/setup-Simple-Cabal-<IP_ADDRESS>-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-osx/Cabal-<IP_ADDRESS> configure --with-ghc=/usr/local/bin/ghc --with-ghc-pkg=/usr/local/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/Users/eugenezhulenev/.stack/snapshots/x86_64-osx/lts-7.0/8.0.1/pkgdb --package-db=/Users/eugenezhulenev/.stack/global-project/.stack-work/install/x86_64-osx/lts-7.0/8.0.1/pkgdb --libdir=/Users/eugenezhulenev/.stack/global-project/.stack-work/install/x86_64-osx/lts-7.0/8.0.1/lib --bindir=/Users/eugenezhulenev/.stack/global-project/.stack-work/install/x86_64-osx/lts-7.0/8.0.1/bin --datadir=/Users/eugenezhulenev/.stack/global-project/.stack-work/install/x86_64-osx/lts-7.0/8.0.1/share --libexecdir=/Users/eugenezhulenev/.stack/global-project/.stack-work/install/x86_64-osx/lts-7.0/8.0.1/libexec --sysconfdir=/Users/eugenezhulenev/.stack/global-project/.stack-work/install/x86_64-osx/lts-7.0/8.0.1/etc --docdir=/Users/eugenezhulenev/.stack/global-project/.stack-work/install/x86_64-osx/lts-7.0/8.0.1/doc/codex-<IP_ADDRESS> --htmldir=/Users/eugenezhulenev/.stack/global-project/.stack-work/install/x86_64-osx/lts-7.0/8.0.1/doc/codex-<IP_ADDRESS> --haddockdir=/Users/eugenezhulenev/.stack/global-project/.stack-work/install/x86_64-osx/lts-7.0/8.0.1/doc/codex-<IP_ADDRESS> --dependency=Cabal=Cabal-<IP_ADDRESS> --dependency=MissingH=MissingH-<IP_ADDRESS>-EKn7kuoDq1aaX1Pfc3iyM --dependency=base=base-<IP_ADDRESS> --dependency=bytestring=bytestring-<IP_ADDRESS> --dependency=containers=containers-<IP_ADDRESS> --dependency=cryptohash=cryptohash-0.11.9-9KNu0EEbreBFrmNJAeHgYz --dependency=directory=directory-<IP_ADDRESS> --dependency=either=either-<IP_ADDRESS>-1JTyD8xndhVAzIXQKhnRWZ --dependency=filepath=filepath-<IP_ADDRESS> --dependency=hackage-db=hackage-db-1.22-I0Ykx1cW36Q2UDcO4nPCnl --dependency=http-client=http-client-<IP_ADDRESS>-CRzZbHb7fhvLc1hBac01Vk --dependency=lens=lens-4.14-LQbbTc84mRL8zB39b41ZKA --dependency=machines=machines-0.6.1-EtSiV7Anza02d5tsjlvU8s --dependency=machines-directory=machines-directory-<IP_ADDRESS>-KwmD3KP06ftLIcPjrPvOFu --dependency=monad-loops=monad-loops-0.4.3-1xZFtRVMQPC4X8bjTBWqNi --dependency=network=network-<IP_ADDRESS>-G4Up1CPKbp7DeFsnywOnGG --dependency=process=process-<IP_ADDRESS> --dependency=tar=tar-<IP_ADDRESS>-Lj53UbIqLpELgGWYmsAfKo --dependency=text=text-<IP_ADDRESS>-5QpmrLQApEZ4Ly9nMHWY0s --dependency=transformers=transformers-<IP_ADDRESS> --dependency=wreq=wreq-<IP_ADDRESS>-8bCdhFjgkLE6wlj1xh5qRg --dependency=yaml=yaml-<IP_ADDRESS>-8kElhq9L84mFnuAIrwPXyZ --dependency=zlib=zlib-<IP_ADDRESS>-4cYT5jyS3jw6zZyCUZMz3T
    Process exited with code: ExitFailure 1
    Logs have been written to: /Users/eugenezhulenev/.stack/global-project/.stack-work/logs/codex-<IP_ADDRESS>.log

    Configuring codex-<IP_ADDRESS>...
    setup-Simple-Cabal-<IP_ADDRESS>-ghc-8.0.1: Encountered missing dependencies:
    codex ==<IP_ADDRESS>
*** Binary installation failed with error 1.
*** Aborting...

Tried with lts-7.0 and lts-6.18

I think I know what is the problem: https://github.com/begriffs/haskell-vim-now/blob/master/scripts/setup.sh#L8
--- Setting up GHC if needed...

That's nasty, we are suppressing stderr, so we do not know what's going on. And we are also not doing any error checking!
We could use awk instead: awk '{if ($1 == "resolver:") {print $2}}'


Redundant folder tabs when opening a folder location from a third-party app

Description
(I'm not sure if this should be classified as a feature request or a bug)
When opening a folder location using a third-party app, Files does not verify if the folder is already open. As a result, it creates a new tab for the same folder, leading to duplicate tabs displaying the same folder
Steps To Reproduce

Open a folder (C:/Test for example)
Have a third-party app to open that folder (That would be a Chrome download to C:/Test, and pressing the tab icon to open the download directory)

Requirements
Files should check if, in the active tabs, the folder is opened or not. If it is, then redirect to that tab. Otherwise, create a tab for that folder
Files Version
<IP_ADDRESS>
Windows Version
10.0.22631.3880
Log File
debug.log

Thank you for the feedback, can you confirm if this is the same as #6925?

Oops my bad, indeed I should actually check before posting if it's a duplicate or not, but yes that the same as #6925


events defined by chart.on(eventName, ... are not triggered

defined events are not triggered
(at least) finished and rendered events are not triggered/executed.
Version & Environment

ECharts version v4.2.0-rc2
Browser version chrome-70.0.3538.77
OS Version windows 7

Expected behaviour
the function defined should be triggered.
in given example:
having 'finished loading' in console
ECharts option
var myChart = echarts.init(document.getElementById('chart1'), null, {
	"devicePixelRatio": null,
	"renderer": "canvas",
	"width": null,
	"height": "600px"
});
myChart.setOption({
	"title": {
		"text": "test",
	},
	"grid": [
		{
			"top": "5%",
			"height": "60%",
			"width": "60%",
			"left": "5%",
			"containLabel": false,
			"borderColor": "transparent",
			"show": "1"
		}
	],
	"xAxis": [
		{
			"type": "time",
			"min": "dataMin",
			"max": "dataMax"
		}
	],
	"yAxis": [
		{
			"type": "value",
		}
	],
	"series": {"name": "insufficient_data", "type": "bar"},
});

myChart.on('finished', function (params){
	console.log('finished loading');
});

@arashdalir - this works for me without problems running on Chrome 70 / Windows 7.
Could it be you do not wait for page loading complete before initializing your div object?
E.g.

...

found the issue. there is a problem with triggering the events when the dataset is empty. if there is no data to be rendered, the events are not triggered. it is not dependant on the onload function, but rather the data of the series; which is a big inconevience.
there is also another problem with mouse-events; they ONLY WORK if users click on series, but not on the chart itself. I assume the triggers are defined on the wrong subjects. please check out the commented series in following example:

console.log('started loading');

var myChart = echarts.init(document.getElementById('chart1'), null, {
	"devicePixelRatio": null,
	"renderer": "canvas",
	"width": null,
	"height": "600px"
});
myChart.setOption({
	"title": {
		"text": "test",
	},
	"grid": [
		{
			"top": "5%",
			"height": "60%",
			"width": "60%",
			"left": "5%",
			"containLabel": false,
			"borderColor": "transparent",
			"show": "1"
		}
	],
	"xAxis": [
		{
			"type": "category",
			"min": "dataMin",
			"max": "dataMax"
		}
	],
	"yAxis": [
		{
			"type": "value",
		}
	],
	// "series": {"name": "insufficient_data", "type": "bar", "data": [[1, 2], [2, 3]]}, // this works
	// "series": {"name": "insufficient_data", "type": "bar", "data": []}, // this doesn't work
	// "series": {"name": "insufficient_data", "type": "bar"}, // this neither
});

console.log('options set');

myChart.on('finished', function (params){
	console.log('finished loading');
});

even // "series": {"name": "insufficient_data", "type": "bar", data:[[0,0]]} doesn't work! which is now causing real issues...

Hmm, it still works for me. But I have set the finished event handler before setting the option...:
<!doctype HTML5>

Test

@arashdalir : Regarding Event triggers: There is a feature planned to expose grid events as well, see e.g. issue #9281.
@Ovilia - is there already a release planned containing this feature?

As intermediate solution, you could add an event listener to the parent div object in order to receive click-coordinates. They then can be transformed into real axis coordinates:
document.getElementById('chart-panel').addEventListener("click",function(e){
    console.log(e.zrX+"#"+e.zrY+'#'+myChart.convertFromPixel({xAxisIndex:0, yAxisIndex:0},[e.zrX,e.zrY]));
})

I'm afraid I have to inform you this only works to some extension.
now,

if there are no series defiend, finished event is happening before options are set.
if there is at least one series defined, the finished event is happening after options are set.

console.log('started loading');

var myChart = echarts.init(document.getElementById('chart1'), null, {
	"devicePixelRatio": null,
	"renderer": "canvas",
	"width": null,
	"height": "600px"
});

myChart.on('finished', function (){
	console.log('finished loading');
});

console.log('setting options');
myChart.setOption({
	"title": {
		"text": "test",
	},
	"grid": [
		{
			"top": "5%",
			"height": "60%",
			"width": "60%",
			"left": "5%",
			"containLabel": false,
			"borderColor": "transparent",
			"show": "1"
		}
	],
	"xAxis": [
		{
			"type": "category",
		}
	],
	"yAxis": [
		{
			"type": "value",
		}
	],
	//"series": {"name": "insufficient_data", "type": "scatter", data:[[0,0]]},
});
console.log('options set');

// console output WITHOUT SERIES:
started loading
setting options
finished loading
options set

// console output WITH series:
started loading
setting options
options set
finished loading

Hmm, it still works for me. But I have set the finished event handler before setting the option...:
<!doctype HTML5>

Test

I tried with option without series provided by @arashdalir , but the rendered and finished event is triggered.
As about the mouse event on other components, we are considering to support this. See: https://github.com/apache/incubator-echarts/issues/9281

@Ovilia  as said, the functions work, but in the wrong order. interesting enough, this has no effect on the chart's options (i.e. var options = chart.getOptions delivers the right options). so technically, it's not an issue on itself, but rather a chronological problem with the events...

In the axis option, you might have to add triggerEvent property.
myChart.setOption({         .         . 	"xAxis": [ 		{ 			triggerEvent: true, 		} 	], 	"yAxis": [ 		{ 			triggerEvent: true, 		} 	], })
This worked for me.
Hope it helps.


initial answers

initial answers

i tried to provide answers to most of the questions based on research and documentation, let me know if anything is incorrect.


Set up training routines and refine AI performance in the Snake game

Develop a training schedule for the AI
Implement performance metrics and logging
Tune hyperparameters for optimal learningAnalyze and iterate on AI performance

Done


Check it's getting new version properly

Jays told me it takes days to get new version

05cf63849772da7b73abf28ebf14244f2a4c6e76


2 BMS CONNECTION PROBLEM

I have been trying for three days to get an esp32 and a wemo d1 connected via UART-TTL to the bms of my second power bank to work but I am not able to, let's see if someone can help me because I am desperate.
I have 2 black jkbms in 2 power banks.
The first one is connected through the rs485 port via UART-TTL to an ESP WT32-ETH01 with the configuration that I indicate below and it works perfectly.
Now in my second power bank I bought another identical WT32-ETH01 and I have connected it the same as the first and I get this error:
[17:29:37][D][text_sensor:064]: 'w32-banco2 Errors': Sending state 'Offline'
[17:29:37][D][sensor:094]: 'w32-banco2 min cell voltage': Sending state nan V with 3 decimals of accuracy
[17:29:37][D][sensor:094]: 'w32-banco2 max cell voltage': Sending state nan V with 3 decimals of accuracy
[17:29:37][D][sensor:094]: 'w32-banco2 min voltage cell': Sending state nan  with 0 decimals of accuracy
[17:29:37][D][sensor:094]: 'w32-banco2 max voltage cell': Sending state nan  with 0 decimals of accuracy

When I put the WT32-ETH01 from bank 1 in bank 2 it works correctly, but I cannot get the new ESP WT32-ETH01 to work.
I have tried connecting bank 2 with a Wemo D1 in case the new WT32-ETH01 did not work, but it does the same.
What am I doing wrong?
CODE:
substitutions:
  name: w32-banco2

esphome:
  name: ${name}
  friendly_name: w32_banco2
  platform: ESP32
  board: esp-wrover-kit

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "1u757XEy/uOj/WcvTB7RpaSjGJx+PfiE7Mqspw="

ota:
  - platform: esphome
    password: "6299d3d3d0ec7414ff477302d"

ethernet:
  type: LAN8720
  mdc_pin: GPIO23
  mdio_pin: GPIO18
  clk_mode: GPIO0_IN
  phy_addr: 1
  power_pin: GPIO16

# Optional manual IP
  manual_ip:
    static_ip: <IP_ADDRESS>
    gateway: <IP_ADDRESS>
    subnet: <IP_ADDRESS>

external_components:
  - source: github://syssi/esphome-jk-bms@main
    refresh: 0s

uart:
  - id: uart_0
    baud_rate: 115200
    rx_buffer_size: 384
    tx_pin: GPIO3
    rx_pin: GPIO1

jk_modbus:
  - id: modbus0
    uart_id: uart_0
#  rx_timeout: 50ms

jk_bms:
  - id: bms0
    jk_modbus_id: modbus0
#  update_interval: 5s

sensor:
  - platform: jk_bms
    jk_bms_id: bms0
    min_voltage_cell:
      name: "${name} min voltage cell"
    max_voltage_cell:
      name: "${name} max voltage cell"
    min_cell_voltage:
      name: "${name} min cell voltage"
    max_cell_voltage:
      name: "${name} max cell voltage"
    delta_cell_voltage:
      name: "${name} delta cell voltage"
    cell_voltage_1:
      name: "${name} cell voltage 1"
    cell_voltage_2:
      name: "${name} cell voltage 2"
    cell_voltage_3:
      name: "${name} cell voltage 3"
    cell_voltage_4:
      name: "${name} cell voltage 4"
    cell_voltage_5:
      name: "${name} cell voltage 5"
    cell_voltage_6:
      name: "${name} cell voltage 6"
    cell_voltage_7:
      name: "${name} cell voltage 7"
    cell_voltage_8:
      name: "${name} cell voltage 8"
    cell_voltage_9:
      name: "${name} cell voltage 9"
    cell_voltage_10:
      name: "${name} cell voltage 10"
    cell_voltage_11:
      name: "${name} cell voltage 11"
    cell_voltage_12:
      name: "${name} cell voltage 12"
    cell_voltage_13:
      name: "${name} cell voltage 13"
    cell_voltage_14:
      name: "${name} cell voltage 14"
    cell_voltage_15:
      name: "${name} cell voltage 15"
    cell_voltage_16:
      name: "${name} cell voltage 16"
    cell_voltage_17:
      name: "${name} cell voltage 17"
    cell_voltage_18:
      name: "${name} cell voltage 18"
    power_tube_temperature:
      name: "${name} Power tube temperature"
    temperature_sensor_1:
      name: "${name} Temperature sensor 1"
    temperature_sensor_2:
      name: "${name} Temperature sensor 2"
    total_voltage:
      name: "${name} Total voltage"
    current:
      name: "${name} Current"
    capacity_remaining:
      name: "${name} Capacity remaining"
    capacity_remaining_derived:
      name: "${name} capacity remaining derived"
    temperature_sensors:
      name: "${name} Temperature sensors"
    charging_cycles:
      name: "${name} Charging cycles"
    total_charging_cycle_capacity:
      name: "${name} Total charging cycle capacity"
    battery_strings:
      name: "${name} Battery strings"
    errors_bitmask:
      name: "${name} Errors bitmask"
    operation_mode_bitmask:
      name: "${name} Operation mode bitmask"
    total_voltage_overvoltage_protection:
      name: "${name} Total voltage overvoltage protection"
    total_voltage_undervoltage_protection:
      name: "${name} Total voltage undervoltage protection"
    cell_voltage_overvoltage_protection:
      name: "${name} Cell voltage overvoltage protection"
    cell_voltage_overvoltage_recovery:
      name: "${name} Cell voltage overvoltage recovery"
    cell_voltage_overvoltage_delay:
      name: "${name} Cell voltage overvoltage delay"
    cell_voltage_undervoltage_protection:
      name: "${name} Cell voltage undervoltage protection"
    cell_voltage_undervoltage_recovery:
      name: "${name} Cell voltage undervoltage recovery"
    cell_voltage_undervoltage_delay:
      name: "${name} Cell voltage undervoltage delay"
    cell_pressure_difference_protection:
      name: "${name} Cell pressure difference protection"
    discharging_overcurrent_protection:
      name: "${name} Discharging overcurrent protection"
    discharging_overcurrent_delay:
      name: "${name} Discharging overcurrent delay"
    charging_overcurrent_protection:
      name: "${name} Charging overcurrent protection"
    charging_overcurrent_delay:
      name: "${name} Charging overcurrent delay"
    balance_starting_voltage:
      name: "${name} Balance starting voltage"
    balance_opening_pressure_difference:
      name: "${name} Balance opening pressure difference"
    power_tube_temperature_protection:
      name: "${name} Power tube temperature protection"
    power_tube_temperature_recovery:
      name: "${name} Power tube temperature recovery"
    temperature_sensor_temperature_protection:
      name: "${name} Temperature sensor temperature protection"
    temperature_sensor_temperature_recovery:
      name: "${name} Temperature sensor temperature recovery"
    temperature_sensor_temperature_difference_protection:
      name: "${name} Temperature sensor temperature difference protection"
    charging_high_temperature_protection:
      name: "${name} Charging high temperature protection"
    discharging_high_temperature_protection:
      name: "${name} Discharging high temperature protection"
    charging_low_temperature_protection:
      name: "${name} Charging low temperature protection"
    charging_low_temperature_recovery:
      name: "${name} Charging low temperature recovery"
    discharging_low_temperature_protection:
      name: "${name} Discharging low temperature protection"
    discharging_low_temperature_recovery:
      name: "${name} Discharging low temperature recovery"
    current_calibration:
      name: "${name} Current calibration"
    device_address:
      name: "${name} Device address"
    sleep_wait_time:
      name: "${name} Sleep wait time"
    alarm_low_volume:
      name: "${name} Alarm low volume"
    manufacturing_date:
      name: "${name} Manufacturing date"
    total_runtime:
      name: "${name} Total runtime"
    start_current_calibration:
      name: "${name} start current calibration"
    actual_battery_capacity:
      name: "${name} Actual battery capacity"
    protocol_version:
      name: "${name} Protocol version"

text_sensor:
  - platform: jk_bms
    errors:
      name: "${name} Errors"
    operation_mode:
      name: "${name} Operation mode"
    battery_type:
      name: "${name} Battery type"
    password:
      name: "${name} Password"
    device_type:
      name: "${name} Device type"
    software_version:
      name: "${name} Software version"
    manufacturer:
      name: "${name} Manufacturer"

binary_sensor:
  - platform: jk_bms
    balancing:
      name: "${name} balancing"
    balancing_switch:
      name: "${name} balancing switch"
    charging:
      name: "${name} charging"
    charging_switch:
      name: "${name} charging switch"
    discharging:
      name: "${name} discharging"
    discharging_switch:
      name: "${name} discharging switch"
    dedicated_charger_switch:
      name: "${name} dedicated charger switch"

Please don't use the TXD and RXD pin. The USB-to-TTL chip is attached here and the BMS doesn't like this. Please use any other GPIO instead.

Oh. Is there a USB-to-TTL chip on the WT32-ETH01? Nevertheless. Please try other GPIOs. :-)

Please don't use the TXD and RXD pin. The USB-to-TTL chip is attached here and the BMS doesn't like this. Please use any other GPIO instead.

I tried with GPIO14 and GPIO4 and the problem continues.

Anyway the wt32 of bank 1 works perfectly on the GPIO3 and GPIO1

Are you sure you haven't swapped the RX/TX lines accidentally?
Another idea is to use the ESP-IDF framework just for testing:
esp32:
  board: wemos_d1_mini32
  framework:
    type: esp-idf

Are you sure you haven't swapped the RX/TX lines accidentally?
Another idea is to use the ESP-IDF framework just for testing:
esp32:
  board: wemos_d1_mini32
  framework:
    type: esp-idf

It doesn't work either. Still giving the same error.

Hallo, i use this Pin´s on my ESP32 for 1xCAN and 2xModbus (1x JK-BMS, 1x Goodwe HV Hybrid  Inverter).
You are already using some of these pins, but it might work with the others.
ESP32 CAN/Serail port pins:
GPIO pins  CAN bus transceiver(TJA1050) is connected to the ESP, note! TX->TX and RX->RX.
can_tx_pin: GPIO23
can_rx_pin: GPIO22
GPIO pins  Modbus JK-BMS RS485(TTL) is connected to the ESP TX->RX and RX->TX.
tx_pin: GPIO17
rx_pin: GPIO16
GPIO pins  Modbus Goodwe RS485(TTL) is connected to the ESP TX->RX and RX->TX.
tx_pin2: GPIO1
rx_pin2: GPIO3
esphome:
name: testbms
friendly_name: testbms
esp32:
board: esp32dev
framework:
type: arduino
logger:
baud_rate: 0

This is starting to work.
First failure, I had the cables connected incorrectly.
Then I had to change the uart port, modbus and bms number to 1.
Now it starts showing data but cuts data from time to time with this error:
[W][uart.arduino_esp32:192]:   You're using the same serial port for logging and the UART component. Please disable logging over the serial port by setting logger->baud_rate to 0.
After giving this notice it continues to work correctly, but after a while it gives this other error and cuts off the communication: [W][jk_modbus:091]: CRC check failed! 0x54DA != 0x54EE
Now I have the GPIO1 and GPIO3. In the afternoon I will change the GPIOs for the 4 and 14 in case this solves the problem.

If you are using GPIO1/GPIO3 for TX/RX you have to disable the serial logging by setting the baud rate to 0:
logger:
  baud_rate: 0

If you are using GPIO1/GPIO3 for TX/RX you have to disable the serial logging by setting the baud rate to 0:
logger:
  baud_rate: 0

ok, that has solved the first warning, but it still gives this error:
[W][jk_modbus:091]: CRC check failed! 0x54CC != 0x54EC

Which framework (Arduino vs. ESP-IDF) do you use at the moment? How often do you see an CRC error?

Which framework (Arduino vs. ESP-IDF) do you use at the moment? How often do you see an CRC error?

if I write
esp32:
board: esp-wrover-kit
framework:
type: esp-idf
gives this error: [W][jk_modbus:063]: Invalid header: 0x38 0x2E
If I put this other:
esp32:
board: esp-wrover-kit
framework:
type: arduino
gives this error: [W][jk_modbus:091]: CRC check failed! 0x54EB != 0x54EC
This is how I have it in the other esp32 of power bank 1 that works perfectly:
esphome:
name: wt32
platform: ESP32
board: esp-wrover-kit

Please don't rush and take your time. Both warnings are about transmission errors. Transmission errors can happen from time to time. This is okay and doesn't harm (you just miss a frame of data from time to time). If this happens once per second this isn't fine anymore and must be resolved.
How often do you see CRC errors? Please check your wires / you need proper connections / double check GND. Avoid long cables etc.

Please don't rush and take your time. Both warnings are about transmission errors. Transmission errors can happen from time to time. This is okay and doesn't harm (if you just miss a frame of data from time to time). If this happens once per second this isn't fine anymore and must be resolved.
How often do you see CRC errors? Please check your wires / you need proper connections / double check GND. Avoid long cables etc.

Finally it seems to work correctly. I have had to change the GPIOs to 14 and 4 and now there seems to be no cuts.

Thanksss!!!
Gracias!!!!


I wish the site supported increasing the text size

I wish the site supported increasing the text size.  On Firefox, if you do a single zoom in, the page shifts way to the right and the left half of the browser is just white space.

cc @CreaturesInUnitards can you investigate the weird zooming behavior on Firefox?

yup fixed


Refactor search: implement elastic search

search has to use "common" search logic and operators - ideally as it is used by Google search

AND, OR, NOT operators
concatination of two words means AND by default ("Ada Lovelace" means Ada AND Lovelace)
if possible allows the use of wildcards * or ?
to be discussed: should parts of the word already match or does it have to be the exact word that is matching? e.g. right now looking for Ada matches firstname Ada but also the twitter handle mADAmecurie

http://joelabrahamsson.com/elasticsearch-101/
german: http://www.schwarzer.de/blog/elasticsearch-tutorial-das-konzept-verstehen/
Video: https://www.youtube.com/watch?v=P6VqWiXsGIo
Book: https://www.elastic.co/guide/en/elasticsearch/guide/master/index.html

I think we want to use this gem: https://github.com/elastic/elasticsearch-rails
Here is a tutorial video:
https://www.youtube.com/watch?v=Pse-2ZkVaTs

Testing elastic search with RSpec: http://www.binarywebpark.com/testing-elasticsearch-in-your-rails-4-application/

Heroku Add-on for Elasticsearch: https://devcenter.heroku.com/articles/bonsai

@zaziemo @tyranja We know great people at Elastic. I could try ping some folks who might be able to help with an initial implementation, or at least some good advice, if you want.

@svenfuchs yes, that would be cool. Good advice always helps :)

have a look on that migration for indexes: db/migrate/20151216091821_add_missing_indexes.rb
do we have to revert it or can we reuse this index?

[ ] add Pagination: https://github.com/elastic/elasticsearch-rails/blob/master/elasticsearch-model/README.md
[ ] solve problems with splitting city and languages

Thanks for your great work @BriocheBerlin. All tests are passing :)
But I realize some crazy behaviour:

if the search box is empty and you click on search button 488 search results are shown - but these are not all the profiles. What are they based on?
if I look for my full name, I get 387 results - I am the first one (yay!) but how can we reduce the other results? Put more weight on fullname? reduce the fuzzyness?


adds support for waiter cluster name env variable

Changes proposed in this PR

adds support for waiter cluster name env variable

Why are we making these changes?
We would like to allow services launched via Waiter to know which Waiter cluster they are running on. This allows the service to make cluster-specific decisions inside its configuration.
Note:
This PR also exposes the settings in a promise inside config.clj enabling mount-like behavior inside waiter for the settings which are effectively constants. This allows us to avoid threading through the cluster name across all the schedulers down to the function that builds the environment. The dependency on the need for the config is still explicit as the tests need to introduce the appropriate with-redef.

@DaoWen I thought about this some and I agree with you regarding locality sensitive decisions. I still feel though having the cluster information available in the environment enables other features e.g. it allows services to track when they are running on a cluster other than where the token was registered.
@sradack also brought up an interesting idea of having cluster-specific environment entries for tokens where downstream dependencies could be configured. This would have to be supported as a new parameter. In such a world, having the cluster environment variable would still help with debugging as it informing which cluster name was used to load the cluster-specific entries.

@sradack renamed to WAITER_CLUSTER

Rebased to avoid merge conflicts.


Support for other signing methods

Hi there.  Thanks for the library.
Per https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-3.1 the spec supports PSS and ECDSA.  It looks like the go crypto library supports this as well.  Do you have any plans to implement this as a signing mechanism?
If not I can take a crack at the implementation
   +--------------+-----------------------------------+----------------+
   | alg Param    | Digital Signature or MAC          | Implementation |
   | Value        | Algorithm                         | Requirements   |
   +--------------+-----------------------------------+----------------+
   | HS256        | HMAC using SHA-256                | Required       |
   | HS384        | HMAC using SHA-384                | Optional       |
   | HS512        | HMAC using SHA-512                | Optional       |
   | RS256        | RSASSA-PKCS-v1_5 using SHA-256    | Recommended    |
   | RS384        | RSASSA-PKCS-v1_5 using SHA-384    | Optional       |
   | RS512        | RSASSA-PKCS-v1_5 using SHA-512    | Optional       |
   | ES256        | ECDSA using P-256 and SHA-256     | Recommended+   |
   | ES384        | ECDSA using P-384 and SHA-384     | Optional       |
   | ES512        | ECDSA using P-521 and SHA-512     | Optional       |
   | PS256        | RSASSA-PSS using SHA-256 and MGF1 | Optional       |
   |              | with SHA-256                      |                |
   | PS384        | RSASSA-PSS using SHA-384 and MGF1 | Optional       |
   |              | with SHA-384                      |                |
   | PS512        | RSASSA-PSS using SHA-512 and MGF1 | Optional       |
   |              | with SHA-512                      |                |
   | none         | No digital signature or MAC       | Optional       |
   |              | performed                         |                |
   +--------------+-----------------------------------+----------------+

I started working on the ECDSA class of signing methods, but ended up down going down a rabbit hole on key serialization and the JWK format.  I keep meaning to get back to it, but I've been busy.  Feel free to give it a crack if you have the time.
Also worth noting, since I've seen some branches that are just for this purpose, you can add signing methods without forking this library.  Simply call RegisterSigningMethod at some point before you try to use the parser.

For a discussion on the none signing method, see https://github.com/dgrijalva/jwt-go/pull/34#issuecomment-58966750

@dgrijalva Hey thanks for responding.  I'm not sure if this is what you're looking for, but I added in PSS so far.  I need to add tests.
https://github.com/patbaker82/jwt-go/commit/42328dd1dc47b3ea41ea40c22fe48e9987a6ef83

Thanks! I'll review as soon as there are passing tests.
Why mush it into rsa.go vs creating a separate file?  Might be easier to follow.

@dgrijalva Sounds good.  No reason for not creating a separate file other than it was a quick edit.  I'll clean things up and see if I can tackle ECDSA.  However I might do that in a separate branch just to get in PSS (which I need :smile: )

@dgrijalva Pull request #72 has been created to support RSASSA-PSS

@dgrijalva Pull request #74 has been created to support ECDSA

thanks!


Examples from handbook for "Writing .d.ts files" do not compile with 1.6.2

I copied the examples for external modules from here http://www.typescriptlang.org/Handbook#writing-dts-files-examples into files and fed them to the compiler. They both do not compile. The zoo example can be fixed by adding a "declare", but i have no idea how to fix the eagle example.
See my test project here: https://github.com/uwinkelvos/tsc-dts-bug

Hey @uwinkelvos, if you'd like to send a PR to https://github.com/Microsoft/TypeScript-Handbook, we'd appreciate it.

Just a question, which eagle example do you mean specifically?

This:
https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Writing Definition Files.md#typing-4
https://github.com/uwinkelvos/tsc-dts-bug/blob/master/external/eagle.d.ts
I kind of need exactly that functionality to type koa-body.

Fixed by https://github.com/Microsoft/TypeScript-Handbook/pull/102
What's wrong with that example? It seems to work correctly in the playground.

The .d.ts file will "compile", but the code using it won't. please see: https://github.com/uwinkelvos/tsc-dts-bug

Wow, I just realized that. That's awful. I think the intent was to export something that had a type and value side, but the example conveys that poorly.

Fixed in 55ceaf7b86ff4314dfd8b3bb8214d336ddd02bb1.

ah thx. fixed the eagle-eddie-diversion here: https://github.com/Microsoft/TypeScript-Handbook/pull/103
This might not solve my Koa typing problems though, but that's an other story/issue. :)

Hopefully you're not having too much trouble! Feel free to post an issue if there's a real problem with the language, or if you're unsure of how to accomplish something there's always StackOverflow and Gitter.


Create a slide out for debug contracts

While navigating and testing your dapp you have to always go back to the debug page to test a contract directly. We are proposing adding a slide-out for the debug contracts with a selector of some sort to choose which contract you want to interact with.

@codenamejason Hello,
I did something like that. I don't know if this is what expected :p
Have a look if you'd like : https://scaffoldeth-cm-challenge3.surge.sh/
Code : https://github.com/AntFrasier/Forke-scaffold-eth-challenges/tree/challenge-3-dice-game