feat: support and enforce number and boolean transform functions

You should also change reportMissingInputProp to generate the correct code in case the type is boolean/number.
And you should add the corresponding test cases:
		{
			code: codeTemplate('', 'myProp: boolean;'),
			errors: [{messageId: 'missingProp', data: {type: 'input', name: 'myProp'}}],
			output: codeTemplate("\n\t@Input({alias: 'auMyProp', transform: auBooleanAttribute}) myProp: boolean | undefined;\n", 'myProp: boolean;'),
		},
		{
			code: codeTemplate('', 'myProp: number;'),
			errors: [{messageId: 'missingProp', data: {type: 'input', name: 'myProp'}}],
			output: codeTemplate("\n\t@Input({alias: 'auMyProp', transform: auNumberAttribute}) myProp: number | undefined;\n", 'myProp: number;'),
		},

thx for the reivew @divdavem ! I have made some changes following your recommendations, when you have time to check ;)

thx for the reivew @divdavem ! I have made some changes following your recommendations, when you have time to check ;)

Thank you for taking my comments into account!
Apart from the logic to coerce to number, I am fine with the PR.


Language translation of mod description in the game?

Hello!
I would like to understand how (for this 0ad mod, maybe applicalbe for other 0ad mods as well) a translation could be done?
E.g., this one shows "Allied Map" and the explanation "Toggle allied map (see what your allies see)."
How could this be translated to other languages, ideally depending on which language is set in the main game?
Thanks for your help and for all the great with this mod and other development!

Hi @7wells!
Translations go in a folder in the mod called l10n. In there, you can see a file called en_GB.public-gui-gamesetup-CartographyMode.po.
I think the easiest way to add translations is to copy-paste the file I mentioned above, replacing 'en_GB' with the 2-letter code for your language e.g. de.public-gui-gamesetup-CartographyMode.po, for German. Then, in the new file, replace all the strings paired with msgstr with your translations. (msgid is the "identifier" for the translation.)
2 letter language codes can be found here: https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
Any translations would be very welcome :). Cheers.


HSEARCH-2554 Using array/iterable/map field bridges requires the @IndexedEmbedded annotation (second attempt)

https://hibernate.atlassian.net/browse/HSEARCH-2554
Please do not merge yet, we'll probably have to wait until 6.0 because this changes the behavior of Hibernate Search for @IndexedEmbedded-annotated fields.
Submitting this PR anyway so that we don't lose the commits.

@yrodiere IIRC you already implemented at least part of it if not all of it in Search 6. If so we could close this PR too.

@gsmet Done.
As for #1288 , this is probably solved in Search 6 but not tested explicitly yet, so I'll leave the ticket open for now.


Halftone Encoding Algorithm is Broken

When using 'halftone' algorithm for image encoding, a Python error is present:
⏳ Applying halftone dithering to image...
Traceback (most recent call last):
  File "/Projects/cat_printer_interface/catprinter/print-modified.py", line 80, in <module>
    custom()
  File "/Projects/cat_printer_interface/catprinter/print-modified.py", line 48, in custom
    data = cmds_print_img(bin_img, dark_mode=True)
  File "/Projects/cat_printer_interface/catprinter/catprinter/cmds.py", line 167, in cmds_print_img
    data += cmd_print_row(row)
  File "/Projects/cat_printer_interface/catprinter/catprinter/cmds.py", line 127, in cmd_print_row
    encoded_img = run_length_encode(img_row)
  File "/Projects/cat_printer_interface/catprinter/catprinter/cmds.py", line 101, in run_length_encode
    if val == last_val:
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
✅ Done.

$ python --version Python 3.10.2

Thanks for filing the issue @8bitben. I took a quick look and #38 should fix it.


Change empty-list text for initial app start

When there are no items in the list, text is displayed saying "No Items". However, that text displays when the app first starts because the items are being loaded from memory.
It would be cool to differentiate between loading and an empty list. If there's a way to detect when the app is being started for the first time, say "Loading." And the text would say "No Items" if the user empties the list while using the app.

The empty-list view was removed (158e80fb28444821be51e1f7e8cb6c44e29dd8a4 and 182c48727c1808f41264a2888a0e3b88406290f1).

No longer needed because:

As mentioned above, the empty-list view was removed
The total number of items is displayed at the top, so the user knows if the list is empty.


socks-proxy is missing in the service list matrix (cloudflared)

Which Cloudflare product does this pertain to?
Zero Trust
Existing documentation URL(s)
https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/tunnel-guide/local/local-management/ingress/#supported-protocols
What changes are you suggesting?
"Socks-proxy" is not listed in the supported service matrix. Since it is one of the supported services and working in field, please add it to that.
https://github.com/cloudflare/cloudflared/commit/206523344f290dcf787156348e55a17348f9569f
ingress:

hostname: socks.example.com
service: socks-proxy

Additional information
No response

Hi there - This looks like a feature request. Feel free to open a feature request with that team at https://github.com/cloudflare/cloudflared/issues.


Update main ci_* playbooks structure

rename ci_tendrl_cluster.yml to ci_default.yml

install and configure Tendrl server and nodes
do not install and configure Ceph or Gluster
usable for cluster creation via Tendrl API/UI

rename ci_default.yml to ci_default_import.yml

install and configure Tendrl server and nodes
install and configure Ceph or/and Gluster cluster
usable for cluster import testing via Tendrl API/UI

It looks like big changes, but it's just file renaming.

Please, do not merge it yourself, because I'll have to update jenkins jobs once it will be merged. Just approval is enough :).


Not working with a map of element

I did try to add a array of element's and I work with a .map to get a View element out for every one of them - the first element returned is showing for me but not the rest.

same issue here


net/http: Transport's errServerClosedIdle escapes to callers

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.8 linux/amd64
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jonhall/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build059328702=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
What did you do?
Tests in one of my applications are frequently receiving the error http: server closed idle connection.  Code comments make me think this error should never be visible. (I fully suspect a buggy server, which is dropping connections, but this issue isn't about that behavior, per se.)
This issue is simply intended to clarify the intended behavior of the net/http package with respect to this error message.
Is the fact that I see this error message a bug which should be reported? (If so, I'll produce a MRE and file a followup issue).  Or is the source comment (line 605 here) just misleading?

Yeah, I don't think that should be visible. I thought it was an internal error that caused the Transport to pick a new conn.
What's your Transport config & usage of the Transport look like?

Thanks for the quick response. I'll work on putting together a minimal reproduction case, and follow up shortly.

I am able to reproduce with this minimal Go code, communicating with a CouchDB 1.6.1 server, running in a Docker environment (I can provide minimal setup instructions if necessary).  I've not yet been able to reproduce the same behavior with an httptest server, which would of course make it so much easier to debug. Since it's not possible to completely reproduce this with just the Go code, I am including as much relevant information as I can think of below. Please let me know what additional info I can provide.
main.go
Note that the failure is semi-random.  It's probably triggered by a race condition (whether the race is happening in the Go library, or on the server, I don't yet know).
With 2 or more simultaneous HTTP requests, the script inevitably panics with one of two errors, after successfully handling an arbitrary number of requests.
panic: Put http://localhost:9000/foo/7.txt: http: server closed idle connection

or
panic: Put http://localhost:9000/foo/4.txt: EOF

I'm not sure how related these are, except that I expect they're both related to the server dropping the connection unexpectedly (perhaps the difference is whether the drop occurs mid-request, or between requests).
As I increase concurrency, the frequency of 'http: server closed idle connection' increases relative to the EOF errors.  For example:

with 2 concurrent requests, after 30 runs I observed 28 EOF panics, and 2 closed idle connection panics.
with 5 concurrent requests and 30 runs, I observed 11 EOF panics versus 19 closed idle connection panics.

I have also done some network captures (sudo tcpdump -i lo -s 0 -w capture) to capture the network traffic of both classes of failure.
This run is captured here:
$ go run main.go
PUT http://localhost:9000/foo/5.txt
PUT http://localhost:9000/foo/2.txt
PUT http://localhost:9000/foo/1.txt
PUT http://localhost:9000/foo/3.txt
PUT http://localhost:9000/foo/4.txt
PUT http://localhost:9000/foo/10.txt
PUT http://localhost:9000/foo/15.txt
PUT http://localhost:9000/foo/6.txt
PUT http://localhost:9000/foo/7.txt
panic: Put http://localhost:9000/foo/10.txt: EOF

goroutine 70 [running]:
main.doRequest(0xc420010ec0, 0xc40000000a)
        /home/jonhall/go/src/github.com/flimzy/issue19943/main.go:33 +0x32f
created by main.main
        /home/jonhall/go/src/github.com/flimzy/issue19943/main.go:21 +0x17b
exit status 2

And this run here:
$ go run main.go
PUT http://localhost:9000/foo/5.txt
PUT http://localhost:9000/foo/2.txt
PUT http://localhost:9000/foo/3.txt
PUT http://localhost:9000/foo/1.txt
PUT http://localhost:9000/foo/4.txt
PUT http://localhost:9000/foo/10.txt
panic: Put http://localhost:9000/foo/10.txt: http: server closed idle connection

goroutine 58 [running]:
main.doRequest(0xc420010ec0, 0xc40000000a)
        /home/jonhall/go/src/github.com/flimzy/issue19943/main.go:33 +0x32f
created by main.main
        /home/jonhall/go/src/github.com/flimzy/issue19943/main.go:21 +0x17b
exit status 2

FWIW, I've only observed this behavior on Linux, never on MacOS, in my CI environment.

@flimzy I am having a similar issue however in a slightly different situation.
I am running a python uwsgi server in Docker and using DELETE methods instead of PUT with no concurrent connections.
I seem to only be able to replicate it while running in Docker with a golang client. Using curl, postman, ruby, python, ect.. to make the same request does not result in any EOF or TCP errors.
Doing a few packet traces and following the TCP stream for the DELETE request shows that as soon as the request is made the TCP connection is ACK'd then FIN, ACK'd and closed without the server having time to respond.

There seems to be a growing support for idempotency-key headers to indicate that a POST should be idempotent. Stripe, GoCardless, Worldpay and Paypal support idempotency-key' and [Openbanking](https://openbanking.atlassian.net/wiki/spaces/DZ/pages/5786479/Payment+Initiation+API+Specification+-+v1.1.0#PaymentInitiationAPISpecification-v1.1.0-Idempotency.1) supports x-idempotency-key`. As far as I can tell there is no current effort to specify via IETF but there does seem to be convergence among financial APIs.
Go could look for this header and infer that the request is intended to be idempotent.

An rclone user has been reporting this on POST-ing to the dropbox API.
I've put a work-around in for the moment.
Since errServerClosedIdle is no longer private could it be exposed?  It would mean I could kill this, most hideous piece of code in the world...
// retriableErrorStrings is a list of phrases which when we find it
// in an an error, we know it is a networking error which should be
// retried.
//
// This is incredibly ugly - if only errors.Cause worked for all
// errors and all errors were exported from the stdlib.
var retriableErrorStrings = []string{
	"use of closed network connection", // internal/poll/fd.go
	"unexpected EOF reading trailer",   // net/http/transfer.go
	"transport connection broken",      // net/http/transport.go
	"http: ContentLength=",             // net/http/transfer.go
	"server closed idle connection",    // net/http/transport.go
}

@iand, nice! Thank you for all those links. That's the first I've heard of that and it's great to see. I've always wanted to see a header like that so I'm pleased that it both exists and is pretty widely used.
I say we make Go respect both idempotency-key and x-idempotency-key. If Go sees either, it can mark the request as retry-able.


scriv collect always creates changelog entry even if nothing has changed

@nedbat, thanks for contributing this tool.
I observed a surprising behavior when running scriv collectseveral times in a row:
Every run of scriv collectcreates a new entry in changelog.md even without a new fragment or changed version number. This results in empty and redundant entries in changelog.md.
Without a new fragment I would not expect to get a new entry in changelog.md. Maybe I am missing something.
Regards, sysid

Oops, thanks! Fixed in 5fedb64

Top, thks for the swift respone!

This is now released as part of scriv 0.17.0.


Batch get archive

[x] closes #191
[x] tests added / passed
[x] passes git diff upstream/master | flake8 --diff
[ ] whatsnew entry

Get multiple archives from a list of archive_names. Involves a single manager query.

Coverage decreased (-0.05%) to 96.205% when pulling a4cfcf986f399c198f9bd2ac972f5a0538680376 on batch_get_archive into 5951cb810709687a45e842f79443861fc69af738 on staging.

Coverage decreases because our test datasets are not large enough to trigger paged batch_get_item queries. I think the code will work if we ever get there but it's currently untested.

Coverage decreased (-0.05%) to 96.245% when pulling 91732b7a8c66b93bc2bc3f5ec8030b7fc7ddb930 on batch_get_archive into ce8b05505f91612ebbe473224524bd801e967075 on staging.

Coverage decreased (-0.05%) to 96.245% when pulling d6f4d49ab3161b047f5830e181ba12debd4371b8 on batch_get_archive into ce8b05505f91612ebbe473224524bd801e967075 on staging.


pika-backup: 0.3.0 -> 0.3.1

Motivation for this change
https://gitlab.gnome.org/World/pika-backup/-/tags/v0.3.1
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 123791 at bf3741bd run on x86_64-linux 1

1 package failed to build:

pika-backup

1 suggestion:

warning: missing-patch-comment
Consider adding a comment explaining the purpose of this patch on the line preceeding.
Near pkgs/applications/backup/pika-backup/default.nix:39:5:
   |
39 |     (substituteAll {
   |     ^

Note that build failures may predate this PR, and could be nondeterministic or hardware dependent.
Please exercise your independent judgement. Does something look off? Please file an issue or reach out on IRC.

https://gitlab.gnome.org/World/pika-backup/-/issues/131


add css constant setting

📝 Changed routes:

/posts/[id]
/posts

(view full size)
(view full size)

Commit 67937caf1aa7e755d9e21a37449f9c53b3878e8f (https://sirius-next-lk8hg9sgz-bookman0001.vercel.app).


CoffeeScriptCompile task failure: cannot find dependency

Expected Behavior
I would like to be able to compile CoffeeScript to JavaScript using the built-in CoffeeScriptCompile task type.
Current Behavior
Running a gradle task of type CoffeeScriptCompile produces an error:
Could not find org.coffeescript:coffee-script-js:1.3.3.

The dependency name and version is specified in CoffeeScriptExtension.java
Context
I require a build task which

accepts as input a set of *.coffee files from one or more directories,
outputs *.js files to a specified directory. If the source dirs contained subdirectories, their structure should be preserved in the output.

Additional documentation/tutorials on using SourceTask and its extensions is also desirable.
Steps to Reproduce (for bugs)
The build.gradle file used:
import org.gradle.plugins.javascript.coffeescript.CoffeeScriptCompile

apply plugin: 'coffeescript-base'

repositories {
    jcenter()
    mavenCentral()
}

task compileCoffee(type: CoffeeScriptCompile) {
    source file('cs')
    destinationDir file('js')
}

Output:
$ gradle compileCoffee
:compileCoffee FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all dependencies for configuration ':coffeeScriptBasePluginJs'.
> Could not find org.coffeescript:coffee-script-js:1.3.3.
  Searched in the following locations:
      https://jcenter.bintray.com/org/coffeescript/coffee-script-js/1.3.3/coffee-script-js-1.3.3.pom
      https://jcenter.bintray.com/org/coffeescript/coffee-script-js/1.3.3/coffee-script-js-1.3.3.js
      https://repo1.maven.org/maven2/org/coffeescript/coffee-script-js/1.3.3/coffee-script-js-1.3.3.pom
      https://repo1.maven.org/maven2/org/coffeescript/coffee-script-js/1.3.3/coffee-script-js-1.3.3.js
  Required by:
      project :

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 31.06 secs

Your Environment
Output of gradle --version:
------------------------------------------------------------
Gradle 3.2-rc-3
------------------------------------------------------------

Build time:   2016-11-07 15:32:33 UTC
Revision:     5d11ba7bc3d79aa2fbe7c30a022766f4532bbe0f

Groovy:       2.4.7
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_101 (Oracle Corporation 25.101-b13)
OS:           Windows 10 10.0 amd64

Looks like the coffeescript module has been removed from JCenter and/or Maven Central. This fix would be to find where it moved to or provide an alternative.

I believe the CoffeeScript plugin has never been in a state ready for public consumption. It was part of the Gradle code base but we never announced it as a feature.
Maven Central doesn't allow for removing published artifacts so I doubt the CoffeeScript JS was every available there. I'd suggest publishing a CoffeeScript artifact to JCenter or an internal binary repository and consuming it from there.

Closing this issue for the following reasons:

A working repository containing the CoffeeScript JS has been provided.
The feature isn't ready for public consumption yet and therefore can change at any time.

@bmuschko is correct. Our integration tests resolve the coffee-script JS from https://repo.gradle.org/gradle/javascript-public.


Set up linting for JS

Similar to the extant linting tools that are configured for Python, we'll want linting for JS code to ensure it's consistent, readable, and following good practices. How exactly linting is set up will depend on which JS framework we go with, particularly if we use JS or TS. For a previous project, I used eslint with prettier as seen here. The .eslintrc and .prettierrc are also in that repo.

Please check out:
https://github.com/Comp-490-SeniorProject/site/commit/374b8a765d1aa3d14cdb0083e642470e9cab5003

You need to create a pull request. This issue isn't complete until your pull request gets merged into the main branch.


latest musl images are not available

Last valid multiarch musl image is of 8.6.1 on https://quay.io/repository/icdh/core-dump-handler-musl
Ideally, it should always be in sync with icdh/core-dump-handler repo and must have both arm and amd images for all versions.

It looks like the mutli arch build is broken https://github.com/IBM/core-dump-handler/actions/runs/3609824787/jobs/6273731929#step:5:177
I haven't had time to investigate much further but it's likely due to the podman version that's available on the Ubuntu image
https://github.com/containers/podman/issues/11745
I'll open a ticket in the action repo and see if we can get any feedback.
In the meantime if you have a fix/workaround you would like to PR that would be great.

Thanks @No9 for the quick fix.


fix(images): favors larger on thumbnail components

Switches to larger for all thumbnail components.

Merging.


[Run] Add option to "Run as different user"

In the specification for power launcher I have seen an entry about adding "Run as admin" to the menu.
Will there also bee a menu item to run an app as "different user"?
Why do I ask this:
In our company we can't use the UAC. It is disabled and does not work.
Wen have to run apps as different user to change into Admin kontext.
Idea from @Borkason
Added 03/11/2021
Have a second "run as different user" button where we can define the user in PT Run settings. (https://github.com/microsoft/PowerToys/issues/1605#issuecomment-796524117)

For v1, the team is focusing on implementing "run as admin" but "run as a different user" is a good suggestion! We can investigate and possibly add it in future versions.

good idea, start menu can do this.

As shown with screenshots in #4038 the start menu can't do it in a lot of cases. Of which all of them are used daily by IT professionals. There is a GPO to enable it, but that mostly doesn't work either.

There should be a setting to show or hide the Run as different user in the PT Run dialogs. And it should be disabled by default. I believe most people wouldn't need that option and this keeps the forms nice and clean for the majority of PowerToys users.
In addition to that, it would be great if we could have an option to add a second "run as different user" button to the form, that has a username preconfigured, so that I only need to enter the password of the preconfigured username. It would be important that only the username is stored, and the password must be entered every time. The use-case is that I have (as many admins do) a second Active Directory account that I use for many administrative tasks and it would be a great help if I would not have to enter the username every time I need to run an application as that user.

In addition to that, it would be great if we could have an option to add a second "run as different user" button to the form, that has a username preconfigured, so that I only need to enter the password of the preconfigured username. It would be important that only the username is stored, and the password must be entered every time. The use-case is that I have (as many admins do) a second Active Directory account that I use for many administrative tasks and it would be a great help if I would not have to enter the username every time I need to run an application as that user.

Love this great idea. Can completely agree. I had thw same use case forbthis feature.

@crutkas
This is an easy thing. Plan this for next release (0.58).
To trigger the other user behavior we have to create the Process.StartInfo object with a different verb: runAsUser (Run as command uses runAs as verb.)

@crutkas
I don't think we should implement a setting for a button with predefined credentials. This might be a security risk.

I don't think we should implement a setting for a button with predefined credentials. This might be a security risk.

@crutkas Nobody said anything about credentials.

Let’s file the storing secondary user name as a different issue and we can revisit. I’d imagine terminal has had similar asks and IMO we should follow their philosophy

Sory I read the suggestion to fast. But this should indeed be a second issue as it imo require the centralization of the run as user code.

Cool that this is part of the hotfix. Didn't expect that.

Shipped with 0.58.0 (Hotfix for 0.57.2)


Does xiu support RTSP source authenticated by password?

您好，感谢您开发了这个项目。我对流媒体相关的软件了解较少，当前要解决的问题是：我有一组（百来个）RTSP 视频流，我想按需地将其转为 HLS 或 WebRTC（用于浏览器上直播）。
我不知道如何填写 RTSP 流的用户名和密码，xiu 支持这样做吗？
Hello, thank you for developing this project. I know little about streaming media-related software, and the current problem I want to solve is: I have a set of (hundreds of) RTSP video streams, and I want to convert them to HLS or WebRTC on demand (for live streaming on the browser).
I don't know how to fill in the username and password for the RTSP stream, does xiu support this?
$ curl -X POST -H "Content-Type: application/json" -d '{
                           "id" : "3_86",
                           "identifier": {
                                      "rtsp": {
                                         "stream_path": "/"
                                      }
                                  },
                            "server_address":"<IP_ADDRESS>:554",
                            "relay_type":"Pull"
                      }' http://localhost:8000/api/start_relay_stream
{"error_code":-1,"desp":"failed","data":"send error"}

我在 文档 中发现了鉴权的方式，问题已解决。由于之前不太想用配置文件操作，所以忽视了这一部分文档，很抱歉！
I found it in document and the problem has been solved. Since I didn’t really want to use configuration files before, I ignored this part of the document. I’m sorry!

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx


mpremote mip install: file not found

Hi Jimmo,
I'm trying to creates the package.json for one of my library stored there (only the oled-ssd1306).
https://github.com/mchobby/esp8266-upy/tree/master/oled-ssd1306
So I did creates the package.json file as it should be (I believe).
Unfortunately the mpremote mip install github:mchobby/esp8266-upy/oled-ssd1306
Does returns the following error
Install github:mchobby/esp8266-upy/oled-ssd1306
Installing github:mchobby/esp8266-upy/oled-ssd1306/package.json to /lib
Package may be partially installed
mpremote: File not found: https://raw.githubusercontent.com/mchobby/esp8266-upy/HEAD/oled-ssd1306/ssd1306-v1.10.py

I do not understand why the HEAD file cannot be resolved.
What did I miss ?

I do not understand why the HEAD file cannot be resolved.

Because the path in package.json was wrong.

This is not the correct location to raise issues against mip.
It looks like you already solved the problem in https://github.com/mchobby/esp8266-upy/commit/ce400705bf5b10a624aff1cfb1430cac1a16ac2d (why didn't you close this issue?)
Do you actually need the collections.defaultdict dependency or did you copy that from the sample?

Hi Jimmo,

You right. Sorry for disturbance.
For me, it was not yet solved... I did certainly forgot to push my update online (why it was still an issue for me, and why the issue was still open).
Was copied from the sample and this was an error. It does "Installing: /lib/collections/defaultdict.mpy" so I do understand the behavior now!

The issue may anyway helps someone else using this example like I did.
Once again, sorry for annoyance.
Dominique


Added new build workers for Windows

Adding recent contributors and buildbot watchers @pablogsal @vstinner
Note that I have already switched the hardware for my main worker, but have left the newly added (renamed) worker offline so as to not flood the build master with connection requests.

@jkloth Do you have already keys(passwords) for those builders I assume, no?

I believe that the password stays the same for all workers from the same owner, given the format '{owner}-{worker}' for worker naming.

I believe that the password stays the same for all workers from the same owner, given the format '{owner}-{worker}' for worker naming.

Yup, but some owners have several ones for different workers so I just wanted to check :)

I'm not sure if this is the correct place to comment (sorry if it isn't, I'm not too familiar with the buildbots in CPython), but recently any keyword changes in the new worker have failed to compile. For example: https://buildbot.python.org/all/#/builders/596/builds/2/steps/2/logs/stdio
It seems that the regen grammar script needs >Python 3.8 as it's using the walrus, while the worker detects and runs py -3.7 on the script.
This wasn't triggered earlier because that specific part of the script isn't run if no keyword changes are detected.

It seems that the regen grammar script needs >= Python 3.8 as it's using :=, while the worker detects and runs py -3.7 on the script.

@jkloth Could you adapt your buildbot so Python3.8 is used for regenerating files as is done in the UNIX Makefile?

This worker has both 3.9 and 3.7 (both 64-bit) installed.  Running py -0p from the terminal shows that 3.9 is also the default.  That would mean that there is a bug in the build scripts for choosing the incompatible python installation.

This worker has both 3.9 and 3.7 (both 64-bit) installed. Running py -0p from the terminal shows that 3.9 is also the default. That would mean that there is a bug in the build scripts for choosing the incompatible python installation.

Hummmm, interesting. But we have Windows builders in the CI and those are ok with it. In fact, this seems to be the only buildbot that is failing with this.

I created the draft PR https://github.com/python/cpython/pull/25389 to see if it fixes this.


About obj2cls_dict.txt file

Hi, thanks for your nice work.
In the obj2cls_dict.txt file of your sample dataset, what is the first column of the txt file? it is from 0~468, and it is indexed in the https://github.com/vlmaps/vlmaps/blob/bc79b26a577e5a9408f86e45e5c16530ca80f867/utils/clip_mapping_utils.py#L114

the semantic image generated from the habitat-sim is not semantic label but instance id. The obj2cls dictionary is converting the instance ids to semantic ids.

I understand. It is the instance ids from mp3d dataset's semantic information right?

yes exactly


Chromely cannot be downloaded on linux-arm (Raspberry Pi)

Hi,
I'm using chromely for my application, the below are my system information:

Raspberry Pi 4

Raspbian.

Net 5

Chromely 5.1.86

I have built application with linux-arm run time.

Everything seems to be fine, but when I start the application, browser was opened with message:
CEF binaries download completed with error.
Error message: The remote server returned an error: (404) Not Found.
Please close.
I have tried the url you mentioned here, the url can be downloaded on my Raspberry.
What's wrong am I doing ?

@redplane
The url used for the download should be logged. Can you compare that with what works and you can share it too.

@redplane
The url used for the download should be logged. Can you compare that with what works and you can share it too.

Hi @mattkol ,
I have cloned your repository to my computer and start debugging the application.
I have notice this line , the downloadUrl value is: https://cef-builds.spotifycdn.com/cef_binary_86.0.21%2Bg6a2c8e7%2Bchromium-86.0.4240.183_linuxarm_minimal.tar.bz2.
When I paste the above line into my browser address, the server returns 404.
Then I went to https://cef-builds.spotifycdn.com/ to find the version 86.0.4240.183_linuxarm_minimal.tar.bz2, nothing could I find.
My guess is: the version already deprecated and the developers already removed and replace version 86 with version 87.
I also found the file version.g.cs. It seems that the download link is being generated by reading CefVersion from ChromelyRunTime.
I have few options below:

Hard coding the version is fine, but the library should provide a class or interceptor to allow developer to customize their download source (in case Cef cdn server is down or the version is removed from server). For now, what I see is the Download url is hard coded here

When I took a look at line 165 - CefLoader.cs, I saw you were downloading the whole CEF spotify cdn page and try finding the version the application needs to download & the download link.

I put a breakpoint there and read the value, the value Chromely downloaded was a raw page, the content seems to be rendered by the below function (which means we can't find any version in the downloaded string - it was client side rendering)
function createBuildTable(tab, build, tag=null)
Actually, there is a json file which lists every available CEF version, and it is: https://cef-builds.spotifycdn.com/index.json (by turning on developer console, we can see this)

I think we can use https://cef-builds.spotifycdn.com/index.json (by turning on developer console, we can see this) to get the available version instead of analyzing Cef spotify web content.

For now, because of my project is a little bit rush, I have to fix the Cef download process on raspberry.
If I have a PR, which branch should I create PR to ?

Hi @mattkol ,
I have cloned your repository to my computer and start debugging the application.
I have notice this line , the downloadUrl value is: https://cef-builds.spotifycdn.com/cef_binary_86.0.21%2Bg6a2c8e7%2Bchromium-86.0.4240.183_linuxarm_minimal.tar.bz2.
When I paste the above line into my browser address, the server returns 404.
Then I went to https://cef-builds.spotifycdn.com/ to find the version 86.0.4240.183_linuxarm_minimal.tar.bz2, nothing could I find.
My guess is: the version already deprecated and the developers already removed and replace version 86 with version 87.
I also found the file version.g.cs. It seems that the download link is being generated by reading CefVersion from ChromelyRunTime.
I have few options below:

Hard coding the version is fine, but the library should provide a class or interceptor to allow developer to customize their download source (in case Cef cdn server is down or the version is removed from server). For now, what I see is the Download url is hard coded here

When I took a look at line 165 - CefLoader.cs, I saw you were downloading the whole CEF spotify cdn page and try finding the version the application needs to download & the download link.

I put a breakpoint there and read the value, the value Chromely downloaded was a raw page, the content seems to be rendered by the below function (which means we can't find any version in the downloaded string - it was client side rendering)
function createBuildTable(tab, build, tag=null)
Actually, there is a json file which lists every available CEF version, and it is: https://cef-builds.spotifycdn.com/index.json (by turning on developer console, we can see this)

I think we can use https://cef-builds.spotifycdn.com/index.json (by turning on developer console, we can see this) to get the available version instead of analyzing Cef spotify web content.

For now, because of my project is a little bit rush, I have to fix the Cef download process on raspberry.
If I have a PR, which branch should I create PR to ?

@redplane

I have cloned your repository to my computer
I saw you were downloading

This is an open source project. Everyone is encouraged to contribute.

@redplane

I have cloned your repository to my computer
I saw you were downloading

This is an open source project. Everyone is encouraged to contribute.

I think we can use https://cef-builds.spotifycdn.com/index.json (by turning on developer console, we can see this) to get the available version instead of analyzing Cef spotify web content.

I am not sure if the proposal will help. CefGlue specifies version.
https://github.com/chromelyapps/Chromely/blob/3622bc432a8f48181d78ec7720816a7fe4fd0654/src/Chromely/CefGlue/Interop/version.g.cs#L12
So it looks like linux-arm build for v86 is deprecated or removed. So trying to change anything in the code may not help much. What is needed is to upgrade CefGlue. But if you can make it work for the project you are working on, I think you should go ahead. It can help others too. When CefGlue is updated, I believe the error you are seeing will go away.
Alternatively you can also upgrade to CefGlue, v87.

I think we can use https://cef-builds.spotifycdn.com/index.json (by turning on developer console, we can see this) to get the available version instead of analyzing Cef spotify web content.

I am not sure if the proposal will help. CefGlue specifies version.
https://github.com/chromelyapps/Chromely/blob/3622bc432a8f48181d78ec7720816a7fe4fd0654/src/Chromely/CefGlue/Interop/version.g.cs#L12
So it looks like linux-arm build for v86 is deprecated or removed. So trying to change anything in the code may not help much. What is needed is to upgrade CefGlue. But if you can make it work for the project you are working on, I think you should go ahead. It can help others too. When CefGlue is updated, I believe the error you are seeing will go away.
Alternatively you can also upgrade to CefGlue, v87.

I think we can use https://cef-builds.spotifycdn.com/index.json (by turning on developer console, we can see this) to get the available version instead of analyzing Cef spotify web content.

I am not sure if the proposal will help. CefGlue specifies version.

I have notice that, on Windows PC (I haven't test with another OS on PC), when you download the page, it returns enough information that Chromely can understand & find the version by using regex.
But when I tried on Raspberry PI 4, perhaps, due to its low memory, the render process runs slow, the content was not rendered by Javascript, that's why even I change the version in CefGlue, Chromely cannot find the targeted version.
Btw, can you tell me where I can find information of:
public const string CEF_API_HASH_PLATFORM_WIN = "3022db6736af26cc38158d38e22f74a51312a5c9";
        public const string CEF_API_HASH_PLATFORM_MACOS = "13e2e2451c2320f0d16b35ba53b3295409888dd8";
        public const string CEF_API_HASH_PLATFORM_LINUX = "abf4cc6ff102e5cd019aaf51f13eb30f9bfeae45";

I think we can use https://cef-builds.spotifycdn.com/index.json (by turning on developer console, we can see this) to get the available version instead of analyzing Cef spotify web content.

I am not sure if the proposal will help. CefGlue specifies version.

I have notice that, on Windows PC (I haven't test with another OS on PC), when you download the page, it returns enough information that Chromely can understand & find the version by using regex.
But when I tried on Raspberry PI 4, perhaps, due to its low memory, the render process runs slow, the content was not rendered by Javascript, that's why even I change the version in CefGlue, Chromely cannot find the targeted version.
Btw, can you tell me where I can find information of:
public const string CEF_API_HASH_PLATFORM_WIN = "3022db6736af26cc38158d38e22f74a51312a5c9";
        public const string CEF_API_HASH_PLATFORM_MACOS = "13e2e2451c2320f0d16b35ba53b3295409888dd8";
        public const string CEF_API_HASH_PLATFORM_LINUX = "abf4cc6ff102e5cd019aaf51f13eb30f9bfeae45";

@redplane

Btw, can you tell me where I can find information of (on internet)

To change those, you may need to get that from CefGlue Version search.
There is a chance that what you are doing will work, but I have tried making such a change in the past and it  just lead to more headaches. My conclusion is if there is not a major code change in the new version, then it will likely work, otherwise you may need an entire source change - this is the guide - here.

@redplane

Btw, can you tell me where I can find information of (on internet)

To change those, you may need to get that from CefGlue Version search.
There is a chance that what you are doing will work, but I have tried making such a change in the past and it  just lead to more headaches. My conclusion is if there is not a major code change in the new version, then it will likely work, otherwise you may need an entire source change - this is the guide - here.

@redplane
As i have written the loader there is a long history of the RasPi (linux-arm) builds.
To support raspi i also provided self-build CEF builds for linux-arm (http://chromely.org/cefbuilds/index.html)
Starting with spotify supporting linux-arm end this apporach...
Due to the missing version 86.0.21 on spotify - i see no simple solution here :-(
I dont't like to restart the self-build apporach.
What do you mean?

@redplane
As i have written the loader there is a long history of the RasPi (linux-arm) builds.
To support raspi i also provided self-build CEF builds for linux-arm (http://chromely.org/cefbuilds/index.html)
Starting with spotify supporting linux-arm end this apporach...
Due to the missing version 86.0.21 on spotify - i see no simple solution here :-(
I dont't like to restart the self-build apporach.
What do you mean?

I think it will be better if Chromely do:

Allow developer to change the download link of cef_sharp file.
Every release should include the cef_sharp tar file, the library will be more consistent. :)

I think it will be better if Chromely do:

Allow developer to change the download link of cef_sharp file.
Every release should include the cef_sharp tar file, the library will be more consistent. :)

Allow developer to change the download link of cef_sharp file.

Is this still related to CefGlue? The way CefGlue is structured, I do not know what benefit that brings. It is a fixed version.  May be as a fallback url, incase it fails like in issue #257. But that is a very very rare occurrence.

Every release should include the cef_sharp tar file, the library will be more consistent. :)

What is cef_sharp tar file?

Allow developer to change the download link of cef_sharp file.

Is this still related to CefGlue? The way CefGlue is structured, I do not know what benefit that brings. It is a fixed version.  May be as a fallback url, incase it fails like in issue #257. But that is a very very rare occurrence.

Every release should include the cef_sharp tar file, the library will be more consistent. :)

What is cef_sharp tar file?

Allow developer to change the download link of cef_sharp file.

Is this still related to CefGlue? The way CefGlue is structured, I do not know what benefit that brings. It is a fixed version.  May be as a fallback url, incase it fails like in issue #257. But that is a very very rare occurrence.

Every release should include the cef_sharp tar file, the library will be more consistent. :)

What is cef_sharp tar file?

I did an application with Chromely before, everything was fine, but after one or 2 months, i built my application again, Chromely cannot download the Cef binary anymore because they removed the old binary version (version 74 arm). I think it will be better to have a fallback url or any kind of mechanism that developer can specify where to download Cef binary file, he/she can copy Cef file to his/her cdn and point the download link there

Allow developer to change the download link of cef_sharp file.

Is this still related to CefGlue? The way CefGlue is structured, I do not know what benefit that brings. It is a fixed version.  May be as a fallback url, incase it fails like in issue #257. But that is a very very rare occurrence.

Every release should include the cef_sharp tar file, the library will be more consistent. :)

What is cef_sharp tar file?

I did an application with Chromely before, everything was fine, but after one or 2 months, i built my application again, Chromely cannot download the Cef binary anymore because they removed the old binary version (version 74 arm). I think it will be better to have a fallback url or any kind of mechanism that developer can specify where to download Cef binary file, he/she can copy Cef file to his/her cdn and point the download link there

@redplane i think, with "cef_sharp tar file" you mean the cef_binary archive containing the CEF runtime.
Bundling that with Chromely will result in VERY LARGE packets due there are nine platforms meanwhile...
The idea of the loader was exactly to avoid that.
@mattkol maybe we can "copy" that files for all available platforms and host them on our site or make them available any other way to avoid them missing on spotify if removed there?
Also i think an alternative download link should be possible as options parameter, but that has to be the direct file link (platfor specific).

@redplane i think, with "cef_sharp tar file" you mean the cef_binary archive containing the CEF runtime.
Bundling that with Chromely will result in VERY LARGE packets due there are nine platforms meanwhile...
The idea of the loader was exactly to avoid that.
@mattkol maybe we can "copy" that files for all available platforms and host them on our site or make them available any other way to avoid them missing on spotify if removed there?
Also i think an alternative download link should be possible as options parameter, but that has to be the direct file link (platfor specific).

@FrankPfattheicher ,
About the tar file I mentioned before, actually I didn't say Chromely have to include the tar file in its bundle.
What I thought was to upload the CEF binary together with Chromely release.
Let say, we can have those items in each section of Github release page:

Released binary file (optional - it can be downloaded from Nuget)
CEF binary for linux, windows, ... which the current Chromely is rely on.

For now, I notice Chromely heavily depends on CefSharp cdn hosting, that's why after 2 months I built the project, I got error 404. That requires me to update Chromely, it is very time consuming.

@FrankPfattheicher ,
About the tar file I mentioned before, actually I didn't say Chromely have to include the tar file in its bundle.
What I thought was to upload the CEF binary together with Chromely release.
Let say, we can have those items in each section of Github release page:

Released binary file (optional - it can be downloaded from Nuget)
CEF binary for linux, windows, ... which the current Chromely is rely on.

For now, I notice Chromely heavily depends on CefSharp cdn hosting, that's why after 2 months I built the project, I got error 404. That requires me to update Chromely, it is very time consuming.

@FrankPfattheicher, @mattkol
For now, I'm fixing the issue of missing version 86 on linux-arm for my project to run first.
I'm trying to update to version 87, but when I run the application, after download & decompression completed, I had this exception:

Here what I have changed in version.g.cs
        public const string CEF_VERSION = "87.1.13+g481a82a+chromium-87.0.4280.141";
        public const int CEF_VERSION_MAJOR = 87;

        public const int CHROME_VERSION_MAJOR = 87;
        public const int CHROME_VERSION_MINOR = 0;
        public const int CHROME_VERSION_BUILD = 4280;
        public const int CHROME_VERSION_PATCH = 141;

//....
        public const string CEF_API_HASH_PLATFORM_MACOS = "13e2e2451c2320f0d16b35ba53b3295409888dd8";

//...

Am I missing anything ?

@FrankPfattheicher, @mattkol
For now, I'm fixing the issue of missing version 86 on linux-arm for my project to run first.
I'm trying to update to version 87, but when I run the application, after download & decompression completed, I had this exception:

Here what I have changed in version.g.cs
        public const string CEF_VERSION = "87.1.13+g481a82a+chromium-87.0.4280.141";
        public const int CEF_VERSION_MAJOR = 87;

        public const int CHROME_VERSION_MAJOR = 87;
        public const int CHROME_VERSION_MINOR = 0;
        public const int CHROME_VERSION_BUILD = 4280;
        public const int CHROME_VERSION_PATCH = 141;

//....
        public const string CEF_API_HASH_PLATFORM_MACOS = "13e2e2451c2320f0d16b35ba53b3295409888dd8";

//...

Am I missing anything ?

Am I missing anything ?

Remember what I wrote earlier:?

There is a chance that what you are doing will work, but I have tried making such a change in the past and it just lead to more headaches.

The easier way I know is to follow the guide I shared earlier - https://github.com/chromelyapps/Chromely/blob/master/src/Chromely/CefGlue/Notes_On_Upgrade.txt
Just note that, if you have to debug anything in CefGlue itself, you are doing something wrong. That is my experience.

Am I missing anything ?

Remember what I wrote earlier:?

There is a chance that what you are doing will work, but I have tried making such a change in the past and it just lead to more headaches.

The easier way I know is to follow the guide I shared earlier - https://github.com/chromelyapps/Chromely/blob/master/src/Chromely/CefGlue/Notes_On_Upgrade.txt
Just note that, if you have to debug anything in CefGlue itself, you are doing something wrong. That is my experience.

Am I missing anything ?

Remember what I wrote earlier:?

There is a chance that what you are doing will work, but I have tried making such a change in the past and it just lead to more headaches.

The easier way I know is to follow the guide I shared earlier - https://github.com/chromelyapps/Chromely/blob/master/src/Chromely/CefGlue/Notes_On_Upgrade.txt
Just note that, if you have to debug anything in CefGlue itself, you are doing something wrong. That is my experience.

Phew, I have found the CefGlue and copy the latest one to the Chromely project.
Don't know why Chromely has to copy the CefGlue library source instead of refering to its dll file.
Finally, with some modifications, Chromely works again on my Raspberry Pi 4, with 2  commented methods that I don't know how to fix with new version of CefGlue:
/// <summary>
        /// Set whether mouse cursor change is disabled.
        /// </summary>
        public void SetMouseCursorChangeDisabled(bool disabled)
        {
            //cef_browser_host_t.set_mouse_cursor_change_disabled(_self, disabled ? 1 : 0);
        }

        /// <summary>
        /// Returns true if mouse cursor change is disabled.
        /// </summary>
        public bool IsMouseCursorChangeDisabled
        {
            get
            {
                // TODO: Implement here.
                return false;
                //return cef_browser_host_t.is_mouse_cursor_change_disabled(_self) != 0;
            }
        }

Still, I hope there will be a fallback url & copy of binary file on Github release to help developer manage their download more easily and don't depend on CEF cdn (even when they delete their distribution)

Am I missing anything ?

Remember what I wrote earlier:?

There is a chance that what you are doing will work, but I have tried making such a change in the past and it just lead to more headaches.

The easier way I know is to follow the guide I shared earlier - https://github.com/chromelyapps/Chromely/blob/master/src/Chromely/CefGlue/Notes_On_Upgrade.txt
Just note that, if you have to debug anything in CefGlue itself, you are doing something wrong. That is my experience.

Phew, I have found the CefGlue and copy the latest one to the Chromely project.
Don't know why Chromely has to copy the CefGlue library source instead of refering to its dll file.
Finally, with some modifications, Chromely works again on my Raspberry Pi 4, with 2  commented methods that I don't know how to fix with new version of CefGlue:
/// <summary>
        /// Set whether mouse cursor change is disabled.
        /// </summary>
        public void SetMouseCursorChangeDisabled(bool disabled)
        {
            //cef_browser_host_t.set_mouse_cursor_change_disabled(_self, disabled ? 1 : 0);
        }

        /// <summary>
        /// Returns true if mouse cursor change is disabled.
        /// </summary>
        public bool IsMouseCursorChangeDisabled
        {
            get
            {
                // TODO: Implement here.
                return false;
                //return cef_browser_host_t.is_mouse_cursor_change_disabled(_self) != 0;
            }
        }

Still, I hope there will be a fallback url & copy of binary file on Github release to help developer manage their download more easily and don't depend on CEF cdn (even when they delete their distribution)

Don't know why Chromely has to copy the CefGlue library source instead of refering to its dll file.

Good question.
Answer is simple, CefGlue does not publish nuget packages. Originally it was a separate dll, but since it was a dll created and maintained by us, there was no need creating a dependency. The nuget package are still created for those who still want to use it - https://github.com/chromelyapps/CefGlue.NetStandard

Don't know why Chromely has to copy the CefGlue library source instead of refering to its dll file.

Good question.
Answer is simple, CefGlue does not publish nuget packages. Originally it was a separate dll, but since it was a dll created and maintained by us, there was no need creating a dependency. The nuget package are still created for those who still want to use it - https://github.com/chromelyapps/CefGlue.NetStandard

You can also help create a nuget package for v87 and add it to https://github.com/chromelyapps/CefGlue.NetStandard

You can also help create a nuget package for v87 and add it to https://github.com/chromelyapps/CefGlue.NetStandard

@mattkol , I tried to update to version 87 and it worked fine.
But for now, my app cannot focus on any text box or select on linux-arm
I'm commenting this function:
`
///
/// Set whether mouse cursor change is disabled.
///
public void SetMouseCursorChangeDisabled(bool disabled)
{
//cef_browser_host_t.set_mouse_cursor_change_disabled(_self, disabled ? 1 : 0);
}
    /// <summary>
    /// Returns true if mouse cursor change is disabled.
    /// </summary>
    public bool IsMouseCursorChangeDisabled
    {
        get
        {
            // TODO: Implement here.
            return false;
            //return cef_browser_host_t.is_mouse_cursor_change_disabled(_self) != 0;
        }
    }

`
Is it related to my issue ?

@mattkol , I tried to update to version 87 and it worked fine.
But for now, my app cannot focus on any text box or select on linux-arm
I'm commenting this function:
`
///
/// Set whether mouse cursor change is disabled.
///
public void SetMouseCursorChangeDisabled(bool disabled)
{
//cef_browser_host_t.set_mouse_cursor_change_disabled(_self, disabled ? 1 : 0);
}
    /// <summary>
    /// Returns true if mouse cursor change is disabled.
    /// </summary>
    public bool IsMouseCursorChangeDisabled
    {
        get
        {
            // TODO: Implement here.
            return false;
            //return cef_browser_host_t.is_mouse_cursor_change_disabled(_self) != 0;
        }
    }

`
Is it related to my issue ?

@redplane
Sorry, I really cannot help here. As I stated earlier, my experience is, if you have to debug CefGlue itself, you are doing something wrong. Also I am not familiar with Raspberry Pi. @FrankPfattheicher may have more input on this.

@redplane
Sorry, I really cannot help here. As I stated earlier, my experience is, if you have to debug CefGlue itself, you are doing something wrong. Also I am not familiar with Raspberry Pi. @FrankPfattheicher may have more input on this.

@redplane
Do you have this file cef_string_t.disabled.cs in https://github.com/chromelyapps/Chromely/tree/master/src/Chromely/CefGlue/Interop? If you do, try delete it. It may help.

@redplane
Do you have this file cef_string_t.disabled.cs in https://github.com/chromelyapps/Chromely/tree/master/src/Chromely/CefGlue/Interop? If you do, try delete it. It may help.

@mattkol , I already deleted it because the application failed to compile.
Btw, thank you for your support.

@mattkol , I already deleted it because the application failed to compile.
Btw, thank you for your support.

I don't think this issue should be closed.
It isn't resolved yet. What developer needs about this is to manage the download instead of relying on the 3rd party hosting such as: CEF cdn.

I don't think this issue should be closed.
It isn't resolved yet. What developer needs about this is to manage the download instead of relying on the 3rd party hosting such as: CEF cdn.

@redplane
If we are going to do that, it is going to be an enhancement. So it is not an issue per se. @FrankPfattheicher and I know what needs to be done if we are going to pursue it. Personally, I have not seen the viability of that. Last time I checked, I do not think Github will allow you transfer a file of libcef.dll file size (even if compressed) - https://docs.github.com/en/github/managing-large-files/conditions-for-large-files
Also we then need to host all CEF binaries for all platforms and all cpu - so we are looking at 8 at least.
But I am not ruling anything out.

@redplane
If we are going to do that, it is going to be an enhancement. So it is not an issue per se. @FrankPfattheicher and I know what needs to be done if we are going to pursue it. Personally, I have not seen the viability of that. Last time I checked, I do not think Github will allow you transfer a file of libcef.dll file size (even if compressed) - https://docs.github.com/en/github/managing-large-files/conditions-for-large-files
Also we then need to host all CEF binaries for all platforms and all cpu - so we are looking at 8 at least.
But I am not ruling anything out.

@mattkol , @FrankPfattheicher , if you don't want to host every CEF binaries, I think there is no problem.
But Chromely library will be very unstable to include in a production software.
As I mentioned before:

3 months ago, I built a software and delivered to my customer. He was happy when he saw the product works as he expected.
Unfortunately, 2 weeks ago, he told me to update some functions on the source code I gave him.
I thought it was fine, just make some Front-end code and a little Chromely code, build & run, it would be fine.
But when I built my application to run on Windows, it showed 404 because Chrominium version 83 was deleted.
I had to update Chromely to the latest version, changed a lot of code.
It took time and I don't want to update Chromely again and again just because of missing CEF binary.

I already gave a solution for this:

Chromely release should mention what version of Chrominum it uses.
Chromely should provide a service, interceptor or any kind of method just to allow developer to change the Download url incase it cannot find CEF binary from cdn.

I don't think this issue should be closed now because the problem is not resolved yet.
We cannot trust CEF cdn, because they can remove the old version at any time.

@mattkol , @FrankPfattheicher , if you don't want to host every CEF binaries, I think there is no problem.
But Chromely library will be very unstable to include in a production software.
As I mentioned before:

3 months ago, I built a software and delivered to my customer. He was happy when he saw the product works as he expected.
Unfortunately, 2 weeks ago, he told me to update some functions on the source code I gave him.
I thought it was fine, just make some Front-end code and a little Chromely code, build & run, it would be fine.
But when I built my application to run on Windows, it showed 404 because Chrominium version 83 was deleted.
I had to update Chromely to the latest version, changed a lot of code.
It took time and I don't want to update Chromely again and again just because of missing CEF binary.

I already gave a solution for this:

Chromely release should mention what version of Chrominum it uses.
Chromely should provide a service, interceptor or any kind of method just to allow developer to change the Download url incase it cannot find CEF binary from cdn.

I don't think this issue should be closed now because the problem is not resolved yet.
We cannot trust CEF cdn, because they can remove the old version at any time.

@redplane
This is an open source project. There are limitations. If we cannot host CEF binaries on Github then it would require using an external server and service. That has its costs - financial, maintenance and human time dedications.
The way to solve such a problem, is not to rely entirely on auto download. If you release a version ensure either the CEF binaries are packaged with it or you download the CEF binaries and keep or you add a functionality that saves the CEF binaries on the user machine.
I am afraid, I do not see how this can be helped, but I will let @FrankPfattheicher chime in to see if has some ideas.

Chromely release should mention what version of Chrominum it uses (providing download link is very good option)

This is already available, but has not been updated for a while - https://github.com/chromelyapps/Chromely/blob/master/Documents/cef_binaries_download.md
https://github.com/chromelyapps/Chromely/issues/286

Chromely should provide a service, interceptor or any kind of method just to allow developer to change the Download url incase it cannot find CEF binary from cdn.

The interceptor is a good idea.
https://github.com/chromelyapps/Chromely/issues/287
On using an alternate url, I will let @FrankPfattheicher chime in on that.

@redplane
This is an open source project. There are limitations. If we cannot host CEF binaries on Github then it would require using an external server and service. That has its costs - financial, maintenance and human time dedications.
The way to solve such a problem, is not to rely entirely on auto download. If you release a version ensure either the CEF binaries are packaged with it or you download the CEF binaries and keep or you add a functionality that saves the CEF binaries on the user machine.
I am afraid, I do not see how this can be helped, but I will let @FrankPfattheicher chime in to see if has some ideas.

Chromely release should mention what version of Chrominum it uses (providing download link is very good option)

This is already available, but has not been updated for a while - https://github.com/chromelyapps/Chromely/blob/master/Documents/cef_binaries_download.md
https://github.com/chromelyapps/Chromely/issues/286

Chromely should provide a service, interceptor or any kind of method just to allow developer to change the Download url incase it cannot find CEF binary from cdn.

The interceptor is a good idea.
https://github.com/chromelyapps/Chromely/issues/287
On using an alternate url, I will let @FrankPfattheicher chime in on that.


Improve .gitignore

Add common IDE folder names, MacOS X system files/folders like .Trashes or .DS_STORE etc
This prevents accidental commits of files that should not be under version control without putting the burden on potential contributors

I like it, what's the default set that we want to support as a minimum?

There is a lot at https://github.com/github/gitignore
I'd consider these essential:
https://github.com/github/gitignore/blob/master/Node.gitignore
https://github.com/github/gitignore/blob/master/Global/Archives.gitignore
https://github.com/github/gitignore/blob/master/Global/OSX.gitignore
https://github.com/github/gitignore/blob/master/Global/Windows.gitignore
Any editor-specific ones from the Global folder are a plus I guess.
From a how-to-do-it perspective it's probably best if kwalitee can take a list of filenames or URLs of "desired" .gitignore contents and then compare them. A "kwalitee badge" on the npm might require only those 4 above, but I might want to run kwalitee locally and require 3 additional ones.

I think we'd want that list of file patterns to be the same everywhere, since the package can be unbundled anywhere.


[DOCS] Update raspbian install instructions

Python 3.5 is available for raspbian via the package python3 (proof). So no need to compile it from scratch anymore.

Need more proof than random Reddit comments. Currently this is the best option to install Python 3.5 on raspbian. Other methods have proved to have outdated/unreliable packages, and ssl issues.

This is not just a "random comment" lol.
Anyway here you go, some from official raspberry pi forums:
https://www.raspberrypi.org/forums/viewtopic.php?t=145706
https://www.raspberrypi.org/documentation/linux/software/python.md
https://raspberrypi.stackexchange.com/questions/15244/installing-python-3-4-on-raspberry-pi

The point wasn't that it didn't work or that you couldn't, it was that installing through apt-get, at one point, was outdated and had ssl issues which prevented it from being reliable. I tested it earlier for them and proved that installing in apt-get worked fine and lacked the ssl issues described.

Will update once approved by head developer now that more proof has shown that we aren't experiencing SSL issues and other unreliabilities. Thanks @AleanaA for the digging.


[Improvement][Task] Improved way to collect yarn job's appIds

Purpose of the pull request

Import aop way as an alternative way to collect yarn job's applicationId.

Also, this PR closes https://github.com/apache/dolphinscheduler/issues/11262

Brief change log

Create new module dolphinscheduler-aop for aop code.

Add new environment configuration for each type of yarn tasks to support aop, as follow:

export HADOOP_CLASSPATH=`hadoop classpath`:${DOLPHINSCHEDULER_HOME}/tools/libs/*
export SPARK_DIST_CLASSPATH=$HADOOP_CLASSPATH:$SPARK_DIST_CLASS_PATH
export HADOOP_CLIENT_OPTS="-javaagent:${DOLPHINSCHEDULER_HOME}/tools/libs/aspectjweaver-1.9.7.jar":$HADOOP_CLIENT_OPTS
export SPARK_SUBMIT_OPTS="-javaagent:${DOLPHINSCHEDULER_HOME}/tools/libs/aspectjweaver-1.9.7.jar":$SPARK_SUBMIT_OPTS
export FLINK_ENV_JAVA_OPTS="-javaagent:${DOLPHINSCHEDULER_HOME}/tools/libs/aspectjweaver-1.9.7.jar":$FLINK_ENV_JAVA_OPTS

Add user properties for user to decide the way to collect applicationId, as follow:

# way to collect applicationId: log(original regex match), aop
appId.collect: log

Verify this pull request

Service logic is verified by unit test.
Effectiveness of aop for supported types of yarn job are simply tested on my local cluster.

@ruanwenjun @SbloodyS @EricGao888
Would you like to help review the code? I'll handle the conflict later today.

Codecov Report

Merging #12197 (94dfe46) into dev (997b022) will decrease coverage by 0.05%.
The diff coverage is 23.21%.

@@             Coverage Diff              @@
##                dev   #12197      +/-   ##
============================================
- Coverage     39.61%   39.56%   -0.06%
+ Complexity     4192     4191       -1
============================================
  Files          1038     1038
  Lines         38843    38825      -18
  Branches       4447     4435      -12
============================================
- Hits          15388    15361      -27
- Misses        21711    21718       +7
- Partials       1744     1746       +2

Impacted Files
Coverage Δ

...e/dolphinscheduler/common/constants/Constants.java
62.50% <ø> (ø)

...pache/dolphinscheduler/common/utils/FileUtils.java
54.28% <0.00%> (-0.79%)
:arrow_down:

...er/master/builder/TaskExecutionContextBuilder.java
56.06% <0.00%> (-10.02%)
:arrow_down:

...r/server/master/runner/task/BaseTaskProcessor.java
15.75% <0.00%> (-0.06%)
:arrow_down:

...ler/remote/command/log/GetAppIdRequestCommand.java
0.00% <ø> (ø)

...apache/dolphinscheduler/service/log/LogClient.java
41.00% <0.00%> (-0.42%)
:arrow_down:

...nscheduler/service/log/LoggerRequestProcessor.java
16.98% <0.00%> (-0.17%)
:arrow_down:

...e/dolphinscheduler/service/utils/ProcessUtils.java
27.65% <0.00%> (-0.30%)
:arrow_down:

...hinscheduler/plugin/task/api/AbstractYarnTask.java
0.00% <0.00%> (ø)

...ler/server/worker/processor/TaskKillProcessor.java
0.00% <0.00%> (ø)

... and 35 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Creating new tab stack resets line wrap setting

VSCode Version: 1.4.0
OS Version: OS X 10.10.5

Steps to Reproduce:

Create a two new files (so there are two tabs), A and B.
Toggle the line wrap setting for file A
Drag the tab for the file A to create a new tab stack
Observe the line wrap setting is reset.

Here is a screencast:

We need to apply more of the editor settings that are defined outside of the real settings to the other side.

@alexandrudima would it make sense to put more of these things into the persisted view state I get from the editor?
Here is my problem: You configure the editor with our toggles and then you move the editor to the side to split it. For me it is just like opening a file to the side, I do not know how the editor was configured (e.g. showing whitespace characters), so it opens without these options applied.
I could look for editor options like those and reapply them but this is fragile when we add more toggles. Today, e.g. the state of expanded/collapsed regions also goes into the view state and restores transparently for me without further knowledge.
If we move more into view state this would actually also allow to set these options on specific files and get these options back when you open the file again after restart 👍

@bpasero I am not sure where these "ephemeral" settings should live. I am also not sure if it is OK that today they apply to the focused/active editor only. If they would apply to all editors, then we could centrally manage them for all editor instances...
We can also make them serialized with the view state, but then wouldn't the uri <-> viewstate mapping bite us back?

Not sure applying them to all editors would make sense, if I want to quickly toggle word wrap for the current editor, I would probably not expect it to change it for any other editor.
Today view state is stored per URI + column so that multiple editors of the same resource can have different view state. In this case I would not use this mechanism though but purely ask the source editor for its view state and apply it to the target editor. I already do this for restoring the view state when you move an editor to the side because I need it there already.
So having this inside viewstate should be OK for this issue as well as restoring the state when you restart for the current editor in the column it is inside.


Sample app returns error if starts via "opening in".

Description:
Sample app returns error if it starts on "opening in".
Steps To Reproduce:

Unload app from memory
Open RMS protected file via app

Expected result: Sample app decrypted RMS protected file.
Actual result: App shows alert with error.
Additional info from another issue: https://github.com/AzureAD/rms-sdk-ui-for-ios/issues/1#issuecomment-250097443

Hi Vasily,
Could you give more details about what kind of file it was, how it was protected etc and also the error message?
Thanks
Shyam

File - simple pjpg file, protected with "view" rights
error:
Consumption failed with error: Error Domain=RMSDomain Code=-1000 "Произошла непредвиденная ошибка при подключении к службе Rights Management. Чтобы получить дополнительную поддержку, обратитесь в службу поддержки приложения." UserInfo={NSLocalizedFailureReason=(
	0   RMSSampleApp                        0x00000001000cf654 +[ErrorFactory createErrorWithLocalizedMsg:englishMsg:code:contextLogger:] + 292
	1   RMSSampleApp                        0x00000001000cf4ec +[ErrorFactory createErrorWithDict:code:contextLogger:] + 180
	2   RMSSampleApp                        0x00000001000cf3ac +[ErrorFactory createErrorWithCode:contextLogger:] + 1024
	3   RMSSampleApp                        0x00000001000a9ed4 +[MSProtectedData completeWithInputInvalidError:completionBlock:] + 80
	4   libdispatch.dylib                   0x000000018bfd5200 <redacted> + 24
	5   libdispatch.dylib                   0x000000018bfd51c0 <redacted> + 16
	6

Hi Vasily,
How was the file protected - which application? Also, what was the email address used with the RMS SDK API? As mentioned in our emails, the failure is in input validation, and we need to know all the parameters.
Thanks
Shyam

Hi, Shyam!
You can't reproduce bug or what? It reproduces on any rms protected file if app wasn't loaded before. If it already running all works fine.


missing ports for master

those ports have to be open on the master as well. otherwise things like kube-proxy+dashboard wont work.

@stephanlindauer we should probably document allowing traffic between both masters and workers on the pod network. So maybe updating the ingress rules from both master/worker to state source could be from master & worker?

not 100% sure what you mean. the ports are already mentioned in the Worker Node Inbound section. or do you want to add a new table for inboud rules that should be applied to both master and worker nodes?

Sorry for the vagueness. We likely also need to allow master->worker pod traffic (and master to master pod traffic). Looks like we're only allowing pod traffic to be sourced from workers.
We mention opening all TCP traffic between worker/master, but not in the case for these UDP ports.
So I think it would just be a change of source=master & worker for the flannel rules in both the ingress tables.

ok understood. makes sense. ;)
i changed the pr accordingly.

LGTM, thanks!

Oh actually, would you mind squashing into a single commit?

yup. done.


Selection - playlists "deselect all" action doesn't work

Steps to reproduce

Go to playlists tab
Select all
Tap the button once again

What did you expect?
All deselected, therefore selection closes
What happened instead?
Nothing happens
Sweyer version
1.0.9
Android version
No response

The problem is with any type of content, which you initially choose for selection (except for songs)


md-menu flashes while closing

What is affected?
Component, Other/unknown
Description
When I close md-menu it starts disappearing animation, then just when it is done, it shows an empty menu for a couple of frames and then it is finally gone.
Especially annoying if the menu is big enough
Reproduction

Go to https://material-web.dev/components/menu/#properties (or any other page with the menu)
Click on any example button to show the menu example
Click outside of the menu
Note the flash (this doesn't always happen, but most often)

It could be visible on this recording: https://share.firefox.dev/3V93LGL
1.490s: menu almost transparent
1.491s (next frame): menu is fully opaque again
1.51s (next frame): menu finally disappeared.
Workaround
Disable animation with quick property
Is this a regression?
No or unsure. This never worked, or I haven't tried before.
Affected versions
reproducable on 1.2.0, 1.3.0
Browser/OS/Node environment
Firefox 124.0b8 (64-bit), macOS 14.4 (23E214)

I wasn't able to reproduce this in Firefox 123 on macOS 14.3.1. Does it happen outside of the catalog or on https://material-web.dev/components/menu/stories/?
I can't see the visuals with the stack trace posted, can you post a screen recording video?

Hey, I also can not reproduce it on FF 123.
On FF 124 it does happen outside of the catalog (I noticed it on my local dev server of my project), it also happens on stories/. I double-checked it with Troubleshoot mode ON, meaning that all the extensions and other stuff are off.
I just reproduced the same problem on <md-*-select>, I attached the recording. You can catch a frame with the problem just after the menu is almost gone.
https://github.com/material-components/material-web/assets/1223112/878e6ddf-6e6e-4b87-8af2-f96bbd693c23
The screenshot of the frame

BTW <md-*-select> examples on https://material-web.dev/components/select/#usage seems to be broken in FF 123:
https://github.com/material-components/material-web/assets/1223112/4321c6a1-e9ff-4bd2-ba3f-4a0429722a19

I'd stick with testing https://material-web.dev/components/select/stories/ since the inline demos may be introducing other problems.
Does it happen in all three menu positioning options in FF 124? If absolute or fixed work, it could be an issue with new popover apis that FF is working on.

I tried all three positioning options, the bug is reproducible on all of them on FF 124 (neither is reproducible on FF 123).
BTW the menuPositioning select on FF works only from keyboard. It closes immediately after it is being open on both FF 123 and FF 124.


ci: remove dupe builds

These were the first 4 builds that I added when testing GCB. Now that we
have all the builds, the functionality here, {bazel, cmake} x {gcc,
clang}, is duplicated several times over in other builds. We still have
this cross product covered even without these builds, and removing them
will ease our GCB quota issues.

This change is

... of course, I forgot to delete the triggers... duh. Trying again.

we could consider removing integration.sh too. All the sanitizer builds run them.

we could consider removing integration.sh too. All the sanitizer builds run them.

Agree.


Could not acquire or refresh tokens [http 400]

Hi there,
Yesterday I succesfully deployed your Laravel wrapper to my Laravel-app (localhost). I was able to make queries to the Exact api. Today, I wanted to connect to the API again, but got the error "Could not acquire or refresh tokens [http 400]" after pressing the button "connect to Exact".
I am basically familair with the OAuth of Exact. Is there anything I can do manually to reconnect? I installed the package yesterday, so I believe i am running the latest version. Thanks in advance.

Sounds a lot like https://github.com/picqer/exact-php-client/issues/359 or https://github.com/picqer/exact-php-client/issues/385, but never heard or had it in the authorization process before.
Normally, a JSON file should be stored on your system with the authentication tokens after the first authentication attempt. Once the token expires a new valid token will be fetched automatically. You shouldn't have to press the connect button again until the token really expires and re-fetching fails a well.

OK, I checked the json file and noticed that the timestamp was already expired. I cleared the file and pressed the "Connect to Exact" button again. Now, I didn't needed to enter my credentials and was redirected to "Your app is now connected" page.
However, when checking the json file again, i notice the exact_tokenExpires is set to<PHONE_NUMBER> (which is 10 minutes after it was released).

That's intended behaviour. The token Exact issues is valid for 10 minutes, after which the refresh token (that's also in the JSON file) can be used to fetch a new access token (which then can be used for 10 minutes again)

This is described here: https://support.exactonline.com/community/s/knowledge-base#All-All-DNO-Content-oauth-eol-oauth-devstep3 and here: https://support.exactonline.com/community/s/knowledge-base#All-All-DNO-Content-oauth-eol-oauth-devstep4

Thanks, I see. And thanks for creating this Laravel Wrapper!

You're welcome :-)


Silex 1.3: Twig debug extension should be loaded always, or add an option to provide an alternative dump function

Right now when putting silex in production mode (without debug), the dump() function is unavailable due to Twig_Extension_Debug not being registered. So when one of your template designers is uploading a twig file with the dump function in it, silex tries getting the error page because a Twig_Error_Syntax exception is thrown.
RIght now I'm solving this with the following code:
<?php

$app = new Silex\Application;

$app->register(new Silex\Provider\TwigServiceProvider(), array(
    'twig.options' => array(
        'cache' => $cache_dir,
        'auto_reload' => true,
    ),
    'twig.path' => __DIR__ . '/../views',
));

$app['twig'] = $app->extend('twig', function (Twig_Environment $twig, Application $app) {
        // triggers E_USER_DEPRECATED in debug mode only
        $twig->addExtension(new \Twig_Extension_Debug());
});

However this feels hacky and should be a default option, the dump function already has code to do nothing if the Twig_Environment debug mode is off:
<?php

function twig_var_dump(Twig_Environment $env, $context)
{
    if (!$env->isDebug()) {
        return;
    }

    // more code, stripped
}

This is consistent with Symfony's TwigBundle.
The only argument I see against having this extension always registered, is the performance impact. But is it worst the bad DX ?

@rubenvincenten why would you want a dump function in production ? I'd rather have an error I can detect quickly than a dump() hidden somewhere

@mathroc Because it would make sense in production mode that pages actually keep working even when your dumb colleagues forget to comment out or remove dump statements.
This can be closed, but I would recommend adding a section to the docs with code to circumvent this problem. Or maybe the extension can use the code below:
$app['twig'] = $app->extend('twig', function (Twig_Environment $twig) {
        // the buttons, they do nothing!!
        $twig->registerUndefinedFunctionCallback(function ($name) {
            if ($name == 'dump') {
                return new Twig_SimpleFunction('dump', function () {
                });
            }

            return null;
        });
});


Set up associations Pull request

In this project, I have finished creating the remaining classes for the school library and create the associations between them. The following are the changes:

Created a class Classroom.
Created the has-many/belongs-to relationship between Classroom and Student.
Created a class Book.
Created a class Rental.
Created the many-to-many (also has-many-through) relationship between Person and Book using the intermediate class Rental.

Thank you for approving my project! 😊


Ability to prevent a metric from accumulating during training

I want a metric that computes the mean value over other metrics. E.g. something like the following:
def construct_mean_accuracy(metrics):
    ''' Pass in a list of all other metrics to compute the mean value over all of them. '''

    def mean_accuracy(y_true, y_pred, sample_weight=None):
        return tf.math.reduce_mean([m.result() for m in metrics])

    return mean_accuracy

The metrics that I'm computing the mean over here are themselves accumulated (i.e. 'streamed') accuracy values that build up over an epoch. The mean_accuracy value printed by TensorFlow during Model.fit() is wrong, because TF is automatically accumulating the batch-wise metric values of mean_accuracy through a rolling mean (I think). This behaviour has caused confusion for people in the past (see #9498, #15115, #42994), and I couldn't find any documentation on it. Is there a way to prevent the accumulation behaviour and just return the batch-wise value? The desired final on_epoch_end value for mean_accuracy should just be the mean over the metrics in the final batch (because the other metrics are themselves accumulated metrics).
Let me know if I can make this any clearer.

@tom-andersson
We see that the issue template has not been filled, could you please do so as it helps us analyse the issue .Thanks

@tom-andersson Thanks for creating the issue. keras moved to a new repository and that repo is dedicated for keras development. Earlier keras team published about the move in TF forum. The link is given below.
https://discuss.tensorflow.org/t/keras-project-moved-to-new-repository-in-https-github-com-keras-team-keras/1999
Can you please create a new issue in that repository. When you create issue, can you please share a simple standalone code to reproduce the issue. Standalone code helps to resolve the issue faster. Thanks!


Use inbound peerslot slots when a substream is received, rather than a connection

Fix #7074
This implements the change described in #7074.
New protocol between behaviour and handler
It took me a lot of time, but I came up with this refactoring of the communication between the NetworkBehaviour and the ProtocolsHandler. I believe that the new asynchronous protocol between the behaviour and handler is sound, in other words that it is not prone to race conditions.
The handler can now accept the following incoming messages:

Open
Close

It can also emit these messages:

OpenResultOk or OpenResultErr.
CloseResult.
OpenDesired.
CloseDesired.

Each Open message sent to the handler will result in a corresponding OpenResultOk or OpenResultErr being sent back. Each Close message will result in a corresponding CloseResult being sent back.
Thanks to this correspondence, the behaviour can track the state (open or closed) of the handler. For instance, if the behaviour sends an Close, then receives an OpenDesired, it knows that the OpenDesired was sent before the Close has been processed.
When in closed state, the handler can also send an OpenDesired, indicating that the remote would like the state to transition to "open".
When in open state, the handler can, vice-versa, send a CloseDesired indicating that the remote would like the state to transition to "closed".
As a small acceptable hack, an OpenDesired should always be answered by sending either Open or Close, otherwise the handler cannot differentiate between the situation where the behaviour is still undecided and the situation where the behaviour wants to remain in the "closed" state.
It is forbidden to remain "open" when a CloseDesired is received, and as such there is no similar ambiguity for that message. The behaviour must send Close as soon as possible.
Inbound slots
At the moment, an inbound slot in the peerset is allocated whenever a TCP connection with a new peer is received.
This PR modifies this behaviour, and peerset inbound slots are now allocated when an OpenDesired is received from the handler.
Similarly, the slots are liberated when the substream is closed (this was already the case before).
This ties the inbound peerset slots to the concept of substreams, rather than the concept of TCP connections.
The motivation behind this change is to ultimately introduce peerset slots attributed to certain notification protocols (see https://github.com/paritytech/substrate/issues/6087). In the future, the messages emitted by the handler would be specific to a notifications protocol. For example, when a substream using the parachains collation protocol is opened, only a parachains collation slot is attributed.
About opening_and_closing
In the implementation, I've opted to track, in the behaviour, the exact state of the handler. Not being tolerant will let us discover bugs sooner.
A consequence of tracking the exact state is that we verify that each OpenResultOk/OpenResultErr/CloseResult message emitted by the handler actually matches the state tracked in the behaviour.
But if the behaviour sends an Open message to the handler, then a Close message, then wants to send an Open message again, it starts being a lot of state to track. Rather than introducing a Vec, I went with putting the connection in a field called opening_and_closing and "banning" the peer for 5 seconds. In other words, we wait for 5 seconds before trying to send an Open message again.
Considering that this can only happen in case of quick state transitions coming from the peerset, I believe that this behaviour is completely ok, as it mimics the existing banning system.

Sorry for the lack of thorough explanations at the moment. This PR was very tiring to make, and I'm just very happy/relieved to finally open it.

Marked as ready for CI purposes only.

Ready for review.

I've found the issue: in the situation where the peer is in the Enabled state, and we have one connection Open and one Closed, and the Open connection closes, we don't try to open Closed and instead stay Enabled but with no opening will be ever be happening.
I'll fix that at the same time as I refactor the connections to be in only one list.

I did the refactoring. It looks like the tests are still failing, so I'll do more investigation/reviewing/debugging.

Since the new code no longer enables or disables the legacy substream at initialization, the timeout system of the legacy substream handler was being triggered, which would shut down connections after 20 seconds.
Rather than hacking around this system, I've pushed a commit that rewrites legacy.rs in order to take into account the current state of the protocol.
There is a debug assertion failing in group.rs which I haven't investigated yet.

After spending a lot of time trying to make NotifsInHandler and NotifsOutHandler work with the new design, I've finally decided to get rid of them and rewrite most of group.rs from scratch.
I'm mostly done, except that I've left some TODOs and commented out everything related to the legacy substream.
I've pushed a first commit now to check whether CI passes, and will finish the changes later.

The compilation warnings seem to prevent the CI from actually running, so I'll have to finish the PR before knowing.

I'm writing this comment before tests have passed, but I believe they do and that this should be ready for reviewing.
There isn't any more change coming from me except bugfixes.

This PR is currently being burned-in on kusama-senty-ae1-0 with debug-assertions = true. It's been running since yesterday (Nov 12th) afternoon and hasn't panicked so far.

I believe I've addressed all concerns.
I'd appreciate a review of the actual details of all the state machine transitions, but I understand if you don't want to.
I suggest to continue the burnin (with debug-assertions = true) over the weekend, and merge early next week if nothing bad happened.

Since everything worked well during the weekend with debug-assertions = true, unless someone intends to review, I'm planning to merge this later today.

(this PR still needs at least one approving review to be merged)

bot merge

@romanb Thanks
To be clear, my eagerness to merge this PR is also due to the fact that #7374, which is the next thing I will work on, will require substantial modifications to behaviour.rs and handler.rs again.

bot merge


Customisation

It would be great to be able to customise the background and font colour as well as font size

The color customization is a good idea and will be committed soon (tomorrow maybe).
The font size will stay the same though - prefer to keep it simple and clean


Better ES export proposal

The following export approach would allow this API:
import { Application, Component} from "@lightningjs/core/es";

On the consumer project side the following configuration is needed:
// tsconfig.json
{
  "compilerOptions": {
    "moduleResolution": "NodeNext",
  }
}

// package.json
{
  "type": "module"
}

VS Code and Vite then nicely pick up the ES exports and offer automatic imports when using e.g. Component alone.
PS: devtool inspector still needs some work as currently it depends on the global lng object.

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

Excellent! Thanks for digging into this, @elsassph. I like this approach. What do you think of calling the export pure-esm instead of es? I don't think es alone quite emphasizes and describes the implications that importing it will have.
Good catch on the Inspector. We might be able to get away with creating a new window global object (with a new name) that only includes the core classes needed by it.

Happy that you like that first shot.
I don't have a strong opinion on es but I appreciate that it's a bit ambiguous and potentially dangerous if you mistakenly import both the global lng export and an ES export. The proper way would be a separate npm module, like @lightningjs/core-es. Like lodash-es for lodash.
For inspector, it would be optimal to have a "regular export" attachInspector(/* explicit types references*/), then you could add a lng.attachInspector() which could be automatic.

@elsassph I reopened this one in lieu of #503. I still think we should call the export "pure-esm" to be more clear what this is. The existing export is ESM compliant technically already. This one purifies it to allow tree shaking.

@frank-weindel OK I revisited the PR to clean up the ES export.

commonjs export (require) still works, pointing to lightning.min.js
ES export allows using the default export with the complete API-compatible object, and the individual exports.

I verified with a basic "hello world" app, both with Webpack (commonjs and ES versions) and Vite (ES only):

minimal ES without applicationimport { Stage, Element } from "@lightningjs/core";

2 minimal ES
import { Application, Component } from "@lightningjs/core";

3 full ES / commonjs
import Lightning from "@lightningjs/core";

Thank you! This looks great. I'm not sure if we should be exporting the minified bundle for commonjs tho. Typically bundlers on the user end do minification for the entire application bundle.

Now I not sure now about minification - I've seen it done often but you're probably right:
https://stackoverflow.com/questions/48673408/should-javascript-npm-packages-be-minified
Reverted that change.

Also added the inspector


this is my commit message for the issue tacos with margarita; closes #6

This is very nice thank you. But I have a suggestion:

...
...
...


SouthParkData examples:when i input query sentence, the server terminated

I noticed that an issue of  version problem in the example of SouthParkData had been raised, and I did not use the  cookiecutter template. When i input query sentence, the server terminated.
I want to build a Chinese serch engine. here is where I changed it
#!Sentencizer
!JiebaSegmenter
metas:
  name: JiebaSegmenter

!TextPaddlehubEncoder
#!TransformerTorchEncoder
with:
  pool_strategy: auto
  pretrained_model_name_or_path: ernie
  max_length: 96

import os
import sys

from jina.flow import Flow

num_docs = int(os.environ.get('MAX_DOCS', 500))

# for index
def index():
    f = Flow.load_config('flows/index.yml')

    with f:
        f.index_files('docs.txt', batch_size=8, read_mode='rb', size=num_docs)

# for search update version
def search():
    f = Flow().load_config("flows/query.yml")

    with f:
        while True:
            text = input("please type a sentence: ")
            # if not text:
            #     break
            print(text)
            def ppr(x):
                print_topk(x, text)
            f.search_lines(lines=[text, ], output_fn=ppr, top_k=10)

def print_topk(resp, sentence):
    for d in resp.search.docs:
        print(f"Ta-Dah🔮, here are what we found for: {sentence}")
        for idx, match in enumerate(d.matches):

            score = match.score.value
            if score < 0.0:
                continue
            character = match.meta_info.decode()
            dialog = match.text.strip()
            print(f'> {idx:>2d}({score:.2f}). {character.upper()} said, "{dialog}"')

search()

!CompoundIndexer
components:
  - !NumpyIndexer
    with:
      index_filename: vec.gz
    metas:
      name: vecidx  # a customized name
      workspace: $WORKDIR
  - !BinaryPbIndexer
    with:
      index_filename: chunk.gz
    metas:
      name: chunkidx
      workspace: $WORKDIR
metas:
  name: chunk_compound_indexer
  workspace: $WORKDIR

Is this show that the doc has been indexed successfully?

the flows work well when I input the ** python app.py** but terminate after inputing a sentence.

please type a sentence: 纵观历史
纵观历史
JINA@7912[W]:parser Client can not recognize the following args: ['--read-only', '--rest-api'], they are ignored. if you are using them from a global args (e.g. Flow), then please ignore this message
<gevent._socket3.socket at 0x7fc5096ddd10 object, fd=20, family=2, type=1, proto=0>: Invalid http version: 'PRI * HTTP/2.0\r\n'
<gevent._socket3.socket at 0x7fc5096ddd10 object, fd=20, family=2, type=1, proto=0>: Invalid http version: 'PRI * HTTP/2.0\r\n'
<gevent._socket3.socket at 0x7fc5096ddd10 object, fd=20, family=2, type=1, proto=0>: Invalid http version: 'PRI * HTTP/2.0\r\n'
<gevent._socket3.socket at 0x7fc5096ddd10 object, fd=20, family=2, type=1, proto=0>: Invalid http version: 'PRI * HTTP/2.0\r\n'
<gevent._socket3.socket at 0x7fc5096ddd10 object, fd=20, family=2, type=1, proto=0>: Invalid http version: 'PRI * HTTP/2.0\r\n'
gateway@7912[C]:can not connect to the server at <IP_ADDRESS>:33809 after 10000 ms, please double check the ip and grpc port number of the server
gateway@7949[S]:terminated
gateway@7949[S]:terminated

    encoder@7923[S]:terminated
    crafter@7920[I]:received "control" from ctl▸⚐
    crafter@7920[I]:RequestLoopEnd() causes the breaking from the event loop
    crafter@7920[I]:#sent: 0 #recv: 1 sent_size: 0 Bytes recv_size: 250 Bytes
    crafter@7920[I]:#sent: 1 #recv: 1 sent_size: 288 Bytes recv_size: 250 Bytes
    crafter@7920[S]:terminated
       Flow@7912[S]:flow is closed and all resources should be released already, current build level is 0

Traceback (most recent call last):
File "/home/daoyuan/miniconda3/envs/jina/lib/python3.7/site-packages/jina/clients/python/grpc.py", line 42, in init
timeout=(args.timeout_ready / 1000) if args.timeout_ready > 0 else None)
File "/home/daoyuan/miniconda3/envs/jina/lib/python3.7/site-packages/grpc/_utilities.py", line 140, in result
self._block(timeout)
File "/home/daoyuan/miniconda3/envs/jina/lib/python3.7/site-packages/grpc/_utilities.py", line 86, in _block
raise grpc.FutureTimeoutError()
grpc.FutureTimeoutError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "app.py", line 42, in
search()
File "app.py", line 28, in search
f.search_lines(lines=[text, ], output_fn=ppr, top_k=10)
File "/home/daoyuan/miniconda3/envs/jina/lib/python3.7/site-packages/jina/flow/init.py", line 709, in search_lines
self._get_client(**kwargs).search(input_lines(lines, filepath, size, sampling_rate, read_mode), output_fn,
File "/home/daoyuan/miniconda3/envs/jina/lib/python3.7/site-packages/jina/flow/init.py", line 52, in arg_wrapper
return func(self, *args, **kwargs)
File "/home/daoyuan/miniconda3/envs/jina/lib/python3.7/site-packages/jina/flow/init.py", line 562, in _get_client
return py_client(**kwargs)
File "/home/daoyuan/miniconda3/envs/jina/lib/python3.7/site-packages/jina/clients/init.py", line 32, in py_client
return PyClient(args)
File "/home/daoyuan/miniconda3/envs/jina/lib/python3.7/site-packages/jina/clients/python/init.py", line 50, in init
super().init(args)
File "/home/daoyuan/miniconda3/envs/jina/lib/python3.7/site-packages/jina/clients/python/grpc.py", line 47, in init
raise GRPCServerError('can not connect to the server at %s:%d' % (args.host, args.port_expose))
jina.excepts.GRPCServerError: can not connect to the server at <IP_ADDRESS>:33809
(jina) ~/PycharmProjects/jina_caption >>>

I found it did not index anything,so the search process terminated. maybe the ernie encoder did not work,I will try another.