feat(docs): Aztec.nr errors in docs

Closes https://github.com/AztecProtocol/aztec-packages/issues/2905

Debugging section with aztec and sandbox errors (moved common errors into here)
Dependencies section

still need to update after getting-started pr is merged
Checklist:
Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

[ ] If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
[ ] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
[ ] Every change is related to the PR description.
[ ] I have linked this pull request to relevant issues (if any exist).

Benchmark results
No metrics with a significant change found.

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 ca52a3e2 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,960
867,728
3,447,704

l1_rollup_execution_gas
842,047
3,594,836
22,203,073

l2_block_processing_time_in_ms
1,985
7,671 (+2%)
29,889 (+1%)

note_successful_decrypting_time_in_ms
293
865 (-2%)
3,173 (-1%)

note_trial_decrypting_time_in_ms
97.0 (+3%)
73.0 (-17%)
134

l2_block_building_time_in_ms
13,164
52,590 (+1%)
210,980 (+1%)

l2_block_rollup_simulation_time_in_ms
11,828 (-1%)
47,258 (+1%)
189,663 (+1%)

l2_block_public_tx_process_time_in_ms
1,298
5,192
20,810 (+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
21,386 (-1%)
42,030

note_history_successful_decrypting_time_in_ms
1,978
3,870

note_history_trial_decrypting_time_in_ms
121 (+2%)
143 (+1%)

node_database_size_in_bytes
1,630,010
1,095,287

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
772
61,697
18,905

private-kernel-ordering
123
24,297
8,153

base-rollup
1,770
656,311
814

root-rollup
76.0 (-5%)
4,072
1,097

private-kernel-inner
788
81,568
18,905

public-kernel-private-input
41.4
41,519
18,841

public-kernel-non-first-iteration
26.2
41,497
18,841

merge-rollup
0.906 (+3%)
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
8,787
27,547

added redirects @critesjosh


image-rs: make tar reader async

before this commit, tar reader is sync, thus we need a separate os thread for every image layer pulling green thread. This would cost more memory and CPU resource because on linux a thread actually means another process.
This commit replace the tar crate to async version, thus we do not need another thread to handle this to decrease memory occupation.
Also, the original thread way would make the error of unpack() function missing because it would not be captured by original thread. Thus always a inclear Send Error {...} error message will be returned. The new way will not face such situation. cc @stevenhorsman
Some abilities like permission maintain, ownership maintain are manually implemented as the original crate does not support well.
cc @arronwy

Rebased and added another commit to replace libc with nix. This commit should be test on kata pipeline before merge.

Rebased and added another commit to replace libc with nix. This commit should be test on kata pipeline before merge.

Sure - as I don't have any green ticks for the current image-rs bump in kata, I'll temporarily re-purpose it to test your branch

Rebased and added another commit to replace libc with nix. This commit should be test on kata pipeline before merge.

Sure - as I don't have any green ticks for the current image-rs bump in kata, I'll temporarily re-purpose it to test your branch

In https://github.com/kata-containers/kata-containers/actions/runs/9806138253/job/27078629312?pr=9828 the non-TEE, SEV and SNP tests passed and the TDX is failing with normal results, so I think this is okay from the kata integration tests. I will drop the change for now, but if this gets merged before the image-rs bump does then I'll update to pick this up too. Thanks!

@arronwy do these changes look good to you?

@arronwy do these changes look good to you?

Yes, the primary concern for this pr is the possibility that crate krata-tokio-tar may not be actively maintained in future.
The init async support for tar is async-tar project https://github.com/dignifiedquire/async-tar  which is forked from tar-rs, and this project is not update for three years.
Next is tokio-tar https://github.com/vorot93/tokio-tar which is forked from async-tar and not update for one year and may PR is not review: https://github.com/vorot93/tokio-tar/pulls
Finally is the crate we use krata-tokio-tar https://github.com/edera-dev/tokio-tar which is forked from tokio-tar with several bug fixings.
After sync with @Xynnn007 if future have issues in this crate, we can fork and fix it.
@fitzthum any suggestions?

@arronwy @Xynnn007
the state of those repos is far from ideal, but I guess we can make it work. Maybe we can get in touch with some of those maintainers and figure out what the status is. We can fork if we have to.


Initial HTTP CONNECT and GET requests fail on 3.11.x, but work on 3.10.x and below

The following is the log when running on Python 3.11.2:
$ python -m pproxy -r "http+ssl://uk2144.nordvpn.com:89#user:pass" --test "https://ipinfo.io/json" -d -v
============ uk2144.nordvpn.com:89 ============
 from 194.35.x.x
Traceback (most recent call last):
  File "C:\Program Files\Python311\Lib\asyncio\tasks.py", line 490, in wait_for
    return fut.result()
           ^^^^^^^^^^^^
  File "C:\Program Files\Python311\Lib\asyncio\streams.py", line 637, in readuntil
    await self._wait_for_data('readuntil')
  File "C:\Program Files\Python311\Lib\asyncio\streams.py", line 522, in _wait_for_data
    await self._waiter
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "C:\Users\x\AppData\Roaming\Python\Python311\site-packages\pproxy\server.py", line 860, in test_url
    reader, writer = await roption.prepare_connection(reader, writer, host_name, port)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\x\AppData\Roaming\Python\Python311\site-packages\pproxy\server.py", line 297, in prepare_connection
    await self.rproto.connect(reader_remote=reader_remote, writer_remote=writer_remote, rauth=self.auth, host_name=whost, port=wport, writer_cipher_r=writer_cipher_r, myhost=self.host_name, sock=writer_remote.get_extra_info('socket'))
  File "C:\Users\x\AppData\Roaming\Python\Python311\site-packages\pproxy\proto.py", line 333, in connect
    await reader_remote.read_until(b'\r\n\r\n')
  File "C:\Program Files\Python311\Lib\asyncio\tasks.py", line 492, in wait_for
    raise exceptions.TimeoutError() from exc
TimeoutError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Users\x\AppData\Roaming\Python\Python311\site-packages\pproxy\__main__.py", line 3, in <module>
    main()
  File "C:\Users\x\AppData\Roaming\Python\Python311\site-packages\pproxy\server.py", line 912, in main
    asyncio.get_event_loop().run_until_complete(test_url(args.test, args.rserver))
  File "C:\Program Files\Python311\Lib\asyncio\base_events.py", line 653, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "C:\Users\x\AppData\Roaming\Python\Python311\site-packages\pproxy\server.py", line 863, in test_url
    raise Exception('Unknown remote protocol')
Exception: Unknown remote protocol

And the following is the exact same call through Python 3.10.9 on the same system:
python -m pproxy -r "http+ssl://uk2144.nordvpn.com:89#user:pass" --test "https://ipinfo.io/json" -d -v
============ uk2144.nordvpn.com:89 ============
HTTP/1.1 200 OK
access-control-allow-origin: *
x-content-type-options: nosniff
content-type: application/json; charset=utf-8
content-length: 244
date: Fri, 03 Mar 2023 06:11:15 GMT
x-envoy-upstream-service-time: 2
strict-transport-security: max-age=2592000; includeSubDomains
vary: Accept-Encoding
Via: 1.1 google
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
Connection: close
--------------------------------
{
  "ip": "178.238.x.x",
  "city": "London",
  "region": "England",
  "country": "GB",
  "loc": "x,-x",
  "org": "x",
  "postal": "x",
  "timezone": "Europe/London",
  "readme": "https://ipinfo.io/missingauth"
}
============ success ============

You can see it's failing on the initial GET request where it reads until it finds \r\n\r\n.
Tested:

Python 3.10.9: Success
Python 3.10.10: Success
Python 3.11.0a1: Success
Python 3.11.0a5: Success
Python 3.11.0a6: Fails
Python 3.11.0b1: Fails
Python 3.11.0: Fails
Python 3.11.2: Fails

So it seems like Python 3.11.0a6 introduced an issue. If I install 3.11.0a6, and overwrite the Lib/asyncio folder with the one from 3.11.0a5, it works.
After further testing if I overwrite just the Lib/asyncio/sslproto.py file with the one from 3.11.0a5, it works. So the error is there somewhere.

Fixed, waiting for merge.
#163


Prevent sampling 2x more than requested when max_steps is set

Hello!
Pull Request overview

Prevent sampling 2x more than requested

Details
max_pairs was used to limit pos_pairs and neg_pairs, but that results in 2 * max_pairs being created. This fixes that by placing a // 2 over max_pairs.

Tom Aarsen

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


Device selection

allow device selection at script start (if multiple were saved as working devices) . This implies saving all the working devices, besides the last working one.

menu could look like this:

last working device (ip + name). if last known is empty then show menu items 2. and 3.
previously working devices > which opens a new menu with all devices in format: ip + name . if the list is empty, automatically initiate the setup of a new device
set up a new device (first must use 'adb kill-server' to refresh the list of usb connected devices)
connect by known IP (manually input the IP:PORT if adb is already running on that device in tcpip mode (wifi))

alternatively, disconnect adb and wipe last_working_device.conf before attempting new connection

This feature would be useful. Thx for considering its implementation.


ci: merge staging to master

This is an automatic PR generated by the pipeline CI/CD. This will be automatically fast-forward merged if successful.

Pipeline Attempt on<PHONE_NUMBER> for 2e41196b53bc62382c70d37e9f38b9201453d2bd
https://gitlab.com/MatrixAI/open-source/js-quic/-/pipelines/1034131882

Pipeline Succeeded on<PHONE_NUMBER> for 2e41196b53bc62382c70d37e9f38b9201453d2bd
https://gitlab.com/MatrixAI/open-source/js-quic/-/pipelines/1034131882


Randomizer Crash on Seed Generation

New issues must complete all sections of this template or they will be
automatically closed.
Use this template if your bug does not relate to a seed being completable due
to relic placement.
Seed Information
SteelMinotaur35
Randomizer version:
3.15.0
Operating system and version:
Win10Pro 19045.3570
Browser and version:
Emulator and version:
Bug description

How to reproduce:
Repeatedly tried to generate the seed in GitBash as well as PowerShell and received the same error.
Please see attached preset file.
forge.json

Can't figure out exactly what's going on, but it's because way too much stuff is done with Holy Glasses. Removing them from the Zircon jar resolves the issue. I think that's just there for convenience so it still works?

Correct, they need to be in the vase so people don't have to Richter skip multiple times. If they are removed it solves the problem?

Yes not having them there frees up the problematic slot.

I still think there is a bug there though so I will keep this open.

Turns out I had a capital letter where it didn't belong and that was causing all of the problems including the softlocks.

What was it now I want to know?

Well, turns out you were still right about the Glasses being in a jar was a problem. But the soft lock that DB experienced was because I spelled "Holy glasses" like "Holy Glasses".

Oh the location, yeah I totally didn't even think that would do it. Closing this.


Enrich cycles by splitting lts/support/discontinued/eol/extendedSupport

Some fields declared in product's front matter (lts, eol, discontinued, support and extendedSupport), can accept both Date or boolean values. This is easier for describing and maintaining products (in front matter), but make it harder and error-prone to use in templates or for generating the API (see #2700).
This commit enrich cycles with new fields to reduce that downside, by splitting boolean and Date values to a pair of new fields:

is_lts / lts_from, derived from the lts field.
is_eol / eol_from, derived from the eol field.
is_discontinued / discontinued_from, derived from the discontinued field.
is_active_support_over / active_support_until, derived from the support field.
is_extended_support_over / extended_support_until, derived from the extendedSupport field.

This commit also introduce a new naming convention for computed fields (snake_case) to distinguish them easily from declared fields (that are using camelCase). This naming convention as been applied to daysTowardXxx fields, so they have been renamed to days_toward_xxx.

@captn3m0, checked a lot of different pages on https://deploy-preview-2708--endoflife-date.netlify.app/ and LGTM. But we should be careful with this PR.

I inverted  the condition  for active and extended support.
This opened the possibility to refactor code, and this feels more exact for extended support. Before that inversion the is_extended_supported was true even when a product was not eol, which did not feel right. Now, with is_extended_support_over we only give an information about whether the extendedSupport date is in the past or not.


Default orientation for some trackers

Default mounting orientations for some trackers should be set according to our recommendations, not just front. Currently it's: left upper arm, left lower arm, left hand - left; right upper arm, right lower arm, right hand - right; hip - right.

Chest, waist and hip should be front! Not side!
Thighs: front
Ankles: side (outwards)

Well The Docs™ recommends waist on the side: https://docs.slimevr.dev/server/putting-on-trackers.html. Which I belive is the leftower from when it was factually hip... We should get to a consensus, recommend this to users and use as a default, since Poly and Uriel are designing the page in wizard about putting trackers on.

That’s just your picture that I didn’t remove. We could remove them now.

Okay. Then front. Thought it still says "or left", but yea...

#679 should be completed for this

Why? No.

#679 should be completed for this

Why? No.

So that ankles and upper arms can be diagonal

We just need them to be on the side by default it's way better than front already. Please don't block this feature by another feature (that I honestly don't think should exist at all). We need something that is better than current one. If we add diagonal mounting in the future (I don't think we should), we can change defaults.


layers: Lighten object tracker slightly

Just avoiding some repeated unordered_map lookups.
Signed-off-by: Chris Forbes<EMAIL_ADDRESS>

+1

cherry-picked and pushed to master


AJ-1533: Spring Boot 3.2.2 / Spring Framework 6.1.3

Upgrade Spring Boot 3.2.1 -> 3.2.2, which includes an upgrade to Spring Framework 6.1.3.
Release notes: https://github.com/spring-projects/spring-boot/releases/tag/v3.2.2
Should resolve a Dependabot issue.

@jladieu @ashanhol this item from the release notes is timely: https://github.com/spring-projects/spring-boot/issues/39128


"refreshing" label not styled as the pull and refresh labels with ListView

When using the custom attribute "ptr:headerTextColor" to change the textColor, the colour only gets applied to the colour of the pullLabel and releaseLabel. This is because the LoadingLayout is called from the PullToRefreshListView to generate the loading text while it is called from PullToRefreshBase for the other two, and the equivalent styling code is missing from the former. This can be fixed by adding the following lines to PullToRefreshListView.java at line 136:
// Styleables from XML - adapted from PullToRefreshBase Line 540 and 572-591
TypedArray a = context.obtainStyledAttributes(attrs, R.styleable.PullToRefresh);
if (a.hasValue(R.styleable.PullToRefresh_headerTextColor)) {
	final int color = a.getColor(R.styleable.PullToRefresh_headerTextColor, Color.BLACK);
	if (null != headerLoadingView) {
		headerLoadingView.setTextColor(color);
	}
	if (null != footerLoadingView) {
		footerLoadingView.setTextColor(color);
	}
}
if (a.hasValue(R.styleable.PullToRefresh_headerBackground)) {
	this.setBackgroundResource(a.getResourceId(R.styleable.PullToRefresh_headerBackground, Color.WHITE));
}
a.recycle();

I've also noticed that when you use a background close to white, it's very difficult to see the ProgressBar (pull_to_refresh_progress), as it is close to white while the arrow image is black. If anyone has a suggestion how to style this, it would be appreciated!

For what it's worth i cured my progressBar issue by replacing
style="?android:attr/progressBarStyleSmall"
with
style="?android:attr/progressBarStyleSmallInverse"
in res/layout/pull_to_refresh_header.xml
Unfortunately i'm not sure how this might be made to be customisable without modifying the src for the library. Any ideas?


closes #1117: never return html code as the API response

:heavy_check_mark: Confirmed with a request like:
curl -H "x-cassandra-token: ..." http://<IP_ADDRESS>:8082/v2/namespaces/namespace/collections/payu/1/quiz/maths/q1/options/[0] -v
*   Trying <IP_ADDRESS>:8082...
* TCP_NODELAY set
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8082 (#0)
> GET /v2/namespaces/namespace/collections/payu/1/quiz/maths/q1/options/[0] HTTP/1.1
> Host: <IP_ADDRESS>:8082
> User-Agent: curl/7.68.0
> Accept: */*
> x-cassandra-token: ...
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Date: Tue, 20 Jul 2021 11:30:06 GMT
< Content-Length: 0
<
* Connection #0 to host <IP_ADDRESS> left intact

which used to return the HTML.
:heavy_check_mark:  Checked the GraphQL playground, works fine.
:heavy_check_mark: INT tests should be fine as well.

✔ Checked the GraphQL playground, works fine.

@ivansenic the swagger ui still works, correct?

heavy_check_mark Checked the GraphQL playground, works fine.

@ivansenic the swagger ui still works, correct?

Yep it works, I double checked.. I think this settings is only how the errors are reported, thus has nothing with actually serving content.


Refine serving and networking client initialization

I refined to initialize serving and networking client in pkg/types.go instead of initialize them in specific commands. So that we can uniform client initialization and make it easier to write unit tests.

@gyohuangxin Looks nice generally, I left some minor comments. Thanks!

/lgtm
Thanks @gyohuangxin for the refining. Looks good and merging!


Fun sound effects

Have fun sound effects when you type a new word or a lootbox is unlocked and stuff like that

Added in Audio branch


feat(compute): Stateful mig metadata example

Description
Fixes #216660851
Checklist
Readiness

[x] Yes, merge this PR after it is approved
[ ] No, don't merge this PR after it is approved

Style

[x] My sample follows the rules described for Terraform in the Effective Samples style guide
[x] My sample follows the other requirements and best practices in the Contributing
guide

Testing

[ ] I have performed tests described in the Contributing guide:
No, this doesn't work as per https://github.com/terraform-google-modules/terraform-docs-samples/issues/501

[x] Tests pass: terraform apply
[x] Lint pass: terraform fmt check

Intended location

[x] Yes, this sample will be (or already is) included on cloud.google.com
Location(s):
https://cloud.google.com/compute/docs/instance-groups/configuring-stateful-metadata-in-migs

API enablement

[x] If the sample needs an API enabled to pass testing, I have added the service to the Test setup file

Review

[x] If this sample adds a new directory, I have added codeowners to the CODEOWNERS file

/gcbrun

Noticed following errors. These seem to unrelated. Raising a bug for the following.
Step #4 - "test-samples-2": TestSamples/2/sqlserver_instance_private_ip 2023-10-19T18:30:26Z retry.go:99: Returning due to fatal error: FatalError{Underlying: error while running command: exit status 1;
Step #4 - "test-samples-2": Error: Unable to remove Service Networking Connection, err: Error waiting for Delete Service Networking Connection: Error code 9, message: Failed to delete connection; Producer services (e.g. CloudSQL, Cloud Memstore, etc.) are still using this connection.

tep #3 - "test-samples-1": TestSamples/1/workflows 2023-10-19T19:07:08Z command.go:185: Error: Error creating Trigger: googleapi: Error 400: Invalid resource state for "": Permission denied while using the Eventarc Service Agent. If you recently started to use Eventarc, it may take a few minutes before all necessary permissions are propagated to the Service Agent. Otherwise, verify that it has Eventarc Service Agent role.

Step #2 - "test-samples-0": TestSamples/0/basic 2023-10-19T19:10:15Z command.go:185: Error: Error creating Trigger: googleapi: Error 400: Invalid resource state for "": Permission denied while using the Eventarc Service Agent. If you recently started to use Eventarc, it may take a few minutes before all necessary permissions are propagated to the Service Agent. Otherwise, verify that it has Eventarc Service Agent role.

Step #2 - "test-samples-0": TestSamples/0/basic 2023-10-19T19:10:15Z command.go:185:         "description": "Permission denied while using the Eventarc Service Agent. If you recently started to use Eventarc, it may take a few minutes before all necessary permissions are propagated to the Service Agent. Otherwise, verify that it has Eventarc Service Agent role."

/gcbrun

/gcbrun

/gcbrun

/gcbrun


Fix manual image upload errors

replace onUpload attribute with onSuccess to fix the error for image not uploading in the manual process

Hello mikko
I have resloved a small bug in the image-upload.tsx module which leads to we cannot upload image manually so kindly

Hello Mikko,
i have requested you to help me for integrating steamship models and run the ai companion project this is my final year project i have mailed you so many time kindly help me out please.

It will good if you provide a alternative communication for effective communication
Dear Mikko,
I hope you are doing well. My name is Rakesh Valasala, and I am a final-year undergraduate student at Sree Vidyanikethan Engineering College, India. My team and I are working on our graduation project, which is closely based on your work on the ai companion GitHub repository. We are incredibly impressed with your project and its potential applications.
However, we have encountered some challenges during development and would greatly appreciate your assistance. Specifically, we are facing the following issues:
How to set up and run Steamship models: We are struggling to configure and run the models locally or within our project environment.
Integrating Steamship models into our companion project: We're unsure how to integrate the Steamship model with our AI Companion project (built using TypeScript, React, Next.js, and MongoDB) to retrieve and handle responses.
Integrating Bolna and adding voice functionality: We aim to integrate voice functionality using Bolna but are unclear on how to achieve this.
Your expertise would be invaluable in helping us resolve these issues. If possible, could we schedule a call or Google Meet at a convenient time for you? Alternatively, I would be happy to work with you through other communication channels. Please let me know your availability, and I will make sure to attend the meeting.
My contact details are:
Email<EMAIL_ADDRESS>Mobile: +91<PHONE_NUMBER>
LinkedIn: My LinkedIn Profile


Fix to address save defaults to .txt file

pass language not mode to get the extension.

Fix: getExtensions method expects language name but the textFileService is passing the mode. Get language by calling getLanguageName with.mode and then pass it in for getExtensions.
This PR fixes #103704

I have a feeling @aeschli addressed this via https://github.com/microsoft/vscode/commit/9f7139a4d71c4861b01915b8dc631ffb65910b5b.


suggestions for DOI tool module

@dignizio-usgs looks like you made this much more helpful for a new user.

I've made some suggestions to wording to consider.  A few that I strongly encourage you to accept (at some variation) include a note about this tool being for USGS products, the note about needing to be on the USGS network (or vpn) to use staging, and the note that you can not delete a published DOI

I initially ran into some crazy errors, but found out that I had an old version of the DOI Tool... might be worth mentioning near top that you need at least version X .

-don't accept changes to the output, that was due to me testing the cells.
-I don't think the camelCase is up to PEP8 standards but I can't say I'm an expert on that... I think variables should be set like so:  str_variable = 'get rid of camel case'

To avoid issues with Jupyter notebook cells, I reviewed your changes and implemented them in master rather than merging. Thanks for the feedback.


ComboBox - handle timezones when searching on date columns

In cases where a ComboBox shows date values, search text will be based on a date value in the configured local timezone. This will not necessarily match the server timezone which may cause unexpected search results when filters are applied to tables. We'll need to do some sort of converting date search text to server time zone before applying filters.
https://github.com/deephaven/web-client-ui/pull/2077 should be wiring up the general search feature. The timezone support can be added after that merges

This seems to already work as expected once https://github.com/deephaven/web-client-ui/pull/2077 is merged. No need for special timezone work.


Stage 1

With the closing of #11  on develop, when we merge #21 we would be ready to make the demo for the first stage.
Is there something else that we should do about it or before it?
Maybe we need to improve the logs for the demo?
I think that having #20  would be nice, but it can wait or be done in parallel with the second stage.

Regarding this proposal:

For the demo, shall we use something like this but with much short output?

I agree that we should make some clear log reporting for the demo (and for ourselves too, probably). Some log with clear representation of chain of transaction built by Seath. Maybe just TX ID's, like
ID-1
-> ID-2
-> ID-3
...

?
So we can show them in cardanoscan afterwards.
Also, maybe some simple representation of state before chain was submitted and after.
I think that people, who will watch the demo during acceptance, won't be too technical (if technical at all), so it's better to make things as clear as possible.

I was also thinking about some "script generator", so we can generate fresh script easily for the demo if we need. But we can also just change source before exporting. Add some line like traceIfFalse "Script-{UUID} True.

At first I thouth that we can use the dot language and a renderer like https://github.com/csicar/purescript-graphviz to do a graphical display of what's happening in the same terms as plutus-pioneer diagrams.
Now I think that, as we already using Purscript we can serve a little webpage that can be used as front end, like in the future (next stage demo) we can set the actions there and watch. But right now the only config available would be the number of users (from 1 to 4). So, we would have a webpage with a single form for the number of wallets, a submission button, and a table with the actions, the state of the signature of them, and the final transaction hash with a link to cardanoScan.

I tried
spago bundle-app --main test/Main.purs --to output.js -v
Then the code compile but then I got this message:
[debug] Running command: `purs bundle "output/*/*.js" -m test/Main.purs --main test/Main.purs -o output.js`
Couldn't find a CommonJS module for the specified main module: test/Main.purs
[error] Bundle failed.

It seems to be the error  of
purs bundle "output/*/*.js" -m test/Main.purs --main test/Main.purs -o output.js
But I don't know what I'm doing wrong.


Vim9: no error when extending number dictionary with mixed values

Describe the bug
In Vim9 script, extending a dictionary of numbers with a dictionary of mixed values (e.g. strings, booleans) doesn't raise any error.
To Reproduce
Run this shell command:
vim -Nu NONE -S <(cat <<'EOF'
    vim9script
    def Func()
        extend({a: 1}, {b: 'x', c: true})
    enddef
    Func()
EOF
)

No error is raised.
Expected behavior
E1013 is raised:
E1013: Argument 2: type mismatch, expected dict<number> but got dict<any>

Because {a: 1} is a dictionary of numbers, while {b: 'x', c: true} is a dictionary of strings and booleans.  The result has the type dict<any> which no longer matches the original type dict<number> of {a: 1}.
Environment

Vim version: 8.2 Included patches: 1-2253
OS: Ubuntu 16.04.7 LTS
Terminal: xterm(363)

Additional context
Regression introduced in 8.2.1996.

Same issue at the script level:
vim9script
extend({a: 1}, {b: 'x', c: true})

No error is raised.
Although this time, I don't think it's a regression. I think type checking never worked as expected here.

Patch adding a test.
diff --git a/src/testdir/test_vim9_builtin.vim b/src/testdir/test_vim9_builtin.vim
index accbca237..73a40593a 100644
--- a/src/testdir/test_vim9_builtin.vim
+++ b/src/testdir/test_vim9_builtin.vim
@@ -234,6 +234,8 @@ def Test_extend_arg_types()
   extend(res, map([1, 2], (_, v) => ({})))
   assert_equal([{}, {}], res)

+  assert_fails('extend({a: 1}, {b: "x", c: true})', 'E1013:')
+
   CheckDefFailure(['extend([1, 2], 3)'], 'E1013: Argument 2: type mismatch, expected list<number> but got number')
   CheckDefFailure(['extend([1, 2], ["x"])'], 'E1013: Argument 2: type mismatch, expected list<number> but got list<string>')
   CheckDefFailure(['extend([1, 2], [3], "x")'], 'E1013: Argument 3: type mismatch, expected number but got string')
@@ -241,6 +243,7 @@ def Test_extend_arg_types()
   CheckDefFailure(['extend({a: 1}, 42)'], 'E1013: Argument 2: type mismatch, expected dict<number> but got number')
   CheckDefFailure(['extend({a: 1}, {b: "x"})'], 'E1013: Argument 2: type mismatch, expected dict<number> but got dict<string>')
   CheckDefFailure(['extend({a: 1}, {b: 2}, 1)'], 'E1013: Argument 3: type mismatch, expected string but got number')
+  CheckDefFailure(['extend({a: 1}, {b: "x", c: true})'], 'E1013: Argument 2: type mismatch, expected dict<number> but got dict<any>')
 enddef

 def Test_extend_return_type()

Describe the bug
In Vim9 script, extending a dictionary of numbers with a dictionary of
mixed values (e.g. strings, booleans) doesn't raise any error.
To Reproduce
Run this shell command:
vim -Nu NONE -S <(cat <<'EOF'
    vim9script
    def Func()
        extend({a: 1}, {b: 'x', c: true})
    enddef
    Func()
EOF
)

This specific example doesn't explicitly say that it is a dictionary of
numbers.  One might argue that the type is only created after calling
extend().
A better example:
var d: dict = {a: 1}
extend(d, {b: 'x', c: true})
Still no error is given, not even at runtime, although the dictionary
now doesn't match the type.  This can cause a crash:
var d: dict = {a: 1}
extend(d, {b: 'x', c: true})
for key in d->keys()
echo d[key] + 5
endfor

Because {a: 1} is a dictionary of numbers, while {b: 'x', c: true}
is a dictionary of strings and booleans.  The result has the type
dict<any> which no longer matches the original type dict<number>
of {a: 1}.

So we would need to check that extend() doesn't violate the type.  I was
aware of this problem, but not yet sure how to fix it.  Check the result
after calling extend() would be slow, especially when extending a large
dictionary.
Probably the best solution is to pass the required type to the builtin
function and let extend() check the type internally.  However, the
generic mechanism for calling a builtin function doesn't support this,
and we only need it for a few functions.
So we probably need to check when compiling that the type of the second
extend() argument is OK.
At the script level it might be more complicated.  When evaluating the
first argument we would need to pass the type together with the value.
That mechanism doesn't exist yet.  We'll need to add it, otherwise the
crash mentioned above could still happen.  Or we would always need to
check the type when getting an item from a list or dictionary, which is
inefficient.
--
hundred-and-one symptoms of being an internet addict:
78. You find yourself dialing IP numbers on the phone.
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Describe the bug
In Vim9 script, extending a dictionary of numbers with a dictionary of
mixed values (e.g. strings, booleans) doesn't raise any error.
To Reproduce
Run this shell command:
vim -Nu NONE -S <(cat <<'EOF'
    vim9script
    def Func()
        extend({a: 1}, {b: 'x', c: true})
    enddef
    Func()
EOF
)

This specific example doesn't explicitly say that it is a dictionary of
numbers.  One might argue that the type is only created after calling
extend().
A better example:
var d: dict = {a: 1}
extend(d, {b: 'x', c: true})
Still no error is given, not even at runtime, although the dictionary
now doesn't match the type.  This can cause a crash:
var d: dict = {a: 1}
extend(d, {b: 'x', c: true})
for key in d->keys()
echo d[key] + 5
endfor

Because {a: 1} is a dictionary of numbers, while {b: 'x', c: true}
is a dictionary of strings and booleans.  The result has the type
dict<any> which no longer matches the original type dict<number>
of {a: 1}.

So we would need to check that extend() doesn't violate the type.  I was
aware of this problem, but not yet sure how to fix it.  Check the result
after calling extend() would be slow, especially when extending a large
dictionary.
Probably the best solution is to pass the required type to the builtin
function and let extend() check the type internally.  However, the
generic mechanism for calling a builtin function doesn't support this,
and we only need it for a few functions.
So we probably need to check when compiling that the type of the second
extend() argument is OK.
At the script level it might be more complicated.  When evaluating the
first argument we would need to pass the type together with the value.
That mechanism doesn't exist yet.  We'll need to add it, otherwise the
crash mentioned above could still happen.  Or we would always need to
check the type when getting an item from a list or dictionary, which is
inefficient.
--
hundred-and-one symptoms of being an internet addict:
78. You find yourself dialing IP numbers on the phone.
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

This specific example doesn't explicitly say that it is a dictionary of
numbers.  One might argue that the type is only created after calling
extend().

I wasn't sure when I posted, but now I think you're right.  {a: 1} is not used in a variable declaration.  It's just a value.  There is no reason to enforce type checking here.

Still no error is given, not even at runtime, although the dictionary
now doesn't match the type.  This can cause a crash:

var d: dict = {a: 1}
extend(d, {b: 'x', c: true})
for key in d->keys()
echo d[key] + 5
endfor

Yes, it still crashes in a :def function on 8.2.2269:
vim9script
def Func()
    var d: dict<number> = {a: 1}
    extend(d, {b: 'x', c: true})
    for key in d->keys()
        echo d[key] + 5
    endfor
enddef
Func()

The crash started from 8.2.0730.
When instrumented by valgrind, Vim doesn't crash; instead, an internal error is raised:
E685: Internal error: get_var_special_name()
42

Not sure why 42 is echo'ed afterward.
Logs:

backtrace
asan log
valgrind log

This specific example doesn't explicitly say that it is a dictionary of
numbers.  One might argue that the type is only created after calling
extend().

I wasn't sure when I posted, but now I think you're right.  {a: 1} is not used in a variable declaration.  It's just a value.  There is no reason to enforce type checking here.

Still no error is given, not even at runtime, although the dictionary
now doesn't match the type.  This can cause a crash:

var d: dict = {a: 1}
extend(d, {b: 'x', c: true})
for key in d->keys()
echo d[key] + 5
endfor

Yes, it still crashes in a :def function on 8.2.2269:
vim9script
def Func()
    var d: dict<number> = {a: 1}
    extend(d, {b: 'x', c: true})
    for key in d->keys()
        echo d[key] + 5
    endfor
enddef
Func()

The crash started from 8.2.0730.
When instrumented by valgrind, Vim doesn't crash; instead, an internal error is raised:
E685: Internal error: get_var_special_name()
42

Not sure why 42 is echo'ed afterward.
Logs:

backtrace
asan log
valgrind log


TLS

@garethr I am not confident for supporting all OS, but it should be fine

Hi @luckyraul, the solution looks promising to me. I think this PR can be improved by adding a test and information to the README on how to use / generate these certificates.

This looks great. Thanks @luckyraul. It would be really useful to have some simple unit tests added to the existing test suite to verify this, and help make sure it doesn't get accidentally broken. The CONTRIBUTING doc has some details but please do ask any questions if you're not too familiar with Puppet testing.

@luckyraul Thanks for adding the tests, and the build passes now as well. @garethr Are the unit tests sufficient or should Beaker integration tests also be added to ensure Docker indeed uses TLS now? Or will we test this manually?

@luckyraul this looks great. Thanks for adding the tests as well.


fix: server corrupting index

This PR fixes the issue where the index would be corrupted after running and shutting down the web server.
The issue occured from the update thread not being joined on shutdown and, hence, not gracefully closing its connection to the index.
2 things have been added in this PR:

termination feature for ctrlc crate. This allows graceful shutting down on a SIGTERM signal which docker and kubernetes use to shut down processes. Currently, running ord in a docker container completely bypasses shutting down gracefully without this.
an UPDATE_THREAD mutex which holds the update thread which the server creates and joins onto it when shutting down gracefully. This allows the update thread to go through the graceful shutdown procedure of committing any uncommitted entries to the index and closing the connection to it.

This has been tested with the following steps:

Run ord in server mode
curl the blockheight endpoint until the server is up and we get the blockheight returned
Send SIGTERM/SIGINT signal
Run the server again
curl the blockheight endpoint
At this point, before the changes, the server would not accept connections and would take a while to start up while it fixes the index. After these proposed changes, it starts up straight away.

Very nice. It fixes the issue for me.
One problem I see is that if I run "ord server" as non-root I see
Listening on http://<IP_ADDRESS>:80
error: Permission denied (os error 13)

as expected (because non-root processes can't listen on low numbered ports), but after that the index is corrupted.

This fixes some persistent issues I was having using AWS + EBS. Even if I tried to kill gracefully (kill -INT %1) it would still kill forcefully and would have to repair the index, resulting in 30 min start times for me on an index-sats index after killing the server (even if killing gracefully). But this fixes it! This is AMAZING.

I think the last commit should fix that up, along with another issue where a second ctrlc wouldn't be picked up to force kill

It doesn't appear to fix the issue.
There's a process::exit(1) before the update_thread.join() when the main thread returns an error

The issue this is fixing is #1861 btw.

I think the last commit should fix that up, along with another issue where a second ctrlc wouldn't be picked up to force kill

It doesn't appear to fix the issue.
There's a process::exit(1) before the update_thread.join() when the main thread returns an error

Ah, oops. You're absolutely right. Will fix it up in a little.

Ok, that should do it

This will also resolve #2180 and #2142

Ok, that should do it

So now when I run "ord server" I see the same error message because I don't have permission to listen on port 80, but then I don't get my shell prompt back. Ord keeps running, updating the index each time a block is mined. I can hit control-C once and it exits gracefully without corrupting the index file. But I shouldn't have to hit control-C when a fatal error has already happened.

How about this? This appears to fix the issue for me:
diff --git a/src/lib.rs b/src/lib.rs
index 020d2bc..4081d0b 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -192,7 +192,9 @@ pub fn main() {
       eprintln!("{}", err.backtrace());
     }

-    gracefully_shutdown_update_thread();
+    if !SHUTTING_DOWN.fetch_or(true, atomic::Ordering::Relaxed) {
+      gracefully_shutdown_update_thread();
+    }

     process::exit(1);
   }

Yeah, there's nothing to notify that thread to break out of the loop 🙈 I think the proposed change will work in the case of the server erroring during normal operation but it wouldn't run the graceful shutdown in the case that the server errors after a shutdown is already executed.
I'll add the setting of the SHUTTING_DOWN value in the function itself to explicitly have it correct before we join.

Thanks, for the PR. Looks good so far!
I just wanted to rename some variables and make the CI pass but I'm unable to push my changes. It's weird because github shows that maintainers are allowed to push changes to this branch. Opened a PR with the changes in #2275  if you could merge them in. I'm going to merge & squash anyways so don't worry about a merge commit.

Thanks, for the PR. Looks good so far!
I just wanted to rename some variables and make the CI pass but I'm unable to push my changes. It's weird because github shows that maintainers are allowed to push changes to this branch. Opened a PR with the changes in #2275 if you could merge them in. I'm going to squash-merge anyways so don't worry about a merge commit.

Reviewed and merged #2275, don't see a need to update this one. Thanks for this fix @victorkirov and the testing @gmart7t2 !