Record Builder Syntax · contributing

I'm working on a few things that would benefit from Proposal: Record Builder Syntax. In my opinion, this would make Roc stand out from other FP languages where applicatives are often leveraged but feel somewhat clunky.

I already looked into how this could be added, and I would love to take a stab at implementing it.

@Richard Feldman Is this at a stage where you'd consider accepting a PR or is it too early for that?

Richard Feldman (May 02 2023 at 21:30):

Richard Feldman (May 02 2023 at 21:31):

the only question mark in my mind is whether we should have it desugar to apply or map2 (each can be implemented in terms of the other, but I haven't thought through the pros/cons of choosing one vs the other) but that's the very last step of the feature, so I don't think it's a blocker for getting started

Agus Zubiaga (May 02 2023 at 21:48):

Interesting. If we desugared to map2 the "sugared" source would be different, right?

usersAndPosts = Task.collect {
    users <- Http.get "/users" |> Task.batch,
    posts <- Http.get "/posts" |> Task.batch,
}

Richard Feldman (May 02 2023 at 22:36):

Richard Feldman (May 02 2023 at 22:37):

it just occurred to me recently that it was an option because it can be losslessly transformed to apply, but thinking about it some more, it doesn't really seem to have any upsides here!

Richard Feldman (May 02 2023 at 22:37):

Agus Zubiaga (May 02 2023 at 23:16):

Richard Feldman (May 02 2023 at 23:33):

Georges Boris (May 02 2023 at 23:33):

I'm not sure if this is the place for it but I just read the design doc for this feature and left wondering if there isn't something even better we could figure out without the downsides listed.

for instance, does it make sense to use anything other than Task.batch for each of the items? I would think that Task.await would make it sequential - though it wouldn't right? since one of the design goals of this syntax is to make people understand they can't use ordering.

it seems like this approach might make people have a headache trying to compute values inside the same collect statement, even if it doesn't work it kinda looks enough like backpassing for people to think it would work...

with that in mind, any computed values or sequential tasks would need to happen in a follow-up step, right? wouldn't it be better to restrict it more and people could use a Task.map if they wanted to compute something or Task.andThen if they wanted to do something after all requests are done.

Task.batch {
  users: Http.get "/users",
  posts: Http.get "/posts"
}

the syntax sugar would be for the function Task.batch itself - it requires a record of tasks.

Brendan Hansknecht (May 02 2023 at 23:53):

Brendan Hansknecht (May 03 2023 at 00:00):

Related to his above question, why do we need Task.collect at all. We should even be able to do:

usersAndPosts = Task.succeed {
    users <- Http.get "/users" |> Task.batch,
    posts <- Http.get "/posts" |> Task.batch,
}

Task.succeed (\users -> \posts -> { users, posts })
|> Task.batch (Http.get "/users")
|> Task.batch (Http.get "/posts")

I am not sure what adding in an extra layer of indirection and wrap function does for us.

Brendan Hansknecht (May 03 2023 at 00:04):

Alos, @Georges Boris, your above proposal would have no way to distinguish from a regular record without blessing Task.batch, it needs to at least keep something like <- so that we know to apply syntax sugar.

Georges Boris (May 03 2023 at 00:11):

so would this syntax work for any other record constructor? from the doc I thought it was explicitly related to parallel tasks - so this would also be useful for something like this?

D.succeed {
  name <- D.field "name" D.string  |> D.required,
  email <- D.field "email" D.string |> D.optional
}

Brendan Hansknecht (May 03 2023 at 00:16):

D.succeed (\name -> \email -> {name, email}
|> D.required (D.field "name" D.string)
|> D.optional (D.field "email" D.string)

required: D a err, D (a -> b) err, D b err

optional: D a err, D (a -> b) err, D (Option b) []

Where optional would on failure return None and clear out the error. While required would propagate the error.

Agus Zubiaga (May 03 2023 at 00:17):

@Georges Boris Yes, it would work for any applicative API. For example, I want to use it to build type-safe SQL selections. You could also use it to build a CLI arguments parser.

Brendan Hansknecht (May 03 2023 at 00:17):

You would just need something that can actually execute D just like we have platforms executing Task. So I think yes, it would enable that.

Agus Zubiaga (May 03 2023 at 00:18):

Brendan Hansknecht (May 03 2023 at 00:20):

Oh, but D.string would not really work. But some other api should work. As in, D.string could work, but then email would not be a Str instead it would be a wrapped [String Str]. So you would then have to match on the type even though you know the only type it could be. I think instead you would need D.fieldStr and same for other types to make the api play nicely with types in roc.

Georges Boris (May 03 2023 at 00:21):

it seems like a nice API that will need a veeery careful error message setup. I can totally see someone getting mixed up with types when trying to mix something like Task.batch and Task.await since the dependency is not as clear as an actual pipeline.

Georges Boris (May 03 2023 at 00:21):

Brendan Hansknecht (May 03 2023 at 00:24):

Will be interesting to see how this works with Decode in the future. I would assume it would in the end be built on top of Decode, but maybe that is wrong. Not sure if you can currently decode with a default value. I think not.

Agus Zubiaga (May 03 2023 at 00:28):

That's true. On the other hand, by having a special syntax for applicatives, we can produce much more insightful error messages than the other languages.

Agus Zubiaga (May 03 2023 at 00:39):

This is a good point. I can't come up with anything the layer of indirection would allow us to do, that we couldn't without it.

Agus Zubiaga (May 03 2023 at 00:41):

Richard Feldman (May 03 2023 at 00:47):

the reason for Task.collect is that it makes the sugar a self-contained expression

Richard Feldman (May 03 2023 at 00:47):

in other words, with Task.collect, the sugar is all inside the curly braces and everything outside the curly braces is normal Roc

Richard Feldman (May 03 2023 at 00:48):

if you want Task.succeed { ... } to replace Task.collect { ... } then you need to say that, despite all appearances, that Task.succeed { ... } is not a function call

Richard Feldman (May 03 2023 at 00:48):

rather it's the beginning of some syntax sugar that you only find out is happening if you read what's inside the curly braces

Richard Feldman (May 03 2023 at 00:49):

and every other time you see Task.succeed { ... } you know that it's going to evaluate to a Task { ...some fields... } but now it might not

Brendan Hansknecht (May 03 2023 at 00:50):

I think calling Task.collect any different/an actual function call is wrong. Task.collect doesn't even make sense to be called with those args. (As in either way it is not a true function call and is a rule that a roc user needs to know. If they look at the raw Task.collect, or the raw Task.succeed neither truly makes senses. I think Task.succeed reads closer to the expected output type.)

Brendan Hansknecht (May 03 2023 at 00:51):

Richard Feldman (May 03 2023 at 00:54):

in other words, in this example we started with Task.succeed { ... } and ended up with (after desugaring) Task.batch (Task.batch (Task.succeed ...)))

Brendan Hansknecht (May 03 2023 at 00:55):

Task.succeed {
    user: getUser someData
    email: loadEmail a b c
}

Task.succeed {
    users <- Http.get "/users" |> Task.batch,
    posts <- Http.get "/posts" |> Task.batch,
}

Both give you the same output Task {user: Str, email: Str} err, but one is in parallel and using sub tasks.

Richard Feldman (May 03 2023 at 00:56):

:thinking: I guess |> itself is actually precedent for adding wrapping calls to an expression after the fact

Brendan Hansknecht (May 03 2023 at 00:57):

Of course, I think it will confuse users that some reason they have to transform to this syntax if there are dependencies:

users <- Http.get "/users" |> Task.await
posts <- Http.getPosts users "/posts" |> Task.await

Task.succeed {users, posts}

Richard Feldman (May 03 2023 at 00:57):

so it's already not necessarily the case that if you see Task.succeed { ... } you know that a Task.succeed will be the first call there; you already have to keep reading to see if there's a |> coming in order to know what will be evaluated first

Richard Feldman (May 03 2023 at 00:57):

and actually I guess that's true of binary operators in general, not just |> :big_smile:

Brendan Hansknecht (May 03 2023 at 01:04):

users <-getUsers |> Task.await

Task.succeed {
    users,
    emails <-getEmails users |> Task.batch,
    posts <-getPosts users |> Task.batch,
}

Agus Zubiaga (May 03 2023 at 01:05):

Richard Feldman (May 03 2023 at 01:07):

I definitely do not think we should allow mixing and matching await and batch

Agus Zubiaga (May 03 2023 at 01:08):

It should work, users in that scope is already the final value, not the Task

Richard Feldman (May 03 2023 at 01:08):

so users is sugar for users: users as usual, not users <- users :thumbs_up:

Richard Feldman (May 03 2023 at 01:08):

in that case we should allow users: blah as well (I forget if the doc mentioned that)

Richard Feldman (May 03 2023 at 01:09):

Agus Zubiaga (May 03 2023 at 01:09):

For sure! When I was looking into how I would implement this earlier, I thought we can split the fields set with : (or LabelOnly) from those using <-.

Agus Zubiaga (May 03 2023 at 01:10):

The former are kept the same, and the latter get desugared into the pipeline thing.

Brendan Hansknecht (May 03 2023 at 01:14):

Georges Boris (May 03 2023 at 01:17):

could be useful to have a default type alias for applicatives so it is easier to spot which functions are compatible with this feature than looking for the usually confusing type signature... type alias is definitely not the way to go but would be great to spot compatibility easily.

Brendan Hansknecht (May 03 2023 at 01:29):

ApplicativeTask a b err : Task a err -> Task (a -> b) err

batch: ApplicativeTask a b err -> Task somethingWithB err

Brendan Hansknecht (May 03 2023 at 01:29):

Agus Zubiaga (May 03 2023 at 01:52):

Task.succeed {
    users <- Http.get "/users" |> Task.batch,
    posts <- Http.get "/posts" |> Task.batch,
}

Task.succeed (\users -> \posts -> { users, posts })
|> Task.batch (Http.get "/users")
|> Task.batch (Http.get "/posts")

because we would be applying Task.batch with 2 arguments: Task.succeed (\users -> \posts -> { users, posts }) and (Http.get "/users")

Agus Zubiaga (May 03 2023 at 01:54):

It would work in Elm because Task.batch would be partially applied with Http.get .. and then the pipe would apply Task.succeed (..)

Brendan Hansknecht (May 03 2023 at 01:57):

Since batch is Task a err -> Task (a -> b) err -> Task b err, it is manually curried.

Task.succeed (\users -> \posts -> { users, posts })
|> (Task.batch (Http.get "/users"))
|> (Task.batch (Http.get "/posts"))

Agus Zubiaga (May 03 2023 at 01:59):

Agus Zubiaga (May 03 2023 at 02:00):

Brendan Hansknecht (May 03 2023 at 02:01):

I think |> may not work correctly, but something like this should definitely type check:

batch1 = Task.batch (Http.get "/users")
batch2 = Task.batch (Http.get "/posts")

Task.succeed (\users -> \posts -> { users, posts })
|> batch1
|> batch2

Brendan Hansknecht (May 03 2023 at 02:01):

Yeah, somehow we need to force application. Not sure if we have a way to do that in roc. Interesting issue.

Agus Zubiaga (May 03 2023 at 02:03):

(Task.batch (Http.get "/posts"))
    (
        (Task.batch (Http.get "/users"))
            (Task.succeed (\users -> \posts -> { users, posts }))
    )

Brendan Hansknecht (May 03 2023 at 02:04):

I think this may be a bug in |>, but I could see an argument for either. Personally, I think the parens should cause execution even in a pipeline cause that is what happens when desugared like above.

Brendan Hansknecht (May 03 2023 at 02:04):

Agus Zubiaga (May 03 2023 at 02:10):

Yeah, interesting. I guess it could do that, I'm not sure if I'd expect it to, the way I would in Elm with partial application.

Brendan Hansknecht (May 03 2023 at 02:15):

Yeah, I'm not sure either, but then it leaves an open question, how do I apply a manually curried function in a pipeline? Feels weird to say it is impossible

Brendan Hansknecht (May 03 2023 at 02:15):

Agus Zubiaga (May 04 2023 at 00:49):

Agus Zubiaga (May 04 2023 at 00:53):

Richard Feldman (May 04 2023 at 00:53):

Brendan Hansknecht (May 04 2023 at 01:26):

Georges Boris (May 04 2023 at 03:20):

would it be too crazy if the formatter transformed the non-sugared versions into this syntax for consistency? it would also prevent the errors this syntax is trying to help with :nerd:

Agus Zubiaga (May 04 2023 at 13:18):

Hm, interesting. I think it'd be hard to detect in a way that wouldn't trigger for other constructs that might look the same (AST wise) but are not applicatives at all.

Agus Zubiaga (May 04 2023 at 13:20):

Agus Zubiaga (May 04 2023 at 13:25):

To me, that'd be similar to having the formatter rewrite a (b c)) to c |> b |> a. I wouldn't want it to do that.

Agus Zubiaga (May 05 2023 at 14:02):

I’m pretty busy after work this week, so I’m unlikely to continue coding this until next week. However, I’d like to determine all the cases where we want to allow record builders in.

Allowed

# 1. Applied to a function identifier
succeed {
    a: 123,
    b <- apply getB,
    c <- apply getC,
    d,
}

# 2. Applied to tag
Succeed {
    a <- apply getA,
    b <- apply getB,
}

# 3. Applied to opaque wrapper
@Opaque {
    a <- apply getA,
    b <- apply getB,
}

# 4. Piped
{
    a <- apply getA,
    b <- apply getB,
}
|> succeed

# 5. Applied next to other arguments
succeed 456 {
    a <- apply getA,
    b <- apply getB,
}

# 6. Applied to an expression that returns a function
(getSucceed somehow) {
    a <- apply getA,
    b <- apply getB,
}

Maybe allowed?

# 7. Record update
succeed {
    recordToUpdate &
        a <- apply getA,
        b <- apply getB,
        c: 123,
        d
}

Compile error

# 8. Record builder in a def
builder =
    {
        a <- apply getA,
        b <- apply getB,
    }

succeed builder

# 9. Mulitple record builders applied to the same function
succeed
    {
        a <- apply getA,
        b <- apply getB,
    }
    {
        z <- apply getZ,
    }

Please let me know what you think. Let’s use the numbers to talk about each case.

Brendan Hansknecht (May 05 2023 at 14:06):

My gut feeling is 1,2,3 and nothing else. It should only apply to functions directly.

4 is not direct.
5... I am really not sure would need to think about use cases
6 Probably not. We already pointed out that (func arg) does not necessarily apply a function in roc. I think it just also would stick out weirdly and be uncommon.
7 Shouldn't be supported
8 Shouldn't be supported
9 Shouldn't be supported

Richard Feldman (May 05 2023 at 15:36):

I hadn't even thought about making this work for all the things that would be valid in front of a normal record literal (e.g. 2, 3, 4, 5) but I like that if someone tries to do that, it can Just Work the same way as any other expression would :thumbs_up:

Richard Feldman (May 05 2023 at 15:36):

I think we definitely should not support record updates (7) at least at first; if there's demand for it in practice, we can have a separate discussion about it and decide later whether to add it

Richard Feldman (May 05 2023 at 15:37):

also there have been discussions in the past about potential changes to record update syntax, so committing to it would potentially complicate those discussions unnecessarily

Richard Feldman (May 05 2023 at 15:38):

I like 8 being a compiler error; I could see an argument for it returning a partially-applied function, but I suspect that would be more surprising/confusing than useful.

Richard Feldman (May 05 2023 at 15:38):

I'm not even sure if there's a design where 9 could work, so :thumbs_up: to compile error there too :big_smile:

Brendan Hansknecht (May 05 2023 at 15:55):

I think if 8 doesn't work, 4 shouldn't work. They are the same code, but one is explicit with the name and the other implicit

Richard Feldman (May 05 2023 at 15:59):

hm, my main concern with 8 is that you can pass builder around, put it into the repl (what would its type be?), etc.

Richard Feldman (May 05 2023 at 15:59):

and those don't really make sense unless you define it to be a partial application or something

Richard Feldman (May 05 2023 at 16:00):

Richard Feldman (May 05 2023 at 16:01):

Richard Feldman (May 05 2023 at 16:02):

Brendan Hansknecht (May 05 2023 at 16:23):

Also, should (someFunc someArg) apply a function in Roc? Currently that isn't consistent due to pipelining which ignores parens.

Brendan Hansknecht (May 05 2023 at 16:23):

Richard Feldman (May 05 2023 at 16:24):

Brendan Hansknecht (May 05 2023 at 16:27):

x
|> someFunc y

# becomes
someFunc x y

# and this
x
|> (someFunc y)

# becomes
(someFunc x y)

# So you have to write
x
|> \n -> (someFunc y) n

# to get something that simplifies to
(someFunc y) x

Richard Feldman (May 05 2023 at 16:30):

but if I write (foo bar) that should just call foo applying bar regardless of what else is going on around it

Richard Feldman (May 05 2023 at 16:30):

Richard Feldman (May 05 2023 at 16:31):

so I think the only way x |> (someFunc y) would work is if I'd defined someFunc = \arg1 -> \arg2 ->

Richard Feldman (May 05 2023 at 16:31):

Agus Zubiaga (May 05 2023 at 16:31):

Agus Zubiaga (May 05 2023 at 16:32):

Agus Zubiaga (May 05 2023 at 16:33):

We're talking about different things here, though. #6 can work fine because (manullyCurriedFn 31) 11 already works.

Agus Zubiaga (May 05 2023 at 16:37):

The downside of not supporting x |> (someFunc y) is that someone cannot just use the apply functions that they'd use in a Record Builder to construct an applicative manually

Richard Feldman (May 05 2023 at 16:38):

Richard Feldman (May 05 2023 at 16:39):

because (twoArgFunction y) would call the 2-arg function immediately, and that would be a type mismatch because it's only getting one argument

Richard Feldman (May 05 2023 at 16:39):

Agus Zubiaga (May 05 2023 at 16:41):

Right. However, the desugared examples in your proposal make it look like you could either use Record Builder or pipe these curried functions. That's not currently possible. It'd be possible the way Elm does pipelines, but not in Roc.

Agus Zubiaga (May 05 2023 at 16:43):

In my current implementation, I'm not using pipes. I'm just desugaring to Expr::Apply like this

Richard Feldman (May 05 2023 at 16:48):

Agus Zubiaga (May 05 2023 at 16:49):

I might be missing something, but I don't think Task.collect would've changed that. This is about Task.batch being curried.

Agus Zubiaga (May 05 2023 at 16:51):

Agus Zubiaga (May 05 2023 at 16:52):

In the Task.collect case, Task.batch would still be applied with the same 2 arguments.

Richard Feldman (May 05 2023 at 16:55):

Richard Feldman (May 05 2023 at 16:56):

Agus Zubiaga (May 05 2023 at 16:56):

That's why @Brendan Hansknecht suggested that x |> (manuallyCurried y) could desugar to (manuallyCurried y) x instead of (manuallyCurried x y) which is a "too many args" error.

Agus Zubiaga (May 05 2023 at 16:57):

Task.succeed (\users -> \posts -> { users, posts })
|> (Task.batch (Http.get "/users"))
|> (Task.batch (Http.get "/posts"))

Richard Feldman (May 05 2023 at 16:59):

Richard Feldman (May 05 2023 at 17:00):

so if I have a function like curriedDivide = \numerator -> \denominator -> numerator / denominator

Agus Zubiaga (May 05 2023 at 17:00):

Richard Feldman (May 05 2023 at 17:00):

Brendan Hansknecht (May 05 2023 at 17:00):

Richard Feldman (May 05 2023 at 17:00):

Agus Zubiaga (May 05 2023 at 17:02):

Ok, great. I think that makes sense intuitively. When I write x |> (someFunc y), |> should not be concerned with was is inside the parens.

Agus Zubiaga (May 05 2023 at 17:04):

Fixing that would allow libraries to expose a single Task.batch-like function that could be used with Record Builders or that can be piped to manually construct something else.

Richard Feldman (May 05 2023 at 17:06):

yeah I think it's fine to have that function be curried manually, because it unavoidably has a highly unusual type signature no matter what

Richard Feldman (May 05 2023 at 17:07):

batch : Task a err, Task (a -> b) err -> Task b err

batch : Task a err -> Task (a -> b) err -> Task b err

Richard Feldman (May 05 2023 at 17:08):

batch : Task a err -> (Task (a -> b) err -> Task b err)

Richard Feldman (May 05 2023 at 17:08):

Richard Feldman (May 05 2023 at 17:09):

in a curried language you'd know that because you encounter it very early on in your learning, but in Roc this would be so rare it might be confusing to beginners what two ->s in the same type signature means

Agus Zubiaga (May 05 2023 at 17:11):

That might already be the case. IIRC the current parser requires the parens actually.

Agus Zubiaga (May 05 2023 at 17:13):

── NOT END OF FILE ───────────────────────────────────────── src/Pg/Result.roc ─

I expected to reach the end of the file, but got stuck here:

135│  apply : Decode a err -> Decode (a -> b) err -> Decode b err
                                                  ^

Agus Zubiaga (May 05 2023 at 17:13):

Richard Feldman (May 05 2023 at 17:13):

Agus Zubiaga (May 05 2023 at 17:14):

Richard Feldman (May 05 2023 at 17:14):

Agus Zubiaga (May 05 2023 at 17:18):

Johan Lövgren (May 05 2023 at 17:54):

What I remember from Haskell is that the function arrow is right-associative because of automatic currying. So it makes sense to me that the parentheses are necessary in Roc since it doesn’t automatically curry

Agus Zubiaga (May 09 2023 at 00:56):

Agus Zubiaga (May 09 2023 at 00:59):

I'm pretty new to Rust and the compiler source, so please let me know if I did anything horrible :smiley:

Agus Zubiaga (May 09 2023 at 01:13):

I'll explore adding a new CalledVia tomorrow. I think it could help me give better hints for type-errors.

Agus Zubiaga (May 10 2023 at 01:53):

Agus Zubiaga (May 10 2023 at 01:54):

These are actually coming from the generated closure, but I don't think they need any special handling

Agus Zubiaga (May 10 2023 at 01:56):

Agus Zubiaga (May 10 2023 at 01:57):

Agus Zubiaga (May 10 2023 at 01:58):

Agus Zubiaga (May 10 2023 at 01:59):

Agus Zubiaga (May 10 2023 at 02:01):

Agus Zubiaga (May 10 2023 at 02:18):

Agus Zubiaga (May 10 2023 at 02:21):

Luke Boswell (May 10 2023 at 02:47):

Agus Zubiaga (May 10 2023 at 03:37):

    succeed {
        id <- Pg.Result.i32 "film_id" |> apply,
        title <- Pg.Result.i32 "title",
    }

Agus Zubiaga (May 10 2023 at 03:37):

Agus Zubiaga (May 10 2023 at 03:39):

Agus Zubiaga (May 10 2023 at 03:40):

Agus Zubiaga (May 10 2023 at 03:41):

Brendan Hansknecht (May 10 2023 at 03:52):

Yeah, definitely a weird error message both ways, but I don't have an immediate idea how to make it better.

Agus Zubiaga (May 14 2023 at 00:17):

This week has been super busy for me, but I finally got some time today to rewrite the parser and improve the errors. I think I'm ready to submit this for review!

Agus Zubiaga (May 14 2023 at 00:37):

Luke Boswell (Aug 14 2024 at 06:46):

I'm thinking as this is in Advanced Concept section and it should provide only a minimal syntax sugar. Enough that someone who already familiar with the advanced concepts but not necessarily roc syntax would be ok with. We can generally wave our hands about what it is but no try to explain it; instead we can point the reader to a more detailed guide which walks it through from start to finish and builds up to the full feature.

I'm finding I have to really think about things like what it is, how it works, why I would use it, etc. I think a well designed API using record builders will be intuitive for people to use, at least the Sqlite one is very easy to work with as long as I can see a worked example. So I think a very surface level knowledge, essentially "what is this syntax called, this is where I can find more information, and don't sweat the details it's an advanced concept", is ok for a tutorial.

Luke Boswell (Aug 14 2024 at 06:47):

I'm interested to know what others think. It's not easy to write good content and I appreciate the effort that Sam has put into the PR.

Luke Boswell (Aug 14 2024 at 06:49):

Luke Boswell (Aug 14 2024 at 06:52):

So I guess I'm thinking; I should have a go at writing a guide for Record Builders to explore this further.

Stream: contributing

Topic: Record Builder Syntax

Agus Zubiaga (May 02 2023 at 21:24):

Richard Feldman (May 02 2023 at 21:30):

Richard Feldman (May 02 2023 at 21:31):

Agus Zubiaga (May 02 2023 at 21:48):

Richard Feldman (May 02 2023 at 22:36):

Richard Feldman (May 02 2023 at 22:36):

Richard Feldman (May 02 2023 at 22:37):

Richard Feldman (May 02 2023 at 22:37):

Agus Zubiaga (May 02 2023 at 23:16):

Agus Zubiaga (May 02 2023 at 23:16):

Richard Feldman (May 02 2023 at 23:33):

Georges Boris (May 02 2023 at 23:33):

Brendan Hansknecht (May 02 2023 at 23:53):

Brendan Hansknecht (May 03 2023 at 00:00):

Brendan Hansknecht (May 03 2023 at 00:04):

Georges Boris (May 03 2023 at 00:11):

Brendan Hansknecht (May 03 2023 at 00:16):

Agus Zubiaga (May 03 2023 at 00:17):

Brendan Hansknecht (May 03 2023 at 00:17):

Agus Zubiaga (May 03 2023 at 00:18):

Brendan Hansknecht (May 03 2023 at 00:20):

Georges Boris (May 03 2023 at 00:21):

Georges Boris (May 03 2023 at 00:21):

Brendan Hansknecht (May 03 2023 at 00:24):

Agus Zubiaga (May 03 2023 at 00:28):

Agus Zubiaga (May 03 2023 at 00:39):

Agus Zubiaga (May 03 2023 at 00:41):

Richard Feldman (May 03 2023 at 00:47):

Richard Feldman (May 03 2023 at 00:47):

Richard Feldman (May 03 2023 at 00:48):

Richard Feldman (May 03 2023 at 00:48):

Richard Feldman (May 03 2023 at 00:49):

Brendan Hansknecht (May 03 2023 at 00:50):

Brendan Hansknecht (May 03 2023 at 00:51):

Richard Feldman (May 03 2023 at 00:54):

Brendan Hansknecht (May 03 2023 at 00:55):

Richard Feldman (May 03 2023 at 00:56):

Richard Feldman (May 03 2023 at 00:56):

Brendan Hansknecht (May 03 2023 at 00:57):

Richard Feldman (May 03 2023 at 00:57):

Richard Feldman (May 03 2023 at 00:57):

Brendan Hansknecht (May 03 2023 at 01:04):

Agus Zubiaga (May 03 2023 at 01:05):

Richard Feldman (May 03 2023 at 01:07):

Richard Feldman (May 03 2023 at 01:07):

Richard Feldman (May 03 2023 at 01:07):

Richard Feldman (May 03 2023 at 01:07):

Agus Zubiaga (May 03 2023 at 01:08):

Richard Feldman (May 03 2023 at 01:08):

Richard Feldman (May 03 2023 at 01:08):

Richard Feldman (May 03 2023 at 01:08):

Richard Feldman (May 03 2023 at 01:08):

Richard Feldman (May 03 2023 at 01:09):

Agus Zubiaga (May 03 2023 at 01:09):

Agus Zubiaga (May 03 2023 at 01:10):

Brendan Hansknecht (May 03 2023 at 01:14):

Georges Boris (May 03 2023 at 01:17):

Brendan Hansknecht (May 03 2023 at 01:29):

Brendan Hansknecht (May 03 2023 at 01:29):

Agus Zubiaga (May 03 2023 at 01:52):

Agus Zubiaga (May 03 2023 at 01:54):

Brendan Hansknecht (May 03 2023 at 01:57):

Agus Zubiaga (May 03 2023 at 01:59):

Agus Zubiaga (May 03 2023 at 02:00):

Brendan Hansknecht (May 03 2023 at 02:01):

Brendan Hansknecht (May 03 2023 at 02:01):

Agus Zubiaga (May 03 2023 at 02:03):

Brendan Hansknecht (May 03 2023 at 02:04):

Brendan Hansknecht (May 03 2023 at 02:04):

Agus Zubiaga (May 03 2023 at 02:10):

Brendan Hansknecht (May 03 2023 at 02:15):

Brendan Hansknecht (May 03 2023 at 02:15):

Agus Zubiaga (May 04 2023 at 00:49):

Agus Zubiaga (May 04 2023 at 00:53):

Richard Feldman (May 04 2023 at 00:53):

Brendan Hansknecht (May 04 2023 at 01:26):

Georges Boris (May 04 2023 at 03:20):

Agus Zubiaga (May 04 2023 at 13:18):