added text label

Added a label in the middle of the progress arc to show a label, like a progress percentage or anything else that might be relative to the progression.
I don't know if you might find this useful for this component, but I needed it and I thought it might be useful to others as well.
I'm using it like in the following snippet:
<progress-arc ng-if="picture.file" label="picture.file.percentage | empty:'0%'" complete="picture.file.progress" counter-clockwise="true" background="#eee" class="progress-arc"></progress-arc>

Where picture.file.percentage and picture.file.progress get both updated during the upload and the empty filter just pushes the '0%' string until the first upload progress occurs.

I thought adding other attributes to the element for styling wouldn't have been much valuable so I thought label styling can be performed through css with
progress-arc#label {
   fill: #000; // label color
   font-size: 1em; // label size
}

Yeah that seems like a good addition; I think it might have even been requested before.  I'll pull down your changes and have a play with them before merging.  Thanks.

Need this pull request soon. :+1:  Awesome one

Happy to contribute back ;)
On Fri, Jun 19, 2015 at 9:06 AM, Malindu Warapitiya <
<EMAIL_ADDRESS>wrote:

Need this pull request soon. [image: :+1:] Awesome one
—
Reply to this email directly or view it on GitHub
https://github.com/mathewbyrne/angular-progress-arc/pull/13#issuecomment-113402083
.

Ok, I've grabbed your changes and made a few more in be3432d66f457954882fbb98f4048f1b3229255e
These include:

I've made the label attribute a static value rather than an expression as I think it fits a bit better.  You can still make it a binding if you want it to be dynamic (see example/index.html).

As with the other pull request I've changed the id for the label to a class with a prefix to avoid name collisions.

Because of #2 the ng-if isn't really required anymore, so it's been removed.  The text element will remain if there isn't a label attribute but I don't think this will be a huge issue.

I used dominant-baseline="central" instead of dy=".3em" since it's more in-line with the spec.  I believe you might have done this for IE9 support?  I'm probably cool to think about dropping IE9 support, but I could go either way on this one.

Let me know if you have any major reservations about these changes, otherwise I'll merge it all in, update the documentation and put out a new version with this feature.
Cheers.

Since I'm using the label to display the progress percentage I'm ok with
them all. With regards to point 4 I personally need IE9, but wasn't aware
of the dominant-baseline attribute at all so i didn't test it specifically,
I just used what appeared to solve the positioning problem. If you know the
former is not liked by IE9 please leave it as dy as that would mean I can
use the official version instead of having my own.
Thanks for the feedback!
On Mon, Jun 29, 2015 at 4:13 AM, Mathew Byrne<EMAIL_ADDRESS>wrote:

Ok, I've grabbed your changes and made a few more in be3432d
https://github.com/mathewbyrne/angular-progress-arc/commit/be3432d66f457954882fbb98f4048f1b3229255e
These include:

I've made the label attribute a static value rather than an expression
as I think it fits a bit better. You can still make it a binding if you
want it to be dynamic (see example/index.html).
2.
As with the other pull request I've changed the id for the label to a
class with a prefix to avoid name collisions.
3.
Because of #2
https://github.com/mathewbyrne/angular-progress-arc/issues/2 the
ng-if isn't really required anymore, so it's been removed. The text element
will remain if there isn't a label attribute but I don't think this will be
a huge issue.
4.
I used dominant-baseline="central" instead of dy=".3em" since it's
more in-line with the spec. I believe you might have done this for IE9
support? I'm probably cool to think about dropping IE9 support, but I could
go either way on this one.
Let me know if you have any major reservations about these changes,
otherwise I'll merge it all in, update the documentation and put out a new
version with this feature.
Cheers.
—
Reply to this email directly or view it on GitHub
https://github.com/mathewbyrne/angular-progress-arc/pull/13#issuecomment-116382761
.


Connection Pooling Timeouts

Please first make sure you have looked at:

Documentation: https://github.com/mkleehammer/pyodbc/wiki
Other issues

Environment
To diagnose, we usually need to know the following, including version numbers.  On Windows, be
sure to specify 32-bit Python or 64-bit:

Python: 3.7+
pyodbc: 4.028
OS: SLES 12
DB: Oracle 12
driver: UnixOCBC 2.3.0

Issue
When connection pooling has been up for some time, the connections fail when reused due to timeout. We're using this connection for an API, so this kills us. Haha
I am currently gathering further information regarding timeout timing. The messages are of the form:
pyodbc.Error: ('HY000', '[HY000] [Oracle][ODBC][Ora]ORA-02396: exceeded maximum idle time, please connect again\n\x00\x00\x00\x00\x00軷뢞⪪\x00ﾐ嘰啕\x00\x00\x00\x00\x00\x00\x00\x00\x00橃嘻啕\x00\x7f\x00\x00\x00橃嘻啕\x00槈嘻啕\x00\x00\x00\x00\x00䕄䕌䕔彄䱆䝁䕙\x00Ԡ嘱啕\x00`\x00\x00\x00¨\x00\x00\x00Ԡ嘱啕\x00\u0e98졠⪪\x00剈嘻啕\x00⨸嘻啕\x00Ԡ嘱 (2396) (SQLExecDirectW)')
The extra chars as I now know are an Oracle driver issue.
I'm pretty new to a lot of this, so I apologize in advance if this is just a simple setting misconfiguration. I will update as I investigate further.
Thank you!

UnixOCBC 2.3.0

First off, upgrade unixODBC to the latest version (currently 2.3.7). There have been a lot of bugs fixed in the last 10 years since 2.3.0 was released.

Hey, I just updated to 2.3.7. I actually compiled it up last night. : )
The only real difference here is that the error message has changed.

pyodbc.Error: ('HY000', '[HY000] [Oracle][ODBC][Ora]ORA-01012: not logged on\nProcess ID: 46901\nSession ID: 1643 Serial number: 56900\n\x00\uf014翿 ...extraneous junk... \uf58e翿\x00 (1012) (SQLEndTran)')

Here's the basic structure of my test.
async def run():
    await tesdb().connect()
    tasks = [tesdb().fetch_all('select 1 from dual') for _ in range(20)]
    res = await asyncio.gather(*tasks)
    print(res)
    await asyncio.sleep(60*30)
    tasks = [tesdb().fetch_all('select 1 from dual') for _ in range(20)]
    res = await asyncio.gather(*tasks)
    print(res)
    await tesdb().disconnect()

Basically connect and run 20 dumb queries on my pool of 2->5 connections. Wait 30 minutes (unfortunately, sometimes even 12 minutes doesn't really do it here as sometimes the connection is still alive.) then run again.
I also found that our DB timeout is 10 minutes, and it is set by the DBA. We only have read access to this DB, so our only option is a keepalive mechanism of some sort. I assumed that PyODBC would handle this automagically, but the more I investigate, I see this may be on us--which is fine, but I would appreciate some guidance.
For instance, I don't know how to best check if a connection has timed out.
If the only way to do so is to try and catch timeouts, then I would love a more specific error so I don't catch all PyODBC.Errors.
Thanks again!

Oh, also I've moved to 4.30. : )


Aligned spin model

Looks good on my end. I have added the hash for the h5 file. Remaining tasks:

uploading h5 file to zenodo.
after that, uncommenting L100 to L104 here: https://github.com/KateRink/BHPTNRSurrogate/blob/2D/surrogates/model_utils/load_surrogates.py#L100


[BUG] TypeError: 'dict' object is not callable when compiling a function that takes a model

I'm trying to get the gradient of a model's input and then compile this. It seems to work with just the gradient, but when I compile it says "TypeError: 'dict' object is not callable". If I close over the model it works:
import time
import mlx.nn as nn
import mlx.core as mx

model = nn.Transformer(dims=256, num_heads=4, num_encoder_layers=4, num_decoder_layers=4, mlp_dims=1024, dropout=0.0, norm_first=False)
context = mx.random.normal((1, 256, 256))
torques = mx.random.normal((1, 256, 256))
target = mx.random.normal((1, 256, 256))

def capture(torques, context, target):
    src_mask = mx.ones(256)
    tgt_mask = mx.ones(256)
    memory_mask = mx.ones(256)
    return (model(context, torques, src_mask, tgt_mask, memory_mask) - target).square().mean()

g_torques = mx.grad(capture, argnums=0)
tic = time.time()
g_torques(torques, context, target)
toc = time.time()
print(f"Time taken: {toc - tic} seconds")

tic = time.time()
c_torques = mx.compile(g_torques)
c_torques(torques, context, target)
toc = time.time()
print(f"Time taken: {toc - tic} seconds")

tic = time.time()
c_torques(torques, context, target)
toc = time.time()
print(f"Time taken: {toc - tic} seconds")

def no_capture(torques, model, context, target):
    src_mask = mx.ones(256)
    tgt_mask = mx.ones(256)
    memory_mask = mx.ones(256)
    return (model(context, torques, src_mask, tgt_mask, memory_mask) - target).square().mean()

g_torques = mx.grad(no_capture, argnums=0)
tic = time.time()
g_torques(torques, model, context, target)
toc = time.time()
print(f"Time taken: {toc - tic} seconds")

tic = time.time()
c_torques = mx.compile(g_torques)
c_torques(torques, model, context, target) # <- TypeError: 'dict' object is not callable
toc = time.time()
print(f"Time taken: {toc - tic} seconds")

tic = time.time()
c_torques = mx.compile(g_torques)
c_torques(torques, model, context, target)
toc = time.time()
print(f"Time taken: {toc - tic} seconds")

It's quite un-obvious what's going wrong or if closing over the model like I'm doing is actually the right thing to do.

After talking to @angeloskath I think the right thing to do is call compile as c_torques = mx.compile(g_torques, inputs=[model]). Not doing that makes the model params fixed, whereas doing this lets me update them.

Also model.state is going to be the more future-proof option as we 'll likely change that behavior so model doesn't extend dictionary and isn't confused with a dictionary of parameters which is overwritten when calling compile. Currently model.state simply returns model so what you wrote above is identical.
Meaning
c_torques = mx.compile(g_torques, inputs=[model.state])


Without class name fork

Avoided serialization of class name for all , except for embedded objects.
Serialization API slightly changed and now is up to user to provide info whether to serialize / deserialize class name or not.
Serialization / Deserialization of class name, for embedded documents, is turned on in serializeValue() and deserializeValue() methods.
New functionality is implemented in ORecordSerializerBinaryV1 class

@markodjurovic could you please do a micro benchmark measuring with this fix how much speed we have gained (if any) and how much space we saved?
@tglman WDYT? We are in time to merge this for v3.0.


Using multiple labels in helpers.nodePattern()

At this moment there seems to be no way to add multiple labels to a nodePattern since they are escaped. Maybe allow array and concatenate escaped labels?

Hello @anton-em. I thought this was impossible to do with cypher? I thought only edges predicates could have multiple options. Let me check the syntax again and add a way to pass multiple labels by using an array if Cypher supports it.


Add ShowOpenFileDialog

Add simple abstraction for OpenFileDialog on IDialogFacade
Sometimes one also has to open files!

Yes, opening files is a useful task on occasion!


Add README translation for Spanish

Hi @JakeRoggenbuck,
Question: Did you translate the Readme by hand or did you use a tool? Your translation seems identical to the one I got with Google translate.

Yea, usually when I do translations, I use google translate for the first pass and then review and correct it manually. Surprisingly, google translate got everything correct. I checked with someone else who also agreed that it was correct, so it was unchanged. I could write it up manually if that would be better.

Thanks for all your reviews, @practicatto! Have you finished reviewing, or are there more suggestions you would like to leave?

Yea, thanks for the reviews!

I don't have more suggestions
I'm glad I could help c:


Set up instructions in README.md were not right for me

Ubuntu 14.04 LTS / x86.

i had to run "cabal configure" again after "cabal install --only-dependencies" -- at least the thing told me to do that which is nice, but it feels bad that it doesn't match the instructions. is this out of date across all system types or just mine?
when i finally run-elm-website it spews out "you may need to install it with: elm-get install johnpmayer/elm-webgl 0.1" like 6 or 7 times. and the kicker is when i do that command, i'm told "elm-get: command not found" :-(

So I also think the mish-mash of all the different ways to get elm tools is not very unified and clear and easy and helpful for newbies.
e.g. i tried "elm-package install elm-get" and that didn't work
so then i tried this and got a real WTF?!
$ cabal install elm-get
Resolving dependencies...
In order, the following would be installed:
publicsuffixlist-0.1 (new package)
http-client-<IP_ADDRESS> (new version)
http-client-tls-0.2.2 (reinstall) changes: http-client-<IP_ADDRESS> -> <IP_ADDRESS>
elm-get-0.1.3 (new package)
cabal: The following packages are likely to be broken by the reinstalls:
elm-package-0.5
Use --force-reinstalls if you want to install anyway.

It sounds like your configuration is really freaky. It sounds like you might be in this scenario.
Are you new to using Haskell? Are you using cabal sandboxes when you run cabal install? If that question makes no sense, that's totally fine. cabal things are pretty crazy.
The best route will probably be to run this fubar.sh script that'll clear all cabal packages on your system. It looks like you have a lot of conflicting packages. This is called "cabal hell" and it was a pretty bad problem in Haskell recently because cabal defaulted to global installs for everything. This meant different projects needed to sync up which was bad. "cabal sandboxes" are meant to keep all the dependencies separate. One thing to keep in mind is that even if you run cabal install cabal-install the actually binary on your PATH may not be the new version. I have been bitten by that before.
Finally, I updated the readme for 0.15 so I'm going to close this for now hoping that things are better. If things mess up again, can you post the transcript of what happened on the command line? What exact commands did you run? What version of cabal do you have? What version of GHC are you using? How did you install that? etc.


Build virtualenv with python2.7

Resolves #14

Codecov Report

Merging #15 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #15   +/-   ##
=======================================
  Coverage   99.71%   99.71%
=======================================
  Files          10       10
  Lines         353      353
=======================================
  Hits          352      352
  Misses          1        1

Continue to review full report at Codecov.

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

@cognifloyd would also be interested in a patch that makes this compatible with python 3.0
Let me know if you're interested in working on that.


End Portal Spawnpoint Glitch

Hey there.
We've observed a bug on our server.
When a player tries to leave the end dimension while having no spawnpoint set, it just puts them back to the world_the_end's worldspawn showing this default minecraft message.

One of our admins made a small video showcasing the glitch: https://streamable.com/pd64u Her computer and internet isn't the best but we would like to get this fixed as soon as possible.
If any of the server files are needed we're more than happy to show them.

Thanks to @blubberdiblub#1541 on discord now we know how to fix it. We just had to set the world world to respawnworld! Thank you very much for the help if you see this.


utf8 support for asset strings

Summary
If asset strings contain non-printable characters they are stored in a byte array.
Return -b64 asset strings in most endpoints.
Test Plan
New unit test

Codecov Report

Merging #577 (d0bef76) into develop (d45623b) will increase coverage by 3.29%.
The diff coverage is 53.93%.

@@             Coverage Diff             @@
##           develop     #577      +/-   ##
===========================================
+ Coverage    43.80%   47.10%   +3.29%
===========================================
  Files           24       24
  Lines         3801     3849      +48
===========================================
+ Hits          1665     1813     +148
+ Misses        1873     1759     -114
- Partials       263      277      +14

Impacted Files
Coverage Δ

api/handlers.go
3.91% <0.00%> (+0.10%)
:arrow_up:

types/types.go
0.00% <0.00%> (ø)

idb/postgres/internal/encoding/encode.go
52.45% <15.62%> (-40.65%)
:arrow_down:

api/converter_utils.go
86.15% <100.00%> (+0.12%)
:arrow_up:

idb/postgres/postgres.go
43.22% <100.00%> (+6.85%)
:arrow_up:

Continue to review full report at Codecov.

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

Looks good overall. Left some comments in the code. Could you also add tests in idb/postgres/internal/encoding similar to https://github.com/algorand/indexer/tree/tolik/acct-rewrite4/idb/postgres/internal/encoding?

LGTM. I will let @tsachiherman and @brianolson take a look as well.


UTS chat adapter

To run adapter locally:

cd to unified-test-suite-chat repo directory and run npm run start:dispatcher command
Run UTSChatAdapter target in Xcode
In another console for unified-test-suite-chat run tests: npm run start:test command

Most of it will fail with "Method not implemented". But I'm opening the PR since the generator and adapter code will not change much since this point.
Temporary fix is needed (see "DefaultMessages.swift" file changes) without which one of the history tests hangs, @umair-ably couldn't you take a look at it? You can run only messages tests passing test file name to the test command: npm run start:test messages.integration.test.ts

Summary by CodeRabbit
Release Notes

New Features

Introduced a ChatAdapter for managing chat operations and handling RPC calls.
Added a WebSocketWrapper class to manage WebSocket connections with automatic reconnection.
Implemented a ChatAdapterGenerator for generating Swift code based on a defined schema.
Added a NanoID class for generating unique identifiers.
Introduced a new package configuration for UTSChatAdapter.

Improvements

Enhanced error handling for the clientID property in the chat client.
Simplified message subscription logic for better performance.
Improved JSON handling and RPC communication through utility functions.

New Files

Added .gitignore and Package.resolved for the UTSChatAdapter project.
Introduced utility and schema files to support chat functionality and code generation.
Added main.swift files for both Adapter and Generator to streamline execution.
New GitHub Actions workflow for automated testing of the unified test suite.

@coderabbitai full review (ignore NanoID.swift file)

@coderabbitai remove all your posts where it's marked "Outdated"

@umair-ably @ttypic @lawrence-forooghian Now it's on the CI.

@coderabbitai pause

@coderabbitai resume


Force Close Issue

2023-05-16 16:28:33.380 TRACE [mutiny_core::node:1359] auto connected peer: 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:28:33.381 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:28:33.532 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:33.652 DEBUG [lightning::ln::peer_handler:1192] Finished noise handshake for connection with 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:28:33.653 TRACE [lightning::ln::peer_handler:1071] Enqueueing message Init { features: [34, 81, 10, 8, 0, 160, 8], remote_network_address: Some(IPv4 { addr: [44, 238, 235, 124], port: 9735 }) } to 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:28:33.654 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:33.654 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:28:33.654 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:28:33.654 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:28:33.654 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:28:33.805 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:33.808 INFO  [lightning::ln::peer_handler:1334] Received peer Init message from 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331: DataLossProtect: required, InitialRoutingSync: not supported, UpfrontShutdownScript: supported, GossipQueries: supported, VariableLengthOnion: supported, StaticRemoteKey: required, PaymentSecret: required, BasicMPP: supported, Wumbo: supported, AnchorsZeroFeeHtlcTx: supported, ShutdownAnySegwit: supported, OnionMessages: not supported, ChannelType: supported, SCIDPrivacy: supported, ZeroConf: not supported, unknown flags: supported
2023-05-16 16:28:33.808 DEBUG [lightning::ln::channelmanager:6563] Generating channel_reestablish events for 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:28:33.809 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:33.809 TRACE [mutiny_core::background:656] Persisting ChannelManager...
2023-05-16 16:28:33.809 TRACE [mutiny_core::background:656] Done persisting ChannelManager.
2023-05-16 16:28:36.510 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:36.513 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:36.514 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:36.517 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:36.517 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:36.517 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:36.517 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:36.518 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:36.518 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:36.520 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:36.520 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:36.527 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:37.344 TRACE [mutiny_core::socket:168] sending keep alive message to proxy
2023-05-16 16:28:37.344 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:28:37.344 TRACE [mutiny_core::socket:173] initiated keep alive message to proxy
2023-05-16 16:28:37.344 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:28:41.601 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:41.605 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:41.608 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:41.619 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:41.620 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:41.620 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:41.621 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:41.624 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:41.625 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:41.628 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:41.709 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:41.715 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:42.400 TRACE [mutiny_core::socket:168] sending keep alive message to proxy
2023-05-16 16:28:42.401 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:28:42.401 TRACE [mutiny_core::socket:173] initiated keep alive message to proxy
2023-05-16 16:28:42.402 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:28:42.535 TRACE [mutiny_core::background:656] Calling PeerManager's timer_tick_occurred
2023-05-16 16:28:42.538 TRACE [lightning::ln::peer_handler:1071] Enqueueing message Ping { ponglen: 0, byteslen: 64 } to 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:28:42.538 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:28:42.539 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:28:42.731 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:42.731 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:42.770 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:42.771 TRACE [lightning::ln::peer_handler:1381] Received message Pong(Pong { byteslen: 0 }) from 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:28:42.771 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:43.358 INFO  [mutiny_core::nodemanager:950] We are synced!
2023-05-16 16:28:43.366 DEBUG [mutiny_core::nodemanager:1556] fetching new bitcoin price
2023-05-16 16:28:46.499 INFO  [mutiny_core::nodemanager:940] Updated cached fees!
2023-05-16 16:28:46.499 INFO  [mutiny_core::esplora:220] Starting transaction sync.
2023-05-16 16:28:46.702 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:46.712 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:46.719 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:46.737 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:46.738 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:46.770 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:46.773 INFO  [mutiny_core::esplora:316] Finished transaction sync.
2023-05-16 16:28:47.424 TRACE [mutiny_core::socket:168] sending keep alive message to proxy
2023-05-16 16:28:47.424 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:28:47.424 TRACE [mutiny_core::socket:173] initiated keep alive message to proxy
2023-05-16 16:28:47.425 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:28:51.621 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:51.627 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:51.627 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:51.629 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:51.630 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:51.631 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:51.632 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:51.632 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:51.718 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:51.758 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:52.350 TRACE [mutiny_core::background:656] Persisting scorer
2023-05-16 16:28:52.352 TRACE [mutiny_core::background:656] Rebroadcasting monitor's pending claims
2023-05-16 16:28:52.457 TRACE [mutiny_core::socket:168] sending keep alive message to proxy
2023-05-16 16:28:52.457 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:28:52.457 TRACE [mutiny_core::socket:173] initiated keep alive message to proxy
2023-05-16 16:28:52.458 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:28:52.664 TRACE [mutiny_core::background:656] Calling PeerManager's timer_tick_occurred
2023-05-16 16:28:52.664 TRACE [lightning::ln::peer_handler:1071] Enqueueing message Ping { ponglen: 0, byteslen: 64 } to 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:28:52.664 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:28:52.665 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:28:52.872 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:52.873 TRACE [lightning::ln::peer_handler:1381] Received message Pong(Pong { byteslen: 0 }) from 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:28:52.873 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:56.630 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:56.635 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:56.638 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:56.658 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:56.662 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:28:56.668 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:28:57.500 TRACE [mutiny_core::socket:168] sending keep alive message to proxy
2023-05-16 16:28:57.500 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:28:57.500 TRACE [mutiny_core::socket:173] initiated keep alive message to proxy
2023-05-16 16:28:57.501 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:29:00.842 INFO  [mutiny_core::nodemanager:950] We are synced!
2023-05-16 16:29:00.844 DEBUG [mutiny_core::nodemanager:1529] got price from cache
2023-05-16 16:29:01.351 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:01.375 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:01.376 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:01.390 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:01.391 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:01.393 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:01.393 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:01.406 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:02.560 TRACE [mutiny_core::socket:168] sending keep alive message to proxy
2023-05-16 16:29:02.560 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:29:02.560 TRACE [mutiny_core::socket:173] initiated keep alive message to proxy
2023-05-16 16:29:02.560 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:29:02.872 TRACE [mutiny_core::background:656] Calling PeerManager's timer_tick_occurred
2023-05-16 16:29:02.872 TRACE [lightning::ln::peer_handler:1071] Enqueueing message Ping { ponglen: 0, byteslen: 64 } to 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:29:02.872 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:29:02.873 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:29:03.023 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:03.024 TRACE [lightning::ln::peer_handler:1381] Received message Pong(Pong { byteslen: 0 }) from 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:29:03.024 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:06.241 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:06.242 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:06.242 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:06.243 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:06.243 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:06.244 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:06.244 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:06.246 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:06.307 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:06.309 DEBUG [lightning::ln::peer_handler:1293] Error handling message from 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331; ignoring: Couldn't find channel for update
2023-05-16 16:29:06.317 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:07.576 TRACE [mutiny_core::socket:168] sending keep alive message to proxy
2023-05-16 16:29:07.576 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:29:07.576 TRACE [mutiny_core::socket:173] initiated keep alive message to proxy
2023-05-16 16:29:07.576 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:29:11.277 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:11.281 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:11.282 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:11.293 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:11.294 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:11.297 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:11.314 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:11.342 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:12.601 TRACE [mutiny_core::socket:168] sending keep alive message to proxy
2023-05-16 16:29:12.601 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:29:12.601 TRACE [mutiny_core::socket:173] initiated keep alive message to proxy
2023-05-16 16:29:12.602 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:29:13.191 TRACE [mutiny_core::background:656] Calling PeerManager's timer_tick_occurred
2023-05-16 16:29:13.192 TRACE [lightning::ln::peer_handler:1071] Enqueueing message Ping { ponglen: 0, byteslen: 64 } to 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:29:13.192 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:29:13.192 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:29:13.351 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:13.351 TRACE [lightning::ln::peer_handler:1381] Received message Pong(Pong { byteslen: 0 }) from 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:29:21.417 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:21.417 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:21.514 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:29:21.521 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:29:22.320 TRACE [mutiny_core::background:656] Calling ChannelManager's timer_tick_occurred
2023-05-16 16:29:22.337 TRACE [lightning::chain::chainmonitor:706] Updating ChannelMonitor for channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44
2023-05-16 16:29:22.337 INFO  [lightning::chain::channelmonitor:2328] Applying update to monitor 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44, bringing update_id from 80 to<PHONE_NUMBER>3709551615 with 1 changes.
2023-05-16 16:29:22.338 TRACE [lightning::chain::channelmonitor:2384] Updating ChannelMonitor: channel force closed, should broadcast: true
2023-05-16 16:29:22.338 ERROR [lightning::chain::channelmonitor:2447] Refusing Channel Monitor Update as counterparty attempted to update commitment after funding was spent
2023-05-16 16:29:22.339 ERROR [lightning::chain::chainmonitor:709] Failed to update ChannelMonitor for channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44.
2023-05-16 16:29:22.341 DEBUG [lightning::chain::chainmonitor:726] Persistence of ChannelMonitorUpdate for channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44 completed
2023-05-16 16:29:22.342 TRACE [mutiny_core::fees:130] Got fee rate from saved cache!
2023-05-16 16:29:22.344 TRACE [mutiny_core::background:656] Persisting ChannelManager...
2023-05-16 16:29:22.344 TRACE [mutiny_core::background:656] Done persisting ChannelManager.
2023-05-16 16:29:22.552 TRACE [mutiny_core::background:656] Persisting scorer
2023-05-16 16:29:22.552 TRACE [mutiny_core::background:656] Rebroadcasting monitor's pending claims
2023-05-16 16:29:22.672 TRACE [mutiny_core::socket:168] sending keep alive message to proxy
2023-05-16 16:29:22.673 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:29:22.673 TRACE [mutiny_core::socket:173] initiated keep alive message to proxy
2023-05-16 16:29:22.673 TRACE [mutiny_core::proxy:99] sent data down websocket

Doesn't give a force close reason, anyway we can get that?

LDK indicating that we have fallen behind:
2023-05-16 16:26:57.116 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:26:57.120 INFO  [lightning::ln::peer_handler:1334] Received peer Init message from 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331: DataLossProtect: required, InitialRoutingSync: not supported, UpfrontShutdownScript: supported, GossipQueries: supported, VariableLengthOnion: supported, StaticRemoteKey: required, PaymentSecret: required, BasicMPP: supported, Wumbo: supported, AnchorsZeroFeeHtlcTx: supported, ShutdownAnySegwit: supported, OnionMessages: not supported, ChannelType: supported, SCIDPrivacy: supported, ZeroConf: not supported, unknown flags: supported
2023-05-16 16:26:57.120 DEBUG [lightning::ln::channelmanager:6563] Generating channel_reestablish events for 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:26:57.121 TRACE [lightning::ln::channel:5656] Enough info to generate a Data Loss Protect with per_commitment_secret 6bbb5a9e391198a65a5cc08fecac33edc9a67c20a8df8bac995574cbee5798a3 for channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44
2023-05-16 16:26:57.122 TRACE [mutiny_core::socket:493] read event from the node
2023-05-16 16:26:57.122 DEBUG [lightning::ln::peer_handler:1801] Handling SendChannelReestablish event in peer_handler for node 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331 for channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44
2023-05-16 16:26:57.124 TRACE [lightning::ln::peer_handler:1071] Enqueueing message ChannelReestablish { channel_id: [16, 168, 62, 34, 209, 143, 133, 1, 186, 72, 213, 173, 123, 108, 148, 36, 198, 50, 194, 178, 246, 88, 252, 70, 25, 32, 174, 202, 185, 43, 254, 68], next_local_commitment_number: 29, next_remote_commitment_number: 28, data_loss_protect: Present(DataLossProtect { your_last_per_commitment_secret: [107, 187, 90, 158, 57, 17, 152, 166, 90, 92, 192, 143, 236, 172, 51, 237, 201, 166, 124, 32, 168, 223, 139, 172, 153, 85, 116, 203, 238, 87, 152, 163], my_current_per_commitment_point: PublicKey(02020202020202020202020202020202020202020202020202020202020202ffcee50f772e0a9972250d4b61b3e5beb95de897c73b4ed1cc35ed013accf1c840) }) } to 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:26:57.124 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:26:57.124 TRACE [mutiny_core::background:656] Persisting ChannelManager...
2023-05-16 16:26:57.125 TRACE [mutiny_core::background:656] Done persisting ChannelManager.
2023-05-16 16:26:57.126 TRACE [mutiny_core::proxy:99] sent data down websocket
2023-05-16 16:26:57.180 TRACE [mutiny_core::socket:488] received binary data from websocket
2023-05-16 16:26:57.184 TRACE [lightning::ln::peer_handler:1381] Received message ChannelReestablish(ChannelReestablish { channel_id: [16, 168, 62, 34, 209, 143, 133, 1, 186, 72, 213, 173, 123, 108, 148, 36, 198, 50, 194, 178, 246, 88, 252, 70, 25, 32, 174, 202, 185, 43, 254, 68], next_local_commitment_number: 33, next_remote_commitment_number: 32, data_loss_protect: Present(DataLossProtect { your_last_per_commitment_secret: [218, 76, 11, 240, 187, 189, 157, 208, 214, 144, 252, 93, 59, 140, 119, 129, 156, 95, 174, 136, 253, 228, 74, 144, 57, 86, 179, 26, 85, 138, 154, 203], my_current_per_commitment_point: PublicKey(6ba7f4180e6b9875514f25c44c51b5d4eb771b5366f600ef7cd7f8d001c0ba683cb077e04df0d63ea67c7b60916651b0447baba10f746aafa02487a513a9d074) }) }) from 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 16:26:57.188 ERROR [lightning::ln::channel:4061] We have fallen behind - we have received proof that if we broadcast our counterparty is going to claim all our funds.
This implies you have restarted with lost ChannelMonitor and ChannelManager state, the first of which is a violation of the LDK chain::Watch requirements.
More specifically, this means you have a bug in your implementation that can cause loss of funds, or you are running with an old backup, which is unsafe.
If you have restored from an old backup and wish to force-close channels and return to operation, you should start up, call
ChannelManager::force_close_without_broadcasting_txn on channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44 with counterparty 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331 or
ChannelManager::force_close_all_channels_without_broadcasting_txn, then reconnect to peer(s).
Note that due to a long-standing bug in lnd you may have to reach out to peers running lnd-based nodes to ask them to manually force-close channels
See https://github.com/lightningdevkit/rust-lightning/issues/1565 for more info.
2023-05-16 16:27:00.615 TRACE [mutiny_core::socket:168] sending keep alive message to proxy

And then some logs here indicating that the channel was detected on chain: https://mempool.space/tx/b446ada928a3098bf150a874dadb14cdbf7826472df2c4748ad2c92b9cb4a367
2023-05-16 16:28:22.144 TRACE [mutiny_core::background:656] Calling ChannelManager's timer_tick_occurred on startup
2023-05-16 16:28:22.146 TRACE [mutiny_core::fees:130] Got fee rate from saved cache!
2023-05-16 16:28:22.146 TRACE [lightning::ln::channelmanager:3743] Channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44 does not qualify for a feerate change from 7500 to 7500.
2023-05-16 16:28:22.147 TRACE [mutiny_core::background:656] Rebroadcasting monitor's pending claims on startup
2023-05-16 16:28:22.158 TRACE [mutiny_core::node:1150] setting up multi proxy socket
2023-05-16 16:28:23.079 INFO  [mutiny_core::nodemanager:940] Updated cached fees!
2023-05-16 16:28:23.081 INFO  [mutiny_core::esplora:220] Starting transaction sync.
2023-05-16 16:28:23.167 DEBUG [mutiny_core::proxy:74] connected to ws: wss://p.mutinywallet.com
2023-05-16 16:28:23.169 TRACE [mutiny_core::socket:179] connecting new multi websocket descriptor
2023-05-16 16:28:23.171 TRACE [mutiny_core::socket:241] spawning multi socket connection reader
2023-05-16 16:28:23.171 TRACE [mutiny_core::socket:286] spawning multi socket channel reader
2023-05-16 16:28:24.092 TRACE [lightning::ln::channelmanager:6076] New best block:<PHONE_NUMBER>0000000001c0496b3c51a841614d103180e307c1167ecdc3dc412c at height 790032
2023-05-16 16:28:24.095 TRACE [lightning::ln::channel:5526] Cannot create an announcement_signatures as our peer is disconnected
2023-05-16 16:28:24.104 DEBUG [lightning::chain::chainmonitor:612] New best block<PHONE_NUMBER>0000000001c0496b3c51a841614d103180e307c1167ecdc3dc412c at height 790032 provided via best_block_updated
2023-05-16 16:28:24.121 TRACE [lightning::chain::channelmonitor:3157] Processing 0 matched transactions for block at height 790032.
2023-05-16 16:28:24.121 DEBUG [lightning::chain::onchaintx:707] Updating claims view at height 790032 with 0 claim requests
2023-05-16 16:28:24.125 DEBUG [lightning::chain::onchaintx:820] Updating claims view at height 790032 with 0 matched transactions in block 790032
2023-05-16 16:28:24.126 TRACE [lightning::chain::onchaintx:955] Bumping 0 candidates
2023-05-16 16:28:24.126 TRACE [lightning::chain::chainmonitor:306] Syncing Channel Monitor for channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44
2023-05-16 16:28:24.128 TRACE [lightning::chain::chainmonitor:309] Finished syncing Channel Monitor for channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44
2023-05-16 16:28:24.136 TRACE [mutiny_core::background:656] Persisting ChannelManager...
2023-05-16 16:28:24.161 TRACE [mutiny_core::background:656] Done persisting ChannelManager.
2023-05-16 16:28:25.440 TRACE [lightning::ln::channelmanager:6057] 1 transactions included in block<PHONE_NUMBER>00000000030efc7359ad507c02aa857a4541fdeae9fb1cbe0caf05 at height 789615 provided
2023-05-16 16:28:25.441 TRACE [lightning::ln::channel:5526] Cannot create an announcement_signatures as our peer is disconnected
2023-05-16 16:28:25.498 DEBUG [lightning::chain::chainmonitor:596] 1 provided transactions confirmed at height 789615 in block<PHONE_NUMBER>00000000030efc7359ad507c02aa857a4541fdeae9fb1cbe0caf05
2023-05-16 16:28:25.501 TRACE [lightning::chain::channelmonitor:3157] Processing 0 matched transactions for block at height 789615.
2023-05-16 16:28:25.501 DEBUG [lightning::chain::onchaintx:707] Updating claims view at height 790032 with 0 claim requests
2023-05-16 16:28:25.501 DEBUG [lightning::chain::onchaintx:820] Updating claims view at height 790032 with 0 matched transactions in block 789615
2023-05-16 16:28:25.502 TRACE [lightning::chain::onchaintx:955] Bumping 0 candidates
2023-05-16 16:28:25.502 TRACE [lightning::chain::chainmonitor:306] Syncing Channel Monitor for channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44
2023-05-16 16:28:25.503 TRACE [lightning::chain::chainmonitor:309] Finished syncing Channel Monitor for channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44
2023-05-16 16:28:25.503 TRACE [lightning::ln::channelmanager:6057] 1 transactions included in block<PHONE_NUMBER>000000000435b064dfdef9c55534f6053c820d607ce56f27122403 at height 790031 provided
2023-05-16 16:28:25.503 INFO  [lightning::ln::channel:5156] Detected channel-closing tx b446ada928a3098bf150a874dadb14cdbf7826472df2c4748ad2c92b9cb4a367 spending 45fe2bb9caae201946fc58f6b2c232c624946c7badd548ba01858fd1223ea810:1, closing channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44
2023-05-16 16:28:25.505 DEBUG [lightning::ln::channelmanager:2136] Finishing force-closure of channel with 0 HTLCs to fail
2023-05-16 16:28:25.506 DEBUG [lightning::chain::chainmonitor:596] 1 provided transactions confirmed at height 790031 in block<PHONE_NUMBER>000000000435b064dfdef9c55534f6053c820d607ce56f27122403
2023-05-16 16:28:25.506 INFO  [lightning::chain::channelmonitor:3063] Channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44 closed by funding output spend in txid b446ada928a3098bf150a874dadb14cdbf7826472df2c4748ad2c92b9cb4a367.
2023-05-16 16:28:25.507 INFO  [lightning::chain::channelmonitor:3728] Received spendable output StaticPaymentOutput b446ada928a3098bf150a874dadb14cdbf7826472df2c4748ad2c92b9cb4a367:0 marked for spending, spendable at height 790036
2023-05-16 16:28:25.507 TRACE [lightning::chain::channelmonitor:3157] Processing 1 matched transactions for block at height 790031.
2023-05-16 16:28:25.507 DEBUG [lightning::chain::onchaintx:707] Updating claims view at height 790032 with 0 claim requests
2023-05-16 16:28:25.508 DEBUG [lightning::chain::onchaintx:820] Updating claims view at height 790032 with 1 matched transactions in block 790031
2023-05-16 16:28:25.508 TRACE [lightning::chain::onchaintx:955] Bumping 0 candidates
2023-05-16 16:28:25.508 TRACE [lightning::chain::chainmonitor:306] Syncing Channel Monitor for channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44
2023-05-16 16:28:25.510 TRACE [lightning::chain::chainmonitor:309] Finished syncing Channel Monitor for channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44
2023-05-16 16:28:25.510 INFO  [mutiny_core::esplora:316] Finished transaction sync.
2023-05-16 16:28:25.527 TRACE [mutiny_core::background:656] Persisting ChannelManager...
2023-05-16 16:28:25.538 TRACE [mutiny_core::background:656] Done persisting ChannelManager.
2023-05-16 16:28:25.541 DEBUG [mutiny_core::event:427] EVENT: Channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44 closed due to: CommitmentTxConfirmed
2023-05-16 16:28:25.542 TRACE [lightning::ln::peer_handler:1865] Handling SendErrorMessage HandleError event in peer_handler for node 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331 with message Channel closed because commitment or closing transaction was confirmed on chain.
2023-05-16 16:28:25.543 TRACE [mutiny_core::background:656] Persisting ChannelManager...
2023-05-16 16:28:25.543 TRACE [mutiny_core::background:656] Done persisting ChannelManager.
2023-05-16 16:28:27.193 TRACE [mutiny_core::socket:168] sending keep alive message to proxy
2023-05-16 16:28:27.195 TRACE [mutiny_core::proxy:88] initiating sending down websocket
2023-05-16 16:28:27.195 TRACE [mutiny_core::socket:173] initiated keep alive message to proxy
2023-05-16 16:28:27.200 TRACE [mutiny_core::proxy:99] sent data down websocket

A thing to keep in mind is that there could be up to 5s of logs that are not persisted to disk.

Here's the eventual sweep back into my on chain wallet:
2023-05-16 17:26:40.502 TRACE [lightning::ln::peer_handler:1972] Handling disconnection of peer 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331
2023-05-16 17:26:40.502 DEBUG [lightning::ln::channelmanager:6460] Marking channels with 026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331 disconnected and generating channel_updates.
2023-05-16 17:26:40.503 TRACE [mutiny_core::socket:532] WebSocket Closed
2023-05-16 17:26:40.503 DEBUG [mutiny_core::proxy:114] closed websocket
2023-05-16 17:26:40.504 TRACE [mutiny_core::background:656] Persisting ChannelManager...
2023-05-16 17:26:40.504 TRACE [mutiny_core::background:656] Done persisting ChannelManager.
2023-05-16 17:26:40.504 TRACE [mutiny_core::background:656] Calling PeerManager's timer_tick_occurred
2023-05-16 17:26:40.504 TRACE [mutiny_core::background:656] Persisting scorer
2023-05-16 17:26:40.504 TRACE [mutiny_core::background:656] Rebroadcasting monitor's pending claims
2023-05-16 17:26:42.414 INFO  [mutiny_core::nodemanager:940] Updated cached fees!
2023-05-16 17:26:42.414 INFO  [mutiny_core::esplora:220] Starting transaction sync.
2023-05-16 17:26:43.339 TRACE [lightning::ln::channelmanager:6076] New best block:<PHONE_NUMBER>00000000021a0207fa97024506baaa74396822fb0a07ac20e70148 at height 790039
2023-05-16 17:26:43.339 DEBUG [lightning::chain::chainmonitor:612] New best block<PHONE_NUMBER>00000000021a0207fa97024506baaa74396822fb0a07ac20e70148 at height 790039 provided via best_block_updated
2023-05-16 17:26:43.340 TRACE [lightning::chain::channelmonitor:3157] Processing 0 matched transactions for block at height 790039.
2023-05-16 17:26:43.340 DEBUG [lightning::chain::channelmonitor:3244] Descriptor StaticPaymentOutput b446ada928a3098bf150a874dadb14cdbf7826472df2c4748ad2c92b9cb4a367:0 marked for spending has got enough confirmations to be passed upstream
2023-05-16 17:26:43.341 DEBUG [lightning::chain::onchaintx:707] Updating claims view at height 790039 with 0 claim requests
2023-05-16 17:26:43.341 DEBUG [lightning::chain::onchaintx:820] Updating claims view at height 790039 with 0 matched transactions in block 790039
2023-05-16 17:26:43.341 TRACE [lightning::chain::onchaintx:955] Bumping 0 candidates
2023-05-16 17:26:43.341 TRACE [lightning::chain::chainmonitor:306] Syncing Channel Monitor for channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44
2023-05-16 17:26:43.343 TRACE [lightning::chain::chainmonitor:309] Finished syncing Channel Monitor for channel 10a83e22d18f8501ba48d5ad7b6c9424c632c2b2f658fc461920aecab92bfe44
2023-05-16 17:26:43.345 TRACE [mutiny_core::background:656] Persisting ChannelManager...
2023-05-16 17:26:43.345 TRACE [mutiny_core::background:656] Done persisting ChannelManager.
2023-05-16 17:26:43.347 DEBUG [mutiny_core::event:494] EVENT: processing SpendableOutputs 1
2023-05-16 17:26:43.348 TRACE [mutiny_core::fees:130] Got fee rate from saved cache!
2023-05-16 17:26:43.656 INFO  [mutiny_core::esplora:316] Finished transaction sync.
2023-05-16 17:26:44.421 INFO  [mutiny_core::nodemanager:950] We are synced!
2023-05-16 17:26:44.421 DEBUG [mutiny_core::nodemanager:1556] fetching new bitcoin price
2023-05-16 17:26:44.424 DEBUG [mutiny_core::node:1232] got disconnected from multi socket proxy, going to reconnect
2023-05-16 17:26:45.432 DEBUG [mutiny_core::proxy:74] connected to ws: wss://p.mutinywallet.com
2023-05-16 17:26:45.433 TRACE [mutiny_core::socket:179] connecting new multi websocket descriptor
2023-05-16 17:26:45.434 TRACE [mutiny_core::socket:241] spawning multi socket connection reader
2023-05-16 17:26:45.434 TRACE [mutiny_core::socket:286] spawning multi socket channel reader
2023-05-16 17:26:46.370 INFO  [mutiny_core::nodemanager:940] Updated cached fees!
2023-05-16 17:26:46.370 INFO  [mutiny_core::esplora:220] Starting transaction sync.
2023-05-16 17:26:46.524 INFO  [mutiny_core::esplora:316] Finished transaction sync.


Upgrade less from 2.5.1 to 2.7.1

I would like to upgrade grunt related dependencies and this was in the way: updating only the grunt dep without the thirdparty didn't seem good.
I renamed less-2.5.1.min.js to simply less.min.js, you can see the version in the comments inside the file.

could we maybe switch to npm dependency instead?

I'm all for moving to npm.
But has pointed out before by @busykai, we need to do something about the increase size of the bundle.
For example less 2.7.1 from npm is about 3MB, but the minified file is only 140kB.
I have some random thought but still nothing good.
So WDYT?

Is it about npm not providing minified file or about npm providing too many files that we don't need?

Too many files, I've opened #13020 as a possible solution

Now it is fetched from npm.

👍  cool

Thank you.


Updated gargoyle cask to not use google code anymore.

Updated download url & homepage for gargoyle as it is listed in issue #10461.

Thank you for the contribution. It needed some fixes, so they were made in the above referenced pull request. Your contribution is still included (and still credited to you), with the appropriate modifications. Please feel free to ask about any of the changes.


chore(main): release 1.4.1

:robot: I have created a release beep boop
1.4.1 (2023-10-12)
Bug Fixes

🐛 修复检查更新失败没有提示的问题 (6f733ea)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/viarotel-org/escrcpy/releases/tag/v1.4.1 :sunflower:


fix(toAddr): Adding the ability to specify a different to-address

:tada: This PR is included in version 1.5.4 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Release note 0.13.3

Hello,
What's new in the version 0.13.3 ?
Thanks

Hi @gchevignon,
This version was tagged mostly to help with a conda build issue. Most of the changes are minor fixes, better handling of vbz-compressed files, and the incorporation of a module for the nano-COP paper. I'll leave this issue open as a reminder to write some release notes.
Jared

Great !Thanks a lotGermainLe 19 mai 2021 01:22, Jared Simpson @.***> a écrit :
Hi @gchevignon,
This version was tagged mostly to help with a conda build issue. Most of the changes are minor fixes, better handling of vbz-compressed files, and the incorporation of a module for the nano-COP paper. I'll leave this issue open as a reminder to write some release notes.
Jared
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

I've added these notes.

Hi, any idea on when 0.13.3 will be available in conda? Thanks


postgresql16JitPackages.pgrouting: 3.6.1 -> 3.6.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/pgRouting/pgrouting/releases.
meta.description for postgresql16JitPackages.pgrouting is: A PostgreSQL/PostGIS extension that provides geospatial routing functionality
meta.homepage for postgresql16JitPackages.pgrouting is: https://pgrouting.org/
meta.changelog for postgresql16JitPackages.pgrouting is: https://github.com/pgRouting/pgrouting/releases/tag/v3.6.2
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.6.2 with grep in /nix/store/l5rk2f5mc5wqcd0ybn49sx8p6mi07b71-pgrouting-3.6.2
found 3.6.2 in filename of file in /nix/store/l5rk2f5mc5wqcd0ybn49sx8p6mi07b71-pgrouting-3.6.2

Rebuild report (if merged into master) (click to expand)

12 total rebuild path(s)

12 package rebuild(s)

First fifty rebuilds by attrpath
postgresql12JitPackages.pgrouting
postgresql12Packages.pgrouting
postgresql13JitPackages.pgrouting
postgresql13Packages.pgrouting
postgresql14JitPackages.pgrouting
postgresql14Packages.pgrouting
postgresql15JitPackages.pgrouting
postgresql15Packages.pgrouting
postgresql16JitPackages.pgrouting
postgresql16Packages.pgrouting
postgresqlJitPackages.pgrouting
postgresqlPackages.pgrouting

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/l5rk2f5mc5wqcd0ybn49sx8p6mi07b71-pgrouting-3.6.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A postgresql16JitPackages.pgrouting https://github.com/r-ryantm/nixpkgs/archive/e920560ff493ae98e56a1f63a835190fa7e0f54e.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/e920560ff493ae98e56a1f63a835190fa7e0f54e#postgresql16JitPackages.pgrouting

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/l5rk2f5mc5wqcd0ybn49sx8p6mi07b71-pgrouting-3.6.2
ls -la /nix/store/l5rk2f5mc5wqcd0ybn49sx8p6mi07b71-pgrouting-3.6.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

10 packages built:

postgresql12JitPackages.pgrouting
postgresql12Packages.pgrouting
postgresql13JitPackages.pgrouting
postgresql13Packages.pgrouting
postgresql14JitPackages.pgrouting
postgresql14Packages.pgrouting
postgresql15JitPackages.pgrouting
postgresql15Packages.pgrouting
postgresql16JitPackages.pgrouting
postgresql16Packages.pgrouting

Maintainer pings
cc @imincik @nh2 @nialov @sikmir @willcohen @steve-chavez for testing.

Duplicate to #300347 .


Upgrade to Vue 3, Vite and latest Amplify Vue UI

Issue #, if available:
Description of changes:

Upgrade from Vue 2 -> Vue 3
Migrated Vue cli -> Vite
Migrated aws-amplify-vue -> aws-amplify/ui-vue
Migrated Amplify event bus -> Amplify Hub
Updated most dependencies to latest versions
Migrated vue-the-mask -> maska

Description of testing performed to validate your changes (required if pull request includes CloudFormation or source code changes):
Tested:

Locally using 'npm run dev'
Locally using docker-compose up --build  web-ui
Deploying through CF

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

I'm finding some UI issues when testing the web app.

The Cognito signup/signin forms have field labels, default text, and text entry centered. Looks odd. Should be left aligned. Same for the chatbot entry field on the help view.

After signing up, the dimensions of the "take a tour" popup are off and appear to be clipped.
When testing the abandoned cart feature, the gray panel under the confirmation popup remained displayed after dismissing the popup. I had to refresh the browser to continue. Same thing when testing the text alerts feature.
When changing the shopper, the tooltip for the selected shopper remains visible after the select and confirm shopper views are dismissed.

The phone number fields (text alerts, pick up in store, etc) seem to be incorrectly formatting the entered phone number. When inspecting the network calls from the web app in the browser's developer tools, it looks like the webapp is prefixing an extra country code to the front of the number (e.g., "+1+1 999-9999").


chore: remove unused include

Description
I ran into this trying to compile in jazzy, it could not be found. But didn't seem neccesary.
Related links
Parent Issue:
None

How was this PR tested?
Compilation verified, CI should succeed
Notes for reviewers
None.
Interface changes
None.

Effects on system behavior
None.

ping @soblin

I recently learned the opener of the PR is expected to merge after an approval.
But often is lacking rights.
Can someone with write permissions merge this since it's approved?

@Timple
There are still some build issues that need to be fixed before the PR can be merged.

Then some more approvals from codeowners are needed

Once you fix the build issue please ping some of the codeowners directly to request reviews.


New package: FastBEAST v0.1.0

Registering package: FastBEAST
Repository: https://github.com/FastBEAST/FastBEAST.jl
Created by: @JoshuaTetzner
Version: v0.1.0
Commit: 09ef6bfe3b8f931fb5fa1dcbb49add2d357d67ea
Reviewed by: @JoshuaTetzner
Reference: https://github.com/FastBEAST/FastBEAST.jl/commit/09ef6bfe3b8f931fb5fa1dcbb49add2d357d67ea#commitcomment-144497896

Stop Registration

Closing in favor of https://github.com/JuliaRegistries/General/pull/111523
Note that you do not need to (or should) change the version number when fixing an automerge issue. Retriggering the registration while keeping the version number the same updates an existing registration PR.


A redesign of my theme

Hi,
I redesigned my bootstrap theme, improving search suggestions, sidebar overflow, legibility, and I also replaced the bootstrap v3 styles with a selection of v4 (I removed the big bootstrap file).
Biggest changes:

Removed all panels and most tables. The class view is the most impacted. I replaced the table columns by a flat view with: name, type, attributes. Now it displays fine on smaller screens.
Search suggestions are displayed full screen, under the search input.
If the menu inside the sidebar overflows, it is shown entirely when the mouse hovers, making it more readable. I removed the splitter since it's of no use anymore.
Replaced some PNG files with glyphs, added a SVG icon for the link.
New behavior for the search button
The theme is now responsive, you can check your documentation from your phone.

You can see it in action over here: https://olvlvl.com/apigen/class-ApiGen.Parser.Reflection.ReflectionElement.html
Feedback appreciated <3

This may be shipped with the next version of apigen.
@olvlvl You may merge it yourself.

@olvlvl I'm concerned of how the user is able to open up the source. I tried in your demo but I wasn't able to open up the source of a specific method.

Good call, I forgot to test that because I'm generating my docs without sources. I'll have a look as soon as I can.

You don't? @kukulich

Hi @olvlvl ,
thank you for great work!
We are merging themes to main ApiGen\ApiGen repository, already did for DefaultTheme, so it's easier to develop.
Could you send PR there after you finish it here? I'll take care about the changes, don't worry about them.

Can I add this?

Hi Tomas, give me a sec, I'll do it.

Here: https://github.com/ApiGen/ApiGen/pull/840

Awesome job. Thank you!


[BUG] Transposed words on your website home page

Bug
Which Delta project/connector is this regarding?
https://delta.io homepage

[ ] Spark
[ ] Standalone
[ ] Flink
[ ] Kernel
[x] Other (fill in here) Homepage of the delta.io website

Describe the problem
There are two transposed words in the last phrase of the first paragraph:
"you can read now Delta tables with Iceberg and Hudi clients"
It's hard to spot when you're reading it, but it should say:
"you can now read Delta tables with Iceberg and Hudi clients"
Thanks!
Steps to reproduce

Observed results
Looks at the first paragraph of content, including the last phrase.

"read now" should be "now read"
Expected results

"now read
Further details

Environment information

Delta Lake version:
Spark version:
Scala version:

Willingness to contribute
The Delta Lake Community encourages bug fix contributions. Would you or another member of your organization be willing to contribute a fix for this bug to the Delta Lake code base? Not now, but maybe later.

[ ] Yes. I can contribute a fix for this bug independently.
[ ] Yes. I would be willing to contribute a fix for this bug with guidance from the Delta Lake community.
[x] No. I cannot contribute a bug fix at this time.

Thanks for reporting this.  I will transfer this issue to the delta-io/website repo where the website code lives.


feat: New install script and container wrappers.

As title.

Benchmark results
Metrics with a significant change:

note_trial_decrypting_time_in_ms (32): 99.1 (+102%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit 379b5adc and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
128 txs

l1_rollup_calldata_size_in_bytes
45,444
179,588
716,132

l1_rollup_calldata_gas
222,984
868,160
3,449,672

l1_rollup_execution_gas
842,071
3,595,268
22,205,041

l2_block_processing_time_in_ms
2,237 (-4%)
8,584 (+1%)
35,866 (+1%)

note_successful_decrypting_time_in_ms
323 (-1%)
968 (+5%)
3,535 (+2%)

note_trial_decrypting_time_in_ms
31.6 (-15%)
:warning: 99.1 (+102%)
203

l2_block_building_time_in_ms
20,430 (+1%)
80,671 (+1%)
324,491 (+1%)

l2_block_rollup_simulation_time_in_ms
16,862 (+1%)
66,665 (+1%)
268,309 (+1%)

l2_block_public_tx_process_time_in_ms
3,534 (+1%)
13,935
55,930 (+1%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
24,986
48,569 (+2%)

note_history_successful_decrypting_time_in_ms
2,230 (+3%)
4,367 (+4%)

note_history_trial_decrypting_time_in_ms
164 (+1%)
235 (+1%)

node_database_size_in_bytes
3,625,646
3,924,403

pxe_database_size_in_bytes
29,748
59,307

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
200 (+1%)
43,109
20,441

private-kernel-ordering
115
25,833
9,689

base-rollup
2,961
667,692
873

root-rollup
90.2 (+6%)
4,072
881

private-kernel-inner
261
64,516
20,441

public-kernel-private-input
172 (+1%)
25,203
20,441

public-kernel-non-first-iteration
169
25,245
20,441

merge-rollup
11.0 (+1%)
2,592
873

Miscellaneous
Transaction sizes based on how many contracts are deployed in the tx.

Metric
0 deployed contracts
1 deployed contracts

tx_size_in_bytes
10,323
25,938


:bomb: Bug: GitHub Api rate limit exceeded

What Happened?
quickstart.sh will get the latest version from https://api.github.com/repos/devstream-io/devstream/releases/latest.
but this url has a ratelimter.
Please assign it to me,i will fix it asap.
How to Reproduce?
No response
Anything else
No response
DevStream Version
latest

Thanks for your feedback on adapting our quick start script to more network environments! @csonezp

resolved by #957


Gen Option fields that not null but have default values

PR Info

Closes

Dependencies:

Dependents:

New Features

[ √]

Bug Fixes

[ ]

Breaking Changes

[ ]

Changes

[ ]

https://discord.com/channels/873880840487206962/900758302294704188/1168461574747455499


Add test cases for volume parse/merge

To cover the cases in #551 (and #490 )
Could @bergwolf add the cases?

will do


chore: upgrade dynamodb for rust-v0.16.x

@rtyler - I think it would be best if we disable the repair_worker tests on that PR as well

just a second too late - saw it merged as i typed 😆


dl_iterate_phdr() and ELF friends only defined on Linux and Fuchsia.

Hi,
I'm writing a library around the dl_iterate_phdr API, and want it to be portable.
I've noticed that dl_iterate_phdr, its types, and constants, are defined only on Linux and Fuchsia for now:
$ ag PT_NULL
src/fuchsia/mod.rs
2431:pub const PT_NULL: u32 = 0;

src/unix/notbsd/linux/mod.rs
1225:pub const PT_NULL: u32 = 0;

$ ag dl_iterate_phdr
src/fuchsia/mod.rs
3976:    pub fn dl_iterate_phdr(

src/unix/notbsd/linux/mod.rs
2045:    pub fn dl_iterate_phdr(

$ ag Elf64_Half
src/fuchsia/mod.rs
50:pub type Elf64_Half = u16;
930:        pub dlpi_phnum: Elf64_Half,

src/unix/notbsd/linux/mod.rs
31:pub type Elf64_Half = u16;
472:        pub dlpi_phnum: Elf64_Half,

AFAIK, all of this stuff if present on the BSDs. The ELF stuff is a standard ABI (although different for 32/64-bit arches) that could be shared across all platforms, but some of the types for dl_iterate_phdr differ per-platform. For example, on OpenBSD dl_phdr_info contains more fields than on Linux.
For now users can work around this by using bindgen, but in the long run I think it would be best for libc to implement  these interfaces across all platforms.
Thanks

Feel free to send PRs for other platforms!

It seems like #1953 added dl_iterate_phdir to all the BSDs. Haiku doesn't have it despite using ELF and neither does illumos. newlib still needs it

[x] Freebsd
[x] openbsd
[x] netbsd
[x] dragonflybsd
[ ] newlib

Haiku now has dl_iterate_phdr, but you must link against -lbsd for it. (It also does not have all the struct members that the BSDs do.)


Fix incorrect method name and idx.

For some cases, name idx may exceed the range of u2, which will lead to a wrong method name resolve.

@anestisb Hi, could you help review this commit?

Bad number of methods is u2 so what is the exceed use case? Do you have a sample Dex file that you hit the bug?

@anestisb Hi,  what I really mean is that, the method's name id may exceed u2. You can refer to the definition of dexMethodId:
typedef struct __attribute__((packed)) {
  u2 classIdx;
  u2 protoIdx;
  u4 nameIdx;    // u4 here
} dexMethodId;

nameIdx is the type of u4,  for the name resolution:
void dex_dumpMethodInfo(const u1 *dexFileBuf,
                        dexMethod *pDexMethod,
                        u4 localIdx,
                        const char *type) {
const char *methodName = dex_getStringDataByIdx(dexFileBuf, pDexMethodId->nameIdx);  // string resolution

And definition of function dex_getStringDataByIdx is:
const char *dex_getStringDataByIdx(const u1 *dexFileBuf, u2 idx) {  // but it's u2 here
  u4 unicode_length;
  return dex_getStringDataAndUtf16LengthByIdx(dexFileBuf, idx, &unicode_length);
}

The parameter of function dex_getStringDataByIdx is the type of u2.
So during the method name resolution, when calling function dex_getStringDataByIdx, there will be a Implicit conversion from u4 to u2. So if the name idx of a method exceed u2, the result of name resolution will be wrong.
I can't upload the dex file which can hit this bug due to security reasons, sorry for that.

Gotcha. Yes you're absolutely right. Merging. Thank you for your contribution.


Extract common test method to test-utils.js

This change is

Review status: 0 of 3 files reviewed, 1 unresolved discussion (waiting on @SomeoneToIgnore)

test/router/lifecycle-events.spec.html, line 132 at r1 (raw file):

          expect(outlet.children[0].tagName).to.match(/x-users-list/i);
          window.VaadinTestNamespace.verifyActiveRoutes(router, ['/users']);

Now the window.VaadinTestNamespace. bit is repeated a number of times. How about having const {verifyActiveRoutes} = VaadinTestNamespace; only once somewhere in the top of the page?

Comments from Reviewable

Reviewed 3 of 3 files at r1.
Review status: all files reviewed, 1 unresolved discussion (waiting on @SomeoneToIgnore)

Comments from Reviewable

Reviewed 2 of 2 files at r2.
Review status: :shipit: complete! all files reviewed, all discussions resolved

Comments from Reviewable

Review status: :shipit: complete! all files reviewed, all discussions resolved

test/router/lifecycle-events.spec.html, line 132 at r1 (raw file):
Previously, vlukashov (Viktor Lukashov) wrote…
Now the window.VaadinTestNamespace. bit is repeated a number of times. How about having const {verifyActiveRoutes} = VaadinTestNamespace; only once somewhere in the top of the page?

Nice idea, done.

Comments from Reviewable


Error while compiling in AOT mode with Angular 9

I'm trying to use Angular 9 in my project to take advantage of Ivy. I upgraded my Angular version and then switched on AOT mode. Angular compiles twice (is this intended?) and then I get this error:
While processing files with angular-compilers (for target web.browser):
   packages/angular-typescript-compiler/index.js:374:42: compiler.analyzeModulesAsync is not a function
   at packages/angular-typescript-compiler/index.js:374:42
   at

Meteor 1.9.2
Angular 9.0.5
angular-compilers 0.3.4
@babel/core 7.8.6
I'm new to this entire stack so please let me know if you need more information from me in order to help me figure out what's going on.

Hello,
I have exactly the same issue. It would be awesome if we somehow can continue to use angular with meteor.

In case no one gets back to you quickly, I know this works with Angular 7. I haven't tested 8 thoroughly. You can use 7 to get started if you don't mind being a few versions behind and missing some of the features 8/9 provide

it also works with angular 8... our current setup. i wanted to try out ivy

@mibto Thank you so much for updating the dependencies for angular-comilers and publishing to Atmosphere.
One more question though. I'm trying to get AOT to work with meteor 1.10.1 but I'm still running into issues. I'm using mibto:angular-compilers 0.3.18 which works great with AOT disabled (no more node-sass errors thanks to your update). However, if I activate the AOT flag

with Angular 7/8 I get: compiler.ts:843:42: host.isSourceFile is not a function
with Angular 9 I get: angular-typescript-compiler/index.js:370:42: compiler.analyzeModulesAsync is not a function

(while processing files with mibto:angular-compilers)
I'm struggling to find a solution for this, did anyone manage to find a fix or workaround?

@cosmin-dumitrache can you please try it with version 0.3.4 - i have it working with AOT and angular 8.2.14

@mibto Thanks for the suggestion, but no luck with meteor 1.10.1 :(
One strange thing is that when i try to add angular-compilers 0.3.4 it picks up other versions, not sure why:
meteor add<EMAIL_ADDRESS>
Changes to your project's package version selections:

mibto:angular-compilers            added, version 0.3.18
mibto:angular-html-compiler        added, version 0.3.17
mibto:angular-scss-compiler        added, version 0.3.17
mibto:angular-typescript-compiler  added, version 0.3.18

mibto:angular-compilers: Rollup, AOT, SCSS, HTML and TypeScript compilers for Angular Meteor

But I did that anyway, and changed Angular to 8.2.14 (still using meteor 1.10.1). The build then produced this error when processing with mibto:angular-compilers compiler.ts:843:42: host.isSourceFile is not a function.
It might work with meteor 1.9.2 as you said, but as far as I know you need the Cordova update in meteor 1.10.1 to be able to produce a version of swift acceptable by the latest XCode. I was fine with meteor 1.8 to be honest, but I can't deploy my app anymore because of swift, so I don't really have an option to not update to 1.10.1.
Mind you, if I disable AOT, it works, but my app suffers a massive performance penalty.

meteor updated to the latest 1.10.2
meteor add<EMAIL_ADDRESS>Looks like working

I've installed meteor 1.10.2, using mibto:angular-compilers (had to clone from github and throw in my packages folder due to some problems including scss files). Installed Angular 9. Still getting this kind of error:
While processing files with mibto:angular-compilers (for target web.browser):    packages/mibto:angular-typescript-compiler/index.js:368:42: compiler.analyzeModulesAsync is not a function    at packages/mibto:angular-typescript-compiler/index.js:368:42
Any idea where I might be going wrong?

@aas395 You can try turning off Ivy as described here: https://forums.meteor.com/t/meteor-1-10-1-breaks-angular-integration-when-aot-is-enabled/52511
That will fix your problem but then you'll get a new problem: compiler.ts:843:42: host.isSourceFile is not a function

@mibto I saw you patching the compiler by setting the compiler-host to an empty object:
https://github.com/mibto/angular-meteor/blob/f39cd151a9e0752533aa8f7dbe0d7802d7a657c7/atmosphere-packages/angular-typescript-compiler/index.js#L345
I got better results (and do not have the error of host.isSourceFile is not a function) when replacing the occurances of compiler._host by compilerHost which seems to be the object meant to manipulate here.
With these changes I'm able to run Angular 10.1.2 for development, but I'm facing the same error as @aas395 when trying to compile it for production (e.g. trying to run meteor --production).
Any hint for a solution? If you don't have, I'll try to see what I can get, but if someone already has the solution, there's no need to reinvent the wheel 😅

@SimonSimCity You are correct, patching the compiler host with an empty object tripped me up as well.
I think the easiest fix for you to get ride of the analyzeModulesAsync problem is to turn off Ivy.
I'll publish a solution using this approach soon in the form of a new angular-meteor atmosphere package.

@cosmin-dumitrache When turning off Ivy (by setting enableIvy to false in the ngcOptions object) I'm faced with the following error:
   While processing files with angular-compilers (for target web.browser.legacy):
   /Users/simon/Documents/packages/compiler/src/util.ts:108:17: Couldn't resolve resource themes from /Users/simon/Documents/angular-project/client/imports/app/app.scss
   at syntaxError (/Users/simon/Documents/packages/compiler/src/util.ts:108:17)
   at Object.resolve (/Users/simon/Documents/packages/compiler/src/aot/compiler_factory.ts:46:15)
   at /Users/simon/Documents/packages/compiler/src/style_url_resolver.ts:40:57
   at String.replace (<anonymous>)
   at extractStyleUrls (/Users/simon/Documents/packages/compiler/src/style_url_resolver.ts:33:32)
   at /Users/simon/Documents/packages/compiler/src/directive_normalizer.ts:251:32
   at Array.map (<anonymous>)
   at DirectiveNormalizer._normalizeStylesheet (/Users/simon/Documents/packages/compiler/src/directive_normalizer.ts:250:41)
   at /Users/simon/Documents/packages/compiler/src/directive_normalizer.ts:236:46
   at Object.then (/Users/simon/Documents/packages/compiler/src/util.ts:96:52)
   at /Users/simon/Documents/packages/compiler/src/directive_normalizer.ts:232:53
   at Array.map (<anonymous>)
   at DirectiveNormalizer._loadMissingExternalStylesheets (/Users/simon/Documents/packages/compiler/src/directive_normalizer.ts:231:28)
   at DirectiveNormalizer._normalizeTemplateMetadata (/Users/simon/Documents/packages/compiler/src/directive_normalizer.ts:161:14)
   at /Users/simon/Documents/packages/compiler/src/directive_normalizer.ts:97:37
   at Object.then (/Users/simon/Documents/packages/compiler/src/util.ts:96:52)
   at DirectiveNormalizer.normalizeTemplate (/Users/simon/Documents/packages/compiler/src/directive_normalizer.ts:95:22)
   at CompileMetadataResolver.loadDirectiveMetadata (/Users/simon/Documents/packages/compiler/src/metadata_resolver.ts:262:54)
   at /Users/simon/Documents/packages/compiler/src/metadata_resolver.ts:482:30
   at Array.forEach (<anonymous>)
   at CompileMetadataResolver.loadNgModuleDirectiveAndPipeMetadata (/Users/simon/Documents/packages/compiler/src/metadata_resolver.ts:481:35)
   at /Users/simon/Documents/packages/compiler/src/aot/compiler.ts:89:48
   at Array.map (<anonymous>)
   at AotCompiler.analyzeModulesAsync (/Users/simon/Documents/packages/compiler/src/aot/compiler.ts:88:38)
   at packages/angular-typescript-compiler/index.js:374:42
   at /Users/simon/.meteor/packages/meteor-tool/.<IP_ADDRESS>af9c.g0b4t++os.osx.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-promise/fiber_pool.js:43:40

In the file /client/imports/app/app.scss I just import another scss file, called themes, which is what triggers the compiler.
It just works when setting the environment variable AOT=0, which disables all the ahead-of-time compilation. This way I can now at least publish my application. I have yet to see what this will allow/close of possibilities, as I'm fairly new to Angular.

I've published an updated version of angular-compilers that uses the disable Ivy trick. You can use it by replacing your dependency to angular-compilers with digicore:angular-compilers (version 0.4.2).
Hopefully this will be useful for people struggling to run Meteor 1.11 + Angular 10 with AOT enabled.
@SimonSimCity Not sure why you're getting the scss issue, I haven't seen that type of error in my project.

I've published an updated version of angular-compilers that uses the disable Ivy trick. You can use it by replacing your dependency to angular-compilers with digicore:angular-compilers (version 0.4.2).
Hopefully this will be useful for people struggling to run Meteor 1.11 + Angular 10 with AOT enabled.
@SimonSimCity Not sure why you're getting the scss issue, I haven't seen that type of error in my project.

Hey thanks for all your work,  I have gotten this working in dev mode perfectly, when I try to deploy using MUP (meteor up) I get Cannot determine the module for class for all my components.  Hopefully you have dealt with this issue already.  Meteor version 1.11.1

@cosmin-dumitrache thank you very much for the better / proper fix. Do you also get following "error" when using meteor --production or meteor build:
meteor --production
Warning: The --production flag should only be used to simulate production bundling for testing purposes. Use meteor build to create a bundle for production deployment. See: https://guide.meteor.com/deployment.html
[[[[[ ~/WebstormProjects/in-pool ]]]]]

=> Started proxy.
[client]: HTML Files Compilation: 47.611ms   |
[client]: Collecting TypeScript source files: 5.363ms
TypeScript Host Created.: 0.183ms
TypeScript Program Created.: 1440.934ms
Angular Compiler Host Created.: 0.241ms
Angular Compiler Program Created.: 61.400ms
Filtering TypeScript source files: 0.157ms
Modules Analyzed.: 2479.059ms
Emitting All Impls: 1334.711ms
Modules Converted to TypeScript.: 221.186ms
<EMAIL_ADDRESS>(26, 25): Expected 1 arguments, but got 3.
<EMAIL_ADDRESS>(29, 25): Expected 1 arguments, but got 3.
<EMAIL_ADDRESS>(74, 25): Expected 1 arguments, but got 3.
client/imports/app/app.module.ngfactory.ts (123, 25): Expected 1 arguments, but got 3.
[client]: TypeScript Files Compilation: 39.721ms

i also get this "error" in this angular-meteor example project

Does it work right now with version 0.4.0?


Update values in specified range

User can specify in A1 notation, which cells of a Sheet will be updated. The rest of the Sheet will be left intact.
Default behaviour is, that the Sheet is cleared on update.
It is also possible to just add option to "not clear" the Sheet before update. So the user can for example just update first 3 columns of a Sheet with values from a 3 column SAPI table. And the rest of the sheet will be left intact.

Not needed now


Internal buffering disrupts format-specific deserialization features

Was not sure if I should file this against serde_json or here. As far as I can tell the bug is more likely in serde itself. While implementing #1179 I noticed that non string keys are not supported for flattening. However the same behavior happens if buffering happens for internally tagged enums:
Example that shows the problem:
#[macro_use]
extern crate serde_derive;

extern crate serde;
extern crate serde_json;

use std::collections::HashMap;

#[derive(Deserialize, Debug)]
#[serde(tag = "type")]
enum E {
    M(HashMap<u32, ()>),
}

fn main() {
    let j = r#" {"type": "M", "1": null} "#;
    println!("{}", serde_json::from_str::<E>(j).unwrap_err());
}

This currently fails with this error:
invalid type: string "1", expected u32

However a HashMap<u32, ()> is otherwise entirely permissible by serde_json.

There are some other JSON-specific assumptions baked into Content too. For example the representation of Serde enums happens to be what serde_json uses but not necessarily shared by other formats.
I suspect we will need a format-specific optional API on Deserializer for buffering data in a way that is consistent for that format. The default implementation would basically be equivalent to today's Content but formats could override it to use their own representation. Even serde_json may want to switch and use something like serde_json::Value for buffering rather than Content.
We should start by identifying all the ways Content is used in our generated code and generalize those into an API that can be provided by the deserializer.

This is complicated by associated type defaults being unstable https://github.com/rust-lang/rust/issues/29661. I thought we might want a format-specific buffer type as a Deserializer associated type with the default being Content, but we will need to find a different way.

Here is a backdoor way to add an associated type.
struct Content;

trait Deserializer {
    // Suppose we want something like this but associated type defaults are unstable.
    type Buffer = Content;
}

trait Deserializer {
    // Instead write it as an associated function that forwards to a generic callback.
    fn deserialize_with_buffering<F>(callback: F) -> F::Value
    where
        F: DeserializeWithBuffer,
    {
        callback.run::<Content>()
    }
}

trait DeserializeWithBuffer {
    type Value;
    fn run<Buffer>(self) -> Self::Value;
}

Is there any update on this?

Customizing the buffer type by Deserializer could provide a powerful alternative to #1327. The key constraint being satisfied in that approach (as compared to just stashing state in some thread local) was to accurately expose state during deserialization of untagged, internally tagged, and flattened members.
If a Deserializer can replace the buffer type, a library could provide a stateful Deserializer built on TLS by wrapping any existing Deserializer and wrapping that Deserializer's buffer type to correctly track the state.

I implemented a proof of concept in #1354.

Is it possible that this issue explains the behavior described in nox/serde_urlencoded#66?  In that case, the author is trying to deserialize the key-value pair bar=123 into a variant B { bar: i32 } in an untagged enum.  It seems like this should work.  Deserialization fails because "data did not match any variant of untagged enum Q2".  When using a similar enum Q1 where the variant is B { bar: String }, it works as expected, with bar = "123".

Yeah that looks like a consequence of this issue. #[serde(with = "serde_with::rust::display_fromstr")] on the field (https://docs.rs/serde_with/1.4.0/serde_with/rust/display_fromstr/index.html) would work around it in that case but obviously is not ideal.

I have the following seemingly simple usage of flatten with an enum in the Inner struct. Is this crash also related to this issue? I see most failures with flatten are reffered to here, but haven't seen this particular case yet.
use serde::{Deserialize, Serialize};
#[derive(Serialize, Deserialize)]
enum E {
    A,
    B,
}

#[derive(Serialize, Deserialize)]
struct Inner {
    e: E,
}

#[derive(Serialize, Deserialize)]
struct Outer {
    #[serde(flatten)]
    inner: Inner,
}

fn main() {
    let yaml = "e: !A";
    let _outer: Outer = serde_yaml::from_str(&yaml).unwrap();
    // Fails with:
    // e: untagged and internally tagged enums do not support enum input
}

The docs have a sentence saying

"It is supported only within structs that have named fields, and the field to which it is applied must be a struct or map type."

Maybe that can/should be updated to mention that enums anywhere in the flattened struct (also more deeply nested) are not allowed either (at least when deserializing YAML).

@RagnarGrootKoerkamp that sounds like it is unrelated to flattening, does it work when you just try to deserialize that string as Inner (because it that fails with the same error, then it is unrelated to flattening, otherwise it's a bug in the flatten impl afaik)

@zseri Yes, deserializing to Inner works fine. Updated the example above.
Should I create a separate issue then?

This might be related: https://github.com/dtolnay/serde-yaml/issues/388
Yaml can treat a value of 42 as a string. This works without flatten, but fails with it.
Stepping on the code in gdb, the interesting transition seems to be:
#0  serde::__private::de::content::{impl#15}::deserialize_string<serde_yaml::error::Error, serde::de::impls::StringVisitor> (self=..., visitor=...)
    at /home/espindola/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.188/src/private/de.rs:1260
#1  0x000055555556516d in serde::de::impls::{impl#8}::deserialize<serde::__private::de::content::ContentDeserializer<serde_yaml::error::Error>> (deserializer=...)
    at /home/espindola/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.188/src/de/impls.rs:582
#2  0x00005555555681f0 in serde::de::{impl#5}::deserialize<alloc::string::String, serde::__private::de::content::ContentDeserializer<serde_yaml::error::Error>> (
    deserializer=...) at /home/espindola/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.188/src/de/mod.rs:794
#3  0x0000555555571b68 in serde::__private::de::{impl#10}::next_value_seed<serde_yaml::error::Error, core::marker::PhantomData<alloc::string::String>> (
    self=0x7fffffffd340, seed=...) at /home/espindola/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.188/src/private/de.rs:2814
#4  0x00005555555716c6 in serde::de::MapAccess::next_value<serde::__private::de::FlatStructAccess<serde_yaml::error::Error>, alloc::string::String> (
    self=0x7fffffffd340) at /home/espindola/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.188/src/de/mod.rs:1865
#5  0x0000555555563867 in serde_yaml::_::{impl#0}::deserialize::{impl#2}::visit_map<serde::__private::de::FlatStructAccess<serde_yaml::error::Error>> (__map=...)
    at src/main.rs:3
#6  0x0000555555571e31 in serde::__private::de::{impl#8}::deserialize_struct<serde_yaml::error::Error, serde_yaml::_::{impl#0}::deserialize::__Visitor> (self=...,
    fields=&[&str](size=1) = {...}, visitor=...) at /home/espindola/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.188/src/private/de.rs:2674
#7  0x0000555555563300 in serde_yaml::_::{impl#0}::deserialize<serde::__private::de::FlatMapDeserializer<serde_yaml::error::Error>> (__deserializer=...)
    at src/main.rs:3
#8  0x0000555555564d80 in serde_yaml::_::{impl#0}::deserialize::{impl#2}::visit_map<&mut serde_yaml::de::MapAccess> (__map=0x7fffffffd6d0) at src/main.rs:8

We go from using deserialize_string from serde_yaml, to using one from serde, which doesn't has the required logic.

Let's give this another attempt as associated type defaults (rust-lang/rust#29661) approaches stabilization. I believe the workaround without associated type defaults in #1354 could have been made to work but would have been too complicated to maintain.

It seems like rust-lang/rust#29661 still has a way to go, so in case #![feature(return_position_impl_trait_in_trait)] is stabilized earlier, perhaps something like the following could also work:
pub trait Deserializer<'de>: Sized {
    /* ... */

    fn deserialize_buffered(self) ->
        Result<impl Clone + Deserializer<'de>, Self::Error>
    {
        crate::__private::de::Content::deserialize(self)
    }
}

Are there other options that could perhaps be used to provide this feature earlier, since several serde-supporting formats have to battle buffering-based issues until then?

@dtolnay Since return impl trait in traits will now be stabilised soon, do you think that using it to solve this issue would be an avenue worth pursuing?

Any update on this matter? Anything we can do to assist?

I'll repeat the last comment:

Any update on this matter? Anything we can do to assist?

It is nearly 2025, is there something that can be done in order to speed this up, other than wait for https://github.com/rust-lang/rust/issues/29661 ?


Webpack2 clean react redux spa

Update Webpack to version 2
Tested to ensure proper functionality

Hi @Bartekus, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla2.dotnetfoundation.org.

TTYL, DNFBOT;

@Bartekus, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.
Thanks, DNFBOT;

Thanks for suggesting this!
As it happens, we're already in the middle of updating all the project templates to Webpack 2. Most of the changes we're making are basically the same as you've posted here, though we're going a bit further with the changes in some areas. The work in progress is here: https://github.com/aspnet/JavaScriptServices/commits/webpack2-clean
Since this is already underway, I hope you won't mind me closing this PR. The React-Redux template (plus all the others) will be on Webpack 2 in a single style very soon. Thanks again for the PR!


Rename the CI cargo fmt job to formatting.

This brings the CI in sync with the latest Linebender standard, see e.g. xilem.

Hmm, was the cargo fmt job not previously required in this repository?

Indeed it was. I just removed that requirement in preparation for this to be merged. 🚀

For reference, I normally swap the requirements just before merging, i.e. once the PR making the change is approved.
Practically though, that's only a small difference


Timezone issue

Describe the bug
UTC to UTC + 8 is not working as intended (it is an hour behind)

How to Reproduce
import pytz

# argus_path is a s3 path
zzzzz = wr.s3.describe_objects(argus_path, last_modified_begin=dt(2024, 7, 20, 19, 0, tzinfo=pytz.timezone('Asia/Singapore')))
print([zzzzz[i]['LastModified'] +timedelta(hours=8) for i in zzzzz])

Expected behavior
i would expect last_modified_begin=dt(2024, 7, 20, 19, 0, tzinfo=pytz.timezone('Asia/Singapore')) to give me everything including and after 7pm but it doesnt.
Your project
No response
Screenshots

OS
Win
Python version
3.9
AWS SDK for pandas version
3.2.1
Additional context
No response

seems like pytz library changed in behaviour ... perhaps it does some DST during its conversion.
specifying a datetime pytz's timezone object results in:
<DstTzInfo 'Asia/Singapore' LMT+6:55:00 STD>
while the dt.now() timezone object results in:
<DstTzInfo 'Asia/Singapore' +08+8:00:00 STD>
I'll use zoneinfo.ZoneInfo instead.


zh-translation: docs/root/intro/arch_overview/security/ext_authz_filt…

…er.rst
ref: https://github.com/cloudnativeto/envoy/issues/27

For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]

@shalk @Miss-you 感谢review，修改已经提交，请查阅


Better aliases (fix #339)

Voilà, we have:

got rid of the three sections for aliases.
allowed the $ prefix for alias expansion of segments of typenames.
and there are now user-definable aliases!
which can be set, listed and delete from bibliopixel.
and which respect --external (renamed to --isolate)!

Take your time.  I'm doing this to delay doing other less-fun things.  :-D


IBM-Swift/Kitura#137 Integrate codecov.io

Description
Provide codecov.io integration
Motivation and Context

How Has This Been Tested?

Checklist:

[ ] I have submitted a CLA form
[ ] If applicable, I have updated the documentation accordingly.
[ ] If applicable, I have added tests to cover my changes.

Current coverage is 25.21% (diff: 100%)

No coverage report found for master at d71d49c.

Powered by Codecov. Last update d71d49c...7b61a56


Apple  is not redirect to url callback

although the callback url is set correctly, after my login, apple redirect to my index and not to my callback route. Has anyone had this problem?

I haven't seen this issue. I've been using it daily in my most recent project and not seen that. If you could provide a test URL that would be great.

of course: https://teste.eita.delivery

Sorry friend, I managed to identify the problem. We still needed to add the callback route in excess of the csrf token. thank you very much and congratulations!