tuxedo-rs: init at 0.2.1

Description of changes
This adds tuxedo-rs, which consists of:

A dbus daemon as well as a simple CLI for interacting with the hardware of TUXEDO computers
A GUI (tailor_gui), which can be used to manage power/keyboard-led/fan profiles.

tuxedo-rs is an alternative to the TUXEDO Control Center (TCC), for which there exists a packaging request: #132206.
Note that if the packaging request for TCC is fulfilled, the daemons will conflict with each other, so the respective modules should ensure that the other one is disabled.
I had previously contributed a flake to tuxedo-rs, on which I have based this PR - with a small change to the module (options.services -> options.hardware).
If this is merged, I plan to rewrite the module in the flake to use this one and override the package src.
I have been using the tuxedo-rs module on my device for a few weeks now.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] 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

[x] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.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
[x] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Please rebase and fix merge conflicts.
Also personally I'd prefer to split "init" of the package and module into 2 commits. I am not sure about waht the consensus is on that. Therefore not "demanding" or "requiring" any change on that. Just putting it to the discussion here.

Please rebase and fix merge conflicts.
Also personally I'd prefer to split "init" of the package and module into 2 commits. I am not sure about waht the consensus is on that. Therefore not "demanding" or "requiring" any change on that. Just putting it to the discussion here.

I have rebased and split the tuxedo-rs commit into separate package init and a module init commits.

If I clone your branch, I can build both tailor_gui and tuxedo-rs without problems. But something is obviously wrong with the output paths here, I don't know what to do about it at the moment, someone with more experience should take a look at that.

Same here.
Thanks for the review 😄

It doesn't seem to like
inherit ((lib.importTOML "${src}/tailord/Cargo.toml").package) version;

and the use of builtins.path.

It doesn't seem to like
inherit ((lib.importTOML "${src}/tailord/Cargo.toml").package) version;

Yes, in the output of nixpkgs-review it looks like it doesn't like that part.

It seems like it was actually failing because of
cargoDeps = rustPlatform.importCargoLock {
    lockFile = src + "/Cargo.lock";
};

lockFile has to be a path.
The latest changes are working on my local machine (tested with nix-env -qaP --out-path -f default.nix --show-trace).

Result of nixpkgs-review pr 231384 run on x86_64-linux 1

1 package blacklisted:

nixos-install-tools

It looks good now.

Result of nixpkgs-review pr 231384 run on x86_64-linux 1

2 packages blacklisted:

nixos-install-tools
tests.nixos-functions.nixos-test

2 packages built:

tailor_gui
tuxedo-rs

I've previously used the flake on my Tuxedo laptop with no issues. As the person who failed to properly package the Tuxedo Control Center Electron monster, I'm more than happy that this implementation lands in nixpkgs! :tada:

Worked for me, thanks!

As you have added a new module, please mention it in the release notes.

As you have added a new module, please mention it in the release notes.

Done.

@figsoda (sorry for the ping)
Is there anything in the way of getting this merged?

:pray:

# x86_64-linux
> nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
2 packages added:
tailor_gui tuxedo-rs (init at 0.2.1)

1 package updated:
nixos-install-tools

added platforms

Updated src.
Note: The author has not changed the version yet.

Updated from 0.2.1 -> 0.2.2.


fix draggable region

Though the title bar is hidden, it exists and covers the top region of the window;
We will lose mouse events outside the title bar if mousedown is fired on it.
If the draggable region is not covered, mouse events are fired even if the mouse is outside the window.
Setting window style mask to NSFullSizeContentViewWindowMask may fix this.
e.g. Creating two draggable regions: one is covered by the title bar but the other is not

I am afraid this solution cannot solve the problem.


Set the Compile using the latest installed platform not work

Hi! I've changed "Compile using Android version (Target Framework) to Android 9.0.99 and the same for Target Android Version. Also minimum version Android 5.0.
Environment: VS for Mac version 8.2.4, Xamarin.Android 9.4.1.
Here is screenshot of error:

@andreybutko is this regarding one of the pages on docs.microsoft.com/xamarin? If so, could you share the link?

Thanks for submitting an issue and we apologize for the delayed response. The requested updates haven't been made since the creation of the issue, and the timeline for resolution may vary based on resourcing, so the issue is being moved to an internal repo to better track it.


Move VI to GA

cc @theacodes @tmatsuo @bshaffer

Please do not merge until I have final sign-off internally.


Additional check for ttl < 10s and Consul

Fixes #838
Signed-off-by: Alexandre Beslic<EMAIL_ADDRESS>

ping @aluzzardi

LGTM

LGTM


自定义节点，锚点在内部，使用polyline链接，边显示异常

[ ] I have searched the issues of this repository and believe that this is not a duplicate.

Reproduction link
https://github.com/HuChundong/g6demo
Steps to reproduce
直接run项目即可，初始化状态下边不显示，拖动之后显示异常

Environment
Info

g6
4.0.1

System
macos

Browser
edge87

按照最短路径正常查找边

v4.1.7 修复了

v4.1.7 修复了


Could you please add "Groove Coaster: Wai Wai Party!!!!" to the list?

I know there is currently a limitation to the amount of games that can be displayed so I understand if you don't want to add this one as it is a bit niche, but I would certainly appreciate it if you could!

I have added the game(s) you requested in the most recent release: https://github.com/hobby-grade/Nintendo-Switch-Discord-Status/releases/tag/<IP_ADDRESS>
we welcome all games here!
Thank you for checking out the project, reach out if you have any more suggestions!


Misc doc changes

Besides other documentation changes, this commit ensures the generated
HTML doc for HexDocs.pm will become the source of truth for this Elixir
library and leverage on latest features of ExDoc.

@kamilkowalski Any updates on this?


dataset for training

Nice work indeed!
To learn from your code better, could you tell me where to get the training dataset?
Thanks

Not the author, the dataset seems to originate from the 2022 edition of the Digital Breakthrough hackathon. You can download the data following the link in the Jupiter notebook.
@slavabarkov can you confirm the origin of the data? Do you know the original dataset licence?

Thanks for your answer! I found it in the notebook
Riccardo Malavolti @.***> 于2024年5月15日周三 14:46写道：

Not the author, the dataset seems to originate from the 2022 edition of
the Digital Breakthrough hackathon. You can download the data following the
link in the Jupiter notebook.
@slavabarkov https://github.com/slavabarkov can you confirm the origin
of the data? Do you know the original dataset licence?
—
Reply to this email directly, view it on GitHub
https://github.com/slavabarkov/railway-infrastructure-segmentation/issues/6#issuecomment-2111706369,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD7N5Q2PGB5TDQOABGGAED3ZCMAD5AVCNFSM6AAAAABHKJR6QCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJRG4YDMMZWHE
.
You are receiving this because you authored the thread.Message ID:
<slavabarkov/railway-infrastructure-segmentation/issues/6/2111706369@
github.com>


Match ability existing in each of the previous Golang FUSE packages to support OSXFuse on MacOS

The mount logic is somewhat different in MacOS. As such, each of this package's predecessors (Bazil FUSE, go-fuse, and jacobsa/fuse) have Mac-specific code to adjust the process for that environment. There are also some extensions to the /dev/fuse API that come with this platform-specific support. Finally, OSXFuse (the equivalent of the FUSE kernel module in Linux) needs to be loaded if not already present... something the MacOS-specific code of the predecessors each performs as well.

As of 1.1.2, initial support for macOS is now available...

As of 1.2.0, this issue is resolved.


Hangs in OSX reading certain sized responses unless specifying Connection::close

I'm making an authenticated GET request that succeeds, but any attempt to read_to_string or read_to_end just hangs indefinitely, but only under all the following criteria:

OSX (works fine on linux)
responses in the range of 3835-16120 bytes (~260 bytes short of the 4K/16K boundaries).
over SSL (works fine if I make the same request through a local http nginx proxy)

This is the debug output of an example Response object I see before it hangs during reading:
Response { inner: Response { status: Ok, headers: Headers { Date: Wed, 23 Nov 2016 03:06:35 GMT, X-Frame-Options: DENY, Strict-Transport-Security: max-age=0; includeSubDomains; preload, X-Data-Type: directory, Connection: keep-alive, Content-Length: 7452, Content-Type: application/json; charset=utf-8, }, version: Http11, url: "https://api.algorithmia.com/v1/connector/data/anowell/foo", status_raw: RawStatus(200, "OK"), message: Http11Message { is_proxied: false, method: None, stream: Wrapper { obj: Some(Reading(SizedReader(remaining=7452))) } } } }

And yet, I haven't managed to repro this with a simple test script to just reqwest::get some public URL in that size range, so I'm still missing some contributing factor. I've also tried an old build of my client which used hyper+openssl, and it had no issue.
Things on my mind to try still:

Read in smaller chunks to see if perhaps read_to_end is waiting on the wrong number of bytes
Put together the minimal repro using an API key for a shareable test account
Try a bit harder to find a repro outside of our API

Is this after using several requests from the same Client? I'd possibly wonder at a connection pooling error, but you say the Response comes back with a status and headers, so the connection had to have been valid enough.
It's not impossible there is an error in rust-security-framework, but I'm hesitant to claim that since it could very well be my own buggy code.

It was a single request, and yeah, Response always has the status and headers that I'd expect. I'm also still hesitant to claim a specific cause since I haven't even managed a repro outside our API or client, but I do lean toward thinking it involves some interaction with security framework given that it's OSX-specific and didn't happen on a previous hyper+openssl build.
I just need to borrow my wife's Macbook again and try and piece together a more minimal repro - got derailed by moving over the holiday - maybe I'll get to that tonight.

I managed to create a fairly minimal repo with a public file on dropbox:
    let mut res = reqwest::get("https://dl.dropboxusercontent.com/u/39033486/file.txt").expect("request failed");
    println!("{:#?}", &res);
    let mut body = String::new();
    res.read_to_string(&mut body).expect("read_to_string failed");
    println!("Body len: {}", body.len());

Prints what appears to be successful Response object, then hangs in read_to_string. (macOS 10.12.1, using reqwest from master).

Great for finding a reproducible case! I don't have a Mac at all, so I can't personally debug that well. It'd be super useful if you could either run dtruss (for syscalls) or gdb (to actually see where it stops)

haha. the joy of supporting platforms we don't actually have access to...
Turns out the repro is behaving a bit differently read_to_string suspiciously/consistently spends almost exactly 60 seconds (give or take a few millis), but then actually returns the correct data, so I suspect there is some I/O timeout at play (which in my original case was possibly much longer than 60 seconds).
dtruss is dumping a lot of invalid kernel access in action #12 at DIF offset 92, but I have a bit of ramp up on macos debugging to make sense of it. I'm still digging.

The 4k-16k aspect of the issue might just be specific to the memory layout of the client I was working with, as I see slight variations with different repros. The repro I've spent the most time digging into consistently hangs in the call to read_to_string for 60 seconds before completing successfully. If I interrupt it with lldb while it's hanging, I consistently see this backtrace:
(lldb) bt
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
* thread #1: tid = 0xde00, 0x00007fffb6f8b2de libsystem_kernel.dylib`read + 10, stop reason = signal SIGSTOP
  * frame #0: 0x00007fffb6f8b2de libsystem_kernel.dylib`read + 10
    frame #1: 0x00000001000e7f46 test-reqwest`_$LT$std..net..tcp..TcpStream$u20$as$u20$std..io..Read$GT$::read::h63aac5a69abb22a3 + 22
    frame #2: 0x0000000100024f0c test-reqwest`hyper::net::{{impl}}::read(self=0x0000000101a17090, buf=(data_ptr = "\x17\x03\x03\"?_\x90GTy\x92?HTTP/1.1 200 OK\r\nServer: nginx\r\nDate: Wed, 30 Nov 2016 10:27:02 GMT\r\nContent-Type: text/plain; charset=utf-8\r\nContent-Length: 8125\r\nConnection: keep-alive\r\nreferrer-policy: no-referrer\r\nx-robots-tag: noindex, nofollow, noimageindex\r\ncontent-disposition: inline; filename=\"6000.txt\"; filename*=UTF-8''6000.txt\r\nset-cookie: uc_session=RBAHoQhIYGiasHZOKDHizfMqcEDODaocU0d70gj4IIL2pHkO5S8TwMf3meluM2Jd; Domain=dropboxusercontent.com; httponly; Path=/; secure\r\naccept-ranges: bytes\r\ncontent-security-policy: referrer no-referrer\r\netag: 311n\r\nx-dropbox-request-id: 3369f10d026ac54f643d98506e10052f\r\npragma: public\r\ncache-control: max-age=0\r\nx-content-security-policy: referrer no-referrer\r\nx-webkit-csp: referrer no-referrer\r\nX-Server-Response-Time: 1451\r\n\r\n2ycmyF2HKuDsKXjxW5uLtOuydBJGarw+8KMw6GS4EtQ7fIJmwvk28tb5yoBSFHdP\npjtuKLabHsFsaznkvPZ/7aOVmPHiLm6YW318JHgbplH6Psue2DgNpCACF5mmJw6K\nYKopNqbBneBIoFby76mFPqUptlIJqvUvKpx33i8Am8wVvnrPnHgRw6lh0A7vX7Tj\nwXTRq6BrkVWQgqWneqdhM+MWqjEt+ijZkmAS0Dj1Qgi9OxJ4aJGbEUSXqynrFZcK"..., length = 5)) + 76 at net.rs:295
    frame #3: 0x000000010003de28 test-reqwest`security_framework::secure_transport::read_func::{{closure}}<hyper::net::HttpStream> + 104 at secure_transport.rs:752
    frame #4: 0x000000010003f304 test-reqwest`core::ops::FnOnce::call_once::ha3b98f2e5c30eb3a + 20
    frame #5: 0x000000010003909a test-reqwest`std::panic::{{impl}}::call_once<core::result::Result<usize, std::io::error::Error>,closure>(self=AssertUnwindSafe<closure> @ 0x00007fff5fbfdb38, _args=<unavailable>) + 106 at panic.rs:255
    frame #6: 0x0000000100015efc test-reqwest`std::panicking::try::do_call<std::panic::AssertUnwindSafe<closure>,core::result::Result<usize, std::io::error::Error>>(data="H?_?) + 284 at panicking.rs:356
    frame #7: 0x00000001000ede2b test-reqwest`__rust_maybe_catch_panic + 27
    frame #8: 0x000000010001576d test-reqwest`std::panicking::try<core::result::Result<usize, std::io::error::Error>,std::panic::AssertUnwindSafe<closure>>(f=AssertUnwindSafe<closure> @ 0x00007fff5fbfde28) + 333 at panicking.rs:332
    frame #9: 0x0000000100015487 test-reqwest`std::panic::catch_unwind<std::panic::AssertUnwindSafe<closure>,core::result::Result<usize, std::io::error::Error>>(f=AssertUnwindSafe<closure> @ 0x00007fff5fbfdea8) + 103 at panic.rs:311
    frame #10: 0x000000010000c23a test-reqwest`security_framework::secure_transport::read_func<hyper::net::HttpStream>(connection=0x0000000101a17090, data=0x0000000102002400, data_length=0x00007fff5fbfe0b0) + 298 at secure_transport.rs:752
    frame #11: 0x00007fffa80ba86f Security`SSLRecordReadInternal + 69
    frame #12: 0x00007fffa804c357 Security`SSLReadRecord + 20
    frame #13: 0x00007fffa804fca6 Security`SSLRead + 380
    frame #14: 0x0000000100038957 test-reqwest`security_framework::secure_transport::{{impl}}::read<hyper::net::HttpStream>(self=0x0000000101a280b8, buf=(data_ptr = "oiqZnlrBq8hUOi4X18L73l603MN5t1oRIN\nu85ZWhi/QQMwbfaI1nNk1REODX1IDQOdBlUPphhmvmeOv1YdVZkGOnp1h4k5X6bl\nNW8ECkKmGj3f0I1r4Bc8m7oKD++QyAulgMaTJBz6r3kby/KuntnMGnY4/BxwGdLY\neIBG0OkHSAGHZYdTAdMLZbMCmIq3a+Bc5/Ri4t4YsKWJJBZ/oT/jXGZ7XYOQNtEu\neJ6jgopwstlCMK/vdA4GM5AlMQ/th7LAcvJZQZUFikPJ92/zwlD8lDMH/uyud4lX\n9skiqv8XAj1cvVchD5N8pDwOPrdzk8vvpq3iw0PP6bq1/8nU8mcnSeNO/2Sx9A7n\nEw3zUTKGwzBCHA50HHAwE9iTBamMtUzjef7wJhyoPUeumCFWqA6ninvEneEBQmCV\ntEXc1mOu5QHUOWhY/dPTYtpBpWUbS4mIMZr8IDfPkh2KeDnfVFxPVPZiHjcPjd5R\ngx2eGFXWJJBIi0vVRXpIh5uKgeyEde3+aBTYKvxjB00jjj7Qm/yKMxN7JMlVgCqP\nBTRs1gkiEsPbgIFDI4ZYY7tiHOKtYgkH1u4V1ojPpF00qzGfXv53Ot+UAIToFM8a\nygOAdPjfRhcSL045k1nLHcT3TMxSZi8q9t+7TLvGkJEFDwGTA9wb2gV3LK95NUmA\n\ndRG8BFGXoT6/Ab+OgqZ9eZP7Na0BoGMlQ/ngpm+p4y7ZAYQ7igG85WMqssEORA1Z\n5rbpUFvRA1tPNTdhWGwRnugd+dJH5GRvObva1f/iIBzKfIPl/3W2Zxwss1yAxsxB\nX96mTFrMBP0H61Zt4IJ2sYEKbBLWlIGhjBbnFAyfg/NAIlnRnIjxo4JejsRijvdx\nb5TRtasUfilAebQenwzeqCZ3fZqZw9cgyLEh5hoKggD2ROVxIsr4gKTXhYf3G6QV\n/4lUjCMb+QiHDYBAacKvxpCIGNYTYU2XFKn/eqpvI3qBiwz5tg5GW0a91S3Hqxr0\nRqv7AXqftZ0DT"..., length = 4096)) + 135 at secure_transport.rs:930
    frame #15: 0x000000010002c76c test-reqwest`native_tls::imp::{{impl}}::read<hyper::net::HttpStream>(self=0x0000000101a280b8, buf=(data_ptr = "oiqZnlrBq8hUOi4X18L73l603MN5t1oRIN\nu85ZWhi/QQMwbfaI1nNk1REODX1IDQOdBlUPphhmvmeOv1YdVZkGOnp1h4k5X6bl\nNW8ECkKmGj3f0I1r4Bc8m7oKD++QyAulgMaTJBz6r3kby/KuntnMGnY4/BxwGdLY\neIBG0OkHSAGHZYdTAdMLZbMCmIq3a+Bc5/Ri4t4YsKWJJBZ/oT/jXGZ7XYOQNtEu\neJ6jgopwstlCMK/vdA4GM5AlMQ/th7LAcvJZQZUFikPJ92/zwlD8lDMH/uyud4lX\n9skiqv8XAj1cvVchD5N8pDwOPrdzk8vvpq3iw0PP6bq1/8nU8mcnSeNO/2Sx9A7n\nEw3zUTKGwzBCHA50HHAwE9iTBamMtUzjef7wJhyoPUeumCFWqA6ninvEneEBQmCV\ntEXc1mOu5QHUOWhY/dPTYtpBpWUbS4mIMZr8IDfPkh2KeDnfVFxPVPZiHjcPjd5R\ngx2eGFXWJJBIi0vVRXpIh5uKgeyEde3+aBTYKvxjB00jjj7Qm/yKMxN7JMlVgCqP\nBTRs1gkiEsPbgIFDI4ZYY7tiHOKtYgkH1u4V1ojPpF00qzGfXv53Ot+UAIToFM8a\nygOAdPjfRhcSL045k1nLHcT3TMxSZi8q9t+7TLvGkJEFDwGTA9wb2gV3LK95NUmA\n\ndRG8BFGXoT6/Ab+OgqZ9eZP7Na0BoGMlQ/ngpm+p4y7ZAYQ7igG85WMqssEORA1Z\n5rbpUFvRA1tPNTdhWGwRnugd+dJH5GRvObva1f/iIBzKfIPl/3W2Zxwss1yAxsxB\nX96mTFrMBP0H61Zt4IJ2sYEKbBLWlIGhjBbnFAyfg/NAIlnRnIjxo4JejsRijvdx\nb5TRtasUfilAebQenwzeqCZ3fZqZw9cgyLEh5hoKggD2ROVxIsr4gKTXhYf3G6QV\n/4lUjCMb+QiHDYBAacKvxpCIGNYTYU2XFKn/eqpvI3qBiwz5tg5GW0a91S3Hqxr0\nRqv7AXqftZ0DT"..., length = 4096)) + 76 at security_framework.rs:238
    frame #16: 0x00000001000283ac test-reqwest`native_tls::{{impl}}::read<hyper::net::HttpStream>(self=0x0000000101a280b8, buf=(data_ptr = "oiqZnlrBq8hUOi4X18L73l603MN5t1oRIN\nu85ZWhi/QQMwbfaI1nNk1REODX1IDQOdBlUPphhmvmeOv1YdVZkGOnp1h4k5X6bl\nNW8ECkKmGj3f0I1r4Bc8m7oKD++QyAulgMaTJBz6r3kby/KuntnMGnY4/BxwGdLY\neIBG0OkHSAGHZYdTAdMLZbMCmIq3a+Bc5/Ri4t4YsKWJJBZ/oT/jXGZ7XYOQNtEu\neJ6jgopwstlCMK/vdA4GM5AlMQ/th7LAcvJZQZUFikPJ92/zwlD8lDMH/uyud4lX\n9skiqv8XAj1cvVchD5N8pDwOPrdzk8vvpq3iw0PP6bq1/8nU8mcnSeNO/2Sx9A7n\nEw3zUTKGwzBCHA50HHAwE9iTBamMtUzjef7wJhyoPUeumCFWqA6ninvEneEBQmCV\ntEXc1mOu5QHUOWhY/dPTYtpBpWUbS4mIMZr8IDfPkh2KeDnfVFxPVPZiHjcPjd5R\ngx2eGFXWJJBIi0vVRXpIh5uKgeyEde3+aBTYKvxjB00jjj7Qm/yKMxN7JMlVgCqP\nBTRs1gkiEsPbgIFDI4ZYY7tiHOKtYgkH1u4V1ojPpF00qzGfXv53Ot+UAIToFM8a\nygOAdPjfRhcSL045k1nLHcT3TMxSZi8q9t+7TLvGkJEFDwGTA9wb2gV3LK95NUmA\n\ndRG8BFGXoT6/Ab+OgqZ9eZP7Na0BoGMlQ/ngpm+p4y7ZAYQ7igG85WMqssEORA1Z\n5rbpUFvRA1tPNTdhWGwRnugd+dJH5GRvObva1f/iIBzKfIPl/3W2Zxwss1yAxsxB\nX96mTFrMBP0H61Zt4IJ2sYEKbBLWlIGhjBbnFAyfg/NAIlnRnIjxo4JejsRijvdx\nb5TRtasUfilAebQenwzeqCZ3fZqZw9cgyLEh5hoKggD2ROVxIsr4gKTXhYf3G6QV\n/4lUjCMb+QiHDYBAacKvxpCIGNYTYU2XFKn/eqpvI3qBiwz5tg5GW0a91S3Hqxr0\nRqv7AXqftZ0DT"..., length = 4096)) + 76 at lib.rs:456
    frame #17: 0x000000010003d87c test-reqwest`reqwest::tls::{{impl}}::read(self=0x0000000101a280b8, buf=(data_ptr = "oiqZnlrBq8hUOi4X18L73l603MN5t1oRIN\nu85ZWhi/QQMwbfaI1nNk1REODX1IDQOdBlUPphhmvmeOv1YdVZkGOnp1h4k5X6bl\nNW8ECkKmGj3f0I1r4Bc8m7oKD++QyAulgMaTJBz6r3kby/KuntnMGnY4/BxwGdLY\neIBG0OkHSAGHZYdTAdMLZbMCmIq3a+Bc5/Ri4t4YsKWJJBZ/oT/jXGZ7XYOQNtEu\neJ6jgopwstlCMK/vdA4GM5AlMQ/th7LAcvJZQZUFikPJ92/zwlD8lDMH/uyud4lX\n9skiqv8XAj1cvVchD5N8pDwOPrdzk8vvpq3iw0PP6bq1/8nU8mcnSeNO/2Sx9A7n\nEw3zUTKGwzBCHA50HHAwE9iTBamMtUzjef7wJhyoPUeumCFWqA6ninvEneEBQmCV\ntEXc1mOu5QHUOWhY/dPTYtpBpWUbS4mIMZr8IDfPkh2KeDnfVFxPVPZiHjcPjd5R\ngx2eGFXWJJBIi0vVRXpIh5uKgeyEde3+aBTYKvxjB00jjj7Qm/yKMxN7JMlVgCqP\nBTRs1gkiEsPbgIFDI4ZYY7tiHOKtYgkH1u4V1ojPpF00qzGfXv53Ot+UAIToFM8a\nygOAdPjfRhcSL045k1nLHcT3TMxSZi8q9t+7TLvGkJEFDwGTA9wb2gV3LK95NUmA\n\ndRG8BFGXoT6/Ab+OgqZ9eZP7Na0BoGMlQ/ngpm+p4y7ZAYQ7igG85WMqssEORA1Z\n5rbpUFvRA1tPNTdhWGwRnugd+dJH5GRvObva1f/iIBzKfIPl/3W2Zxwss1yAxsxB\nX96mTFrMBP0H61Zt4IJ2sYEKbBLWlIGhjBbnFAyfg/NAIlnRnIjxo4JejsRijvdx\nb5TRtasUfilAebQenwzeqCZ3fZqZw9cgyLEh5hoKggD2ROVxIsr4gKTXhYf3G6QV\n/4lUjCMb+QiHDYBAacKvxpCIGNYTYU2XFKn/eqpvI3qBiwz5tg5GW0a91S3Hqxr0\nRqv7AXqftZ0DT"..., length = 4096)) + 76 at tls.rs:49
    frame #18: 0x00000001000290c7 test-reqwest`hyper::net::{{impl}}::read<reqwest::tls::TlsStream>(self=0x0000000101a280b0, buf=(data_ptr = "oiqZnlrBq8hUOi4X18L73l603MN5t1oRIN\nu85ZWhi/QQMwbfaI1nNk1REODX1IDQOdBlUPphhmvmeOv1YdVZkGOnp1h4k5X6bl\nNW8ECkKmGj3f0I1r4Bc8m7oKD++QyAulgMaTJBz6r3kby/KuntnMGnY4/BxwGdLY\neIBG0OkHSAGHZYdTAdMLZbMCmIq3a+Bc5/Ri4t4YsKWJJBZ/oT/jXGZ7XYOQNtEu\neJ6jgopwstlCMK/vdA4GM5AlMQ/th7LAcvJZQZUFikPJ92/zwlD8lDMH/uyud4lX\n9skiqv8XAj1cvVchD5N8pDwOPrdzk8vvpq3iw0PP6bq1/8nU8mcnSeNO/2Sx9A7n\nEw3zUTKGwzBCHA50HHAwE9iTBamMtUzjef7wJhyoPUeumCFWqA6ninvEneEBQmCV\ntEXc1mOu5QHUOWhY/dPTYtpBpWUbS4mIMZr8IDfPkh2KeDnfVFxPVPZiHjcPjd5R\ngx2eGFXWJJBIi0vVRXpIh5uKgeyEde3+aBTYKvxjB00jjj7Qm/yKMxN7JMlVgCqP\nBTRs1gkiEsPbgIFDI4ZYY7tiHOKtYgkH1u4V1ojPpF00qzGfXv53Ot+UAIToFM8a\nygOAdPjfRhcSL045k1nLHcT3TMxSZi8q9t+7TLvGkJEFDwGTA9wb2gV3LK95NUmA\n\ndRG8BFGXoT6/Ab+OgqZ9eZP7Na0BoGMlQ/ngpm+p4y7ZAYQ7igG85WMqssEORA1Z\n5rbpUFvRA1tPNTdhWGwRnugd+dJH5GRvObva1f/iIBzKfIPl/3W2Zxwss1yAxsxB\nX96mTFrMBP0H61Zt4IJ2sYEKbBLWlIGhjBbnFAyfg/NAIlnRnIjxo4JejsRijvdx\nb5TRtasUfilAebQenwzeqCZ3fZqZw9cgyLEh5hoKggD2ROVxIsr4gKTXhYf3G6QV\n/4lUjCMb+QiHDYBAacKvxpCIGNYTYU2XFKn/eqpvI3qBiwz5tg5GW0a91S3Hqxr0\nRqv7AXqftZ0DT"..., length = 4096)) + 151 at net.rs:474
    frame #19: 0x0000000100031c0a test-reqwest`hyper::client::pool::{{impl}}::read<hyper::net::HttpsStream<reqwest::tls::TlsStream>>(self=0x0000000101a28070, buf=(data_ptr = "oiqZnlrBq8hUOi4X18L73l603MN5t1oRIN\nu85ZWhi/QQMwbfaI1nNk1REODX1IDQOdBlUPphhmvmeOv1YdVZkGOnp1h4k5X6bl\nNW8ECkKmGj3f0I1r4Bc8m7oKD++QyAulgMaTJBz6r3kby/KuntnMGnY4/BxwGdLY\neIBG0OkHSAGHZYdTAdMLZbMCmIq3a+Bc5/Ri4t4YsKWJJBZ/oT/jXGZ7XYOQNtEu\neJ6jgopwstlCMK/vdA4GM5AlMQ/th7LAcvJZQZUFikPJ92/zwlD8lDMH/uyud4lX\n9skiqv8XAj1cvVchD5N8pDwOPrdzk8vvpq3iw0PP6bq1/8nU8mcnSeNO/2Sx9A7n\nEw3zUTKGwzBCHA50HHAwE9iTBamMtUzjef7wJhyoPUeumCFWqA6ninvEneEBQmCV\ntEXc1mOu5QHUOWhY/dPTYtpBpWUbS4mIMZr8IDfPkh2KeDnfVFxPVPZiHjcPjd5R\ngx2eGFXWJJBIi0vVRXpIh5uKgeyEde3+aBTYKvxjB00jjj7Qm/yKMxN7JMlVgCqP\nBTRs1gkiEsPbgIFDI4ZYY7tiHOKtYgkH1u4V1ojPpF00qzGfXv53Ot+UAIToFM8a\nygOAdPjfRhcSL045k1nLHcT3TMxSZi8q9t+7TLvGkJEFDwGTA9wb2gV3LK95NUmA\n\ndRG8BFGXoT6/Ab+OgqZ9eZP7Na0BoGMlQ/ngpm+p4y7ZAYQ7igG85WMqssEORA1Z\n5rbpUFvRA1tPNTdhWGwRnugd+dJH5GRvObva1f/iIBzKfIPl/3W2Zxwss1yAxsxB\nX96mTFrMBP0H61Zt4IJ2sYEKbBLWlIGhjBbnFAyfg/NAIlnRnIjxo4JejsRijvdx\nb5TRtasUfilAebQenwzeqCZ3fZqZw9cgyLEh5hoKggD2ROVxIsr4gKTXhYf3G6QV\n/4lUjCMb+QiHDYBAacKvxpCIGNYTYU2XFKn/eqpvI3qBiwz5tg5GW0a91S3Hqxr0\nRqv7AXqftZ0DT"..., length = 4096)) + 138 at pool.rs:175
    frame #20: 0x000000010004da04 test-reqwest`std::io::impls::{{impl}}::read<NetworkStream>(self=0x0000000101a2f048, buf=(data_ptr = "oiqZnlrBq8hUOi4X18L73l603MN5t1oRIN\nu85ZWhi/QQMwbfaI1nNk1REODX1IDQOdBlUPphhmvmeOv1YdVZkGOnp1h4k5X6bl\nNW8ECkKmGj3f0I1r4Bc8m7oKD++QyAulgMaTJBz6r3kby/KuntnMGnY4/BxwGdLY\neIBG0OkHSAGHZYdTAdMLZbMCmIq3a+Bc5/Ri4t4YsKWJJBZ/oT/jXGZ7XYOQNtEu\neJ6jgopwstlCMK/vdA4GM5AlMQ/th7LAcvJZQZUFikPJ92/zwlD8lDMH/uyud4lX\n9skiqv8XAj1cvVchD5N8pDwOPrdzk8vvpq3iw0PP6bq1/8nU8mcnSeNO/2Sx9A7n\nEw3zUTKGwzBCHA50HHAwE9iTBamMtUzjef7wJhyoPUeumCFWqA6ninvEneEBQmCV\ntEXc1mOu5QHUOWhY/dPTYtpBpWUbS4mIMZr8IDfPkh2KeDnfVFxPVPZiHjcPjd5R\ngx2eGFXWJJBIi0vVRXpIh5uKgeyEde3+aBTYKvxjB00jjj7Qm/yKMxN7JMlVgCqP\nBTRs1gkiEsPbgIFDI4ZYY7tiHOKtYgkH1u4V1ojPpF00qzGfXv53Ot+UAIToFM8a\nygOAdPjfRhcSL045k1nLHcT3TMxSZi8q9t+7TLvGkJEFDwGTA9wb2gV3LK95NUmA\n\ndRG8BFGXoT6/Ab+OgqZ9eZP7Na0BoGMlQ/ngpm+p4y7ZAYQ7igG85WMqssEORA1Z\n5rbpUFvRA1tPNTdhWGwRnugd+dJH5GRvObva1f/iIBzKfIPl/3W2Zxwss1yAxsxB\nX96mTFrMBP0H61Zt4IJ2sYEKbBLWlIGhjBbnFAyfg/NAIlnRnIjxo4JejsRijvdx\nb5TRtasUfilAebQenwzeqCZ3fZqZw9cgyLEh5hoKggD2ROVxIsr4gKTXhYf3G6QV\n/4lUjCMb+QiHDYBAacKvxpCIGNYTYU2XFKn/eqpvI3qBiwz5tg5GW0a91S3Hqxr0\nRqv7AXqftZ0DT"..., length = 4096)) + 84 at impls.rs:87
    frame #21: 0x0000000100071a50 test-reqwest`hyper::buffer::{{impl}}::fill_buf<Box<NetworkStream>>(self=0x0000000101a2f048) + 144 at buffer.rs:102
    frame #22: 0x00000001000715f2 test-reqwest`hyper::buffer::{{impl}}::read<Box<NetworkStream>>(self=0x0000000101a2f048, buf=(data_ptr = "", length = 685)) + 242 at buffer.rs:91
    frame #23: 0x0000000100083573 test-reqwest`hyper::http::h1::{{impl}}::read<hyper::buffer::BufReader<Box<NetworkStream>>>(self=0x0000000101a2f040, buf=(data_ptr = "", length = 720)) + 1059 at h1.rs:570
    frame #24: 0x000000010004db5f test-reqwest`std::io::impls::{{impl}}::read<hyper::http::h1::HttpReader<hyper::buffer::BufReader<Box<NetworkStream>>>>(self=0x00007fff5fbff030, buf=(data_ptr = "", length = 720)) + 79 at impls.rs:23
    frame #25: 0x0000000100081185 test-reqwest`hyper::http::h1::{{impl}}::read(self=0x0000000101a2f000, buf=(data_ptr = "", length = 720)) + 181 at h1.rs:124
    frame #26: 0x00000001000151f4 test-reqwest`std::io::impls::{{impl}}::read<HttpMessage>(self=0x00007fff5fbff9c0, buf=(data_ptr = "", length = 720)) + 84 at impls.rs:87
    frame #27: 0x000000010002a511 test-reqwest`hyper::client::response::{{impl}}::read(self=0x00007fff5fbff918, buf=(data_ptr = "", length = 720)) + 129 at response.rs:71
    frame #28: 0x000000010003d57c test-reqwest`reqwest::client::{{impl}}::read(self=0x00007fff5fbff918, buf=(data_ptr = "", length = 720)) + 76 at client.rs:299
    frame #29: 0x0000000100001e6c test-reqwest`std::io::read_to_end<reqwest::client::Response>(r=0x00007fff5fbff918, buf=0x00007fff5fbff8f0) + 316 at mod.rs:351
    frame #30: 0x0000000100007607 test-reqwest`std::io::Read::read_to_string::{{closure}}<reqwest::client::Response>(b=0x00007fff5fbff8f0) + 71 at mod.rs:561
    frame #31: 0x00000001000022bf test-reqwest`std::io::append_to_string<closure>(buf=0x00007fff5fbff8f0, f=closure @ 0x00007fff5fbff580) + 271 at mod.rs:319
    frame #32: 0x00000001000024c7 test-reqwest`std::io::Read::read_to_string<reqwest::client::Response>(self=0x00007fff5fbff918, buf=0x00007fff5fbff8f0) + 71 at mod.rs:561
    frame #33: 0x00000001000072cb test-reqwest`test_reqwest::main + 411 at main.rs:13
    frame #34: 0x00000001000ede2b test-reqwest`__rust_maybe_catch_panic + 27
    frame #35: 0x00000001000ec357 test-reqwest`std::rt::lang_start::h538f8960e7644c80 + 391
    frame #36: 0x00000001000076aa test-reqwest`main + 42
    frame #37: 0x00007fffb6e5b255 libdyld.dylib`start + 1
    frame #38: 0x00007fffb6e5b255 libdyld.dylib`start + 1

Other fun fact, if I avoid read_to_{string,end} and just call read with a fixed-size array, I never see it hang. I often don't get the whole response back in the first read, but for example with 8125 byte response, I can get all 8125 bytes with 2 back-to-back read calls in a matter of milliseconds.
Nothing has definitively clicked yet, but maybe I'll have more luck with fresh eyes after I get away from it for a while.

Would you be able to run that with a logger hooked up? Something like env_logger, with RUST_LOG=hyper=trace.

Reply to this email directly, view it on GitHub
https://github.com/seanmonstar/reqwest/issues/26#issuecomment-264074562,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADJFzhSxpOcQZ52dpy7-uOh72yl8pwwks5rDknBgaJpZM4K7E1m
.

In the case of this simple repro, yes.
In the case of the API client where I originally hit this, it hangs much longer - at least 15 min (I've yet to see it complete) for a 16,120 byte GET response.

Are those numbers consistent in multiple runs? If so, I see a possible off
by 1 error.
On Wed, Nov 30, 2016, 9:00 PM Anthony Nowell<EMAIL_ADDRESS>wrote:

In the case of this simple repro, yes.
In the case of the API client where I originally hit this, it hangs much
longer - at least 15 min (I've yet to see it complete) for a 16,120 byte
GET response.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/seanmonstar/reqwest/issues/26#issuecomment-264079426,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADJF3vefnHc9Yu-cAxa-xo3B_ckEkwmks5rDlRvgaJpZM4K7E1m
.

Yeah, those numbers are consistent across runs.
Sorry if it seems I'm just dumping random results here. While I do sorta hope that something stands out causing that "Aha!" moment, I do plan to keep digging - it's just a question of time and access to a mac.

It'd also be helpful to see the logs included from hyper::buffer, which I
know are noisy.
I tried to test on my Linux machine, and found that the Url you're using
was only around 4K, instead of 8...
On Wed, Nov 30, 2016, 10:53 PM Anthony Nowell<EMAIL_ADDRESS>wrote:

Yeah, those numbers are consistent across runs.
Sorry if it seems I'm just dumping random results here. While I do sorta
hope that something stands out causing that "Aha!" moment, I do plan to
keep digging - it's just a question of time and access to a mac.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/seanmonstar/reqwest/issues/26#issuecomment-264093156,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADJFzLEfs-Xplgn94Xe83IUu2D4RcUcks5rDm7xgaJpZM4K7E1m
.

ah.. sorry, I switched files at some point... https://dl.dropboxusercontent.com/u/39033486/8125.txt
the full trace output (and a few things I was printing) is here

The logs suggest this is hanging when trying to read the last 684 bytes (plaintext, would be more encrypted). However, if it was also doing that, then it should also happen when not using read_to_string.
To clarify if this is hyper trying to read more than it should, could try putting Connection::close() header in the request? That should make the server close the connection after writing the end, and so reading on the tcp stream at the point would give a Ok(0) instead of blocking for more. If that header doesn't fix it, then it's as the logs suggest, and pausing somewhere in the middle.

I'm seeing this exact same issue. Adding Connection::close() header does indeed stop it from hanging for 60 seconds.

Can confirm the same, had no idea what the issue locally was about (thought it was somewhere in the json mapping), but stumbled across this issue by accident and the additional Connection::close() header seems to help.

I ran into something like this earlier today with larger requests, where the body is binary data between 200k-500k. It gets down to the last 0.5k-3k and then hangs for 10s of seconds before continuing normally:
`
15:54:04 [DEBUG] hyper::client::response: version=Http11, status=Ok
15:54:04 [DEBUG] hyper::client::response: headers=Headers { Content-Type: application/tar;charset=UTF-8
, Content-Length: 370276
, Date: Sat, 18 Feb 2017 20:54:04 GMT
, }
15:54:04 [TRACE] hyper::http::h1: Sized read, remaining=370276
15:54:04 [TRACE] hyper::http::h1: Sized read: 32
15:54:04 [TRACE] hyper::http::h1: Sized read, remaining=370244
15:54:04 [TRACE] hyper::http::h1: Sized read: 64
15:54:04 [TRACE] hyper::http::h1: Sized read, remaining=370180
15:54:04 [TRACE] hyper::http::h1: Sized read: 128
15:54:04 [TRACE] hyper::http::h1: Sized read, remaining=370052
15:54:04 [TRACE] hyper::http::h1: Sized read: 256
15:54:04 [TRACE] hyper::http::h1: Sized read, remaining=369796
15:54:04 [TRACE] hyper::http::h1: Sized read: 512
...
15:54:07 [TRACE] hyper::http::h1: Sized read, remaining=1668
15:54:37 [TRACE] hyper::http::h1: Sized read: 1668
15:54:37 [TRACE] hyper::http::h1: Sized read, remaining=0`
Setting Connection::close() resolves it

I'm suffering from the same issue, on macOS 10.12.3.
The following hangs (don't know how long, C-c my way out of it):
extern crate reqwest;

use std::io;
use std::io::prelude::*;
use std::env;
use std::path::Path;
use std::fs::File;

fn main() {
    let mut sink = File::create("wordlist.txt").unwrap();
    let mut source = reqwest::get( "https://www.eff.org/files/2016/07/18/eff_large_wordlist.txt").unwrap();
    io::copy(&mut source, &mut sink).unwrap();
}

However, the following finishes in under a second, as expected:
fn main() {
    let client = reqwest::Client::new().unwrap();
    let mut sink = File::create("wordlist.txt").unwrap();
    let mut source = client.get("https://www.eff.org/files/2016/07/18/eff_large_wordlist.txt").header(reqwest::header::Connection::close()).send().unwrap();
    io::copy(&mut source, &mut sink).unwrap();
}

I did not debug any further, for it works now.  I can provide debug information, but I should like to add that I'm making my very first steps in Rust, and am not familiar with its ecosystem or debugging tools, so I'd appreciate step-by-step instructions for anything I should do :blush:

I just started taking a look at this again. An update to reqwest 0.5.0 fixed this for one of my tools (without using Connection::close), but it's definitely the gzip decoding path that works, as I'm still seeing the same behavior as before by adding gzip(false), so it seems that libflate's reading of Hyper's response seems to play nicer, reiterating a previous mention that individual calls to read seem to work better than read_to_{end,string}.
I started tinkering with hyper's h1 HttpReader, and I see it happen consistently on the final sized read (where the remaining bytes is less than the buffer length). My simple (non-gzip) repro only hangs on that final read for ~5 seconds now (as opposed to 60s before), but my library wrapping reqwest still hangs for way longer than I've been able to wait. I'll try a few more things tonight/tomorrow before caving in and accepting the Connection::close() work-around.

Other fun fact, if I avoid read_to_{string,end} and just call read with a fixed-size array, I never see it hang. I often don't get the whole response back in the first read, but for example with 8125 byte response, I can get all 8125 bytes with 2 back-to-back read calls in a matter of milliseconds.

Re-reading this stuck out at me: can you clarify if this was with using a [u8; 8125] buffer, or using something like [u8; 4096] twice.

@anowell @seanmonstar
Just a thought, the gzip decoding path sets the Content-Length header equal to the length of the un-gzipped content when the automatic un-gzip path is taken (courtesy of @rylio from his PR  https://github.com/seanmonstar/reqwest/pull/68).
So that means, on the auto un-gzip code path, the Content-Length is guaranteed to be correct (as it has been set by checking the length of the content itself).
On the other code path however, the value of the Content-Length header is the literal value from the response returned by the API you are hitting (I  haven't looked at hyper code to see how it constructs its response object to verify thats what hyper does). So that means if hyper doesn't validate the content length actually matches the size of the received content body (my gut tells me shouldn't be hyper's responsibility) that means that the Content-Length value has the potential to be incorrect on the non-gzipped code path.
So could a discrepancy between the Content-Length header and the actual size of the content cause this behavior? I don't know enough about the surrounding systems at play to guess how it could or would, but that sticks out as one of the major differences between those two code paths and so would make sense why one code path experiences the hang and the other doesn't.

@echochamber when gzip decoding, the Content-Length header isn't set to another value, it's removed.
hyper checks for a Content-Length header when constructing the Response, and then sets up an internal SizedReader that counts bytes to prevent from reading past the end.

I experienced this issue also. I assumed it was a problem with hyper and keep-alive since setting the Connection header to close fixed it. I found that the connection always closes after timing out, and also changing the read timeout length will change how long it hangs for.

Ah, you are correct. My fault for skimming over the body of the message at the top of that PR.
Last idle thought. Maybe the gzip decoding path is succeeding just because the reduced content-body size means its no longer falling into one of the problematic size ranges.
@seanmonstar If you aren't already working on this yourself, I wouldn't mind digging into it some. Do you have any suspicions of potential causes?

@echochamber I experienced this issue with non-gzipped content, so I don't think the problem is related to the gzip decoding.

@echochamber I don't own a Mac, so debugging is hard for me.
I find two pieces of this error to be peculiar: it only seems to happen on Macs (so TLS is secure-transport), and it sounds like it only happens with read_to_end (need more confirmation in https://github.com/seanmonstar/reqwest/issues/26#issuecomment-289960562).
If it is hanging because of keep-alive, it sounds like for some reason the TcpStream is being asked to read again after we've reached the end, because with keep-alive disabled, that last read just ends quickly with Ok(0). That would imply that even though there is the SizedReader keeping count of bytes, something is getting passed that and asking for more data.

I also found that reproducing the error was inconsistent, sometimes it would hang, sometimes it would not.

@rylio Good to know. I was a bit vague in my previous comment. I should have said "maybe the gzip decoding pat his succeeding for @anowell because...
@seanmonstar Thanks for sharing. I'll try taking a look into those potential causes and see what I can find.

@seanmonstar - I was about to say it's back to back [u8; 4096], but actually it gradually reads into larger buffers until it could read the whole remainder into a [u8; 4096], but instead it reads just 32 bytes into a [u8; 4096]. Then it tries to read the remainder into a [u8; 4064] - presumably the unused 4096-32 bytes from the previous buf.
Here's slightly augmented trace that prints buf.len():
TRACE:hyper::http::h1: Sized read, remaining=8125 buf.len()=32
TRACE:hyper::http::h1: Sized read: 32
TRACE:hyper::http::h1: Sized read, remaining=8093 buf.len()=64
TRACE:hyper::http::h1: Sized read: 64
TRACE:hyper::http::h1: Sized read, remaining=8029 buf.len()=128
TRACE:hyper::http::h1: Sized read: 128
TRACE:hyper::http::h1: Sized read, remaining=7901 buf.len()=256
TRACE:hyper::http::h1: Sized read: 256
TRACE:hyper::http::h1: Sized read, remaining=7645 buf.len()=512
TRACE:hyper::http::h1: Sized read: 512
TRACE:hyper::http::h1: Sized read, remaining=7133 buf.len()=1024
TRACE:hyper::http::h1: Sized read: 1024
TRACE:hyper::http::h1: Sized read, remaining=6109 buf.len()=2048
TRACE:hyper::http::h1: Sized read: 2048
TRACE:hyper::http::h1: Sized read, remaining=4061 buf.len()=4096
TRACE:hyper::http::h1: Sized read: 32
TRACE:hyper::http::h1: Sized read, remaining=4029 buf.len()=4064
<------- This is where it hangs for a bit -------->
TRACE:hyper::http::h1: Sized read: 4029
TRACE:hyper::http::h1: Sized read, remaining=0 buf.len()=35

This gives me a couple more ideas to experiment with.
@echochamber - fair point about the compressed size affecting the success. I quickly tried a few other sizes in the gzip path without any repro, but my methodology was kinda arbitrary, so I can't exactly rule that out yet.

narrowing this down by explicitly passing in various sized buffers (all using the 8125-byte response):
If the first buf fits the entire contents, it works flawlessly:
TRACE:hyper::http::h1: Sized read, remaining=8125 buf.len()=8192
TRACE:hyper::http::h1: Sized read: 8125

otherwise, if the first read is >= 4096 bytes, the second read will always hang:
TRACE:hyper::http::h1: Sized read, remaining=8125 buf.len()=6144
TRACE:hyper::http::h1: Sized read: 6144
TRACE:hyper::http::h1: Sized read, remaining=1981 buf.len()=32
---------- HANGS HERE ----------
TRACE:hyper::http::h1: Sized read: 32
TRACE:hyper::http::h1: Sized read, remaining=1949 buf.len()=4096
TRACE:hyper::http::h1: Sized read: 1949

otherwise, (if the first read is <4096), then the first read to reach or exceed the 4096th byte of the response will only read to that point (not filling the buffer), and the subsequent read will hang:
TRACE:hyper::http::h1: Sized read, remaining=8125 buf.len()=2048
TRACE:hyper::http::h1: Sized read: 2048
TRACE:hyper::http::h1: Sized read, remaining=6077 buf.len()=4096
TRACE:hyper::http::h1: Sized read: 2048
TRACE:hyper::http::h1: Sized read, remaining=4029 buf.len()=4096
---------- HANGS HERE ----------
TRACE:hyper::http::h1: Sized read: 4029

and now I need to decompress a bit to see if I can make sense of "why?"

It hangs during the call to Secure Transport's SSLRead. Regardless of the buffer size when reading from hyper Response, SslStream always gets read with a buffer of at least 4096 bytes (INIT_BUFFER_SIZE), thus, it always happens on the second call to SSLRead, e.g.:
TRACE:hyper::http::h1: Sized read, remaining=8125 buf.len()=2048
SSLRead: buf.len()=4096 nread=4096 ret=0
TRACE:hyper::http::h1: Sized read: 2048
TRACE:hyper::http::h1: Sized read, remaining=6077 buf.len()=4096
TRACE:hyper::http::h1: Sized read: 2048
TRACE:hyper::http::h1: Sized read, remaining=4029 buf.len()=4096
---------- SSLRead Hangs ----------
SSLRead: buf.len()=4096 nread=4029 ret=0
TRACE:hyper::http::h1: Sized read: 4029

I tinkered with bumping hyper's INIT_BUFFER_SIZE from 4096 to 8192, and that just shifted the problem to larger responses. The second call to SSLRead still hangs.
Nothing obvious stands out skimming the Secure Transport docs, but I didn't dig into how the rest of the session impacts SSLRead. The questions on my mind at this point are:

How does Connection::close() affect the state of Secure Transport?
Why doesn't this repro if SSLRead gets called 3 times? (i.e. none of the 3 calls will hang)

How does Connection::close() affect the state of Secure Transport?

By setting Connection: close, the server will shutdown the socket after sending the end of the response. Therefore, when SSLRead asks our TcpStream for more data, TcpStream::read can immediately respond with Ok(0).
The hang is because for a yet undiscovered reason, SSLRead is calling TcpStream::read([u8; 5]) after having read to the end of the response body. Since the server hasn't closed the connection, the TcpStream::read blocks until a timeout occurs, or the server sends more data. The 5 bytes are to read the next TLS header, which would exist if there was more body to read.
It seems like during the final SSLRead call, it does read the end (since your log says nread=4029), but then something makes it call its inner SSLReadFunc again, which just is where the hang happens.

A useful thing to help debugging is if we remove hyper from the equation. Here's a gist that will just use native-tls: https://gist.github.com/seanmonstar/fa4c700e6cd9b8399ae736638f8164e5. Can alter it to request any resource.

Er, I hadn't thought that through. The gist couldn't use read_to_end, since it's a keep-alive connection. It'd need to check for a Content-Length header, and then be sure to not read once that many bytes have been read...

It turns out SSLRead does A Bad Thing!
https://gist.github.com/seanmonstar/c58fc023d60bc295230539f2f4c82a0c#file-ssltransport-cpp-L100-L102
https://github.com/sfackler/rust-security-framework/commit/4cd518d11a5c7e292a48c7ced15555e931bd0278#diff-0c189053dd842cb8ae78ca32925584a8R1029

I believe I've found the issue. Searching the Apple's source code for SSLRead revealed that if called with data length longer than what was buffered internally in SslContext, it would copy from the buffer, and then perform a socket read. This is contrary to how typical IO objects work, such as TCP will first return the data in its buffer, and only subsequent calls will block on the socket.
We should have a new update of security-framework soon, and then a cargo update should hopefully fix everyone.

@seanmonstar @sfackler Nice job hunting that down.

I was just about to post a bunch of debug output with a modified version of your gist - but it basically confirms exactly what you described. I just wasn't sure if it was hyper giving a wrong sized buffer or SSLRead not handling it sanely. Many thanks for on getting to the bottom of that.

There was recently the release of macOS 10.12.4, and it still has this bug 😞.

 Using this: https://gist.github.com/rylio/aa055cc08c07fac38782805118f01238

@rylio after doing a cargo update?

@rylio I think this comment is relevant

The gist couldn't use read_to_end, since it's a keep-alive connection. It'd need to check for a Content-Length header, and then be sure to not read once that many bytes have been read...

As far as I can tell, the fix has resolved all of my repros.

@anowell You are correct, didn't notice that.

Woo! Closing as fixed. Thanks all for helping track down this issue.


issue with install script

┌──(root💀kali)-[~/Tools/Garud]
└─# sh install.sh
: not found 3:
: not found 9:
install.sh: 10: cd: can't cd to /root
install.sh: 23: Syntax error: "elif" unexpected (expecting "then")

Hi @syncinggreen,
I have fixed the code in the new commit. Now you can use the script to install all the tools.
regards,
R0X4R

Hi @syncinggreen,
I have fixed the code in the new commit. Now you can use the script to install all the tools.
regards,
R0X4R


/guileaderboard

A leaderboard that uses player heads in a UI with maps on the horizontal axis and placement on the vertical

On second thoughts, this doesn’t sound so useful. The one in chat is much better


error caught with rnafeatures.py

When I run the fellow command, I caught errors.
$python rnacommender/rnafeatures.py examples/utrs.fa examples/utrs.h5
###################################################
/panfs/home/sun/wujinyu/anaconda2/lib/python2.7/site-packages/sklearn/cross_validation.py:44: DeprecationWarning: This module was deprecated in version 0.18 in favor of the model_selection module into which all the refactored classes and functions are moved. Also note that the interface of the new CV iterators are different from that of this module. This module will be removed in 0.20.
"This module will be removed in 0.20.", DeprecationWarning)
/panfs/home/sun/wujinyu/anaconda2/lib/python2.7/site-packages/sklearn/grid_search.py:43: DeprecationWarning: This module was deprecated in version 0.18 in favor of the model_selection module into which all the refactored classes and functions are moved. This module will be removed in 0.20.
DeprecationWarning)
Folding sequences using RNAplfold -W 100 -L 40 -c 0.400000                 --noLP... Done.
Vectorizing (complexity: 2, hashing: 10 bits)...
#--------------------------------------------------------------------------------
object of type 'generator' has no len()
Error in: uc001abw.1_3UTR GGUUGCCGGGGGUAGGGGUGGGGCCACACAAAUCUCCAGGAGCCACCACUCAACACAAUGGCCCUGCCUCCCACCGCUUUAUUUCUUUCGGUUUCGGAUGCAAAACAAAAAAUUUUAAAAGAAAAUGUGACUUCAAAGGAAAGGAACAAAUUUUCAAAGACUUGGGGGAGUGAAGGCAGAGCCUGGUGCAGAUGGACGAGGUCUGCAGACGGAGGGCAGAGGUGGUGGAAGGGGCCAGGGGCCUGCAGGCCUCCCCCUGGAACUGGGACUGGUCUCGGUCUGCUGACGUCAGGGUCAGCUCCCCCGCGGAGCUGACUUCAGCAGCCCACAGCUGUGGGGCUUCAGCAGCCACACCAGCCCAGCCCAGCCCAGCUCUCGAUACGUUUGGUCUUUCAUGCUGAAAAAUAAAUAAUAAAGCCUGUCCCGUG
Reverting to path graph from sequence
WARNING: window size 100 larger than sequence length 80
#--------------------------------------------------------------------------------
object of type 'generator' has no len()
Error in: uc001abw.1_5UTR GCAGAUCCCUGCGGCGUUCGCGAGGGUGGGACGGGAAGCGGGCUGGGAAGUCGGGCCGAGGGAAAAGUCUGAAGACGCUU
Reverting to path graph from sequence
##########################################################
So, how to fix this bug?
Thanks!

These are errors are generated because of RNAplfold. The messages you are seeing are the error handling implemented in the rnaplfold converter of EDeN.
When, for some reason, it was not possible to generate the graph encoding of the predicted folded structure of the RNA, EDeN generates a path graph from the RNA sequence. A path graph is just the graph representation of a sequence and it can be used with the graph vectorizer (as the other correctly generated graphs).
Anyway, these errors are not supposed to halt the computation of the RNA features, and, at the end, you will have a feature vector for each RNA sequence in the input fasta file. For sequences that raised RNAplfold errors, those features are computed from the sequence information only.
Cheers


Add the ThrowException fn to the isolate

I've re-implemented the ThrowException function from #143, but added support for passing in a Value instead of just a string, as pointed out by @dylanahsmith. This allows us to pass a string, or forward in a TypeError.
A few notes:

The return value is always null or undefined.
I don't know how to write a test for this.

Might be able to test it by calling the function from within another function like:
func TestIsolateThrowException(t *testing.T) {
	t.Parallel()
	iso := v8.NewIsolate()
	defer iso.Dispose()

	typeErr, err := v8.NewValue(iso, "some type error")
	if err != nil {
		t.Errorf("unexpected error: %v", err)
	}

	fn := v8.NewFunctionTemplate(iso, func(info *v8.FunctionCallbackInfo) *v8.Value {
		v := iso.ThrowException(typeErr)
		if !v.IsNull() && !v.IsUndefined() {
			t.Error("expected result to be <nil> or undefined")
		}
		return nil
	})

	global := v8.NewObjectTemplate(iso)
	global.Set("foo", fn)

	ctx := v8.NewContext(iso, global)
	defer ctx.Close()

	_, e := ctx.RunScript("foo()", "forever.js")
	if e.Error() != "some type error" {
		t.Errorf("expected error but got: %v", e)
	}
}

Thanks, @genevieve. I had forgotten about the error returned by RunScript. I modified it a little to include a test case for a TypeError.


Add topics

Add topics (e.g. "pesonal website homepage resume gh-pages html css binary-studio-academy bsa18")

added topics


[WIP] Related Files - Extension Module

Extension that provides related files (CSS and JS) for given HTML document.
Unit test case to validate related files provided by the extension.

@shraddhasarda There are lint errors in the change list for this PR.
Please refer to the following errors from the build log -

Closing this PR as this is not in progress any more.


svg images

I started using html2pdf and appreciated how powerful it is. I wasn't able to reproduce svg images thought and I don't understand if it's a problem of configuration, plugin or what else. I do see jpg and png images.  Any hint is appreciated. Thanks in advance. BTW: I tried to create a jsfiddle, but in that fiddle, I couldn't even see the png and jpg images and that means I miss something fundamental...

This issue might help you: https://github.com/niklasvh/html2canvas/issues/1578

Thanks @AbelVM  for the pointer, I just tried adding width and height but it didn't solve the issue.

It took me a while to understand that there was an option named 'onclone' *;-) Nevertheless, this was not enough for me. I amanaged to bypass the problem using png images...

The above didn't do the trick for me. Anyone else came up with a solution for SVG elements not being displayed in the PDF ?

The above didn't do the trick for me. Anyone else came up with a solution for SVG elements not being displayed in the PDF ?

me too, both width or x doesn't work for me

@AbelVM @eKoopmans thanks, that solution in "onclone" callback worked for me.

I tried to resolve this issue but it didn't solve issue. html2canvas.js?c0e9:2424 1776c1e1438 3960ms Error loading image

I was still having trouble with the svg being oversized and this did the trick for me. Thanks to @eKoopmans start code and a small edit I did. here is another solution.

Hi, thanks @AbelVM for helping out. @sandroden it sounds like your issue was resolved, albeit not in a way that got SVG working. I'm going to close, but please reopen if you want to investigate the SVG issue further.
For anyone else visiting, I haven't tested but from @AbelVM's comments I'd recommend trying:
html2pdf().set({
    html2canvas: {
        onclone: (element) => {
            const svgElements = Array.from(element.querySelectorAll('svg'));
            svgElements.forEach(s => {
                const bBox = s.getBBox();
                s.setAttribute("x", bBox.x);
                s.setAttribute("y", bBox.y);
                s.setAttribute("width", bBox.width);
                s.setAttribute("height", bBox.height);
          }
     }
})... // Whatever else you want to do.

Thank you for answer it made my day but there is a problem on bracets i fixed it.
            html2canvas: {                 onclone: (element) => {                     const svgElements = Array.from(element.querySelectorAll('svg'));                     svgElements.forEach(s => {                         const bBox = s.getBBox();                         s.setAttribute("x", bBox.x);                         s.setAttribute("y", bBox.y);                         s.setAttribute("width", bBox.width);                         s.setAttribute("height", bBox.height);                     })                 }             }

To anyone that finds this. I have found this issue quite helpful.
https://github.com/niklasvh/html2canvas/issues/1803

for anyone encountering the problem just add the width and height attributes to the svg example witdh="100"


Different style for icon

I try to mimic this theme in way bar https://raw.githubusercontent.com/adi1090x/files/master/polybar-themes/previews/blocks/main.gif.
However, I don't know how to style Icon different versus the text.
Does waybar support this option?

I'm not sure that it's good solution, but you can try to create 2 different modules (one for icon and one for text), e.g. network and network#text.

You can wrap your icon in a  and set a background attribute on it, like this:
"format": "{temperatureC}°C {icon}"

which results in:

It's a bit of a hack, since your now styling from the config file and not the style.css. But you can nonetheless achieve what you're trying to do.
Btw. something like class="icon" won't work, because class is not valid pango markup. See valid attributes here

yeah, thank you all. But I think it's a little hacky. I think waybar should provide us a official way to style icon in style.css.

I agree, I don't think hardcoding the styles for icons in configuration is a viable solution. It would be difficult to allow styling "icons" specifically when you are able to put a fontawesome glyph anywhere in the format string though. It really is a shame pango spans cannot have classes.

"backlight": {
                 "device": "intel_backlight",
                 "format": "{icon}",
                 "tooltip-format": "盛{Percentage}%",
                 "format-icons": ["", "", "", "", "" ],
                 "on-scroll-up" : "light -A 1",
                 "on-scroll-down" : "light -U 1"
             },

This is my backlight module, now what should i do to increase the size of icon in format. Kindly help.

Hi @ashish-kus ,
Try this
"backlight": {
                 "device": "intel_backlight",
                 "format": "{icon}",
                 "tooltip-format": "盛{Percentage}%",
                 "format-icons": ["", "", "", "", "" ],
                 "on-scroll-up" : "light -A 1",
                 "on-scroll-down" : "light -U 1"
             },


Dialog with Title and Content prevents overflow

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

Expected Behavior 🤔
Label should be shown full.
Steps to Reproduce 🕹
https://codesandbox.io/s/materialui-dialog-tb1g4?file=/index.js
Context 🔦

Your Environment 🌎

`npx @material-ui/envinfo`
  Don't forget to mention which browser you used.
  Output from `npx @material-ui/envinfo` goes here.

@eps1lon Can I work on this issue?

@eps1lon How can I check what changes my code does locally?

@Gautam-Arora24 Please check https://github.com/mui-org/material-ui/blob/next/CONTRIBUTING.md and https://github.com/mui-org/material-ui/blob/next/test/README.md


Roll engine 9aa7c9a48e93..c3824f06933a (13 commits)

https://github.com/flutter/engine/compare/9aa7c9a48e93...c3824f06933a
git log 9aa7c9a48e9342a450c3078e15c8d7923a338ede..c3824f06933af54b54d1094594c0159828dd1a45 --no-merges --oneline
c3824f069 Roll src/third_party/skia e62bf561638c..990bfc785891 (2 commits) (flutter/engine#8569)
49a72e1e4 Roll src/third_party/skia 8be917af4313..e62bf561638c (5 commits) (flutter/engine#8568)
7292d62ef Revert Versions API (flutter/engine#7828)
9336671a8 Revert "Roll src/third_party/dart a8f3a5dae6..c2eb9a9860 (8 commits)" (flutter/engine#8567)
a54354349 Roll src/third_party/dart a8f3a5dae6..c2eb9a9860 (8 commits)
23b0e02ec Android Embedding PR29: Improve FlutterFragment construction API + engine config API. (flutter/engine#8540)
e6c822db9 Roll src/third_party/skia 25071cc52b4b..8be917af4313 (6 commits) (flutter/engine#8564)
1bb2c0cf0 Remove unused import in FlutterActivityDelegate (flutter/engine#8563)
ad04340e5 Add missing <memory> include to text_input_model.h (flutter/engine#8562)
fcd717e28 Update README.md to point to flutter.dev (flutter/engine#8557)
501892a92 Roll src/third_party/skia 35f1c154c5e5..25071cc52b4b (7 commits) (flutter/engine#8560)
db99c86ab Roll src/third_party/skia 41476708db86..35f1c154c5e5 (1 commits) (flutter/engine#8559)
a88cd8032 Roll src/third_party/skia f74fff660084..41476708db86 (1 commits) (flutter/engine#8558)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (garyq@google.com), and stop
the roller if necessary.

Auto-roller completed checks. About to merge.


cargo-c: 0.8.1 -> 0.9.2

This fixes a build error that was originally triggered by 1d1ef50501d0dd2d30394b5e0ca1d8aec8498988.
Motivation for this change
Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 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.

Here is the changelog https://github.com/lu-zero/cargo-c/releases

LGTM. I would merge except since this affects quite a lot of package, I'm leaving this open to give more time for others to have a look.


Several things

MC Version - 1. 10. 2
Mod vesion - AdvancedRocketry-1.10.2-1.0.19.jar
Hello, i added your mod on my server and we now testing your and other mods on server, i found some bugs what are not good for game itself and some things what are not good for mod itself.

You can launch rocket remotely what have guidence computer with chip configured to luna and launch it. Rocket will never leave Overworld and it will be stuck in nowhere. Cargo rockets to other planets seems not working :D
https://youtu.be/CG9ORnP1i94

Sometimes rockets not render to player and they bug itself on earth, you can start them, they burn fuel but they will stay on ground without moving until they burn all fuel.

Minning rockets eating chips with asteroid data.
And they get stucked in mid air while landing.
https://youtu.be/eaXZnTXfRpY

Sometimes rockets get stuck while landing in mid air and dont fall down ( i thing it will be good if all rockets will fall down if their engines not working)

You can build 2 or more identical satelites if you will add there 2 or more chasis, if you will launch to satelites with ID 2 they will rewrite data of staelite before.

Sometime when you oppening guidence computer your game can crash: https://pastebin.com/RPi88m4R
At mostly happening on bugged rockets.
Rokets can mostly bug themself after landing on moon.
https://www.youtube.com/watch?v=eEGxFdYDrog

Crusher from mekanism can make your silicon, it mean silicon recipe in your multiblock is not in use.

Stations on multilayer not workin properly.
https://www.youtube.com/watch?v=RnxPgemTFAE

Satelite data in satelite terminal have bigged AI if satelite data extend internal buffer, it will be good incriesse internal buffer to 5000 data and make recipe harder.
https://youtu.be/eaXZnTXfRpY

Dilithium generating on Earth by default - pointless to go on moon.

Other bugs:
https://youtu.be/i5eBU10plEQ
https://youtu.be/e1tePRgP6vM
https://youtu.be/kaAngaO3jpE

I can relate to most of theses, so I'm subscribing to see when this will be fixed, I really hope to see theses bugs fixed in 1.10.2 and not only on latest versions like most modders tend to do theses days, I took the time to design an awesome modpack for myself and wanted to enjoy this advanced rocketry mod to the max, have big plans for it, but right now, its not exactly working. I have to disconnect and reconnect from my server every single time I travel on my rocket between destinations, otherwise I'm not loaded properly and I'm stuck in between lands and such. All of this using latest 1.2.2 version of the mod.

Are both of you using sponge or something similar?

Nope, straight Forge latest version, but I've decided to move to 1.12.1 and more than likely will not see your mod on it for quite awhile so it will be something I'll enjoy much later (I don't blame you for this, its quite a task to develop a mod for already 3 versions of Minecraft at the same time) will hopefully see this mod in a future version.

Hello everyone, I'm having the same problems as Cenbes describes. I'm using Sponge. Please zmaster587, try your best to fix it, you've already done a lot of good work to make this mod as much awesome as it is, but without this fix I'm unable to use it. Thanks and have a good day :)

Is this still a issue? Please comment if it is and i will reopen if if you are unable? We are closing old issues to see what is still relevant and needs to be fixed.

Some of these are still issues. I get stuck in transition before landing ~25% of the time, and have to regularly reload my world to get it to work. I'm concerned that on a server a player could get stuck. 1.12.2


tree editor label missing for odd number of receivers

What did you do?
Utilizing https://prometheus.io/webtools/alerting/routing-tree-editor/ Added an odd number (3, 5, 7 etc) of receivers to a config and pressed 'draw routing tree'. Receiver labels for "one" and "two" and drawn, but "three" is not visible. A line is drawn 90 degrees down to the bottom of the browser page, and no label is present - not knowing any better, I thought this line was the 'entry point' into the tree. This led to a lot of confusion as I thought my routing was broken.
This simple config snippet illustrates the problem, and will show the result for any odd number of receivers added.
route:
  receiver: default
  routes:
  - receiver: one
  - receiver: two
  - receiver: three

What did you expect to see?
Expected to see all receiver names drawn on the tree.
What did you see instead? Under which circumstances?
When using an odd number of receivers, one element is always drawn at the bottom of the page and the name of the receiver is outside the rendered area.
Environment
Tested on chrome and firefox, both under MacOS

Alertmanager configuration file:

route:
  receiver: default
  routes:
  - receiver: one
  - receiver: two
  - receiver: three

For reference the code is in the docs repository: https://github.com/prometheus/docs/blob/master/static/routing-tree.js
Maybe @stuartnelson3 has some insights.

Untill it is fixed you can possibly use the amtool for visualising the routing tree.
$ ./amtool config routes show --config.file=am.yaml
Warning: --config.file flag overrides the --alertmanager.url.
Routing tree:
.
└── default-route  receiver: default
    ├── default-route  receiver: one
    ├── default-route  receiver: two
    └── default-route  receiver: three

Yup, the amtool (once I found it) was how I verified my setup was actually
correct.
On Mon, Jan 13, 2020, 5:11 PM Martin Chodur<EMAIL_ADDRESS>wrote:

Untill it is fixed you can possibly use the amtool for visualising the
routing tree.
$ ./amtool config routes show --config.file=am.yaml
Warning: --config.file flag overrides the --alertmanager.url.
Routing tree:
.
└── default-route  receiver: default
├── default-route  receiver: one

├── default-route  receiver: two

└── default-route  receiver: three

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/prometheus/alertmanager/issues/2159?email_source=notifications&email_token=AAJWY6U6HBT3IKXDBVWPY2TQ5TRJTA5CNFSM4KFZBKS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI2PRQY#issuecomment-573896899,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJWY6X7VCTKCLTWRSHAW73Q5TRJTANCNFSM4KFZBKSQ
.

I somehow fixed it hopefully in https://github.com/prometheus/docs/pull/1531
Please could you verify that it's working as expected here?
https://5e1cf535758772000a2abe8e--prometheus-docs.netlify.com/webtools/alerting/routing-tree-editor/?_ga=2.248804999.1456365537.1578956161-1630445063.1578956161
I tested it and works ok.

Confirmed, that did the trick!


Can't connect with sftp

First of all, thank you for a great application. I've used it before and loved it. I'm trying to use it again on a Mac to access the backup from another machine.
I'm using macOS release 0.3.1.
The first screenshot shows that I am connected with SSH to the host, yet from restic browser, I can't seem to connect. I have my SSH config set up with the host name and identity file to use, so when running the SSH command, I don't have to enter a password or point to an identity file (this does work though the screenshot has the -i flag).
I can also connect via SFTP with the restic CLI to the exact path that I'm putting into restic browser, so it does seem to just be an issue with restic browser SFTPing.
Checking the insecure TLS box makes no difference.
Thanks for any help!

Hi. Sorry for the late reply.
If that works in the command line restic call, this indeed should just work. I am not sure why it doesn't.
Maybe some of nacOS security features do break this, or you are setting some of the credentials in your bash, zsh init scripts? Those are not loaded in GUI apps such as Restic Browser. To test if that's the issue, try launching Rustic Browser from your shell instead of launching it from Finder.

I cant connect at all btw. its stuck on " Fetching Snapshots ":
https://github.com/emuell/restic-browser/issues/128

Now i had the same error as @gigibytes
@gigibytes Furthermore maintained?


Implement upcoming deadlines section

Task

Implement upcoming deadlines section

Deliverables

Functional upcoming deadlines section

Size Estimation: Medium (2-4 hours)

Completed.


Release 3.5.0

fixes #595
fixes #596
New version to app and Change log

Coverage decreased (-0.0004%) to 2.3% when pulling 2faf7db129cf5f97ac20a37ff2c3f36d8113faf4 on rel_app_params into 6c4d13a440f87a7dec81d61fc571db6d0609318a on master.


explore menu icons

additional icon for explore menus. The menu entry can be some internal or external link with an additional icon. The icon can be configured for each explore_section
References

Fixes https://github.com/4Science/dspace-angular/issues/43

Description
Short summary of changes (1-2 sentences).

some additonal icon can be included in explore menus
the icon can be configured in default-app.config.ts
the icon works on internal routes as well as external links
additional css classes can be configured in the icon to style the icon.

Instructions for Reviewers
configure icon

Include guidance for how to test or review your PR. This may include: steps to reproduce a bug, screenshots or description of a new feature, or reasons behind specific changes.
Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

[ ] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
[x] My PR passes ESLint validation using yarn lint
[ ] My PR doesn't introduce circular dependencies (verified via yarn check-circ-deps)
[ ] My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
[ ] My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
[ ] If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
[ ] If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
[x] If my PR fixes an issue ticket, I've linked them together.

This is a nice feature, but how to add an icon to communities_and_collections which is not an explore_section?


Need consistent assignment of fullUrl, id, and url for LOINC.

This is an example of one that's right:
https://fhir-dev.loinc.org/ValueSet/tmp-all-loinc
The resource ID, the end of the URL, and the identifier all agree.

Working branch: 1483-need-consistent-assignment-of-fullurl-id-and-url-for-loinc

Pull request: #1501

Merged.


Replace Page.isHtml with Page.contentType

Enter your suggestions in details:
Just saw the changelog which included the addition of Page.isHtml, which is great, but I wonder if a broader is-function might be more useful. Lume's docs mention the possibility of dynamically generated assets here, and those assets could be blobs like PDFs of other files, or text files, indeed like the example'd Javascript-map file. But what if it's an XML file like an RSS feed? Would that appear to Lume as a HTML file? Would that therefore impact how that file is rendered? I'm not sure tbh, but I do think either way there's enough of a reason to allow for more exhaustive check. You could even keep the Page.isHtml by having its value set via Page.isHtml = Page.contentType === "text/html"; You could check the prefix of the content-type to know how to save the file: if the type is prefixed with text/ then you know that you can safely use Deno.writeTextFile() instead of another method.

You can get the content type of the pages by the url. For example:
if (page.data.url.endsWith(".css")) {
    // it's a CSS file
}

The isHtml property is used internally because HTML pages are the only format that doesn't require to have the .html extension in the url. For example /about-me/. It's used internally by some plugins like search that only returns html pages.
Thinking more about this, probably it could use the outputPath property to get the .html extension (page.outputPath.endsWith(".html")).
Here's the code: https://github.com/lumeland/lume/blob/master/core/filesystem.ts#L121-L136
Maybe i will change it in the next version.

@oscarotero What about markdown and nunjucks files, which become HTML? I found this property very useful.

@binyamin Pages have two properties:

page.src: Info about the source file (page.src.ext returns the extension, like .md, .njk, etc).
page.outputPath: The output path of the page. For example /about-me/index.html (with prettyUrls enabled) or /about-me.html with prettyUrls disabled.

So, if you want to detect if a page will become to HTML, just do page.outputPath.endsWith(".html").


fix: skip tkn-bundle task test temporarily

Description
Skipping the test to unblock build-definitions CI
Issue ticket number and link
https://issues.redhat.com/browse/EC-629
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added meaningful description with JIRA/GitHub issue key(if applicable), for example HASSuiteDescribe("STONE-123456789 devfile source")
[ ] I have updated labels (if needed)

/approve


Generic name when running tryceratops as a module

I installed tryceratops and tryceratops.exe got installed into a folder that is not on my PATH variable.
What I usually do, to run things like black, is python -m black, and the same thing works for tryceratops, naturally.
However, some of the command-line options give generic info back because __name__ is now "__main__":
 > python -m tryceratops --version
__main__.py, version 0.2.3

and
 > python -m tryceratops --help
Usage: __main__.py [OPTIONS] [DIR]...
# omitted

Notice both appearances of __main__.py where I expected tryceratops or tryceratops.py. In my opinion the __main__.py doesn't look good, in a stylistic sense.

Interesting... I couldn't simulate. What's your OS?

Windows 10, 64 bit, Python 3.9, tryceratops installed for the user, not globally.

Update: seems like other tools also have this quirk, e.g. black shows the same thing.

Interesting, I'll take a look

It seems easy to fix. Saving for later: https://github.com/pallets/click/issues/1399

Done, next release it will be fixed


eMQTT5 does not install at all

Hi, it's me again :laughing:,
when including eMQTT5 into some project, which wants to install eMQTT5 along with some other product, at least the shared object should be installed, possibly even the test program. Using eMQTT5 without local modifications will lead to the effect, that the installed product will not have eMQTT5 installed. CMake before version 3.13 will not allow this to be added from the outside, so could you please add something like
install(TARGETS eMQTT5 LIBRARY DESTINATION lib)

and
install(TARGETS MQTTc RUNTIME DESTINATION bin)

to the respective project files?

Should be done now. Please report if it fails.


Footnotes are not replaced when RichTextWithFootnotesBlock is a StructBlock sub-block

When you include a RichTextWithFootnotesBlock in a StreamBlock definition, things work great! This is because StreamBlock.to_python returns a StreamValue, which has a render_as_block() method that feeds back into  StreamBlock.render_basic() to do the actual rendering... which calls the render() method of each sub-block, ultimately leading to RichTextWithFootnotesBlock.replace_footnote_tags() doing its thing.
When you include a RichTextWithFootnotesBlock as a sub-block of a StructBlock, things work out a little differently. The tendency is to do the following in StructBlock templates:
{% load wagtailcore_tags %}
{{ value.caption|richtext }}

This definitely won't trigger RichTextWithFootnotesBlock.replace_footnote_tags(), because we're basically just taking the value from the block and rendering it directly.
I thought that changing all instances of the above would resolve the problem:
{% load wagtailcore_tags %}
{% include_block value.caption %}

However, that didn't do the job because {% include_block %} only does anything special with the value if it has a render_as_block() method (like StreamValue does). If not, the value itself is used as the output value, which isn't really what we want.
What we want is for RichTextWithFootnotesBlock.render() to always be used in rendering, and in order to do that, RichTextWithFootnotesBlock needs to return something other than an instance of RichText... we need something with a render_as_block() method (like StreamValue does), so that we can always bring things back to RichTextWithFootnotesBlock.render(). Something like this worked in a project I am currently working on:
class RichTextBlockValue:
    """
    Value type returned by CustomRichTextBlockWithFootnotes.to_python().

    When rendered in a StructBlock, FieldBlock values are usually rendered directly, bypassing the
    footnote replacement logic that is usually triggered by RichTextBlockWithFootnotes.render().
    If the block instead returns a value with a 'render_as_block()' method, we can always reliably
    hand things back to RichTextBlockWithFootnotes.render() to take care of rendering, where the
    footnote replacement logic will kick-in.
    """

    def __init__(self, block, value):
        self.block = block
        self.source = value
        self.value = RichText(value)

    def render_as_block(self, context=None):
        return self.block.render(self, context=context)

    def __html__(self):
        return self.block.render(self)

    def __str__(self):
        return self.__html__()

class CustomRichTextWithFootnotesBlock(RichTextWithFootnotesBlock):
    def to_python(self, value):
        if isinstance(value, RichTextBlockValue):
            return value
        return RichTextBlockValue(self, value)

    def render(self, value, context=None):
        if isinstance(value, RichTextBlockValue):
            value = value.value
        return super().render(value, context=context)

With these changes, as long as I use {% include_block %} in all StructBlock templates, the footnotes are replaced successfully, wherever they are used:
{% load wagtailcore_tags %}
{% include_block value.caption %}

I just realised that there is a simpler way to get RichTextWithFootnotesBlock.replace_footnote_tags() to run for StructBlock sub-blocks, which does not require customisation of the return value:
{% load wagtailcore_tags %}
{% include_block value.bound_blocks.caption %}

With this, {% include_block %} has access to the block AND value, and can use the former to render the latter.

Interesting, I do think that it'd be great if we could standardise the RichTextWithFootnotesBlock so that you don't need to be aware of these different uses.
Personally, after an initial skim of your suggestion, I quite like the idea of creating aRichTextBlockValue as it sounds like it makes the Block function more like the existing Blocks.

Personally, after an initial skim of your suggestion, I quite like the idea of creating a RichTextBlockValue as it sounds like it makes the Block function more like the existing Blocks.

One downside of this approach is that {{ value.caption|richtext }} raises an exception (because richtext expects a str or RichText value only), whereas the {% include_block value.bound_blocks.caption %} solution just works (the 'bound blocks' trick is mentioned in the wagtail docs here, but it's quite easy to miss)

I was bitten by this the other day.

the 'bound blocks' trick is mentioned in the wagtail docs here, but it's quite easy to miss

Agreed. I'm not sure if I had read that specific section of the docs before but if I did, I completely forgot about it. I eventually stumbled upon them and was able to solve my issue by using bound_blocks. At any rate, is the only viable solution simply to document the StructBlock gotcha here as well? If so, I can work up a PR to update the docs. Let me know. Thanks!


fix: dump data with batch inserts

What kind of change does this PR introduce?
Bug fix https://github.com/supabase/cli/issues/1183
What is the current behavior?
Data only dump only generates single column inserts which is extremely slow to restore
What is the new behavior?

uses --rows-per-insert to batch dump 100k records

Additional context
Tested locally with a million records
$ psql --single-transaction --variable ON_ERROR_STOP=1  -f supabase/seed.sql
2.02s user 0.63s system 15% cpu 16.957 total

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 7 (0.0%)  changed or added relevant lines in 1 file are covered.
7 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.1%) to 62.145%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

internal/db/dump/dump.go
0
7
0.0%

Files with Coverage Reduction
New Missed Lines
%

internal/gen/keys/keys.go
7
7.94%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
4590

Relevant Lines:
7386

💛  - Coveralls


py3: fix iterkeys() and exception.message

d.iterkeys() should be iter(d) instead of iter(d.keys()) so it doesn't return
a whole list but only the iterators.
exception.message doesn't exits in Python3

Nice :)


Commit 470f5912 breaks build on M1 mac

After the commit 470f5912, I get this error message when building libtheora:
building libtheora - version 1.1.1
=======================
Downloading https://ftp.osuosl.org/pub/xiph/releases/theora/libtheora-1.1.1.tar.gz as libtheora-1.1.1.tar.gz
... Done
Extracted libtheora-1.1.1.tar.gz
$ ./configure --prefix=/Users/jeff/ffmpeg-build-script/workspace --with-ogg-libraries=/Users/jeff/ffmpeg-build-script/workspace/lib --with-ogg-includes=/Users/jeff/ffmpeg-build-script/workspace/include/ --with-vorbis-libraries=/Users/jeff/ffmpeg-build-script/workspace/lib --with-vorbis-includes=/Users/jeff/ffmpeg-build-script/workspace/include/ --enable-static --disable-shared --disable-oggtest --disable-vorbistest --disable-examples --disable-asm --disable-spec
checking build system type... Invalid configuration `aarch64-apple-darwin21.4.0': machine `aarch64-apple' not recognized
configure: error: /bin/sh ./config.sub aarch64-apple-darwin21.4.0 failed

Failed to Execute ./configure --prefix=/Users/jeff/ffmpeg-build-script/workspace --with-ogg-libraries=/Users/jeff/ffmpeg-build-script/workspace/lib --with-ogg-includes=/Users/jeff/ffmpeg-build-script/workspace/include/ --with-vorbis-libraries=/Users/jeff/ffmpeg-build-script/workspace/lib --with-vorbis-includes=/Users/jeff/ffmpeg-build-script/workspace/include/ --enable-static --disable-shared --disable-oggtest --disable-vorbistest --disable-examples --disable-asm --disable-spec

The config.guess that comes with the libtheora returns arm-apple-darwin21.4.0, while the gcc one returns aarch64-apple-darwin21.4.0. The libtheira configure script, however, rejects the name aarch64.

A workaround is to comment the lines of the incriminated commit.

Sorry, which lines did you comment out?

The lines of commit https://github.com/markus-perl/ffmpeg-build-script/commit/470f591269cd31514af40e2ef30db43fbb13d168 at the top of the page.


Mobile onclick

Clicking buttons on mobile such as the contact me, or theme switcher outline the entire containing div in blue instead of only the button.

Added -webkit-tap-highlight-color: transparent; to css to remove onClick background.


schema initialization script fails

Using version 0.2:

Create a database and user:

aslund,[~],17:07(0)$ sudo -u postgres /usr/bin/createuser -S -D -R accreq

aslund,[~],17:07(0)$ sudo -u postgres /usr/bin/psql -c "\\password accreq"
Enter new password:
Enter it again:

aslund,[~],17:07(0)$ /usr/bin/sudo -u postgres /usr/bin/createdb accreq

aslund,[~],17:07(0)$

Run the insertion script:

aslund,[~],17:07(0)$ psql -U accreq -h localhost accreq -f /usr/share/geni-ar/db/postgresql/schema.sql
SET
SET
DROP TABLE
psql:/usr/share/geni-ar/db/postgresql/schema.sql:30: ERROR:  syntax error at or near "at"
LINE 13:   request_ts timestamp DEFAULT NOW() at time zone 'utc',
                                              ^
aslund,[~],17:08(3)$

Imported from trac ticket #27,  created by chaos on 09-11-2013 at 17:09, last modified: 09-13-2013 at 16:07

See http://stackoverflow.com/questions/16609724/using-current-time-in-utc-as-default-value-in-postgresql
I think what's there needs parentheses. Obviously it also needs to be tested.
Trac comment by tmitchel (github user: tcmitchell) on 09-11-2013 at 17:24

I added the change to utc timestamps after the table was created.  The default works when I insert new entries into the db.  I didn't create the new table with the commands you're using (I'm new to database creation, sorry!).  I logged into the database and manually created the new table, then manually changed the column to default to utc. But I will make some dummy schemas (with utc timestamps) and test database creation using the above commands to debug this.
Trac comment by phelinek on 09-11-2013 at 17:49

Adding the parenthesis fixed the problem.
Trac comment by phelinek on 09-12-2013 at 10:50

Looks good for me now too:
aslund,[~],13:32(0)$ psql -U accreq -h localhost accreq -f /usr/share/geni-ar/db/postgresql/schema.sql
SET
SET
DROP TABLE
CREATE TABLE
DROP TABLE
CREATE TABLE
aslund,[~],13:32(0)$

Trac comment by chaos on 09-13-2013 at 13:32


Bots not spawning in

All of sudden my script keeps saying. Connected! then right when it connects it disconnects them. Its probably because of the new update. I made it so now it connects 3 clients per proxy now. Also facebook is broken, but you are probably aware of that

I found one of my old scripts that used to work. http://pastebin.com/1S8LEtAb

Tested examples/basic.js for hour, works fine.
Tested examples/auth_token.js - generates valid tokens.
Tested examples/basic.js with token, spawning bigger mass than without key.
So agario-client is fine, don't see any problems there.

@pulviscriptor If he is saying what I think he his saying, I'm having the same problem, I connect to Agar.IO on a browser and I can't connect my bot

@pulviscriptor  I am sooo stupid. Just fixed my script

@thegreat1200
Do examples works for you?

http://grantsommer.com/pictures/error.png

@thegreat1200
Are you trying to connect to one IP using key from another? You can't do that.
You need to use IP and key received from servers.getFFAServer

@pulviscriptor How would I get the key from an IP?

@thegreat1200
You can't need to request FFA servers from region until you get that same IP and then connect there and check if there are same leaders as on the server that you searching for.
But if you will do that too fast, you will get banned.
Also key must be requested from same IP that you will be connecting from.

@pulviscriptor
I don't want to disrespect you, you made an awesome script but the solution you are telling him is verry inconvenient.
@thegreat1200
If you requested an ffa server from you nodejs script you can get the key from the functiom argument with serv.key as seen on https://github.com/pulviscriptor/agario-client/blob/master/examples/basic.js
But if you did manage to get an ip from agar.io with your browser as far as i know its difficult to get the key.
But if it is an party the key is the party hashtag without '#'

@issy123
My experiments shows that you can not use one key twice.
You can replace createPartyServer to getFFAServer in line 141
And only one bot will be able to connect.
But if you are able to connect to FFA server multiple times using one key, i think you found some bug in agar.


Dark Mode Button

The Dark Mode Button is not Working please assign it to me.

I would like to work on the issue the Dark mode toggle button in not functioning u can assign me the issue


ZoomBox doesnt initiate correctly if DemoApp is used as UserControl

I am trying to implement the DemoApp as UserControl inside a Canvas of my Main Application.
Therefore, changed the Project properties of the DemoApp to build an UserControl-library. Copied all the xaml and c# code into an UserControl and then build the Project.
When building the library, the Zoombox does not have any dimensions.
See pic 1. Left as where pic 1 right displays the default project settings (build an WPF-app).

In my main Project I can implement this "DemoApp - UserControl" and get the Toolbar to show.
If the DiagrammControl gets enabled in the "DemoApp -UserControl" the Zoombox doesn't seem to initialize with  "scaleTransform" and "zoomThumb".
I did not rewrite any of the Window1ViewModell-Code so if there are any parameters to change let me know.

Turns out you DO need the Resource Dictionary in the MainWindows Application file, of course changing the resourcepath to the now new dll path


[Event Request] report 5405 "Calc. Consumption" - OnAfterCreateItemJournalLine

We would like to add a new event OnAfterCreateItemJournalLine in the following procedure:
local procedure CreateConsumpJnlLine(LocationCode: Code[10]; BinCode: Code[20]; QtyToPost: Decimal)

.
.
.
if Item."Item Tracking Code" <> '' then
AssignItemTracking("Prod. Order Component", ItemJnlLine);
OnAfterCreateItemJournalLine(ItemJnlLine, NextConsumpJnlLineNo); //A200F0000.Event
end;
Event signature:
[IntegrationEvent(false, false)]
local procedure OnAfterCreateItemJournalLine(var ItemJournalLine: Record "Item Journal Line"; var NextLineNo: Integer)
begin
//A200F0000.Event
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Unit tests for RedisCache

Description

Unit tests for RedisCache
Interface for Redis storage is mocked, of course

Type of change

[ ] Refactor
[ ] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library
[x] Unit tests

Related Tickets & Documents

Related Issue #OLS-83

Checklist before requesting a review

[x] I have performed a self-review of my code.
[x] PR has passed all pre-merge test jobs.
[ ] If it is a core feature, I have added thorough tests.

Testing

make test-unit as usual should display 100% code coverage for RedisCache

Is it mock or fake?:P

Is it mock or fake?:P

it's class with logic. Fakes are usually just encapsulated static data.

I thought the difference is that fake is working re-implementations, while mock is using the actual object and just overrides/mocks relevant functionality (like setting self.redis_client = {} more or less).
But that might be a topic for some different time, so /lgtm
Btw it's dumb that you can't create a thread on standard comments here (just on review comments).

/lgtm
/approve


[Q] "None" was logged when wandb.sweep using pytorch_lightning

Hi, I'm training my model using pytorch_lightning frame. Everything is fine when training but when I use wandb.sweep I found that "None"s were logged for all my "train/*" metrics.
So would we only log the metric in the sweep config?

Hi, I'm training my model using pytorch_lightning frame. Everything is fine when training but when I use wandb.sweep I found that "None"s were logged for all my "train/*" metrics.
So would we only log the metric in the sweep config?

Sadly I found that my goal metric was logged as "None" either...

I have no idea what is going on, anybody can help me?

Hi there! May I start by asking what version of wandb you are using?

Hi there! May I start by asking what version of wandb you are using?

Hi, thank you for reply.
Version of wandb is 0.17.2. I finally found that I made a mistake, that it's "NaN" rather than "None".
"NaN" was produced because bugs in my metrics calculate functions. So this issus was closed as bugs have been fixed.


Rebuild gh-pages from OCIO 1.1.1

The 1.1.1 release didn't deploy the updated docs to gh-pages because the current Travis build only builds the PDF docs. This PR updates gh-pages from my local build of the html docs.

@scoopxyz , do you mind taking a look at this since you have done previous gh-pages deployments?


Having some trouble with posting data

Hey, so I am trying to upload a file but am kind of confused how I will go about it, so I have
b2.uploadFile({
     uploadUrl: 'my url is here',
     uploadAuthToken: 'my token is here',
)}

Now, how do I go about uploading a file, because the only other param I see is fileName, and not like a specific file or path where I can get the image and upload it, because I have an api and want to post the uploaded users image to backblaze,
So, Example for uploading an image from a canvas #17 kind of helped me, but it's just upload buffer, and I am unable to view it, just shows a black box.

Sorry your question isn't too clear to me... You should just be able to pass your user's image as a Buffer via data? What part isn't working?


Arduino lib no more resolved after update to v2

Hi there!
I just updated platformio to the brand new v2 (thanks for this release!) and tried the cool init --ide eclipse feature.
But it appears that libs such as avr/io.h or stdlib.h (included in Arduino.h) are no more resovled by eclipse (even after clean / rebuild), resulting in build error in the IDE whereas CLI build is running well.
See following picture:

I zipped the project if you want to test by yourself. Maybe I've done things the wrong way, please tell me.
Cheers,
Nicolas

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/17654323-arduino-lib-no-more-resolved-after-update-to-v2?utm_campaign=plugin&utm_content=tracker%2F2014790&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F2014790&utm_medium=issues&utm_source=github).

I know it, thanks. Please add __AVR_ATmega328__ symbol.

More details here http://www.ikravets.com/wp-content/uploads/2014/06/eclipse_setup_project_symbols.png
P.S: I'll fix it tomorrow.

As usual, thanks for your quick answer @ivankravets :)
It seems this is not enough to fix the issue, even after clean/rebuild the project from ide and from CLI, plus restarted eclipse.

I also re-checked your blog post and it seems a directory was also missing: ${HOME}/.platformio/packages/toolchain-atmelavr/avr/include. So I added it to all languages and, and it fixed the issue!

As usual, thanks for your quick answer @ivankravets :)

Thank you too for the report and retweets!!! :+1:

I also re-checked your blog post and it seems a directory was also missing: ${HOME}/.platformio/packages/toolchain-atmelavr/avr/include. So I added it to all languages and, and it fixed the issue!

This issue was fixed in #210

Please add AVR_ATmega328 symbol.

This symbol is required for Serial and etc lib. Basing on MCU framework detects how much UARTs device has. I'll fix it in 2.0.1 release.


Allow response type to be determined at runtime

Partial revert of #294 to address providers (Facebook) that changed response type between API versions.
Refs thephpleague/oauth2-facebook#2.
cc @SammyK

:+1: Love it. :)

Looks great. Thanks!


Don't suggest StringBuilder for consts

The following will generate a suggestion for StringBuilder, however that is not possible and is also a compile time constant:
const string templateName = (nameof(Account) + "." +  nameof(Login));

Thanks, indeed this is a bug.


Uncaught TypeError: this.getRegexForProperty is not a function

when ever I am trying to press any key and error is popping with the title Uncaught TypeError: this.getRegexForProperty is not a function
can anyone help me here

I disable the package too but still getting this error I have the<EMAIL_ADDRESS>version of his package


APT whitelist request for mmdv-bin

Here's the issue for adding the source: travis-ci/apt-source-whitelist#146.


Use HTML-to-image to generate story poster image

Feature Description
The HTML-to-image library, is already used in a number of places in the web stories editor. The library is used to convert rendered html to a image. Web stories, require a poster image for them to be a valid web story. There is currently a check list item to reminder users to upload a poster asset. Poster asset are required to be of a size.
We could add the option to automatically generate a poster image from the first page of the web story. Similar to how we generate poster images from videos.
Alternatives Considered

Additional Context

Citing the Slack conversation here for completeness:

Just taking a screenshot of the first page as-is is not something we want to do because of content quality issues.
The first page of the story (the “cover page”) is not the same as the poster image and will look very different. See https://www.youtube.com/watch?v=nKi1QWPwZng
We could offer users some simple image editor to create the poster image and we'd save them for them
It would be nice to find a good solution so that creators have one less thing to do / worry about

This PR contain logic to generate a image from a story page https://github.com/google/web-stories-wp/pull/9700