Differences

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

@@ 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.