Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Engineer can start the P2P module #3

Closed
PhilWindle opened this issue Mar 2, 2023 · 1 comment
Closed

Engineer can start the P2P module #3

PhilWindle opened this issue Mar 2, 2023 · 1 comment
Assignees
@spypsy

Comments

@PhilWindle
Copy link
Collaborator

An engineer can start an instance of the P2P module configured with a TxPool and a rollup source
@PhilWindle PhilWindle added this to A3 Mar 2, 2023
@PhilWindle PhilWindle converted this from a draft issue Mar 2, 2023
@PhilWindle PhilWindle added this to the 📜 Deploy a Contract milestone Mar 7, 2023
@spypsy spypsy self-assigned this Mar 9, 2023
@spypsy spypsy moved this from Todo to In Progress in A3 Mar 9, 2023
@spypsy spypsy mentioned this issue Mar 9, 2023
Merged
6 tasks
@spypsy spypsy moved this from In Progress to In Review in A3 Mar 10, 2023
@PhilWindle PhilWindle moved this from In Review to Done in A3 Apr 3, 2023
@iAmMichaelConnor
Copy link
Contributor

Closing as "Done" in A3 project board.

ludamad pushed a commit that referenced this issue Apr 14, 2023
@dbanks12
TxContext.hash() (#3)
80f93ea 
* tx context hash using proper generator

* implement TxContext.hash()
ludamad pushed a commit that referenced this issue Apr 17, 2023
@dbanks12 @ludamad
TxContext.hash() (#3)
142bb5a 
* tx context hash using proper generator

* implement TxContext.hash()
ludamad pushed a commit that referenced this issue Apr 17, 2023
@dbanks12 @ludamad
TxContext.hash() (#3)
bf12581 
* tx context hash using proper generator

* implement TxContext.hash()
ludamad pushed a commit that referenced this issue Jul 19, 2023
@jjwumaster
Merge pull request #3 from joss-aztec/jcf/jun2021update-and-valuation
4579387 
Document the  jun2021 update and asset valuation
ludamad pushed a commit that referenced this issue Jul 21, 2023
@jjwumaster
Merge pull request #3 from joss-aztec/jcf/jun2021update-and-valuation
3c22343 
Document the  jun2021 update and asset valuation
@spalladino spalladino mentioned this issue Jul 26, 2023
Closed
@iAmMichaelConnor iAmMichaelConnor removed this from A3 Jul 26, 2023
guipublic added a commit that referenced this issue Jun 3, 2024
@guipublic
fix merge issue #3
81cf85c
@ludamad ludamad mentioned this issue Jun 4, 2024
Merged
ludamad added a commit that referenced this issue Jun 6, 2024
@ludamad
feat(bb): stack traces for check_circuit (#6851)
eb35e62 
Overview:
If you are in a scenario where you have a failing call to check_circuit
and wish to get more information out of it than just the gate index, you
can use this feature to get a stack trace, see example below.

Usage instructions:
- On ubuntu (or our mainframe accounts) use `sudo apt-get install
libdw-dev` to support trace printing
- Use `cmake --preset clang16-dbg-fast-circuit-check-traces` and `cmake
--build --preset clang16-dbg-fast-circuit-check-traces` to enable the
backward-cpp dependency through the CHECK_CIRCUIT_STACKTRACES CMake
variable.
- Run any case where you have a failing check_circuit call, you will now
have a stack trace illuminating where this constraint was added in code.

Caveats:
- This works best for code that is not overly generic, i.e. where just
the sequence of function calls carries a lot of information. It is
possible to tag extra data along with the stack trace, this can be done
as a followup, please leave feedback if desired.
- There are certain functions like `assert_equals` that can cause gates
that occur _before_ them to fail. If this would be useful to
automatically report, please leave feedback.

Example:
```
[ RUN      ] standard_circuit_constructor.test_check_circuit_broken
Stack trace (most recent call last):
#4    Source "_deps/gtest-src/googletest/src/gtest.cc", line 2845, in Run
       2842:   if (!Test::HasFatalFailure() && !Test::IsSkipped()) {
       2843:     // This doesn't throw as all user code that can throw are wrapped into
       2844:     // exception handling code.
      >2845:     test->Run();
       2846:   }
       2847: 
       2848:   if (test != nullptr) {
#3    Source "_deps/gtest-src/googletest/src/gtest.cc", line 2696, in Run
       2693:   // GTEST_SKIP().
       2694:   if (!HasFatalFailure() && !IsSkipped()) {
       2695:     impl->os_stack_trace_getter()->UponLeavingGTest();
      >2696:     internal::HandleExceptionsInMethodIfSupported(this, &Test::TestBody,
       2697:                                                   "the test body");
       2698:   }
#2  | Source "_deps/gtest-src/googletest/src/gtest.cc", line 2657, in HandleSehExceptionsInMethodIfSupported<testing::Test, void>
    |  2655: #if GTEST_HAS_EXCEPTIONS
    |  2656:     try {
    | >2657:       return HandleSehExceptionsInMethodIfSupported(object, method, location);
    |  2658:     } catch (const AssertionException&) {  // NOLINT
    |  2659:       // This failure was reported already.
      Source "_deps/gtest-src/googletest/src/gtest.cc", line 2621, in HandleExceptionsInMethodIfSupported<testing::Test, void>
       2618:   }
       2619: #else
       2620:   (void)location;
      >2621:   return (object->*method)();
       2622: #endif  // GTEST_HAS_SEH
       2623: }
#1    Source "/mnt/user-data/adam/aztec-packages/barretenberg/cpp/src/barretenberg/circuit_checker/standard_circuit_builder.test.cpp", line 464, in TestBody
        461:     uint32_t d_idx = circuit_constructor.add_variable(d);
        462:     circuit_constructor.create_add_gate({ a_idx, b_idx, c_idx, fr::one(), fr::one(), fr::neg_one(), fr::zero() });
        463: 
      > 464:     circuit_constructor.create_add_gate({ d_idx, c_idx, a_idx, fr::one(), fr::neg_one(), fr::neg_one(), fr::zero() });
        465: 
        466:     bool result = CircuitChecker::check(circuit_constructor);
        467:     EXPECT_EQ(result, false);
#0    Source "/mnt/user-data/adam/aztec-packages/barretenberg/cpp/src/barretenberg/stdlib_circuit_builders/standard_circuit_builder.cpp", line 22, in create_add_gate
         19: {
         20:     this->assert_valid_variables({ in.a, in.b, in.c });
         21: 
      >  22:     blocks.arithmetic.populate_wires(in.a, in.b, in.c);
         23:     blocks.arithmetic.q_m().emplace_back(FF::zero());
         24:     blocks.arithmetic.q_1().emplace_back(in.a_scaling);
         25:     blocks.arithmetic.q_2().emplace_back(in.b_scaling);
gate number4
```
rahul-kothari pushed a commit that referenced this issue Aug 15, 2024
@charlielye
fix: Docker.dockerignore file can be huge. (#8023)
cee9d9a 
We run into some nutty error when dockerignore files get large (circleci
path):

```
#3 [internal] load metadata for docker.io/library/ubuntu:noble
#3 sha256:afb7fa05fafd7c9e9fe1ecefd45ae0531e51b736cd519c2fb8893340e4e08b59
#3 DONE 0.4s

#10 [internal] load build context
#10 sha256:8189bdeed2ad9e316ae51d8dddc8d96a01e5180ee99f9f37015f7c3dc8de7e41
#10 ERROR: rpc error: code = Internal desc = header list size to send violates the maximum size (1048896 bytes) set by server
```

This became the case with avm-transpiler as it's build context is the
root of the monorepo so it can gain access to the noir source code. The
autogenerated dockerignore file has to explicitly list every file in he
monorepo as a reverse match which eventually got so big something broke
internally to docker.

New script will not autogen the dockerignore file if its committed to
git. This PR includes a manually crafted one for avm-transpiler.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@spypsy spypsy

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@spypsy @iAmMichaelConnor @PhilWindle