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.