<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/crates/hashx/src/generator.rs, branch main</title>
<subtitle>mirror of https://gitlab.torproject.org/tpo/core/arti
</subtitle>
<id>http://git.dilluti0n.com/mirrors/arti.git/atom?h=main</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=main'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2026-05-12T20:55:43Z</updated>
<entry>
<title>Upgrade rand crates to 0.10.</title>
<updated>2026-05-12T20:55:43Z</updated>
<author>
<name>Wesley Aptekar-Cassels</name>
<email>me@wesleyac.com</email>
</author>
<published>2026-05-07T20:06:21Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=a18167928901d8c88cd1cdd87346de8ad1ee42a2'/>
<id>urn:sha1:a18167928901d8c88cd1cdd87346de8ad1ee42a2</id>
<content type='text'>
When the circ-padding feature is enabled, we use maybenot, which does
not yet support rand 0.10. In the meantime, enabling this feature pulls
in rand 0.9. This is not ideal, but should be okay as a temporary
situation.

This also replaces the use of ReseedingRng (which was removed in 0.10)
with the reseeding_rng crate. This is somewhat less performant, but it
should be okay.
</content>
</entry>
<entry>
<title>hashx: Use .is_multiple_of() as recommended by clippy</title>
<updated>2026-02-16T15:22:24Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2026-02-09T12:37:22Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=f637aa7288a5dd7263873ebbb101fc2c98510fe3'/>
<id>urn:sha1:f637aa7288a5dd7263873ebbb101fc2c98510fe3</id>
<content type='text'>
I'm applying the clippy suggestion, even though in this case, using
`is_multiple_of()` instead of `%` is a bit questionable IMO, because the
`% 3` operation can never panic.
</content>
</entry>
<entry>
<title>Rename variables named "gen"</title>
<updated>2025-08-07T15:28:39Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-08-06T02:01:09Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=9da44e30b2b61e80ca8cc89db272d9406347385d'/>
<id>urn:sha1:9da44e30b2b61e80ca8cc89db272d9406347385d</id>
<content type='text'>
This is now a reserved identifier.  The automatic migration
changed it to a raw identifier (`r#gen`), but it's better to use a
different name.
</content>
</entry>
<entry>
<title>Switch Cargo.toml files to edition 2024.</title>
<updated>2025-08-07T15:28:36Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-08-06T01:19:58Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=77b0de43b8c67cdb81befe0680a3df43b6ad37bc'/>
<id>urn:sha1:77b0de43b8c67cdb81befe0680a3df43b6ad37bc</id>
<content type='text'>
First, run

```
git grep -l "^edition =" |
    xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```

Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.

Third, run cargo fmt again.
</content>
</entry>
<entry>
<title>Update code for Edition 2024</title>
<updated>2025-08-07T15:28:31Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-08-07T12:44:47Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=0453fb4be8cf618b94230812957ce1db1afe74bd'/>
<id>urn:sha1:0453fb4be8cf618b94230812957ce1db1afe74bd</id>
<content type='text'>
1. Run cargo fix --edition

2. Selectively revert the "if let"-&gt;"match" changes.
   These changes are meant to protect us from the lifetime changes
   for "if let" bindings in Rust 2024.
   But we're not actually relying on the old lifetime rules
   anywhere, and the match syntax here is quite ugly.

3. Automatically revert `$pat:expr_2021` to `$pat:expr`.
   (We don't actually want to restrict the expression syntax
   that our macros accept).
   Done with
   `git grep -l expr_2021 | xargs perl -i -pe 's/expr_2021/expr/g;'`

4. Run cargo fmt.
</content>
</entry>
<entry>
<title>hashx: Cleanup around Instruction and NUM_INSTRUCTIONS</title>
<updated>2023-08-25T20:14:24Z</updated>
<author>
<name>Micah Elizabeth Scott</name>
<email>beth@torproject.org</email>
</author>
<published>2023-08-25T20:11:47Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=2cb50d1be35a4a6623ff318fcf8ac2620521bb1f'/>
<id>urn:sha1:2cb50d1be35a4a6623ff318fcf8ac2620521bb1f</id>
<content type='text'>
This patch tries to make some of the expressions around NUM_INSTRUCTIONS
more convenient. We can import it directly where it's needed, but most
uses are replaced by new type aliases for InstructionArray and
InstructionVec.

No change to any hashx_cachegrind iai benchmarks
</content>
</entry>
<entry>
<title>Rustfmt</title>
<updated>2023-08-24T16:01:44Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-08-24T16:01:44Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=b1fd9934a166392e8dc0acada4b5bea376569fb5'/>
<id>urn:sha1:b1fd9934a166392e8dc0acada4b5bea376569fb5</id>
<content type='text'>
</content>
</entry>
<entry>
<title>hashx: FixedCapacityVec: Move into its own module</title>
<updated>2023-08-24T12:50:20Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-08-24T12:23:20Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=6529846787aa65dc480edcca4a3e9cab1712e75b'/>
<id>urn:sha1:6529846787aa65dc480edcca4a3e9cab1712e75b</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Rustfmt</title>
<updated>2023-08-23T11:02:24Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-08-23T11:02:24Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=99def36084e65491482cd6871adc8972ccfd82ee'/>
<id>urn:sha1:99def36084e65491482cd6871adc8972ccfd82ee</id>
<content type='text'>
</content>
</entry>
<entry>
<title>RFC: hashx: Introduce FixedCapacityVec</title>
<updated>2023-08-23T10:59:24Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-08-23T10:48:40Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=3deb358cd2dd588baa560d347f1e69d078e28d9d'/>
<id>urn:sha1:3deb358cd2dd588baa560d347f1e69d078e28d9d</id>
<content type='text'>
This is quite shoddy.  It shouldn't be merged without some tidying up
and unit tests and so on.  Also I am confused about the difference
between NUM_INSTRUCTIONS and model::REQUIRED_INSTRUCTIONS.

However:

generate_interp_1000x
  Instructions:           220115418 (-1.147100%)
  L1 Accesses:            278918725 (-0.936103%)
  L2 Accesses:                   25 (-98.46248%)
  RAM Accesses:                 414 (-0.956938%)
  Estimated Cycles:       278933340 (-0.938920%)

generate_interp_1000x_c
  Instructions:           272748034 (No change)
  L1 Accesses:            349932970 (+0.000001%)
  L2 Accesses:                   76 (-1.298701%)
  RAM Accesses:                 405 (-0.491400%)
  Estimated Cycles:       349947525 (-0.000021%)

generate_compiled_1000x
  Instructions:           257344624 (-0.982784%)
  L1 Accesses:            343007206 (-0.753942%)
  L2 Accesses:               152502 (-17.12839%)
  RAM Accesses:                 809 (-0.369458%)
  Estimated Cycles:       343798031 (-0.797384%)

generate_compiled_1000x_c
  Instructions:           281855218 (No change)
  L1 Accesses:            362569043 (+0.000002%)
  L2 Accesses:                   87 (-4.395604%)
  RAM Accesses:                 466 (-0.427350%)
  Estimated Cycles:       362585788 (-0.000023%)

interp_u64_hash_1000x
  Instructions:            13451818 (-0.100680%)
  L1 Accesses:             16623452 (-0.105967%)
  L2 Accesses:                   28 (No change)
  RAM Accesses:                 392 (-1.507538%)
  Estimated Cycles:        16637312 (-0.107138%)

interp_8b_hash_1000x_c
  Instructions:             8618541 (No change)
  L1 Accesses:             12316165 (+0.000032%)
  L2 Accesses:                   80 (-2.439024%)
  RAM Accesses:                 428 (-0.465116%)
  Estimated Cycles:        12331545 (-0.000616%)

compiled_u64_hash_100000x
  Instructions:            87312230 (-1.358594%)
  L1 Accesses:             94397055 (-1.669415%)
  L2 Accesses:                  212 (-0.469484%)
  RAM Accesses:                 776 (-0.767263%)
  Estimated Cycles:        94425275 (-1.669144%)

compiled_8b_hash_100000x_c
  Instructions:            91547640 (No change)
  L1 Accesses:             98838176 (+0.000009%)
  L2 Accesses:                  134 (-4.964539%)
  RAM Accesses:                 481 (-0.414079%)
  Estimated Cycles:        98855681 (-0.000097%)
</content>
</entry>
</feed>
