expose map type callback

This PR would expose the google maps event that says "hey, the user changed from satellite view to roads view" or vice versa. This is something I need to detect and change the icon styles based on so am looking to expose it. Any input is greatly appreciated!

Doesn't seem like CI is related to my PR...

Really?
653:63  error  Trailing spaces not allowed  no-trailing-spaces

LOL when i looked at it that message hadn't loaded yet and I got super confused. Will update!!

Having onBlabblaChange calback in interface I always try to find blabbla prop on any Component public interface.
Here we have 'onMapTypeIdChange' but mapTypeId is not present in props, for me it's confusing a little.
Not sure what to do, or to add mapTypeId as a controllable property, or to somehow change the event name. IMO first is overhead, and I can't suggest a good name for the second.
Your opinion?

That's a great point, I would say considering it's something that a user might want to set.. for example "oh, i want to show a satellite map here" we probably want it to be controlled. This seems reasonable to me.
https://developers.google.com/maps/documentation/javascript/reference#MapTypeId. The real truth though, is isn't it wrapped up in the options object? Like a lot of the things you can do with this library are hidden behind that sort of big options object that you can fill with styles, or whatever you want, so in a sense it's kinda handled. Thoughts?

Please add 1-2 lines about in documentation, and let's merge then.
Let's think about after merge, as now I have no ideas ;-)

<EMAIL_ADDRESS>


update database schema

Hi Stefan,
First, Thanks for this docker images. There was an error when I applied the latest image as dependency-check 's central database. The error said we should upgrade the schema of database

I checked repository of dependency-check, they have already upgraded database schema. We'd better follow them.
I can send a new pr to fix this problem.

Hey fiveddd,
Thanks for pointing this out. I´d happily accept your PR. Otherwise I could also provide a fix, but this would probably not happen earlier than the end of next week.
Regards,
Stefan

Hi,
Please take a look  (https://github.com/stefanneuhaus/dependencycheck-central-mysql-docker/pull/14).

Hi Stefan, any update on this? The current version of dependency-check does not work with this db anymore. Thanks :-)

Hey @cpfeiffer and @fiveddd, I'm sorry for the delay. I was wondering on how to proceed as DockerHub discontinued the automatic builds for their free accounts. After a first quick evaluation current plan is to migrate to a GitHub Workflow that builds the Docker image and publishes to DockerHub.
Once this is in place I will provide an updated image that is compatible with the current version of DependencyCheck.
Hopefully I do not run into compatibility issues when building/running/testing the image locally on my new M1 Mac. :see_no_evil:

I see, good luck with your new Mac :smiley: If you need help with the GitHub workflow, please yell. And thanks a lot for maintaining this :heart:

I fixed the compatibility issue, but did not yet replace the pipeline to publish to DockerHub. Hopefully I will manage to do this in the next couple of days.
So in the meantime feel free to clone the repository and build your docker image locally, if ypplicable for you.

I finally managed to publish the latest v6.5.3 release to DockerHub. 🎉
Getting the GitHub Actions workflows running took me longer than expected ... 🙈 Thanks for waiting and sorry for the delay!


new release

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/73474
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v1.1.0 -m "<description of version>" ee7d573110d7550fa7218899e827c916f946e62b
git push origin v1.1.0

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/73732
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v1.1.1 -m "<description of version>" 620b692182acf8d54c7746e85d5bbd02cbec68c8
git push origin v1.1.1

Also, note the warning: Version 1.1.1 skips over 1.1.0
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

@JuliaRegistrator register

Registration pull request updated: JuliaRegistries/General/73474
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v1.1.0 -m "<description of version>" e58f28bb19e977bc63e76c848e37144356267b75
git push origin v1.1.0

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/77100
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v2.0.0 -m "<description of version>" 4b6748290c70707cdd1a0d91fc6b4a3ac4c110a7
git push origin v2.0.0

@JuliaRegistrator register

Registration pull request updated: JuliaRegistries/General/77100
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v2.0.0 -m "<description of version>" df0db4db4c2ee2bc78be57e44813b251fa04b5d8
git push origin v2.0.0

@JuliaRegistrator register

Registration pull request updated: JuliaRegistries/General/77100
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v2.0.0 -m "<description of version>" 73dff9f911123f4b193625e20096042cba5eff9c
git push origin v2.0.0

@JuliaRegistrator register

Error while trying to register: "Tag with name v2.0.0 already exists and points to a different commit"

@JuliaRegistrator register

Error while trying to register: "Tag with name v2.0.0 already exists and points to a different commit"

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/77426
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v2.0.1 -m "<description of version>" 038c2aaac9901c33a096105dc5144b5d9ba6c0a3
git push origin v2.0.1

Also, note the warning: Version 2.0.1 skips over 2.0.0
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

@JuliaRegistrator register

Error while trying to register: "Tag with name v2.0.0 already exists and points to a different commit"

@JuliaRegistrator register

Registration pull request updated: JuliaRegistries/General/77100
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v2.0.0 -m "<description of version>" dc913fc2f9598f2c77a6f37673a623e2ff7fcdad
git push origin v2.0.0

@JuliaRegistrator register

Registration pull request updated: JuliaRegistries/General/77426
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v2.0.1 -m "<description of version>" 23d20fbdb6fd100e75ca541add8e7febfdbe4c4d
git push origin v2.0.1

Also, note the warning: Version 2.0.1 skips over 2.0.0
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/77699
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v2.0.2 -m "<description of version>" 895c4127c9b184247768af8c12f181063c2b2fc3
git push origin v2.0.2

Also, note the warning: Version 2.0.2 skips over 2.0.0
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/78052
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v2.0.1 -m "<description of version>" c0ed8c06ccc1db05d779d40fd79acd2e6dd8a8c7
git push origin v2.0.1

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/79814
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v2.0.2 -m "<description of version>" e2f583d5a7cac30f9503c6eec72380cf0e2a8695
git push origin v2.0.2

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/82337
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v2.0.3 -m "<description of version>" 5ac12a69a720e2bc186fc9c2730a6029f817bc18
git push origin v2.0.3

@JuliaRegistrator  register

Registration pull request created: JuliaRegistries/General/83803
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v2.0.4 -m "<description of version>"<PHONE_NUMBER>c855e429ad6c17654a3aa03fa49f4c
git push origin v2.0.4

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/86586
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v2.0.5 -m "<description of version>" 00b2265bb1a00ec8284f1ddb9ee8bd5bd994f1f0
git push origin v2.0.5


Dockerfile: remove genienlp and torch

Pull Request Test Coverage Report for Build 3492

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.01%) to 64.798%

Files with Coverage Reduction
New Missed Lines
%

src/model/entity.ts
2
76.92%

Totals

Change from base Build 3491:
-0.01%

Covered Lines:
7360

Relevant Lines:
10703

💛  - Coveralls


Sapling problems

SaplingBlock is not in the sapling subpackage. It probably should as it uses SaplingGenerator from that package.
SaplingGenerator has createTreeFeature and subclass LargeTreeSaplingGenerator has createLargeTreeFeature; however, these methods return a constant reference to a feature than creating a new configured feature on each call.

Note: Thanks to FabricMC/fabric#1507 for spotting these issues

As for (1), I'm not so sure about moving since all the block classes are currently in the same package (even though there are packages like block.piston and block.cauldron). Moving them into that package would break the current "semi-convention".
(On the other hand, fixing (2) is just fine.)

Oh right, didn't realize the sapling package only has generators but no block classes. My bad!


[9.x] Typehint tap to input value

This allows tap($myObject)->someFunctionHere() to be properly typehinted so that chained functions are inferred as elements from $myObject,
I've targeted 9.x because this is code annotation only and useful for everyone.

I am sorry, but the currently type system in PHP via annotations does not allow to proper type this function. Thank you for your contribution.


revert: "revert: "fix(rspack_loader_swc): enable SWC plugins"" !windows !macos

Reverts web-infra-dev/rspack#5865

Do you need any assistance resolving this? Did you find a bug when SWC is compiled with plugins or is it a test runner issue?


Adjust the prompt at release to remind releasing querydsl-contrib

I don't think a backport is necessary for this one.
One reminder sounds okay I think.

Ha! Elegant solution, sir. ;)

Maybe in release.sh instead? At only for major versions? ;)

How about a reminder to update the soft link to the latest documentation?

Good point!
Shall I also just repush with [ci skip]?
It doesn't affect the build.

Yes.

I made adjustments, comments?

Looks good, shall I merge?

Yes, that's fine with me.

Nice work, Ruben.


CI: pin asv to avoid slowdowns in 0.5/0.5.1

[skip azp]
[skip actions]
Closes gh-15568

Okay, CI is green again, the end of almost 2 weeks of N emails/day about failures. So in it goes.

Timing for the job is back to ~25 minutes for the asv run, rather than timing out at 40% after an hour.


Doesn't recognize the TLS record header

This is my server run:
$ python main.py --proxy_mode=HTTPS --debug
### Started HTTPS proxy on 4433 ###
DEBUG:root:request from the ip <IP_ADDRESS>
DEBUG:root:handling request
DEBUG:root:Proxy mode is HTTPS
DEBUG:root:Read host example.com and port 443 from HTTP connect
DEBUG:root:Resolved <IP_ADDRESS> from example.com
DEBUG:root:Connected to <IP_ADDRESS>:443
DEBUG:root:Not a TLS handshake record header: b'\x14\x03\x03\x00\x01'
Exception in thread Thread-3 (forward):
Traceback (most recent call last):
  File "/usr/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.10/threading.py", line 953, in run
    self._target(*self._args, **self._kwargs)
  File "/home/jigsaw/code/DPYProxy/network/Proxy.py", line 96, in forward
    data = from_socket.recv(4096)
  File "/home/jigsaw/code/DPYProxy/network/WrappedSocket.py", line 70, in recv
    _res = self.socket.recv(size, *args, **kwargs)
OSError: [Errno 9] Bad file descriptor

This is the client:
curl -p -x http://localhost:4433 https://example.com/

I do get the page, but it's not behaving as expected.
I should not get the Not a TLS handshake record header: b'\x14\x03\x03\x00\x01' error.
There's also a bad file descriptor error there, though that doesn't seem to affect the page fetch.

This also doesn't work:
Server
$ python main.py --proxy_mode=SNI --debug
### Started SNI proxy on 4433 ###
DEBUG:root:request from the ip <IP_ADDRESS>
DEBUG:root:handling request
DEBUG:root:Proxy mode is SNI
WARNING:root:Could not parse initial proxy message with (('Not a TLS connection',), {}). Stopping!

Client:
curl --connect-to ::localhost:4433 http://example.com/

In this case the connection gets stuck.
Perhaps I'm misunderstanding how you should use the server. It would be really helpful if you provided examples with curl.

Nevermind, the error is misleading. The code is working.
I confirmed the TCP and TLS record fragmentation with tshark.
 In my case, TCP fragmentation didn't help in any way.

For the record, this is how I ran with TCP fragmentation only:
python main.py --proxy_mode=HTTPS --tcp_frag --no-record_frag --debug

And TLS record fragmentation only:
python main.py --proxy_mode=HTTPS --no-tcp_frag --record_frag --debug

I used --frag_size to change the fragment size.
In this network in Iran, you don't need small TLS record fragments. All you need it to leave a single byte out.
In my experiment the TLS handshake is 512 bytes.
A fragment of 511 bytes bypassed blocking, while 512 didn't:
python main.py --proxy_mode=HTTPS --no-tcp_frag --record_frag --frag_size=511 --debug

This is the tshark output with 511:
Transmission Control Protocol, Src Port: 41514, Dst Port: 443, Seq: 1, Ack: 1, Len: 522
Transport Layer Security
    TLSv1 Record Layer: Handshake Protocol: Client Hello (fragment)
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 511
        Handshake Protocol: Client Hello (fragment)
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 1
        Handshake Protocol: Client Hello (last fragment)
        [2 Reassembled Handshake Fragments (512 bytes): #587(511), #587(1)]
            [Frame: 587, payload: 0-510 (511 bytes)]
            [Frame: 587, payload: 511-511 (1 byte)]
            [Handshake Fragment count: 2]
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 508
            Version: TLS 1.2 (0x0303)

Thanks for the feedback. I changed some debug statements to the info or warning level and their content to clear up which statements are purely "debug" and which indicate an actual error.
The "Not a TLS handshake record header:" occurs when the handshake is finished and the proxy stops fragmenting TLS records. So that one should not look like an error. I changed that
The BadFileDescriptor OSError is also caught now. What's still missing is to close both the client and server socket when one closes, right now this happens a bit late.
I'm glad to see that record fragmentation also works in Iran! Interestingly, they seem to have the same behavior as the GFW. Both cannot handle even the slightest case of record fragmentation even tho they could greedily interpret at least the first fragment.

Thanks for being so responsive!
I'm also surprised that keeping the SNI in the first record worked!

I tested in a network in Russia, and it behaves the same as in Iran:

The TLS record fragmentation bypasses SNI-based blocking

All you need is to leave one byte out. The SNI doesn't need to be split and can be in the first record

TCP fragmentation doesn't bypass blocking

For reference, this is how I tested it:
Started a local proxy that uses an Outline server in Russia:
go run github.com/Jigsaw-Code/outline-sdk/x/examples/http2transport@latest -transport "$KEY" -localAddr localhost:8080

Started a local DPYProxy, forwarding to my local proxy.
./venv/bin/python main.py --proxy_mode=HTTPS --no-tcp_frag --record_frag --frag_size 313 --debug --forward_proxy_address=localhost --forward_proxy_port=8080 --forward_proxy_mode=HTTPS

Used curl, talking to DPYProxy and resolving the destination name locally:
curl -p -x http://localhost:4433 --connect-to ::$(dig +short meduza.io | tail -1) https://meduza.io

I did a binary search to find the largest --frag_size that works, which is one byte shorter than the size of the handshake recorded emitted by curl, which I found using Wireshark.

Thanks for the input!
I'm wondering why censors cannot interpret the SNI in the first fragment. In my head there are two options rn:

They check for a match of TLS record/TLS message length fields before parsing the SNI (i.e. TLS record length = TLS message length+4
They try to parse a complete message from the record and fail during parsing

Both seem a bit unnecessary in the sense that it would be much easier to greedily start checking the cientHello until the SNI is reached and fail only if its not present in the record for whatever reason (no SNI or fragmented records). So my best guess is that censors are completely unaware of the concept of record fragmentation. But I might be wrong here
I also ran some more experiments on the GFW and the message / record length fields. In all experiments I used a TLS 1.3 ClientHello to wikipedia.org as a basis and only tampered with the length fields:
Reducing both fields: Censored, so the GFW does need need to parse a complete message
Reducing only TLS message length: Censored, so the GFW does not need to parse a complete TLS message and does not rely on a match between both length fields (this is also censored when we remove the bytes that are not indicated by the length field from the clienthello message i.e. sending an incomplete tls clienthello over the wire)
Reducing only TLS record length: Not censored, message that exceed their record length seem not to be analyzed by the GFW, even though they are technically able to analyze partial message as seen above.

I think your theory #1 makes sense. Their "is TLS" filter probably checks for 16 03 01 * * 01 * * * and adding a length check would increase the precision of the filter (though the chance of that sequence is already tiny).

Reducing both fields: Censored, so the GFW does need need to parse a complete message

I believe you meant "the GFW does not need to parse a complete message". That makes sense, since when we reduce both the TLS message and record lengths, you should see a corrupted extension at the end, with a length that goes past the message boundary.
My takeaway is that they may remove the length check, so we should fragment before the SNI, to force a record reassembly.
/cc @jyyi1 @daniellacosse

Yes, you are correct. I meant

Reducing both fields: Censored, so the GFW does not need to parse a complete message

I would slightly change my theory 1 from

TLS record length = TLS message length+4

to at least

TLS record length >= TLS message length+4

as the GFW is able to parse TLS message that are smaller than the surrounding TLS record.
In the end, I agree with your takeaway that fragmenting before the SNI is the safer option as it forces record reassembly. I also suspect that a combination of TCP and TLS fragmentation of different sizes might prove useful even if censors start reassembling messages.


ignore transform on classes loaded by opentelemetry AgentClassLoader

fix https://github.com/arextest/arex-agent-java/issues/513

@lucas-myx please take a review

@mr3 新的 commit 增加了配置 ignoreTypePrefixes，简化了 ArexIgnoreMatcher 构造，再 review 下呢

@mr3 新的 commit 增加了配置 ignoreTypePrefixes，简化了 ArexIgnoreMatcher 构造，再 review 下呢

Copy that. I'll check it out later.

@shichanglin5 Thanks very much for the PR!
I've made a small change, type and classloader are now unified as prefix configuration, please complete the unit tests for the changed codes, and we will merge this PR for regression testing later.

好的，建议把ot agent 相关忽略默认加上，ot agent 非常通用，降低同时挂载场景时的接入和理解成本

@shichanglin5 LGTM.


[HUDI-1518] Remove the logic that delete replaced file when archive

What is the purpose of the pull request
Since https://github.com/apache/hudi/pull/2422 Cleaner now takes care of removing replaced file groups. This call to deleteReplacedFileGroups can be removed.
Also it's a little confused that archive can delete data file even users set auto.clean false.
Brief change log
(for example:)

Modify AnnotationLocation checkstyle rule in checkstyle.xml

Verify this pull request
(Please pick either of the following options)
This pull request is a trivial rework / code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end.
Added HoodieClientWriteTest to verify the change.
Manually verified the change by running a job locally.

Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Codecov Report

Merging #3310 (39fc079) into master (572a214) will decrease coverage by 45.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master   #3310       +/-   ##
============================================
- Coverage     47.83%   2.82%   -45.02%
+ Complexity     5565      85     -5480
============================================
  Files           936     284      -652
  Lines         41663   11868    -29795
  Branches       4197     985     -3212
============================================
- Hits          19929     335    -19594
+ Misses        19960   11507     -8453
+ Partials       1774      26     -1748

Flag
Coverage Δ

hudicli
?

hudiclient
0.00% <ø> (-34.53%)
:arrow_down:

hudicommon
?

hudiflink
?

hudihadoopmr
?

hudisparkdatasource
?

hudisync
4.88% <ø> (-51.10%)
:arrow_down:

huditimelineservice
?

hudiutilities
8.97% <ø> (-50.80%)
:arrow_down:

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

Impacted Files
Coverage Δ

...rg/apache/hudi/table/HoodieTimelineArchiveLog.java
0.00% <ø> (ø)

...va/org/apache/hudi/utilities/IdentitySplitter.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...va/org/apache/hudi/utilities/schema/SchemaSet.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...a/org/apache/hudi/utilities/sources/RowSource.java
0.00% <0.00%> (-100.00%)
:arrow_down:

.../org/apache/hudi/utilities/sources/AvroSource.java
0.00% <0.00%> (-100.00%)
:arrow_down:

.../org/apache/hudi/utilities/sources/JsonSource.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...rg/apache/hudi/utilities/sources/CsvDFSSource.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...g/apache/hudi/utilities/sources/JsonDFSSource.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...apache/hudi/utilities/sources/JsonKafkaSource.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...pache/hudi/utilities/sources/ParquetDFSSource.java
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 772 more

Continue to review full report at Codecov.

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

@satishkotha do you mind taking a second look at this? Seems ok to do.

Hi @satishkotha Thanks a lot for your review and merge!


serving with grunt, am I missing something?

I am trying to serve with grunt.
When I try, I get:
/daux.io)  git:(master) 1A $ grunt
A valid Gruntfile could not be found. Please see the getting started guide for
more information on how to configure grunt: http://gruntjs.com/getting-started
Fatal error: Unable to find Gruntfile.

I thought in the README is says a gruntfile is included. What am I missing? I am not quite familiar with grunt.

Actually the built in generate and serve commands are enough.


Preloading orders by partial primary key

What version of Go are you using (go version)?
1.13.7 (gorm 1.9.12)
Which database and its version are you using?
postgres
Please provide a complete runnable program to reproduce your issue. IMPORTANT
package main

import (
	"github.com/google/uuid"
	"github.com/jinzhu/gorm"
	_ "github.com/jinzhu/gorm/dialects/postgres"
)

type header struct {
	ID      uuid.UUID `gorm:"column:header_id;primary_key"`
	Name    string    `gorm:"column:header_name"`
	Details []detail  `gorm:"foreignkey:HeaderID"`
}

type detail struct {
	HeaderID    uuid.UUID `gorm:"column:header_id;primary_key"`
	LineNumber  uint32    `gorm:"column:line_num;primary_key;auto_increment:false"`
	Description string    `gorm:"column:detail_txt"`
}

func main() {
	db, _ := gorm.Open("postgres", "host=localhost port=5432 user=postgres dbname=sandbox password=p05Tgr352 sslmode=disable")
	defer db.Close()

	db = db.Set("gorm:auto_preload", true)

	db.AutoMigrate(&header{})
	db.AutoMigrate(&detail{})

	id := uuid.New()

	hdr := header{
		ID:   id,
		Name: "Sample",
		Details: []detail{
			{HeaderID: id, LineNumber: 1, Description: "line 1"},
			{HeaderID: id, LineNumber: 2, Description: "line 2"},
			{HeaderID: id, LineNumber: 3, Description: "line 3"},
		},
	}

	db.Create(&hdr)

	db.LogMode(true)

	hdr1 := header{ID: id}
	db.First(&hdr1)
}

output:
(U:/Documents/PortfolioManager/gormPreload.go:47)
[2020-03-20 14:11:03]  [4.42ms]  SELECT * FROM "headers"  WHERE "headers"."header_id" = '2fa7ac7a-66b7-47a3-96f3-4366a38ff349' ORDER BY "headers"."header_id" ASC LIMIT 1
[1 rows affected or returned ]
(U:/Documents/PortfolioManager/gormPreload.go:47)
[2020-03-20 14:11:03]  [0.50ms]  SELECT * FROM "details"  WHERE ("header_id" IN ('2fa7ac7a-66b7-47a3-96f3-4366a38ff349')) ORDER BY "details"."header_id" ASC
[3 rows affected or returned ]
The SQL generated orders by only the first field of the primary key, but for this structure, that will be the same for all members of the same list.  Essentially, the order within the list is random.  The order clause for the generated SQL (if there is going to be one) should take the entire primary key into account.
Workarounds:

Use the documented custom SQL capability.  Unfortunately, that doesn't work with auto_preload (I'll link that bug in comments) and this model structure should be supported by default.

Flip the order of the primary key fields so that the unique part of the key is the first field listed.  Feels wrong from a standard data modelling perspective, and also because database coding (in general) shouldn't have different behavior if columns are listed in a different order.

Don't include the parent ID in the primary key.  This would work in my environment because we don't use gorm to build the tables, I could just put the primary key tag on the LineNumber field.  That won't work for anyone who uses gorm to create the tables.  Also, it would feel wrong as well because LineNumber is not unique on its own and having the gorm tags disagree with the underlying data structure would cause maintenance problems later.

custom preload SQL can't be auto_preloaded


Update lint dependencies

This PR updates lint packages and fixes the relevant code.
Note that eslint-config-seegno and jscs-config-seegno are pointing to commits until those are released.

Deprecated. Closing the PR.


Proposal: @js.native vals and defs

Currently, we can use @js.native only on classes and objects (and traits, but with a different story). We can do that if they are at the top-level of a package, or within a static Scala object. For example:
object Container {
  @js.native
  @JSImport("foo.js", "bar")
  object Bar extends js.Object
}

This allows to easily import (or fetch from the global scope) classes and objects from JavaScript. However, for values and functions, we have to use an artificial enclosing object, and then use members of that object. For example:
@js.native
@JSImport("foo.js", JSImport.Namespace)
object Foo extends js.Any {
  val bar: Int = js.native
  def baz: String = js.native
  def add(x: Int, y: Int): Int = js.native
}

This is an inconsistent limitation, especially when contrasted with:

@JSExportTopLevel, which can be used on any static term definition, and
the fact that in Scala, every level of scoping obeys the same rules.

I propose that we allow @js.native (together with @JSGlobal or @JSImport) on vals, getter defs and method defs (not on setter defs) enclosed in a static Scala object (just like we do for classes and objects). And if Scala ever supports top-level vals and defs, we would extend @js.native to those as well. The right-hand side must in that case be = js.native. For example:
object Container {
  @js.native
  @JSImport("foo.js", "bar")
  val bar: Int = js.native

  @js.native
  @JSImport("foo.js", "baz")
  def baz: String = js.native

  @js.native
  @JSImport("foo.js", "add")
  def add(x: Int, y: Int): Int = js.native
}

In addition to the consistency argument, the above definition, while more verbose given the multiple imports, will allow to emit (and guarantee) better code for ES modules. Indeed, we will be able to avoid namespace imports, which have poor properties in terms of cross-module dead-code-elimination, something that is supposed to be one of the flagship advantages of ES modules.
Such definitions would naturally also be allowed in package objects, which will compensate the fact that we forbade package objects from extending js.Any.

This is excellent! One more way it will help is avoid casting. In our code base, we have several instances of the following kind:

object LandingPage extends StatelessComponentWrapper {
  @js.native
  @JSImport("resources/img/logo-banner.png", JSImport.Default)
  object LogoBanner extends js.Object

  ...
  img(src := LogoBanner.asInstanceOf[String], alt := "LearnRaga")
  ...

}

With the proposal, I believe, we will be able to do the following:
object LandingPage extends StatelessComponentWrapper {
  @js.native
  @JSImport("resources/img/logo-banner.png", JSImport.Default)
  val logoBanner: String = js.native

  ...
  img(src := logoBanner, alt := "LearnRaga")
  ...

}

With the proposal, I believe, we will be able to do the following:

Indeed.

Oh that will eliminate a lot of casts, I like it!

I'm tentatively scheduling this post-1.0.0. @sjrd if there are binary compatibility concerns, please revise.


Allow Plans to apply to multiple repositories

There are now many plans in our production instance which duplicate everything except the repository they target.  It would be far easier to maintain plans that can apply to multiple repositories with the same config.  If an individual project needed a custom version of the plan, it would be unlinked from the shared plan's repositories field and a new Plan with the same configuration would be manually created targeting only that repository with the config customizations it requires.

this is done!


Move pipeline steps into templates and add internal Release build

Extract common parts of build definitions into templates.
Add ci-release template (for the build that creates official packages).
Some things to note or to improve further:

The standard extension for YAML is .yml, not .yaml. Unfortunately I used the latter for the original pipeline definitions and I did not rename those files in this PR (mrtk_CI and mrtk_PR pipelines point to them, so we would need to switch on the Azure DevOps side). I used .yml extension for any new files.
We could actually change to a different convention - use .yml for top level configs (Azure DevOps UI will automatically locate them and display in a drop down when creating a new build) and .yaml for internal templates (won't be picked up by the UI). Perhaps something to consider later on?
I tried to move UnityVersion and MRTKVersion variables into a separate template. This works but unfortunately pool:demands does not perform variable expansion, so we would still end up with multiple places where the Unity version needs to be updated. I reverted that change for now - we can revisit that later.
PR validation now also gained a step to compile with .NET backend. It was convenient to do that instead of splitting the "common.yml" template but I can change that based on feedback.

@macborow has this been tested in pipelines?

/run azp mrtk_PR

@macborow has this been tested in pipelines?

Yes, all 3 of them (in both projects).

FYI, another PR check (with unrelated changes) has just failed with the exact same error (using the old build definitions). Perhaps machine got in bad state??


Examples?

Can create any examples e.g. to intercept on MITM and do something with the payload, like refusing a forward.

Would recommend Titanium Web Proxy for that. This repository doesn't seem to be updated often.


Horizontal TabBar item changes after being pressed

Let's say my tab bar item index is 0
If I press Tabbar item with index=3, both the Vertical view and the Horizontal tabbar scrolls to the right place.
However, instantly the horizontal tabbar scroll backs to index=2.
As you can see from the video, this only happens if we are going from a smaller index to a higher index AND if that particular index has lots of items in them (more than the screen height).
@wayne900204 Can you please look into this bug? Thank you.
https://user-images.githubusercontent.com/6442915/158272351-ad7f930b-f747-4428-bf98-68fb8fb79696.mov

I will try to look into this bug

I have the same issue

I had the same issue and tried to understand what was happening. I found out that the method getVisibleItemsIndex() sometimes returns indices that are not even visible on the screen. I found out that this happens because for some reason the list I was having was overlapping with the AppBar (the list items were going below it), so to the getVisibleItemsIndex() method, they are visible until they are scrolled out from below the AppBar as well. To fix this I altered the method to make sure it does not return the item if it is only under the AppBar by adding the height of the AppBar to the if condition.
`List getVisibleItemsIndex() {
// get ListView Rect
Rect? rect = RectGetter.getRectFromKey(listViewKey);
List items = [];
if (rect == null) return items;
/// TODO Horizontal ScrollDirection
// bool isHoriontalScroll = widget._axisOrientation == Axis.horizontal;
bool isHoriontalScroll = false;
itemsKeys.forEach((index, key) {
Rect? itemRect = RectGetter.getRectFromKey(key);
if (itemRect == null) return;
// y 軸座越大，代表越下面
// 如果 item 上方的座標 比 listView 的下方的座標 的位置的大 代表不在畫面中。
// bottom meaning => The offset of the bottom edge of this widget from the y axis.
// top meaning => The offset of the top edge of this widget from the y axis.
//Change offset based on AxisOrientation [horizontal] [vertical]
switch (isHoriontalScroll) {
case true:
if (itemRect.left > rect.right) return;
// 如果 item 下方的座標 比 listView 的上方的座標 的位置的小 代表不在畫面中。
if (itemRect.right < rect.left) return;
break;
default:
if (itemRect.top > rect.bottom) return;
// 如果 item 下方的座標 比 listView 的上方的座標 的位置的小 代表不在畫面中。
if (itemRect.bottom < rect.top + MediaQuery.of(context).viewPadding.top +
kToolbarHeight +
65) return;
}
  items.add(index);
});
return items;

}`

when you click on a tab, the onScrollNotification() method is called after the controller scrolls to that tab, the method then does its job and animates the tab controller to the middle visible tab

The getVisibleItemsIndex() method sometimes returns an index of an item that is not visible on the screen. It only stops returning this index if you scroll a little more past the length of the AppBar.
So if you alter this if condition:
 if (itemRect.bottom < rect.top ) return;
To this:
 if (itemRect.bottom < rect.top + MediaQuery.of(context).viewPadding.top +kToolbarHeight +AppBar().preferredSize.height) return;
It will solve the problem in most cases but not in the case where there are three categories visible on the screen. because in this case, the onScrollNotification() will do its job and animate the tab controller to the middle category.

Thanks @mohamedalaaser

@mohamedalaaser @wayne900204 thank you for the fixes. I have tested with the new version.
But currently there is another problem as you can see in these 2 videos.
1-When "Bao" is pressed, indicator goes to "Highlighted" momentarily and then goes back to "Bao"
2-When we scroll the horizontal bar all the way to the end and press the last category, the whole horizontal scroll goes back to the beginning(current category) and scrolls again to the last item
https://user-images.githubusercontent.com/6442915/161397432-11160663-38cd-413b-8e16-1b084f2c6a7c.mov
https://user-images.githubusercontent.com/6442915/161397441-445bd5ef-2b2c-4469-af88-b35a22df471d.mov

@aytunch this doesn't happen with me :/
can you please share your code? ill try to see what's going on

@aytunch Can you please share your code?

@wayne900204 thanks for the package but, this problem is also in your example(folder) code, you can look there.

I have the same issue, too

@mohamedalaaser @wayne900204 thank you for the fixes. I have tested with the new version. But currently there is another problem as you can see in these 2 videos. 1-When "Bao" is pressed, indicator goes to "Highlighted" momentarily and then goes back to "Bao" 2-When we scroll the horizontal bar all the way to the end and press the last category, the whole horizontal scroll goes back to the beginning(current category) and scrolls again to the last item
Screen.Recording.2022-04-02.at.21.49.49.mov
Screen.Recording.2022-04-02.at.21.52.56.mov

I have the same issue,too

@wayne900204 Any updates on this?

already fixed.


popTo from useNavigation is missing componentId parameter

Hello,
I am trying to replace Navigation.popTo(componentId) with useNavigation hook, however according to typings there is not support for passing componentId which I want to pop to.
const {popTo} = useNavigation();
popTo(someComponentId); // <-- can not pass componentId

Please compare official rnn docs with rnn hooks docs to see the difference.
If this is not a mistake then please instruct me how to implement requested scenario. Btw I am glad to have this library, the code is so clean. Thank you.

This is a breaking change but since nobody has mentioned it before I think it won't have much impact
I'll let you know as soon as I can publish the new version
Thank you for reporting this!

Hi, I'm interested in this chage as well ;-)

shipped 🚀
thanks for your contribution

Any update?

glad to have this one on the next release


[GO] when using newSubnet setup args input the AvailabilityZoneId will fail.

i try to using
	pulumi.Run(func(ctx *pulumi.Context) error {
		vpc, err := ec2.NewVpc(ctx, "test", &ec2.VpcArgs{
			CidrBlock:       pulumi.String("<IP_ADDRESS>/24"),
			InstanceTenancy: pulumi.String("default"),
		})

		if err != nil {
			return err
		}

		_, err = ec2.NewSubnet(ctx, "test", &ec2.SubnetArgs{
			VpcId:            vpc.ID(),
			CidrBlock:        pulumi.String("<IP_ADDRESS>/24"),
			AvailabilityZone: pulumi.String("us-east-2b"),
			AvailabilityZoneId: pulumi.String("use2-az2"),
		})

		return err
	})

setup newSubnet.
but i got error aws:ec2/subnet:Subnet resource 'test' has a problem: ConflictsWith
this error description is confuse me. waste me one day to find the solution.
but, i got solution to fix this error.
solution is remove the AvailabilityZoneId arg.
if not put the AvailabilityZoneId, will got pass.
maybe need in document let user know. don't put AvailabilityZoneId this arg.
or just remove AvailabilityZoneId this arg.

Hi @nick6969
I am sorry that this caused you pain here. Unfortunately, these are both valid options to be passed to a subnet BUT they are not able to be used together. I agree with you that the error message is incorrect here and we should seek to improve that message
Paul

Closing this as a dupe of https://github.com/pulumi/pulumi-terraform-bridge/issues/309 which is the underlying issue to improve the diagnostic message.


Extract GeoStyler Data models as declaration file

To re-use the GeoStyler Data models in different parts of the GeoStyler ecosystem we need to extract them as TypeScript Declaration File.
Once this is done the declaration file can live in an own repository and thus be included in different GeoStyler components (DataParser, Core, etc.).
Child issue of #7

I just did a proof-of-concept by putting the GeoStyler Data models into a local Declaration File inside the GeoJSON-Parser implementation.
The Declaration File is here and the diff can be viewed here.
By now it works like expected.  Any feedback very welcome.

I move the TypeScript Declaration File for GeoStyler Data to an own repository:
https://github.com/terrestris/geostyler-data

I think we can close this issue as the https://github.com/terrestris/geostyler-data repo is in the README.md know...


When using the new breadcrumbs handler with Messenger, the Messenger should either flush or clear before every new message

Environment
sentry/sdk                             3.3.0                         This is a metapackage shipping sentry/sentry with a recommended HTTP client.
sentry/sentry                          3.11.0                        A PHP SDK for Sentry (http://sentry.io)
sentry/sentry-symfony                  4.4.0                         Symfony integration for Sentry (http://getsentry.com)

Steps to Reproduce
sentry:
    register_error_listener: false
    dsn: "%env(file:SENTRY_DSN_FILE)%"
    messenger:
        enabled: true
        capture_soft_fails: false
    tracing:
        enabled: false
    options:
        environment: '%env(APP_COHORT)%'
        integrations:
            - 'Sentry\Integration\IgnoreErrorsIntegration'

services:
    Sentry\Monolog\BreadcrumbHandler:
        arguments:
            - '@Sentry\State\HubInterface'
            - !php/const Monolog\Logger::INFO

monolog:
    handlers:
        sentry_breadcrumbs:
            type: service
            name: sentry_breadcrumbs
            id: Sentry\Monolog\BreadcrumbHandler
        sentry:
            type: sentry
            level: !php/const Monolog\Logger::ERROR
            hub_id: Sentry\State\HubInterface

Expected Result
The captured error contains breadcrumbs for the current message.
Actual Result
The captured error contains breadcrumbs for all the messages prior, most of which didn't trigger a Sentry capture.

Just to clarify, you're talking about unrelated breadcrumbs during the current request? This sounds like it's expected to me, breadcrumbs should show a trail of events that happened before an event. Or do I miss something?

The issue is it can show you many unrelated events, sometimes minutes before the current one. In the example I'm looking at, the first breadcrumb is from 10:48:07, the capture happened in 11:08:16, there were totally unrelated messages processed in the meantime, but they're still marked as "breadcrumbs".
From my POV, the breadcrumbs should be related to the current event, no? They're not meant to replace distributed tracing.

Are you running in some sort of CLI context? For HTTP requests, yes, the breadcrumbs should only be related to the current request cycle and nothing more.

Yes, this is Symfony Messenger specifically.

But I think I understand what you mean, the state of the process is also part of the story. It having processed previous messages can also be something to influence the current issue. :+1: I guess it's working as intended, it just looks weird when you're not used to it. :)

In our Laravel SDK, we do clear the breadcrumbs for each job.
https://github.com/getsentry/sentry-laravel/blob/8ce96842a9c3b047077fd59d66692ccf4eee5fc0/src/Sentry/Laravel/EventHandler.php#L573-L584
I can see how this would be helpful, not clearing them might be helpful as well. So it depends 🙂

So, what do you think here? Do I reopen?

Yes, let's take a look on how to improve this a bit.

TBH since I've opened the issue I've been thinking on POV made by @cleptric where the previous messages being processed by the same worker are also "breadcrumbs" in a way. I can see merit in both approaches, but clearing is for sure more efficient.
Having a longer history could be some sort of opt-in, for example:
sentry:
    messenger:
        breadcrumbs: 50 # would control the main SDK limit specifically in Messenger / CLI mode

The same problem will be present in newer runner based PHP runtimes like Swoole etc. The state of the process (previous requests processed) might directly be responsible for the event being captured by Sentry, having that in breadcrumbs would be extremely valuable.
Might we worth thinking it over in both directions.

#702 was opened as a duplicate of this one. There seems to be still request for this change.

What also is worth mentioning is that the ResetInterface was introduced on the DI component to support resetting services on the container, which is something that by-default happens on many services already (to prevent memory leaks / prevent stateful services to affect processing).
Having a stateless worker could be considered more valuable as having a trail of breadcrumbs from previous iterations. Why? Let's say you use supervisor to always have 20 workers, then the breadcrumb trail became more irrelevant because you don't know which worker processes which message, and that basically also wouldn't be considered as that valuable.

I've ran into the same problem using symfony messenger. Are there any plans on tackling this?

We'll look at this eventually. Can't give you a timeframe though 🙁

@rvanlaak

Let's say you use supervisor to always have 20 workers, then the breadcrumb trail became more irrelevant because you don't know which worker processes which message

The breadcrumbs would come from the current worker, as in, the worker which is reporting into Sentry. It doesn't matter which worker processed which messages, it's more like

This specific worker processed these specific messages when the error condition was reached.

Hence "breadcrumbs". We've actually solved one issue because of this feature, there was a message which wasn't cleared properly after having been completed and the next message would error out, but it itself wasn't at fault, the previous message was (which didn't trigger the error!). We've noticed in the breadcrumbs this happening and it gave us an idea what to look for. On one hand, yes it leads to memory leakage, on the other hand it has value in a distributed environment so it's a tradeoff.

What about a simple fix by letting the handler implement ResetInterface ?
https://symfony.com/doc/current/messenger.html#stateless-worker
https://github.com/symfony/symfony/blob/6.4/src/Symfony/Contracts/Service/ResetInterface.php

This would mean you don't get the described information about the previous messages in your Sentry issue breadcrumbs.

Correct. Given that every bus message by most users is considered to be an isolated transaction, that preferably is the expected behaviour as described in the issue above. Would you have a scenario in which you would like to know the breadcrumbs of a previous message?

Would you have a scenario in which you would like to know the breadcrumbs of a previous message?

I've literally just wrote about it today? :thinking:

We could add listening to WorkerMessageReceivedEvent & WorkerMessageHandledEvent and push/pop a scope for each job executed. As breadcrumbs are stored on the scope, this would clear those. And we likely also should make this configurable, as both behaviours have their merit.

We could add listening to WorkerMessageReceivedEvent & WorkerMessageHandledEvent and push/pop a scope for each job executed. As breadcrumbs are stored on the scope, this would clear those. And we likely also should make this configurable, as both behaviours have their merit.

That's exactly what I did to solve this problem for now:

    public function onWorkerMessageReceived(WorkerMessageReceivedEvent $event): void
    {
        $this->sentryHub->configureScope(function (Scope $scope) {
            $scope->clear();
        });
    }

IMO, my suggestion from here still makes sense, I'd just change the name:
sentry:
    messenger:
        prior_breadcrumbs: 10

This would mean you keep at most 10 most recent breadcrumbs from previous messages (or disable with setting to 0). If the handler generates say 5 breadcrumbs while handling the current message, you'd get 15 in total.
The listener then does the equivalent of:
    public function onWorkerMessageReceived(WorkerMessageReceivedEvent $event): void
    {
        $this->sentryHub->configureScope(function (Scope $scope) {
            $scope->clearAllButMostRecent(10);
        });
    }

This would require changing the base SDK, and to be honest, I'm not keen on adding such a specific method there.


Badly formatted translations crash the server process

How to reproduce:

Click any translation field in the UI.
Write {, or just any MessageFormat with oddly matched braces.
Press Tab.

An exception is thrown. Since the exception is thrown inside an asynchronous callback without a try/catch (_.debounce :bomb:), it reaches the node.js main loop. Boom. The entire server process crashes. And no traceback whatsoever of who called the errored function.
/tmp/guigrpa-mady-9485b5e/src/server/db.js:395
        throw _iteratorError2;
        ^

Error: Parser error with `exampleContext_{NUM, plural, one{1 hamburger} other{# hamburgers} }`: SyntaxError: Expected "=", "}" or identifier but end of input found.
    at compileMsg (/tmp/guigrpa-mady-9485b5e/node_modules/messageformat/lib/messageformat.js:483:17)
    at MessageFormat.compile (/tmp/guigrpa-mady-9485b5e/node_modules/messageformat/lib/messageformat.js:508:21)
    at compileTranslations (compileTranslations.js:33:24)
    at _compileTranslations (db.js:286:25)
    at invokeFunc (/tmp/guigrpa-mady-9485b5e/node_modules/lodash/lodash.js:9402:23)
    at trailingEdge (/tmp/guigrpa-mady-9485b5e/node_modules/lodash/lodash.js:9450:18)
    at Timeout.timerExpired (/tmp/guigrpa-mady-9485b5e/node_modules/lodash/lodash.js:9437:18)
    at tryOnTimeout (timers.js:224:11)
    at Timer.listOnTimeout (timers.js:198:5)

npm ERR! Linux 4.5.1-1-ARCH
npm ERR! argv "/usr/bin/node" "/usr/bin/npm" "start"
npm ERR! node v5.10.1
npm ERR! npm  v3.8.7
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>start: `babel-node src/server/startup`
npm ERR! Exit status 1

It's kind of funny that less than 12 hours after I extensively wrote about this problem with node.js server programming in general I find it crashing applications on the wild.
You may want to do all your asynchronous staff with promises in order to be able to catch errors, since those have a built-in try catch that avoid them reaching the main loop and a mechanism to gracefully react to them (promise rejection). You may also want to have long stack traces in order to track what is causing the errors.

Thanks for the report! It has been corrected with my latest commit.
@ntrrgc Regarding promises and long stack traces, I also use them in mady (see server/startup.js), but clearly not in this case with the debounced compileTranslations() (it was synchronous originally).


how to remove youtube logo from iframe in player

modestbranding can remove youtube logo but i dont know how to use it in this player

How to set modestbranding=0 ?


Error in legit-info-job-analyzetext - value too long for type character varying(800)

Relevance attribute of Law model can only accommodate 800 characters:
https://github.com/Call-for-Code-for-Racial-Justice/Legit-Info/blob/5e4f8d8faf5f7a721e658ec5053fd17aaadda965/cfc_app/models.py#L244
@tonypearson @tnadams: not sure the best way to handle this. Can increase the field to 1000 or truncate relevance? I am not sure where else relevance is being used.
Any more throws this error:
Jun 13 18:36:20 Code Engine legit-info-job-analyzetext-jobrun-2xb9n-0-0 06-14 01:36:13 analyze_text:handle [ERROR] 151:Process State Error: value too long for type character varying(800)
Jun 13 18:36:20 Code Engine legit-info-job-analyzetext-jobrun-2xb9n-0-0 Traceback (most recent call last):
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
Jun 13 18:36:20 Code Engine legit-info-job-analyzetext-jobrun-2xb9n-0-0 psycopg2.errors.StringDataRightTruncation: value too long for type character varying(800)
Jun 13 18:36:20 Code Engine legit-info-job-analyzetext-jobrun-2xb9n-0-0 The above exception was the direct cause of the following exception:
Jun 13 18:36:20 Code Engine legit-info-job-analyzetext-jobrun-2xb9n-0-0 Traceback (most recent call last):
  File "/opt/app-root/src/cfc_app/management/commands/analyze_text.py", line 162, in handle
    self.process_state(state)
  File "/opt/app-root/src/cfc_app/management/commands/analyze_text.py", line 188, in process_state
    self.process_legislation(filename, textdata, header)
  File "/opt/app-root/src/cfc_app/management/commands/analyze_text.py", line 273, in process_legislation
    self.save_law(key, header, rel, imp_chosen)
  File "/opt/app-root/src/cfc_app/management/commands/analyze_text.py", line 376, in save_law
    law.save()
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/models/base.py", line 753, in save
    self.save_base(using=using, force_insert=force_insert,
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/models/base.py", line 790, in save_base
    updated = self._save_table(
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/models/base.py", line 872, in _save_table
    updated = self._do_update(base_qs, using, pk_val, values, update_fields,
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/models/base.py", line 926, in _do_update
    return filtered._update(values) > 0
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/models/query.py", line 803, in _update
    return query.get_compiler(self.db).execute_sql(CURSOR)
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/models/sql/compiler.py", line 1522, in execute_sql
    cursor = super().execute_sql(result_type)
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/models/sql/compiler.py", line 1156, in execute_sql
    cursor.execute(sql, params)
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/backends/utils.py", line 98, in execute
    return super().execute(sql, params)
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/backends/utils.py", line 66, in execute
    return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/backends/utils.py", line 75, in _execute_with_wrappers
Jun 13 18:36:20 Code Engine legit-info-job-analyzetext-jobrun-2xb9n-0-0 .........................................................................................................................................................................................................................Processing: Arizona, USA (AZ)
    return executor(sql, params, many, context)
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/utils.py", line 90, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/opt/app-root/lib64/python3.8/site-packages/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)

I think this is because the "relevance" column has been defined with an 800 character limit in the database itself. If we want to raise this to 1000, it needs to be done here first then extend the new limit to anywhere else we assign this a value.
https://github.com/Call-for-Code-for-Racial-Justice/Legit-Info/blob/23d502f9ca5309924d33821059874010b85a079c/sources/cfc-law30.sql#L12
    CREATE TABLE "cfc_app_law"(
      id SERIAL UNIQUE,
      "key" VARCHAR(25),
      title VARCHAR(200),
      summary VARCHAR(1000),
      impact_id INT,
      location_id INT,
      bill_id VARCHAR(15),
      doc_date DATE,
      cite_url VARCHAR(200),
      **relevance VARCHAR(800)**
    );

Thanks @tnadams. Is the sql file used? I thought the makemigrations and migrate commands created the database from the models.py file directly. Is the SQL file more for backup?
In either case, if 1000 is the correct length, we can change it in both places. Is that enough? Secondly, what is the relevance field used for? What does a relevance like this signify?
(NLU)'Medicine' => 'Healthcare', 'Health care' => 'Healthcare', 'Nursing' => 'Healthcare', 'Physician' => 'Healthcare', 'Registered nurse' => 'Healthcare', 'Health care provider' => 'Healthcare', 'Opioid' => 'Healthcare', 'Prescription drug' => 'Healthcare', 'Health' => 'None', 'Drugs' => 'None'


Add files via upload

solicitud seq

@hub-igna You might miss my previous comment. Please react.

@hub-igna I am sorry, this request remains unanswered for a while. I have to close it without merging. Please reopen and comment if you have an update regarding the aforementioned issue. Thank you for your understanding!


Improve HTTP error handling.

This modifies the code which handles failed server responses to attempt to unmarshal the response bytes as a regular JSON-RPC response regardless of the HTTP status code and, if that fails, return an error that includes the status code as well as the raw response bytes.
This is being done because some JSON-RPC servers, such as Bitcoin Core, don't follow the intended HTTP status code meanings.  For example, if you request a block that doesn't exist, it returns a status code of 500 which is supposed to mean internal server error instead of a standard 200 status code (since the HTTP request itself was successful) along with the JSON-RPC error response.
The result is that errors from Core will now show up as an actual RPCError instead of an error with the raw JSON bytes.
This also has the benefit of returning the HTTP status code in the error for real HTTP failure cases such as 401 authentication failures, which previously would just be an empty error when used against Core
since it doesn't return the actual response along with the status code as it should.
Fixes #60.

A few more details.  Using the following code to talk to Bitcoin Core:
	// Try to get block that doesn't exist.
	hash := &chainhash.Hash{}
	block, err := client.GetBlock(hash)
	if err != nil {
		log.Fatalf("type: %T, error: %[1]v", err)
	}
	log.Print(block.BlockHash())

Without this PR:

2016/09/16 14:58:26 type: *errors.errorString, error: {"result":null,"error":{"code":-5,"message":"Block not found"},"id":2}

With this PR:

2016/09/16 14:59:01 type: *btcjson.RPCError, error: -5: Block not found

In the case of an authentication failure when talking to Core.
Without this PR:

2016/09/16 14:58:24

With this PR is:

2016/09/16 14:58:59 status code: 401, response: ""

Definitely OK.


[FR] Make the skin OLED safe.

Currently one of my devices have an always-on OLED screen connected with Material skin on it and there's a real concern of possible burn in of static elements.
The skin already has a pure black variant so it is quite friendly but my idea to move it further would be to trigger Now Playing screen [if it isn't on already] after x amount of time and auto-hide the top/bottom toolbars.

But the now-playing still has static elements (playback controls).

I've implemented this in the dev branch, for a future 4.6.0 release. I want to release 4.5.0 soon, and this is too close to release to add this feature now.

Closing, as implemented in master for next (4.6.0) release.


Update coursier-jvm_2.13, ... to 2.1.17

About this PR
📦 Updates

io.get-coursier:coursier-jvm_2.13
io.get-coursier:coursier-launcher_2.13
io.get-coursier:coursier-proxy-setup
io.get-coursier:coursier_2.13

from 2.1.14 to 2.1.17
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

🔍 Files still referring to the old version number
The following files still refer to the old version number (2.1.14).
You might want to review and update them manually.
website/docs/release_notes.md

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.get-coursier" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "io.get-coursier" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, old-version-remains, commit-count:1

Superseded by #3275


Migrate to travis-ci.com

Pull Request Test Coverage Report for Build 165

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 89.843%

Totals

Change from base Build 155:
0.0%

Covered Lines:
628

Relevant Lines:
699

💛  - Coveralls


Poc/seo improvements

This code isn't going into prod, its a preview of the feature. Will rewrite it properly if we decide to go ahead with this.
Proposed Changes

dynamic titles POC
more stuff to come...

Additional Info.
TODO:

[x] proper implementation
[x] canonical url
[x] hreflangs
[x] html lang
[x] juicy description tag
[x] juicy keywords
[x] change OG image and favicon (closes #243)
[x] canonicalise default location and default language

out of scope:

[ ] alt tags
[ ] schema.org/sitemap
[ ] make the whole website static/cacheable?
[ ] suburb id instead of any location
[ ] local SEO

notes:

We've got a lot of link juice/off-site SEO. Now need to add on-site SEO.
next.js migration is just not happening.
Gotta think of Google as CDN and canonical URLs as file path keys.
Content is still king - do we need a blog/long form info?

Screenshots
https://user-images.githubusercontent.com/2031472/134192343-22d662a9-6cd9-404d-9da8-6a4312cf474b.mov

Sorry I'm not remotely qualified to review this, shall defer!


dep ensure pulls malformed subpackage

What version of Go (go version) and dep (git describe --tags) are you using?
go version go1.9rc1 darwin/amd64
dep v0.3.0-34-gc80fab8
What dep command did you run?
$ git clone https://github.com/VojtechVitek/dep-test.git

$ cd dep-test

$ cat Gopkg.toml
[[constraint]]
  name = "github.com/go-chi/docgen/raml"
  version = "^1.0.2"

$ dep ensure -v
Root project is "github.com/VojtechVitek/dep-test"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)
(1)	? attempt github.com/go-chi/docgen/raml with 1 pkgs; 4 versions to try
(1)	    try<EMAIL_ADDRESS>(1)	✓ select<EMAIL_ADDRESS>w/1 pkgs
(2)	? attempt github.com/go-chi/chi with 1 pkgs; 16 versions to try
(2)	    try<EMAIL_ADDRESS>(2)	✓ select<EMAIL_ADDRESS>w/1 pkgs
  ✓ found solution with 2 packages from 2 projects

Solver wall times by segment:
     b-source-exists: 1.731622899s
         b-list-pkgs: 477.610861ms
              b-gmal: 448.395904ms
             satisfy:    366.948µs
         select-atom:    328.329µs
            new-atom:    137.822µs
         select-root:     63.428µs
     b-list-versions:     56.773µs
  b-deduce-proj-root:     28.949µs
               other:     13.635µs

  TOTAL: 2.658625548s

What did you expect to see?

dep should have installed github.com/go-chi/docgen/raml subpkg
dep should have installed github.com/go-chi/docgen transitive dependency pkg

What did you see instead?
vendor/
└── github.com
    └── go-chi
        └── docgen
            └── raml               <=== This directory is wrong. All the files should have been in the parent directory instead.
                ├── LICENSE
                ├── builder.go
                ├── docgen.go
                ├── docgen_test.go
                ├── funcinfo.go
                ├── markdown.go
                ├── raml           <=== Um, what? Yet another raml subdirectory?
                │   ├── raml.go
                │   └── raml_test.go
                └── util.go

$ dep status
PROJECT                        CONSTRAINT  VERSION  REVISION  LATEST   PKGS USED
github.com/go-chi/chi          *           v3.1.5   25354a5   25354a5  1
github.com/go-chi/docgen/raml  ^1.0.2      v1.0.2   ac43d9a   ac43d9a  1

Reproducer repo: https://github.com/VojtechVitek/dep-test

hi hi - so this is the problem:
$ cat Gopkg.toml
[[constraint]]
  name = "github.com/go-chi/docgen/raml"
  version = "^1.0.2"

that's not a project root; github.com/go-chi/docgen is. all constraints declared in Gopkg.toml have to be on a root, or we see weird behavior, like this.
clearly this is something that needs enforcement - which is why we have...huh. weird. i thought we did this in #697, but it seems not. @ibrasho, do we have something open for this?

@sdboyer yea, I figured the problem would be the non-root dependency path in Gopkg.toml.
So, how do I vendor github.com/go-chi/docgen/raml subpkg again? Do I need to vendor root package and then dep prune to get rid of any unused pkgs? Imho, this needs better documentation and error messages.

So, how do I vendor github.com/go-chi/docgen/raml subpkg again?

you just import it, and dep ensure (and dep prune if that matters for your use pattern). you're overthinking it 😄
the rules declared in Gopkg.toml are only for applying version constraints or alternate sources. they don't have to be there at all for your dependencies to be satisfied, though it's generally preferable that they're there.
what kind of doc heading would you expect to find this information under?

@sdboyer How about adding root path check in manifest validation function?
When ensure and status try to load manifest via dep.Ctx they can fail to load with error message.

@darkowlzz yes, we definitely need that. what's weird is, i thought we'd added it in an earlier PR by @ibrasho - but it seems to not be there :/

$ dep ensure -v
The following issues were found in Gopkg.toml:

  ✗ the name for "github.com/go-chi/docgen/raml" should be changed to "github.com/go-chi/docgen"

ProjectRoot name validation failed

Thanks for fixing this!


Add GH workflow to check if datasources are working

Description

The step to check if datasources are working was removed during the CLI removal PR. This PR adds it back in the form of another GH workflow. We cannot use the e2e test job as before as ct install immediately cleans up after itself as well.
Fixes #517
Type of change
What type of changes does your code introduce to tobs? Put an x in the box that apply.

[ ] CHANGE (fix or feature that would cause existing functionality to not work as expected)
[ ] FEATURE (non-breaking change which adds functionality)
[ ] BUGFIX (non-breaking change which fixes an issue)
[ ] ENHANCEMENT (non-breaking change which improves existing functionality)
[x] NONE (if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)

Closing as it has been superseded by #521.


Enable table support

I'm currently working on an update to ACM that involves sending email that contains tabular data within the body of the email. I can definitely build the email based on a .markdown template, but I need table support turned on in Telex in order for the email to be rendered properly.
This change enables the use of markdown tables in the body of an email.

@dmcinnes I'd like to do what @cyx suggests above. Could we chat when you get online?

@dmcinnes on second thought, the unit tests in this project actually generate both a plaintext and HTML email content for the sake of comparison. Is it necessary to actually do that in staging to verify the behavior?

LGTM 👍  I'll leave the deploy/testing up to @brockspratlen who is secondary on call 😄

@brockspratlen Thanks very much! Could you ping me when this is deployed...?

@wchrisjohnson deployment to production just finished; I manually verified this was working via the minitel gem on my machine

Thanks @brockspratlen


Fix Time in Seconds

Value Proposition
As a user
I want to see the duration of an episode properly formatted
So that I don't have to guess what a number like "3495" might mean.
Description
Some podcast feeds like https://wochendaemmerung.de/feed/mp3/ or https://sternengeschichten.podigee.io/rssfeed give the time in seconds instead of the format HH:MM:SS. The podcast player should check for that and convert if necessary.
Acceptance Criteria

[ ] The display episodes component should show the episode's duration in the format HH:MM:SS for https://sternengeschichten.podigee.io/rssfeed.
[ ] The player component should show the episode's duration in the format HH:MM:SS for https://sternengeschichten.podigee.io/rssfeed.

Tasks

[ ] Write a utility that checks episode duration format and converts it if necessary.
[ ] Add this utility to the player component.
[ ] Add this utility to the display episodes component.

Complexity
S

Hi Andreas,
looks good. 👍
cheers
R.


Remove all the updated / new tags or indications on the download box on the methodology & data page

Describe the bug
Since we are past the "window of newness", remove the coloring and tagging to indicate that things are new or have been updated on the methodology & data page.
To Reproduce
Steps to reproduce the behavior:

Go to 'methodology & data'
See error

Expected behavior
Revert to normal state
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

@KameronKerger - I believe we can close this right as the UI is no longer applicable?

yes that tracks @vim-usds


Required plugins

Could you please mention which plugins are required?
Because out-of-the box experience (only neovim installed) is pretty ugly:

Hi
The plugin I recommend is below. If you feel that setting is troublesome, it is recommended to clone the setting of those who publish init.vim (vimrc) as repository to github.

Manages the plugins
Shougo/dein.vim

Color scheme

andreypopp/vim-colors-plain (I used the top image of this repositry)
joshdick/onedark.vim (atom like dark / light color scheme)

lint
w0rp/ale

Compression
Shougo/deoplete.nvim

Thank you for the tips!
And what about git status info with git branch icon? Or is it a built-in feature of gonvim?

The git icon is constant, not the status in particular.
The label to the right of the git icon indicates the state of git in the repository.

Yep, I know what they mean, I just asked what plugin I need to install for this icons to work. Currently I don't have any git info with gonvim.

The git icon display of gonvim is a built-in feature, so you do not need any additional plug-in. It is displayed for files under the directory associated with the git repository.


ERROR: the correct camera poses for current points cannot be accessed

COMMAND
bash multipleviewprogress.sh dataset_name
ERROR
Images # 26
ERROR: the correct camera poses for current points cannot be accessed
Done with imgs2poses
cp: cannot stat './colmap_tmp/poses_bounds.npy': No such file or directory

Do you know why this happend TT

same problem


Allow for independent permission sets for books stored on multiple shelves

Describe the feature you'd like
I'm in the middle of migration of our books between old and new shelves and one thing missing I noticed is that when you add a book to more than one shelf, BookStack won't let you independently setup permissions for that book.
Let's say we have book "Documentation" and two shelves and roles named the same way - "Department X" and "Department Y". I want to move that book from some old shelf initially to "Department X" shelf, but I already know that I will have to share this book with "Department Y" role in the near future. The only difference being the scope of permissions - "Department X" should have full read/write access while "Department Y" should only have read-only permission.
Now the problem is that although I can add book "Documentation" to both shelves, book can only have one set of permissions at the same time. If I cascade permissions from shelf "Department X", book wil now have permissions relative to that shelf, also within "Department Y" shelf. meaning if "Department X" shelf allows read/write access only for "Department X" role, members of "Department Y" role won't be able to display that book despite it being assigned to their shelf as well.
Describe the benefits this would bring to existing BookStack users
Allow to share books between shelves with independent, per-shelf permission sets without a need to setup a proxy roles able to access certain resources.
Can the goal of this request already be achieved via other means?
Only via setting up a proxy roles granting access to specific resources or by manually setting up book permissions and assigning proper roles. but when you need to setup a complex system where each department has access to different things or permission scopes, it becomes very problematic to manage and gets out of control fast. not to mention every cascade permission copy erases all customization and you're back to square one.
Have you searched for an existing open/closed issue?

[X] I have searched for existing issues and none cover my fundamental request

How long have you been using BookStack?
1 to 5 years
Additional context
No response

Thanks for the suggestion @jsarnowski96,
Personally I'm very much not keen on adding any more complication to the permission system.
Sorry if I have not understood, but what stops you manually managing the permissions at the book level instead to set up the desired permissions, instead of copying them down from the shelves? I don't understand why there's a need to create proxy roles if you could manually re-create the merge of permissions for this book.

@ssddanbrown it's not like something is stopping me, but if you have to manage several dozens of these "loose" books it becomes a slog. every now and then a new book pops up and since I'm unable to keep track of these changes, the fastest way to deal with users not having access to certain resources within their shelf is to cascade permissions. but the drawback is loss of custom permissions in book config.
as for the proxy roles, I use them mostly because we want to limit the amount of users permitted to access certain resources. For example I don't want all people from "Department X" access book "Documentation" from "Department Y" shelf, but only one or two persons, while at the same time not allowing them to access any other resource within that shelf, thus creating a proxy role is necessary.

@jsarnowski96 Okay, I'm still not totally clear on the proxy roles but I'm assuming it's more of a complication that adds to the trouble of your scenario rather than a direct solution to core problem area here.
The particular trouble here, is that it sounds like your desire is not even a combination of the shelf permissions, at least within the current core logic of how BookStack treats permissions. I was wondering if a custom command could be used to copy permissions down in a merge-style way, but you really need a change to the core logic, or specific book-permission handling at a shelf level (not aligned to shelves) by the sounds of it.
That's quite a significant addition or change that I definitely wouldn't like to make, nor can I see an smaller scope that could be achieved via a hack.
If it's possible to think of your desired permission goal, in respect to current permission core logic and UI, it might be possible to come up with a hack to take information from books & shelves to apply that, otherwise things get much more complex.

@ssddanbrown I'll try to explain that concept to the best of my ability:

"Department X" shelf has read/write permission override for "Department X" role, containing 5 members
"Department Y" shelf has read/write permission override for "Department Y" role, containing 5 members
in "Department Y" there's a single book "Documentation" which I want to share with two members of "Department X", but at the same time no other documents should be available to them
in order to achieve it, in "Documentation" book custom permission override I have to set rule for read/write access of role "Mixed", which contains these two individuals. If I'd set up rule for "Department X", all of its members would have access to that book. on the other hand I cannot assign these two members of "Department X" role to "Department Y" role, because they'd have full access to the entire "Department Y" shelf.


Restructured messages into separate files/modules.

The only changes made are:

Moving each message and its handler to separate file/module
Reduction of visibility of several modules/fields.
Renamed outbound_message to just message to unify api with other actors

No actual logic of the app was modified.

This was necessary change, when I was ~extending~ creating basic game logic and the number of messages increased a lot.
It seemed like a lot of changes for one PR, so I extracted this refactoring into separate PR.


Allow B extension for ISA string

The value is already checked in schemaValidator.py but not allowed by
the schema.

please create an entry in CHANGELOG.md for 2.6.2 and also update the __version`__` in init.py``

please create an entry in CHANGELOG.md for 2.6.2 and also update the __version`__` in init.py``


iFan 03 not updating HOME App

Hi,
I am using the iFan 03 with the latest OEM firmware. When I turn on the FAN in the EWELNK APP or the remote, it does not update HOME App, I have tried both AUTO and WAN Connection Mode. With the Light Switch T0 or T1 the HOME App is updated. HooBs and the EWELINK uses the same account.
I am using HOOBs on a Raspberry PI 4 (8G) with 16G storage.
Hoobs Version: 3.35
Node Version: 14.15.1
Plug-in Version: 5.6.0
If I look at the logs I see the FAN turned on and the percentage of the FAN speed.
Mar 27 22:55:55 hoobs hoobs[651]: [eWeLink] [Devicexxxxxx] current state [on].
Mar 27 22:55:55 hoobs hoobs[651]: [eWeLink] [Devicexxxxxx] current speed [66%]
Mar 27 22:57:38 hoobs hoobs[651]: [eWeLink] [Devicexxxxxx] current state [off].
Mar 27 22:57:38 hoobs hoobs[651]: [eWeLink] [Deviceexxxxx] current speed [33%]
I even close the HOME App and re-open it to see if there are any changes.
When I use the home to turn the FAN off and On it updates both HOME App and EWELINK
Mar 27 23:01:47 hoobs hoobs[651]: [eWeLink] [Devicexxxxxx] current state [on].
Mar 27 23:01:47 hoobs hoobs[651]: [eWeLink] [Devicexxxxxx] current speed [99%].
Mar 27 23:01:50 hoobs hoobs[651]: [eWeLink] [Devicxxxxxx] current state [off].
Mar 27 23:01:50 hoobs hoobs[651]: [eWeLink] [Devicexxxxxx] current speed [0%].
Any ideas?

Hi @deon-wentzel
Could you follow these instructions to update to the beta version I have just released, v5.6.1-1, to see if this has fixed your issue?
Thanks

Excellent. I will leave this issue open until v6 of the plugin is released which includes the fix for the fan.

Great, thanks


Live demo

I found this library. I haven't tried it out yet. Is there a live demo or sample code that uses this library? If not then I can try using it and then create a live demo.

No there's nothing like that yet. I was thinking to add a visual editor at some point but haven't gotten around to that yet.


Invalidate Cache on new data

Hi, i tried to find more information on how to invalidate the response cache when underlaying data has changed. The link to change tokes is very interesting but I didn't get if it is possible to use change tokens to invalidate the cache on a GET call when a new POST/PATCH/PUT call was made or the data changed in any other way. Some pages I found mention this is not possible. Maybe a note about how this works would be nice.

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

ID: 10cda0f9-e2c7-015d-4fbf-d361f6c67d9f
Version Independent ID: 13154131-c2b6-2c72-fb0e-1d83bca4e21a
Content: Response Caching Middleware in ASP.NET Core
Content Source: aspnetcore/performance/caching/middleware.md
Product: aspnet-core
Technology: aspnetcore-performance
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

@JunTaoLuo can you please provide some writeup for this? Thanks!

This is not possible with the current API. A feature request should be filed instead.


libewf-legacy: migrate to by-name

Description of changes

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[X] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Sure, but how were the previous commits merged?

Sure, but how were the previous commits merged?

The previous commits were merged by using the old path (pkgs/development/libraries) but forgot to add libewf-legacy in all-packages.nix. Indeed the commit related to the master branch was merged, the one related to the backport no.
Is it possible to create a backport to 23.11 for this current one?

The bot won't work since #283201 wasn't in. I suggest making a PR yourself against release-23.11 to integrate both #283201 and #287912, with the commits squashed.

Ok. So, this afternoon I create a PR on release.23-11 by moving it to by-name.


[Docs] Add release note for v1.3.0

Add release note for v1.3.0.

Coverage remained the same at 34.45% when pulling d85282f9607b5e13355fbc2c781fa42d13e87ca5 on xiongyf/release-note-1.3.0 into 0fc450596c7275ca2416bc16b57582a1739fe2da on master.


[FLINK-3909] update Maven Failsafe version

Failures during execution of the integration tests with the Maven
Failsafe plugin were silently ignored on Travis with Maven version
3.2.5. The problem is that failures are not passed on correctly from the
'integration-test' phase (where failures are recorded and tolerated) to
the 'verify' phase.
The cause of the error is most likely SUREFIRE-1127. An exception in the
'integration-test' is sometimes not flushed back to disk where it is
evaluated in the 'verify' phase. Bumping the version of the Failsafe
plugin from 2.18.1 to 2.19.1 fixes the issue.
Tests will fail for this PR ;)

Tests fail in flink-runtime now. Seem to be class path related problems.
  CheckpointIDCounterTest$ZooKeeperCheckpointIDCounterITCase.org.apache.flink.runtime.checkpoint.CheckpointIDCounterTest$ZooKeeperCheckpointIDCounterITCase Â» NoClassDefFound
  CheckpointIDCounterTest$ZooKeeperCheckpointIDCounterITCase.<clinit>:53 Â» NoSuchMethod
  CheckpointIDCounterTest$ZooKeeperCheckpointIDCounterITCase.testSerialIncrementAndGet Â» NoClassDefFound
  CheckpointIDCounterTest$ZooKeeperCheckpointIDCounterITCase.testSetCount Â» NoClassDefFound
  ZooKeeperCompletedCheckpointStoreITCase.org.apache.flink.runtime.checkpoint.ZooKeeperCompletedCheckpointStoreITCase Â» NoClassDefFound
  ZooKeeperCompletedCheckpointStoreITCase.testAddAndGetLatestCheckpoint Â» NoClassDefFound
  ZooKeeperCompletedCheckpointStoreITCase.testAddCheckpointMoreThanMaxRetained Â» NoClassDefFound
  ZooKeeperCompletedCheckpointStoreITCase.testDiscardAllCheckpoints Â» NoClassDefFound
  ZooKeeperCompletedCheckpointStoreITCase.testEmptyState Â» NoClassDefFound Could...
  ZooKeeperCompletedCheckpointStoreITCase.testExceptionOnNoRetainedCheckpoints Â» NoClassDefFound
  ZooKeeperCompletedCheckpointStoreITCase.testGetAllCheckpoints Â» NoClassDefFound
  ZooKeeperCompletedCheckpointStoreITCase.<clinit>:40 Â» NoSuchMethod org.apache....
  ZooKeeperSubmittedJobGraphsStoreITCase.org.apache.flink.runtime.jobmanager.ZooKeeperSubmittedJobGraphsStoreITCase Â» NoClassDefFound
  ZooKeeperSubmittedJobGraphsStoreITCase.testConcurrentAddJobGraph Â» NoClassDefFound
  ZooKeeperSubmittedJobGraphsStoreITCase.<clinit>:58 Â» NoSuchMethod org.apache.f...
  ZooKeeperSubmittedJobGraphsStoreITCase.testRecoverJobGraphs Â» NoClassDefFound ...
  ZooKeeperSubmittedJobGraphsStoreITCase.testUpdateJobGraphYouDidNotGetOrAdd Â» NoClassDefFound
  ZooKeeperStateHandleStoreITCase.org.apache.flink.runtime.zookeeper.ZooKeeperStateHandleStoreITCase Â» NoClassDefFound
  ZooKeeperStateHandleStoreITCase.testAdd Â» NoClassDefFound Could not initialize...
  ZooKeeperStateHandleStoreITCase.testAddAlreadyExistingPath Â» NoClassDefFound C...
  ZooKeeperStateHandleStoreITCase.testAddDiscardStateHandleAfterFailure Â» NoClassDefFound
  ZooKeeperStateHandleStoreITCase.testAddWithCreateMode Â» NoClassDefFound Could ...
  ZooKeeperStateHandleStoreITCase.testGetAll Â» NoClassDefFound Could not initial...
  ZooKeeperStateHandleStoreITCase.testGetAllSortedByName Â» NoClassDefFound Could...
  ZooKeeperStateHandleStoreITCase.testGetAndExists Â» NoClassDefFound Could not i...
  ZooKeeperStateHandleStoreITCase.testGetNonExistingPath Â» NoClassDefFound Could...
  ZooKeeperStateHandleStoreITCase.testRemove Â» NoClassDefFound Could not initial...
  ZooKeeperStateHandleStoreITCase.testRemoveAndDiscardAllState Â» NoClassDefFound
  ZooKeeperStateHandleStoreITCase.testRemoveAndDiscardState Â» NoClassDefFound Co...
  ZooKeeperStateHandleStoreITCase.testRemoveWithCallback Â» NoClassDefFound Could...
  ZooKeeperStateHandleStoreITCase.testReplace Â» NoClassDefFound Could not initia...
  ZooKeeperStateHandleStoreITCase.<clinit>:66 Â» NoSuchMethod org.apache.flink.ru...
  ZooKeeperStateHandleStoreITCase.testReplaceNonExistingPath Â» NoClassDefFound C...

Good fix! The failures went unnoticed before, I guess?

Running the tests from within IntelliJ works fine without a problem. I guess it has something todo how failsafe 2.19 handles dependencies.

Couldn't find the problem.

Could you reproduce the problem on your laptop?

I could reproduce it via maven on my machine. It is a bit odd since he complains that
org.apache.flink.runtime.util.ZooKeeperUtils.startCuratorFramework(Lorg/apache/flink/configuration/Configuration;)Lorg/apache/curator/framework/CuratorFramework

Even though ZooKeeperUtils is in flink-runtime. Maybe it has something to do with the shading and that org.apache.curator.framework.CuratorFramework has been relocated?

Reverting back to version 2.17 it works again (at least the plugin does not complain about the NoSuchMethodError).

But maybe it only works since the exceptions are silently ignored and not forwarded?

If we can't resolve issues with the Failsafe plugin, we could switch to using the Surefire plugin also for Integration tests. Actually, the only benefit of the Failsafe plugin is that it enables to use different phases to reuse test infrastructure that is costly, e.g. pre-integration-test, post-integration-test, integration-test, verify. However, we only use the integration-test phase. We don't have any special code in the verify phase, other than Failsafe's own mechanism to check for test failures which seems to be broken.

@aljoscha Yes, I think so too :)

The question is whether this bug was introduced with version 2.18.1 or whether it was already there in version 2.17. We originally bumped the version to 2.18 in order to allow retries for the ElasticSearchSinkITCase. But if it works with the Surefire plugin, then we can also do this.

In the surefire JIRA, the "silently ignore exceptions" bug is tagged to affect 2.18, not 2.17, so it may be good.
How about:

Checking if using surefire solves things
If not, use failsafe 2.17 making sure it is not affected

👍 and make sure that the tests were not silently failing with 2.17

I just replaced Failsafe with Surefire. Also updated the version of Surefire in a separate commit to see if the classpath issues occur there as well (after all it's the same Apache project).

Also pushed a version to my local Travis branch with some deliberately failing tests and debug output to see if the above tests are executed correctly (and don't fail silently).

Thanks @mxm ! Eagerly looking forward to the results...

I took a look at the root issue of upgrading to 2.19.1. I'm able to reliably reproduce this issue on my laptop.
When I bump the version I get the same as @tillrohrmann
java.lang.NoSuchMethodError: org.apache.flink.runtime.util.ZooKeeperUtils.startCuratorFramework(Lorg/apache/flink/configuration/Configuration;)Lorg/apache/curator/framework/CuratorFramework
When running the build in debug mode for both 2.18.1 and 2.19.1 I observed some differences in the classpath.
2.18.1
[DEBUG] boot(compact) classpath:  surefire-booter-2.18.1.jar  surefire-api-2.18.1.jar  test-classes  classes  flink-core-1.1-SNAPSHOT.jar.....
2.19.1
[DEBUG] boot(compact) classpath:  surefire-booter-2.19.1.jar  surefire-api-2.19.1.jar  test-classes  flink-runtime_2.10-1.1-SNAPSHOT.jar  flink-core-1.1-SNAPSHOT.jar.....
So 2.19.1 has changed behaviour. What is loaded onto the classpath differs, in 2.19.1 instead of loading target/classes it loads the actual built jar. https://issues.apache.org/jira/browse/SUREFIRE-855 confirms this.
The issue with this is the final jar has curator shaded while the test classes are looking for the unshaded version of curator, as shown by the debug output:
Lorg/apache/curator/framework/CuratorFramework
If @mxm can get everything working on a lower version thats the easiest solution. If not or we want to proceed with moving up in version, at least we know the root of the issue and can work from there....

Thanks for looking into the problem and providing a detailed explanation @markreddy. I think we're good to go with the newest version of the Surefire plugin. I verified the tests 1) fail when errors occur 2) are actually run (added some debug output) 3) the number of tests/ITCases remains unchanged.
Just running one more time because I forgot to set the default of reuseForks to false for the integration tests. Reusing of forks doesn't work for some tests because of garbage collection problems (this was the same for the Failsafe plugin). Apparently almost all tests pass. So looking forward to merging this soon.

I get segfaults from RocksDB in my Travis tests:  https://travis-ci.org/mxm/flink/builds/131412162
Let's see how the builds here go. All in all, looks ready to be merged.

The Travis builds here also segfault in all RocksDB tests. I'm assuming these test failed silently in the past since I can't make any connection to the test plugin changes.

Merging...we need to fix the RocksDB issue afterwards. In the worst case, we'll comment out the relevant test cases for now. The test which seems to cause the segfaults is EventTimeWindowCheckpointingITCase.