| --- Log opened Tue Dec 21 00:00:40 2021 |
| 00:11 | | Kindamoody is now known as Kindamoody[zZz] |
| 00:55 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
| 01:01 | | gizmore|2 [kvirc@Nightstar-cg79p2.dip0.t-ipconnect.de] has joined #code |
| 01:02 | | gizmore|2 [kvirc@Nightstar-cg79p2.dip0.t-ipconnect.de] has quit [[NS] Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/] |
| 01:03 | | gizmore|2 [kvirc@Nightstar-cg79p2.dip0.t-ipconnect.de] has joined #code |
| 01:04 | | gizmore [kvirc@Nightstar-r64chs.dip0.t-ipconnect.de] has quit [Ping timeout: 121 seconds] |
| 01:29 | | Degi_ [Degi@Nightstar-mkkdbo.pool.telefonica.de] has joined #code |
| 01:32 | | Degi [Degi@Nightstar-qa9ata.pool.telefonica.de] has quit [Ping timeout: 121 seconds] |
| 01:32 | | Degi_ is now known as Degi |
| 02:00 | | gizmore [kvirc@Nightstar-0eko9p.dip0.t-ipconnect.de] has joined #code |
| 02:02 | | gizmore|2 [kvirc@Nightstar-cg79p2.dip0.t-ipconnect.de] has quit [Ping timeout: 121 seconds] |
| 03:27 | | * McMartin gets his Rust stuff kinda working! |
| 03:27 | <&McMartin> | It's 130 lines of code, though, and it has types with specs like `enum Value { Literal(i32), Pair(RefCell<(Rc<Node>, Rc<Node>)>) }` |
| 03:47 | | abudhabi_ [abudhabi@Nightstar-hg3nmi.adsl.tpnet.pl] has joined #code |
| 03:51 | | abudhabi__ [abudhabi@Nightstar-4v0thu.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 04:48 | | Vorntastic [uid293981@Nightstar-phvupn.irccloud.com] has joined #code |
| 04:48 | | mode/#code [+qo Vorntastic Vorntastic] by ChanServ |
| 06:30 | | macdjord [macdjord@Nightstar-7aijs7.dsl.bell.ca] has quit [Connection closed] |
| 06:30 | | macdjord [macdjord@Nightstar-7aijs7.dsl.bell.ca] has joined #code |
| 06:30 | | mode/#code [+o macdjord] by ChanServ |
| 11:01 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [[NS] Quit: -a- Connection Timed Out] |
| 11:01 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 11:01 | | catalyst_ [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 11:01 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [Connection reset by peer] |
| 14:38 | | JustBob [justbob@Nightstar.Customer.Dissatisfaction.Administrator] has quit [[NS] Quit: ] |
| 14:41 | | JustBob [justbob@Nightstar.Customer.Dissatisfaction.Administrator] has joined #code |
| 14:41 | | mode/#code [+o JustBob] by ChanServ |
| 14:42 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 14:42 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 15:53 | | catalyst_ [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [[NS] Quit: -a- Connection Timed Out] |
| 15:53 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 16:48 | | Vorntastic [uid293981@Nightstar-phvupn.irccloud.com] has quit [[NS] Quit: Connection closed for inactivity] |
| 16:59 | | catalyst_ [catalyst@Nightstar-ij9fqs.dab.02.net] has joined #code |
| 17:00 | | Emmy [Emmy@Nightstar-l49opt.fixed.kpn.net] has joined #code |
| 17:01 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [Ping timeout: 121 seconds] |
| 17:12 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 17:14 | | catalyst_ [catalyst@Nightstar-ij9fqs.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 18:58 | | catalyst_ [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 18:58 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [Connection closed] |
| 19:40 | <@sshine> | did anyone do Rust traits here yet? |
| 19:40 | <@sshine> | I'm trying to design something, and I'm not quite there. |
| 19:42 | <@sshine> | I basically have two types, pub struct PrimeFieldElement128 { pub value: u128; } and pub struct PrimeFieldElementBig { pub value: BigInt; pub field: PrimeField } -- in PrimeFieldElement128 a quotient is hardcoded, and in PrimeFieldElementBig the quotient is variable at run-time with elem.field.quotient |
| 19:44 | <@sshine> | I'm looking for a middle thing where I can have a PrimeFieldElementGeneric<B: PrimeFieldElementBase> where B::QUOTIENT is known at compile time instead. this makes a big difference performance-wise. |
| 19:48 | <@sshine> | hmm... |
| 19:48 | <@sshine> | I'll try and write a minimal reproducible example of what's not working. |
| 20:08 | | Kindamoody[zZz] is now known as Kindamoody |
| 20:45 | <&McMartin> | sshine: I'm still a novice, but... |
| 20:46 | <&McMartin> | ... this sounds like you might want to be using associated types, kind of like the Iterator trait's Iterator::Item type? |
| 20:46 | <&McMartin> | That might generalize to actual values. |
| 20:47 | <&McMartin> | This does sound like it's walking dangerously close to C++ Template Metaprogramming though which I'm pretty sure Rust puts a rapid halt to... |
| 20:53 | <&McMartin> | I've been locked in combat with the corners of traits and the borrow checker these past couple days as part of advent of code, but I've managed to get some usefully generic functions out of it |
| 20:54 | <&McMartin> | And I've also made use of std::cell::RefCell now, which... closes a major gap in Rust's design and also makes me a little sad because it breaks some of its strongest claims ;) |
| 21:14 | | macdjord [macdjord@Nightstar-7aijs7.dsl.bell.ca] has quit [[NS] Quit: Deep inside, every housecat believes themself to be just a temporarily embarrassed tiger.] |
| 21:15 | | catalyst_ [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [[NS] Quit: -a- Connection Timed Out] |
| 21:16 | | macdjord [macdjord@Nightstar-7aijs7.dsl.bell.ca] has joined #code |
| 21:16 | | mode/#code [+o macdjord] by ChanServ |
| 21:18 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 21:20 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [Connection closed] |
| 21:23 | | catalyst_ [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 22:18 | | catalyst_ [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [[NS] Quit: -a- Connection Timed Out] |
| 22:23 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 22:35 | <@sshine> | McMartin, yeah, I recently ran into a warning about having accidentally used associated types for the trait that I'm now trying to copy -- so that's very likely! |
| 22:35 | <@sshine> | https://gist.github.com/sshine/28392c2690f55383bedd9c08998a4500 -- here's some not working code |
| 22:36 | <@sshine> | so uhm... I'm not sure how to express this, except using ML higher-order modules. |
| 22:38 | <@sshine> | I'd like a *thing* that is called a PrimeFieldElementGeneric<B>, and it should contain methods for arithmetic and a few other things. they fundamentally all assume some number with which to perform modulo whenever necessary. |
| 22:38 | <&McMartin> | ... I know how I'd do that in C++, and that gives me something to dig into. One moment |
| 22:39 | <@sshine> | I'll show something I actually succeeded at, that I'm kinda proud of... but now don't know how to mimic. |
| 22:39 | <@sshine> | ok |
| 22:41 | <&McMartin> | Anyway, in C++ the way you'd do this is that you'd have PrimeFieldElementGeneric<B,M>, and M would be the modulus, baked into that type. |
| 22:41 | <@sshine> | yes, I'm looking at baking it into at compile-time. |
| 22:42 | <&McMartin> | I don't think Rust allows you to parameterize on things that aren't types though. |
| 22:42 | <@sshine> | ahhh, that tells me, PrimeFieldElementGeneric needs to be a trait, not a struct. because my struct then impl's that trait with a specific modulus. |
| 22:42 | <&McMartin> | I base this on *very cursory research* though. |
| 22:43 | <@sshine> | it only lets me do <SomeType: SomeTrait> |
| 22:43 | <&McMartin> | Right what I mean is |
| 22:43 | <&McMartin> | It has to be SomeType |
| 22:43 | <&McMartin> | It can't be SomeInteger the way it can in C++ |
| 22:43 | <&McMartin> | Because that way lies the road of computing the Fibonnaci sequence as part of your type checking phase |
| 22:44 | <@sshine> | only if SomeInteger is e.g. u8, i32, usize, or BigInt :) |
| 22:44 | <@sshine> | but yeah, no templates involved |
| 22:45 | <@sshine> | this is pure type inference... very much like how Haskell type class instances and, probably, exactly like traits in Scala, are resolved. |
| 22:47 | <@sshine> | for a similar thing, I copied the design of this module: https://github.com/antouhou/rs-merkle/blob/master/src/merkle_proof.rs#L48 |
| 22:48 | <@sshine> | here a pub struct MerkleProof<T: Hasher> { proof_hashes: Vec<T::Hash> } takes a T that has the trait Hasher and refers to the type T::Hasher. that makes MerkleProof |
| 22:49 | <@sshine> | I did a very similar thing, with a: pub struct Calculator<F: PrimeFieldElement> { offset: F::Elem, omega: F::Elem, ... } |
| 22:50 | <&McMartin> | This is a super dumb question but |
| 22:50 | <&McMartin> | can you just... define the const outside of the trait? |
| 22:50 | <@sshine> | and then did: impl<F: PrimeFieldElement> Calculator<F> { ... } and filled that with generic stuff that depends on some abstract F that isn't defined yet... |
| 22:50 | <@sshine> | hmm |
| 22:50 | <@sshine> | I can't make it a global constant. |
| 22:52 | <@sshine> | if this were ML module functors, I'd want: structure PrimeFieldElement17 = PrimeFieldElementFunctor(struct val modulus = 17 end); and instantiate the abstract module with that one value missing, at compile-time. |
| 22:52 | <&McMartin> | ... fuck |
| 22:52 | <&McMartin> | You know what this probably is |
| 22:52 | <&McMartin> | It's probably a macro |
| 22:52 | <@sshine> | I'm *really* hoping I can do this with type inference. I really hope I don't have to do macros yet. :D |
| 22:53 | <&McMartin> | Or something related to that; a thing that generates code based on parameters as opposed to something that gets potentially monomorphized later. |
| 22:53 | <&McMartin> | I'm *pretty* sure Rust's trait implementations work like C++ templates and ML functors in that they essentially are compiled once for each instantiation |
| 22:53 | <&McMartin> | But I'm not sure if they've *baked it into the language* the way C++ and ML have |
| 22:53 | <@sshine> | yes, I think so |
| 22:54 | <@sshine> | ah yes, I don't know yet. |
| 22:55 | <&McMartin> | I'm already way out over my skis though. Sorry. |
| 22:55 | <@sshine> | yeah, me too, hehe. no worries. |
| 22:56 | <&McMartin> | I've been doing Advent of Code in Rust for the past couple years and it has had very little impact on really exploring its corners, just given the nature of the problems |
| 22:56 | <&McMartin> | There are a few impressive exceptions, but. |
| 22:58 | <@sshine> | I started working on some blockchain stuff that needs to perform really well. we already have some data structures in place for doing the highly performant modular arithmetic in our real prime fields, but those are so big it's hard to create easy, small tests. so I'm currently trying to refactor a BigInt struct so that it's at least interface-compatible. |
| 22:59 | <@sshine> | so... if it works for 17, it may also work for 2^64 - 2^32 + 1 :P |
| 22:59 | <&Reiver> | You're working on blockchain? That there would be your problem. |
| 22:59 | | * Reiver flrrrd |
| 22:59 | <@sshine> | bl*argh*chain |
| 23:01 | <@sshine> | I've been interested in blockchain VMs for a while, helping a friend with a compiler. now he found a guy who is an expert with zero-knowledge protocols who is really into zk-STARKs. I think that it's the closest thing I've come to magic, so at this point I just want to see it exist. :) |
| 23:01 | <&Reiver> | ...blockchain VMs |
| 23:01 | <@sshine> | also, this is the first time I get to actually work with abstract algebra. it was one of my favorite courses at uni. |
| 23:01 | | * Reiver stares blankly, turns to McMartin for elucidation |
| 23:02 | <@sshine> | Reiver, you know... Ethereum... the glorified TI-83 calculator we can take turns at operating at a premium cost. :-D |
| 23:11 | <&Reiver> | Ah, the setting-the-world-on-fire-for-a-ponzi-scheme? Jolly good |
| 23:12 | <@sshine> | this one only kills kittens. |
| 23:33 | <&ToxicFrog> | Reiver: a lot of blockchains have a VM spec that's used to execute the "smart contracts" used to execute some of the scams |
| 23:33 | <&ToxicFrog> | Some of them have exciting security flaws! |
| 23:33 | <&ToxicFrog> | Someone elsenet(?) described using Etherium for actual code execution as "renting 1/500th of a raspberry pi for $250/day" |
| 23:34 | | Emmy [Emmy@Nightstar-l49opt.fixed.kpn.net] has quit [Ping timeout: 121 seconds] |
| 23:35 | <&ToxicFrog> | sshine: so how terrible is the consensus model for this blockchain you're working on? |
| 23:39 | <@sshine> | ToxicFrog, it is proof-of-work. |
| 23:41 | <&ToxicFrog> | so why, exactly, the fuck are you doing this |
| 23:41 | <@sshine> | ToxicFrog, so depending on whether you mean terrible as in no-certainty-it-will-work or as in will-increase-global-energy-consumption, it is terrible. |
| 23:42 | <@sshine> | that's an open-ended question, but I sense that you're implicitly criticising the energy consumption aspect? |
| 23:45 | <&ToxicFrog> | Energy consumption aspect, and the more general fact that blockchains (in the general sense of "merkle trees with a distributed consensus mechanism for finding the root") are very much a solution¹ looking for a problem |
| 23:45 | <&ToxicFrog> | ¹ I use the term very, very loosely |
| 23:47 | <&ToxicFrog> | Like, when the pitch for a blockchain isn't just openly "it's a ponzi scheme", it tends to be "this does the same thing as a centralized database with replication, but it's way more complicated and also worse at its job in every way" |
| 23:49 | <@celticminstrel> | Oh my. |
| 23:49 | <@celticminstrel> | Blockchains have even hit #code now, cool. :/ |
| 23:51 | <@sshine> | I understand the "fuck" wrt. energy consumption. I'm not sure it is warranted wrt. the usefulness of blockchains, since it isn't immoral to make stuff that doesn't solve problems. |
| 23:57 | <&ToxicFrog> | I make things that don't solve problems all the time, but they also don't have massive negative externalities |
| --- Log closed Wed Dec 22 00:00:41 2021 |