!XfqLiaavxVgyMSiRwK:matrix.org

Ruma

136 Members
Discussion of Ruma, a Matrix homeserver, client, and supporting libraries written in the Rust programming language. https://www.ruma.io/65 Servers

Load older messages


Timestamp Message
26 Feb 2020
14:35:03@poljar:matrix.orgpoljari guess feature flag is ok, but i suspect that most clients will use some other way to get to the token
14:36:08@jplatte:matrix.orgjplatteYeah most likely this just doesn't belong in ruma-client proper. But it could definitely be added as an example :)
14:36:30@poljar:matrix.orgpoljaragree
16:05:39@emilazy:matrix.orgemilyjplatte: yeah I groaned at the fragmentation too, but their justification does seem fairly sound for the usecase
16:05:57@emilazy:matrix.orgemilyI hope some of the libraries die so we can have fewer HTTP type abstractions than HTTP type consumers
16:06:38* @emilazy:matrix.orgemily is kinda happy to see the Rust ecosystem start to develop some of the generic streaming data abstractions Haskell has had for a few years now
16:13:18@jplatte:matrix.orgjplatteYeah I'm also totally happy that this stuff is being worked on, I just wish everyone worked together...
16:14:49@jplatte:matrix.orgjplatteIs the situation better in Haskell? I remember there being conduit and pipe(s?) and they each also had their set of libraries built around them
16:16:07@jplatte:matrix.orgjplatteBut it's been a few years since I've touched any Haskell code
17:42:27@ralith:ralith.comRalith
In reply to @jplatte:matrix.org
There's now a new http_types crate by the async-std people...
man, they seem really determined to reinvent the world
18:43:33@emilazy:matrix.orgemilyjplatte: there's a fair bit of fracturing unfortunately, yeah. Less so with async stuff because Haskell just has a proper lightweight threaded runtime a la Erlang that can support a bajillion threads with straight-line-style blocking code
18:43:41@emilazy:matrix.orgemilymore "stackful coroutines" than Rust's stackless
18:44:06@emilazy:matrix.orgemilyI personally think Haskell is actually a bit ahead of Rust there in terms of programming experience (but ofc the GHC approach has inherently higher overhead so it's a tradeoff)
18:44:29@emilazy:matrix.orgemilyit's still easier to adapt different stream types to each other than it is to plug libraries that don't use abstractions like that at all together, I'd say
27 Feb 2020
04:28:12@iinuwa:matrix.orgiinuwa

All right, I'm so confused with this struct serialization for lazy loading. Do I need to serialize the enum into a struct, and then let #[serde(flatten)] handle the rest? Here's what I have right now:

#[derive(Clone, Copy, Debug, Deserialize, Serialize)]
pub struct LazyLoad {
    pub lazy_load_members: bool,
    pub include_redundant_members: bool,
}
impl Serialize for LazyLoadOptions {
    fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
    where S: Serializer {
        match self {
            Self::Disabled => { 
                let mut state = serializer.serialize_struct("LazyLoad", 2)?;
                state.serialize_field("lazy_load_members", &false)?;
                state.serialize_field("include_redundant_members", &false)?;
                state.end()
            },
            Self::Enabled { include_redundant_members } => { 
                let mut state = serializer.serialize_struct("LazyLoad", 2)?;
                state.serialize_field("lazy_load_members", &true)?;
                state.serialize_field("include_redundant_members", include_redundant_members)?;
                state.end()
            },
        }
    }
}
04:29:22@iinuwa:matrix.orgiinuwa Is there a way to skip serialization altogether if the variant is LazyLoadOptions::Disabled?
10:46:12@jplatte:matrix.orgjplatte

iinuwa: I think it should roughly be

let mut st = serializer.serialize_struct("LazyLoadOptions", 2)?;
if let Self::Enabled { include_redundant_members } = self {
    st.serialize_field("lazy_load_members", &true)?;
    if include_redundant_members {
        st.serialize_field("include_redundant_members", &true)?;
    }
}

st.end()
10:46:30@jplatte:matrix.orgjplatteAlso you don't need to declare a separate struct
10:53:10@jplatte:matrix.orgjplatteOr you could actually pass the right amount of fields, which would require a bit more work, but maybe make it compatible with a few non-JSON formats
10:54:02@jplatte:matrix.orgjplatte
match self {
    Self::Enabled { include_redundant_members } if include_redundant_members => {
        let mut st = serializer.serialize_struct("LazyLoadOptions", 2)?;
        st.serialize_field("lazy_load_members", &true)?;
        st.serialize_field("include_redundant_members", &true)?;
        st.end()
    }
    Self::Enabled { .. } => {
        let mut st = serializer.serialize_struct("LazyLoadOptions", 1)?;
        st.serialize_field("lazy_load_members", &true)?;
        st.end()
    }
    Self::Disabled => {
        serializer.serialize_unit_struct("LazyLoadOptions")
    }
}
16:08:47@iinuwa:matrix.orgiinuwaOk, so at least I wasn't too far off. I really need to sit down sometime and work through some serde examples; it feels esoteric to me
16:11:18@jplatte:matrix.orgjplatte There's also SerializeStruct::skip_field 🤔
16:14:03@jplatte:matrix.orgjplatte For deserialization you probably want serde::de::MapAccess and its next_entry method
21:20:34@tanriol:matrix.orgtanriolThere's also the trick of (de)serializing with a local type written to match the representation. Not sure whether that has overhead - I'd expect LLVM to optimize it to the same code, but I've never checked that myself.
21:22:16@jplatte:matrix.orgjplatte Yeah that's another possibility and doesn't even require implementing Serialize and Deserialize manually - serde has #[serde(from)] and #[serde(into)]. I'm not sure whether that would be easier here though.
28 Feb 2020
01:26:19@jplatte:matrix.orgjplatte T'was a quiet day here today. Stuff is happening though! Two days ago I was asked whether there was interest in a ruma project in GSoC under the matrix organization, yesterday I got merge rights to matrix-org/matrix-ircd because of a discussion related to GSoC, today I submitted my first GSoC project idea and merged a PR in matrix-ircd that had been sitting idle for over a year...
01:27:57@jplatte:matrix.orgjplatte If there are students here who are be interested in participating in GSoC this year with something matrix-related you should watch matrix-org/gsoc and join #gsoc:matrix.org! :)
01:29:31@jplatte:matrix.orgjplatteI've got one more ruma GSoC idea, just need to find the time to write it down properly.
01:31:40@jplatte:matrix.orgjplatteWould love to do that now but I really need to head to bed.
01:31:50@jplatte:matrix.orgjplattebye for today! o/

There are no newer messages yet.


Back to Room List