portkey

Portkey: from REPL to Serverless in one call
cgrand 2018-05-28T14:17:09.000044Z

> `“Fonction tu lui donne un input et il t’appelle les fn de ser qui on été généré pour faire le confirming.“`

cgrand 2018-05-28T14:17:14.000098Z

🙂

cgrand 2018-05-28T14:18:01.000005Z

Guys, if we start writing comments in our own languages this codebase is going to be fun

baptiste-from-paris 2018-05-28T14:24:31.000352Z

ahah, it was dev stuff only

cgrand 2018-05-28T14:26:01.000073Z

Kidding, the worst is if it hasn’t been written in Frenglish I may have failed to notice it

cgrand 2018-05-28T14:49:14.000160Z

On the generated side: it should be more straightforward (no iteration or lookup not related to the data). On the generator side: what are the gains of a single omniprotocol multimethod (opposed to eg a multi per protocol)? Last on resp and one-per-protocol: maybe but I have the same feeling/doubt that about gen-ser-input: that we are prematurely factoring things together with little gain.

cgrand 2018-05-28T14:50:34.000417Z

Do you see what I mean? Maybe I’m missing something

baptiste-from-paris 2018-05-28T14:51:43.000291Z

got it

baptiste-from-paris 2018-05-28T14:52:03.000271Z

I understand your last point but not the first 2 🙂

baptiste-from-paris 2018-05-28T14:52:13.000271Z

1) generated code is to complex ?

baptiste-from-paris 2018-05-28T14:52:20.000391Z

2) interface is not the right one ?

cgrand 2018-05-28T15:23:44.000265Z

on point 2: is there any reason (other than making code similar across protocols) for having a single multimethod for all?

cgrand 2018-05-28T15:25:15.000114Z

on point 1: how would you write ser-tracing-config by hand?