Differences

This shows you the differences between two versions of the page.

Link to this comparison view

— irc:1453071600 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[11:09:20] <aesteve> hi everyone, hi temporalfox
 +
 +[11:09:28] <temporalfox> hi aesteve
 +
 +[11:09:32] <temporalfox> what's up ?
 +
 +[11:09:49] <aesteve> lot of things !
 +
 +[11:10:01] <aesteve> but i was reading your PR re. multiple-futures
 +
 +[11:10:31] <aesteve> and was wondering if there was an `all` and `any` implementation taking a list parameter
 +
 +[11:10:42] <aesteve> since lists are codegen-friendly
 +
 +[11:11:55] <aesteve> and also, if there was an iterator like feature involving `compose`
 +
 +[11:12:09] <aesteve> basically, two things I'm writing all the time :
 +
 +[11:13:11] <aesteve> "take that list of methods (which all are Handler<Future>) and execute them, no matter how, call me back when everything's done"
 +
 +[11:13:23] <aesteve> and 2nd use case :
 +
 +[11:13:54] <aesteve> same thing but it HAS to wait for the previous success
 +
 +[11:14:31] <aesteve> First use case is `all`with a list as parameter if I'm not mistaking
 +
 +[11:14:47] <aesteve> Second use case is basically a `compose`with an iterator
 +
 +[11:26:57] <aesteve> also, I used "completeOrFail()" instead of "completer()" in my own implementation. Not sure it's better though
 +
 +[11:29:18] <temporalfox> aesteve it's  not possible to have LIst<Future<?>> in codegen
 +
 +[11:29:26] <temporalfox> and that's what should be used if any
 +
 +[11:29:43] <temporalfox> I mean it's better to use T1 -> T6 parameters
 +
 +[11:29:48] <temporalfox> because we don't use generic contravariance
 +
 +[11:29:57] <temporalfox> so doing something like
 +
 +[11:30:08] <temporalfox> all(Future<String>, Future<Integer> etc...)
 +
 +[11:30:17] <temporalfox> would make the compiler not happy
 +
 +[11:30:30] <temporalfox> because a Future<String> is not a Future<Object>
 +
 +[11:30:35] <temporalfox> and if we use a single T
 +
 +[11:30:44] <temporalfox> you have to use the same parameter
 +
 +[11:31:14] <Narigo> When I use jsonArray.remove(5) and the element at index 5 is a JsonArray, it will return a java.util.ArrayList<?> - is this expected?
 +
 +[11:32:00] <temporalfox> it is because of an internal impl detail
 +
 +[11:32:16] <temporalfox> when an object/array is unwrapped by jackson
 +
 +[11:32:21] <temporalfox> it creates List and Map
 +
 +[11:32:27] <temporalfox> and sometimes we rewrap them
 +
 +[11:32:30] <aesteve> ouch ok. It could be a problem. Because often you're gonna deploy a list of verticles, maybe defined in a json file or something
 +
 +[11:32:40] <aesteve> and you cannot know in advance how many there are
 +
 +[11:32:46] <temporalfox> but not in the case of remove
 +
 +[11:33:02] <temporalfox> ok I see aesteve
 +
 +[11:33:15] <temporalfox> we could have something with a list or array
 +
 +[11:33:16] <Narigo> temporalfox, shouldn't it check this and return a JsonArray / JsonObject in that case?
 +
 +[11:33:26] <temporalfox> marked as @GenIgnore
 +
 +[11:33:56] <temporalfox> I could try List<Future> too to see if codegen likes it or not :)
 +
 +[11:33:59] <temporalfox> not sure
 +
 +[11:34:08] <temporalfox> Narigo yes I think it should
 +
 +[11:34:14] <aesteve> you're the expert ;)
 +
 +[11:34:57] <aesteve> oh, something I noticed, too
 +
 +[11:35:09] <temporalfox> I'm not a big fan of "completer"
 +
 +[11:35:11] <temporalfox> too
 +
 +[11:35:26] <temporalfox> orignally I wanted "handler()" butit's confusing with setHandler
 +
 +[11:35:29] <temporalfox> or maybe asHandler() ?
 +
 +[11:36:09] <aesteve> asHandler is good but doesn't 'tell' what it's actually gonna do
 +
 +[11:36:19] <temporalfox> indeed
 +
 +[11:36:24] <aesteve> (i.e. completing or failing)
 +
 +[11:36:35] <temporalfox> actually failing is completing
 +
 +[11:36:36] <aesteve> but re. the list, not sure you should implement it
 +
 +[11:36:44] <temporalfox> it would rather be succeeding or failing
 +
 +[11:37:10] <aesteve> my use case is a bit different, since I'm passing List<Handler<Future>> and not List<Future>
 +
 +[11:38:43] <temporalfox> so it looks like
 +
 +[11:38:45] <temporalfox> List<Future> futures
 +
 +[11:38:48] <temporalfox> pass with codegen
 +
 +[11:39:07] <temporalfox> (but not List<Future<?>> which is expected
 +
 +[11:39:28] <temporalfox> and we cannot use a <T> parameter too othewise it has to be the same type
 +
 +[11:39:48] <aesteve> ok
 +
 +[11:39:59] <aesteve> the main idea behind this is : https://github.com/aesteve/nubes/blob/master/src/main/java/com/github/aesteve/vertx/nubes/VertxNubes.java#L173-L177
 +
 +[11:40:03] <tsegismont> temporalfox, I like asHandler
 +
 +[11:40:10] <tsegismont> or asAsyncResultHandler
 +
 +[11:40:21] <temporalfox> as asResultHandler ?
 +
 +[11:40:28] <aesteve> (that's an example but that's the kind of code I'm writing quite often)
 +
 +[11:40:48] <temporalfox> aesteve yes when you need a dynamic list
 +
 +[11:41:08] <temporalfox> yes the idea is to remove what you do and what everbyody does all over the place :-)
 +
 +[11:41:24] <aesteve> yes but the noticeable difference is List<Handler<Future>>
 +
 +[11:41:28] <aesteve> not List<Future>
 +
 +[11:41:36] <temporalfox> ah
 +
 +[11:41:36] <aesteve> notice the "start" method
 +
 +[11:42:17] <aesteve> so my use case is different I think, so not sure that my advices are really accurate
 +
 +[11:42:57] <temporalfox> in the CompositeFuture case such list would be too specific
 +
 +[11:43:32] <aesteve> makes sense
 +
 +[11:44:12] <temporalfox> thanks for the feedback on Liist
 +
 +[11:44:17] <aesteve> at least my implementation would use CompletableFuture behind the hood, which is still an improvement
 +
 +[11:44:22] <temporalfox> I think it's someting doable
 +
 +[11:44:29] <aesteve> CompositeFuture, sry
 +
 +[11:45:35] <aesteve> tsegismont: I'm using 'voidz' generally when I'm facing the naming issue with a Void lambda parameter
 +
 +[11:48:44] <aesteve> temporalfox: do you know who's in charge with the scala implementation ?
 +
 +[11:49:04] <temporalfox> aesteve martin I think
 +
 +[11:49:26] <temporalfox> ah no
 +
 +[11:49:28] <temporalfox> Lars Timm
 +
 +[11:49:30] <temporalfox> Timm / martin (close for me)
 +
 +[11:49:44] <temporalfox> are you interested in taking over :) ?
 +
 +[11:50:11] <aesteve> absolutely not I'm a Scala beginner
 +
 +[11:50:26] <aesteve> but it's easier learning a language through an API you already know :P
 +
 +[12:00:06] <temporalfox> aesteve I just push a commit with all/any list
 +
 +[12:00:17] <aesteve> thanks :)
 +
 +[12:02:27] <aesteve> but if you need a scala lead, maybe asking on twitter or scala's user list would do it ?
 +
 +[12:12:28] <temporalfox> we need someone that finishes the work
 +
 +[12:12:32] <temporalfox> indeed good idea
 +
 +[12:35:04] <Narigo> I guess most of the scala users are using Akka instead of Vert.x... :S
 +
 +[13:28:43] <temporalfox> aesteve now the TestContext#asyncAssert* are not @GenIgnore anymore
 +
 +[13:28:53] <temporalfox> (due to improvmements in codegen)
 +
 +[13:28:58] <aesteve> cool !
 +
 +[13:29:37] <aesteve> https://github.com/aesteve/grooveex/blob/master/src/main/groovy/com/github/aesteve/vertx/groovy/TestContextExtension.groovy can vanish, then !
 +
 +[13:29:48] <temporalfox> yes
 +
 +[13:30:03] <temporalfox> the new codegen feature allows Handler<> as return type
 +
 +[13:30:10] <temporalfox> maybe it can be useful to you as well
 +
 +[13:30:23] <aesteve> actually no, there's still : async { } which is useful
 +
 +[13:30:28] <temporalfox> ok
 +
 +[13:30:30] <temporalfox> ah yes
 +
 +[13:30:35] <temporalfox> this one is good
 +
 +[13:31:29] <aesteve> context.async { assertNotNull(someVar);it.complete() }
 +
 +[13:31:45] <aesteve> where assertNotNull is actually context.assertNotNull
 +
 +[13:33:29] <temporalfox> I think it would be more or less like
 +
 +[13:33:43] <temporalfox> context.async(Handler<Async> v -> { ... })
 +
 +[13:34:04] <aesteve> yes, you'll still miss the delegate, but yes
 +
 +[13:34:06] <temporalfox> it is similar except that groovy syntax makes it look like a block
 +
 +[13:35:07] <aesteve> that's something I was wondering, too
 +
 +[13:35:27] <aesteve> if thanks to codegen we could'nt do what C[unknown:eacute]dric sometimes talks about
 +
 +[13:35:35] <aesteve> atomatically delegating
 +
 +[13:35:48] <temporalfox> ah ok
 +
 +[13:35:50] <aesteve> since Handler always has one parameter
 +
 +[13:35:59] <temporalfox> having the "this" changed
 +
 +[13:36:04] <aesteve> the parameter could be a delegate
 +
 +[13:36:06] <temporalfox> like bind in js
 +
 +[13:36:21] <temporalfox> but that's not something that would work everywhere
 +
 +[13:36:23] <aesteve> so C[unknown:eacute]dric talks about many things :D
 +
 +[13:36:38] <aesteve> I was thinking about removing the 'it'
 +
 +[13:36:59] <temporalfox> ah, having the it becoming "this"
 +
 +[13:37:08] <aesteve> not necesserily
 +
 +[13:37:15] <temporalfox> what does it become then ?
 +
 +[13:37:17] <temporalfox> implicit
 +
 +[13:37:18] <temporalfox> ?
 +
 +[13:37:20] <aesteve> yes
 +
 +[13:37:28] <temporalfox> so
 +
 +[13:37:33] <temporalfox> it would need some naming like
 +
 +[13:37:50] <temporalfox> Handler<@Named("request") HttpServerRequest> handler
 +
 +[13:37:51] <temporalfox> or
 +
 +[13:37:59] <temporalfox> Handler<HttpServerRequest> requestHandler
 +
 +[13:38:05] <aesteve> that's what I did in the DSL for exemple
 +
 +[13:38:10] <temporalfox> and requestHandler -> handler of request
 +
 +[13:38:15] <temporalfox> and the parameter is named "request"
 +
 +[13:38:37] <temporalfox> perhaps that some meta programming could do that
 +
 +[13:38:46] <temporalfox> if it dispatches to a closure with no arguments
 +
 +[13:38:49] <aesteve> https://github.com/aesteve/grooveex/blob/master/src/test/resources/multi-method.groovy#L6-L8
 +
 +[13:38:56] <temporalfox> then the argument is made available with the name
 +
 +[13:39:07] <temporalfox> but I think it's too much magic
 +
 +[13:39:10] <aesteve> response is directly 'getResponse' without me having to do anything
 +
 +[13:39:19] <aesteve> because the delegate is RoutingContext
 +
 +[13:39:20] <temporalfox> but also pehraps groovy guys feel very natural wit hthat
 +
 +[13:39:46] <temporalfox> ok in this case it is because you are doing special crafting to the api
 +
 +[13:40:04] <aesteve> cool thing is if you annotate the method with @DelegatesTo
 +
 +[13:40:18] <aesteve> your IDE will understand that response is the response from the routingContext
 +
 +[13:40:42] <aesteve> I'm not sure it's good for every handler
 +
 +[13:40:51] <aesteve> but for the RoutingContext it makes a lot of sense
 +
 +[13:41:18] <aesteve> think about it : request, response, params, user, etc. all are context attributes
 +
 +[13:42:36] <aesteve> bodyAsString, bodyAsJson
 +
 +[13:42:46] <aesteve> these don't need any special crafting
 +
 +[13:42:58] <aesteve> they are already getters
 +
 +[13:43:38] <temporalfox> so in this case it become the "this"
 +
 +[13:50:10] <aesteve> not exactly
 +
 +[13:50:11] <aesteve> https://groovyconsole.appspot.com/script/5145285726568448
 +
 +[13:52:22] <aesteve> it's implicit as you said
 +
 +[13:53:55] <aesteve> but anyway, I'm not sure it works in all Vert.x cases, but for writing DSL it makes sense. Gradle does this, I think (didn't  check) ratpack does too
 +
 +[13:58:55] <temporalfox> I remember I used delegates in crashub
 +
 +[13:59:03] <temporalfox> with the shell session
 +
 +[13:59:04] <temporalfox> so doing
 +
 +[13:59:11] <temporalfox> def a = foo;
 +
 +[13:59:17] <temporalfox> was doing a foo lookup in session
 +
 +[13:59:28] <temporalfox> I think it was a bad idea after all
 +
 +[13:59:33] <temporalfox> too magic
 +
 +[13:59:45] <temporalfox> (in this context)
 +
 +[14:40:45] <aesteve> temporalfox: tell me if you're making an annoucement re. Scala I'll try to support you ;)
 +
 +[14:41:49] <aesteve> even though Akka is great and scala developpers probably use it, I think diversity can't be something bad for scala users
 +
 +[15:09:38] <robal> hi guys, I've been writing a reverse proxy built on Vertx. Works almost perfect, except for websockets. I understand I need to upgrade the connection.. any idea on how to do this? can I just add it to response.headers()?
 +
 +[15:10:01] <robal> the repo can be found here, if you're interested:  https://github.com/robertalpha/vertx-reverse-proxy
 +
 +[15:13:27] <aesteve> robal: if(clientResponse.getHeader('Connection') == 'Upgrade') { serverRequest.upgrade() }
 +
 +[15:13:31] <aesteve> something like that ?
 +
 +[15:14:33] <robal> aesteve: that easy? sounds like it could be. I'm going to try it! :D thanks!
 +
 +[15:14:51] <aesteve> that's pseudo-code but I would write it this way I think
 +
 +[15:15:03] <aesteve> just give it a try :)
 +
 +[15:16:15] <robal> yeah, I understand, I'm going to try and make it work. Thanks! I'm really happy with the reverse proxy, hopefully I can make it work with websockets :D
 +
 +[15:17:37] <aesteve> http://vertx.io/docs/apidocs/io/vertx/rxjava/core/http/HttpServerRequest.html#upgrade--
 +
 +[15:18:28] <aesteve> but once the websocket handshake has ended I'm not sure how you will forward the frames
 +
 +[15:19:17] <aesteve> since you don't have any websocketHandler on your server
 +
 +[15:19:55] <tsegismont> temporalfox, with the new function capability in codegen, it means we could remove @genignore on io.vertx.ext.unit.TestContext#asyncAssertSuccess(io.vertx.core.Handler<T>) ?
 +
 +[15:20:01] <tsegismont> correct?
 +
 +[15:20:05] <temporalfox> yes
 +
 +[15:20:09] <tsegismont> issue?
 +
 +[15:20:19] <temporalfox> https://github.com/vert-x3/vertx-unit/issues/27
 +
 +[15:20:28] <temporalfox> I have the commit locally :-)
 +
 +[15:20:33] <aesteve> so maybe robal it's not that easy after all, don't hesitate to ask our question on the Google group
 +
 +[15:21:09] <tsegismont> temporalfox, change your nickname to boosterfox :)
 +
 +[15:29:48] <robal> aesteve: oh right, thanks for taking a look at my code and thinking along :D if I can't get it to work I'll also approach the Google group
 +
 +[15:31:21] <aesteve> temporalfox: if I was asking about Scala that's because I'd like to write something very functional-oriented with Vert.x. I think maybe that's one of the fields where improvements could be made
 +
 +[15:31:44] <aesteve> "composing" handlers is maybe what I'm missing the most
 +
 +[15:31:48] <temporalfox> Clojure!!! :-)
 +
 +[15:31:59] <aesteve> too many parenthesis :p
 +
 +[15:33:43] <aesteve> joke aside, a way to express that : GET('/api/friends') = (checkBearerToken >> checKUserRegistered >> getFriends).mapToResponse
 +
 +[15:33:46] <aesteve> would be fantastic
 +
 +[15:34:40] <aesteve> where every function is a Handler<RoutingContext> and has a piece of logic
 +
 +[15:41:26] <mcw> Hi there, is it possible to mix vert.x versions. Let's say my vert.x app runs with version 2.1.2 but I deploy a module which is written in v3.2.0. Does this work or do all modules have to be written in the same version? thank you
 +
 +[16:12:38] <mcw> Hi there, is it possible to mix vert.x versions. Let's say my vert.x app runs with version 2.1.2 but I deploy a module which is written in v3.2.0. Does this work or do all modules have to be written in the same version? thank you
 +
 +[16:34:28] <robal> mcw: I think most modules are dependent on io.vertx.core, so they need to be the same version. It shouldn't be a lot of work to switch versions though
 +
 +[16:40:23] <mcw> robal: thank you, but do you think a switch from vert.x 2x to 3x isn't much work too?
 +
 +[17:05:14] <robal> mcw: well, depending on how much code you've written you might see a few errors. If you're using maven you can simply change the version number for all of your vertx dependencies. I think I only had to change 4 lines of code to make it work in one of my projects, but that was for a simple vertx-web project.