Approvals: 0/1
[08:45:11] * ChanServ sets mode: +o temporalfox
[10:21:43] <aesteve> hi everyone !
[10:25:06] <pmlopes> hi
[10:25:46] <aesteve> made progress avout the groovy sugar stuff, and I was wondering if maybe something could be added to codegen
[10:26:23] <aesteve> In groovy, an Handler is a Closure, but what about setting the closure's delegate to the closure's parameter
[10:27:48] <aesteve> https://github.com/aesteve/vertx-groovy-sugar/blob/master/src/test/resources/routes.groovy#L35
[10:28:18] <aesteve> that would allow ppl to use response() directly, without calling context.response() or it.response()
[10:30:54] <aesteve> iirc that's what ratpack does
[10:30:56] <aesteve> https://github.com/ratpack/example-ratpack-gradle-groovy-app/blob/master/src/ratpack/Ratpack.groovy#L19
[10:32:49] <aesteve> tbh, if I continue working on the sugar stuff, you'll be able to write pretty much the same Groovy stuff in Vert.x than you would with Ratpack :)
[13:03:18] <temporalfox> aesteve that would be a good thing
[13:03:59] <temporalfox> the delegate thing that would rather be done in vertx-lang-groovy right ?
[13:10:04] <aesteve> hi temporalfox sorry I was away for lunch
[13:10:24] <aesteve> yes the delegate thing could be done in vertx-lang-groovy, I suppose
[13:11:59] <temporalfox> so what would it change ?
[13:12:18] <temporalfox> the properties would be on “this” instead of the object, right ?
[13:12:37] <temporalfox> cescoffier just tried the vertx stack manager with cache, it seems much more responsive
[13:12:41] <temporalfox> where is the cache stored ?
[13:12:47] <aesteve> req.handler { ctx → ctx.response().end('stuff') }
[13:12:49] <aesteve> becomes
[13:13:00] <aesteve> req.handler { ctx → response().end('stuff') }
[13:13:13] <temporalfox> why do we still need ctx then ?
[13:13:25] <aesteve> typo, you can remove ctx idd
[13:13:27] <temporalfox> ok
[13:13:32] <temporalfox> I think we would not do that for now
[13:13:34] <temporalfox> however
[13:13:45] <temporalfox> it could be an alternative implementation
[13:13:47] <aesteve> if you mix that with response() who becomes getResponse()
[13:14:08] <temporalfox> and become later the main impl
[13:14:13] <aesteve> then you get : req.handler { response.end 'stuff' }
[13:14:21] <temporalfox> yes about that
[13:14:26] <aesteve> which is really cool and readable
[13:14:34] <temporalfox> I believe it would be good to have support for properties at some pont
[13:14:50] <temporalfox> although it means more annotation and error prone
[13:15:01] <temporalfox> so I have mixed feelings about it
[13:15:11] <temporalfox> yesterday [unknown:icirc] had to make change in ceylon
[13:15:22] <temporalfox> because it transforms getToto() → toto property
[13:15:25] <aesteve> if it's just about Groovy, get* methods would be enough
[13:15:30] <temporalfox> so it is getTotto() now like in java
[13:15:55] <temporalfox> because getOrCreateContext() was translated to orCreateContext property
[13:16:03] <temporalfox> that sucks
[13:16:23] <aesteve> ah ok, I see
[13:16:33] <aesteve> Groovy does the same, but the method still exists
[13:16:43] <temporalfox> in ceylon the method is erased
[13:17:09] <aesteve> still early in my Ceylon learning, didn't know about that
[13:18:31] <temporalfox> well now it is gone
[13:18:35] <temporalfox> I didn't like it that much
[13:18:42] <temporalfox> also in vertx read-only properties are
[13:18:44] <temporalfox> foo()
[13:18:50] <temporalfox> and r/w are getFoo() / setFoo()
[13:18:56] <temporalfox> so read only property where still foo()
[13:19:09] <temporalfox> but r/w prop were “.foo” and “.foo = ”
[13:19:18] <temporalfox> I did not like that differene
[13:19:24] <temporalfox> + the getOrCreateContext() thing
[13:19:49] <aesteve> mmh actually, this can be misleading in my Groovy implementation
[13:20:01] <temporalfox> yes
[13:20:02] <aesteve> because you can write : response += buffer
[13:20:24] <temporalfox> that's the problem of this convention
[13:20:31] <temporalfox> which is nice for java
[13:20:51] <temporalfox> perhaps we should have a getFoo() convention and code generate an api with “foo()”
[13:20:58] <temporalfox> I mean java api
[13:21:11] <aesteve> so Java would no longer be the top-level ?
[13:21:19] <aesteve> that sounds interesting
[13:21:31] <aesteve> an idiomatic API on top of the Java API
[13:28:01] <temporalfox> I was kidding
[13:28:19] <aesteve> I liked the idea :P
[13:29:01] <temporalfox> ok but we do it in Scala
[13:29:32] <aesteve> let me get some aspirin
[13:31:15] <cescoffier> @temporalfox (changing channel again
[13:31:27] <temporalfox> why are you saying that ?
[13:31:32] <cescoffier> @temporalfox the cache is just a json file (.something.json)
[13:31:40] <temporalfox> where ?
[13:31:44] <cescoffier> @temporalfox was not expecting ping on IRC
[13:31:50] <temporalfox> .stack-manager-cache.json
[13:31:55] <cescoffier> in the current directory / VERTX_HOME if set
[13:31:58] <cescoffier> yep
[13:31:58] <temporalfox> ok
[13:32:09] <cescoffier> it just stored the path to the resolved artifact
[13:32:10] <temporalfox> we should have several .json files in the vertx
[13:32:13] <temporalfox> full
[13:32:14] <temporalfox> etc…
[13:32:20] <cescoffier> if the file is not there (anymore) it resolves it again
[13:32:22] <temporalfox> so user can easily switch to it
[13:32:27] <temporalfox> mayeb put them in a directory
[13:32:30] <temporalfox> so if someone does
[13:32:36] <temporalfox> vertx resolve whatever
[13:32:42] <temporalfox> it would look for whatever.json
[13:32:45] <cescoffier> I'm not sure about this “profile” idea
[13:32:50] <temporalfox> if it's not found
[13:32:54] <temporalfox> it's not a profile
[13:32:58] <cescoffier> because it asks the user to change set the stack file
[13:33:06] <cescoffier> if he forget to set it, it's back to the default one
[13:33:12] <cescoffier> so, really error prone
[13:33:21] <cescoffier> well kind of profile stored in different file
[13:33:27] <temporalfox> it avoids the user creating new files on purpose
[13:33:33] <temporalfox> or inventing them
[13:33:39] <temporalfox> let's say I download the not full distrib
[13:33:43] <temporalfox> and I want to have “more”
[13:33:56] <cescoffier> you edit the exiting file
[13:33:57] <temporalfox> how do I do that ?
[13:34:06] <temporalfox> yes but you need to create the content
[13:34:12] <temporalfox> you cannot copy it from somewhere else
[13:34:14] <temporalfox> that already exists
[13:34:15] <cescoffier> “full” does not really exist anymore
[13:34:31] <temporalfox> somwehre we need a list of everything user can take
[13:34:33] <cescoffier> it is just created for docker and NPM, but IMHO, it should not be distributed anymore
[13:34:33] <temporalfox> that is released
[13:34:46] <temporalfox> so perhaps we should comment some parts in the json file
[13:34:49] <cescoffier> everything he can take ? well, list the full maven repo
[13:34:52] <temporalfox> I don't know
[13:34:57] <cescoffier> no !
[13:35:00] <temporalfox> so you mean someone goes in maven central
[13:35:05] <cescoffier> open the file, everything is there, just not included
[13:35:07] <temporalfox> and find what could be the supported stuff ?
[13:35:15] <cescoffier> it's already in the file
[13:35:25] <temporalfox> ah ok
[13:35:35] <temporalfox> could we have them
[13:35:35] <cescoffier> the “default” json file list all the component from the official stack (except JCA)
[13:35:39] <temporalfox> or maybe it works
[13:35:40] <temporalfox> have
[13:35:41] <temporalfox> “included”: true
[13:35:50] <temporalfox> be resolvable as a property
[13:35:54] <temporalfox> ${whatever}
[13:36:18] <temporalfox> and perhaps we should have a format more flexible
[13:36:29] <cescoffier> macro are not supported for included I guess (need to check) what that's rather easy to add
[13:36:37] <temporalfox> define the various versions somewhere
[13:36:44] <temporalfox> andthen have a coma separated list of the actual content
[13:36:50] <cescoffier> json is not really flexible ….
[13:37:05] <cescoffier> (missing inclusions, inheritence…)
[13:37:20] <temporalfox> like “content”: [ “vertx-core”, “vertx-lang-ceylon”, … ]
[13:37:59] <temporalfox> or perhaps we need something more tooled with vertx manager
[13:38:07] <cescoffier> does not work for artifacts having the same artifact id
[13:38:37] <temporalfox> ah ok
[13:38:48] <cescoffier> but yes, the json format is not flexible enough
[13:38:50] <temporalfox> maybe we could support several descriptor files
[13:38:57] <cescoffier> HOCON would have been better I would say
[13:38:58] <temporalfox> so one can combine a vertx descriptor
[13:39:07] <temporalfox> and a “user” descriptor“
[13:39:19] <cescoffier> it's what I was trying to do in the first place (inclusion and inheritence of stacks)
[13:39:24] <temporalfox> or we do support inclusion ?
[13:39:27] <cescoffier> but this leads to non-determinitic resolution
[13:39:40] <temporalfox> well I'm just saying things are aggregated
[13:39:40] <cescoffier> json does not support inclusions (YAML did)
[13:39:52] <temporalfox> like if it were one single file
[13:39:56] <temporalfox> but it's several files
[13:40:20] <cescoffier> aggragation implieis order, this would be distrubing as it won't be the “Same” order as what you would expect in Maven
[13:40:22] <temporalfox> I think what we are missing at least is a report
[13:40:29] <temporalfox> that list everything in the config file
[13:40:38] <temporalfox> and print “yes” / “no”
[13:40:39] <temporalfox> on the console
[13:40:49] <cescoffier> well, don't forget we have transitive
[13:40:54] <cescoffier> and so it's not yes / no
[13:40:55] <temporalfox> I mean top level
[13:41:01] <temporalfox> there could be a –transitive
[13:41:02] <cescoffier> it's yes / no / already selected by
[13:41:03] <temporalfox> flag
[13:41:09] <cescoffier> no
[13:41:21] <cescoffier> not a flag, this would be a disater, transitivity is decided at the dependency level
[13:41:36] <temporalfox> without a falg then
[13:41:46] <temporalfox> something that allows easy reporting of what is actually there
[13:41:54] <temporalfox> so if someone adds new jar in libs
[13:41:57] <temporalfox> and you do a resolve
[13:42:01] <temporalfox> are these jars removed ?
[13:43:06] <cescoffier> yes
[13:43:11] <cescoffier> everything not listed is removed
[13:43:24] <cescoffier> it's the only way to cleanup things correctly
[13:43:25] <temporalfox> I think we should keep them
[13:43:32] <cescoffier> if you want to add jar manually, don't use the stack manager
[13:43:33] <cescoffier> no
[13:43:48] <cescoffier> I've tried, went out of control
[13:44:02] <cescoffier> (conflicts, not understanding why a jar was still there)
[13:44:18] <temporalfox> just tried vertx resolve error
[13:44:19] <temporalfox> got
[13:44:20] <cescoffier> if you want to do stuff manually, don't use the resolver
[13:44:20] <temporalfox> https://gist.github.com/vietj/c607831263ca5dec7de0
[13:44:24] <cescoffier> do it by yourself
[13:44:24] <temporalfox> it's a bit cryptic
[13:44:37] <temporalfox> ” .Users/julien/java/vertx-stack/stack-manager/target/vert.x-3.2.0-SNAPSHOT/–launcher-class=io.vertx.core.Launcher“
[13:44:50] <temporalfox> . should not be here if we can
[13:44:53] <cescoffier> hum, I did something wrong yesterday (missing a space)
[13:45:01] <temporalfox> and there is no extra space before ”–“
[13:46:13] <temporalfox> perhaps this list entries should have “\r\n” before
[13:46:18] <temporalfox> so they are listed
[13:46:19] <temporalfox> vertically
[13:48:32] <cescoffier> except that you have only one location if VERTX_HOME is not defined
[13:48:46] <temporalfox> ok
[13:48:52] <cescoffier> I can use \n\t - …
[13:49:02] <cescoffier> and display only one line in this case
[13:49:25] <temporalfox> I'm wondering if we could in the vertx script start the shell and have this followed by an SSH command to this vertx instance
[13:49:36] <temporalfox> so you have an implicit console to the running instance
[13:50:03] <temporalfox> and cert would be created on the fly
[13:51:17] <cescoffier> should probably be an interactive mode
[13:51:23] <cescoffier> (–console, or –shell)
[13:51:31] <temporalfox> but would it work technically ?
[13:51:44] <cescoffier> generating certificate is always tricky, but yes
[13:51:50] <temporalfox> I don't want to manage the JVM ios for shell
[13:51:54] <temporalfox> because it's really messy
[13:52:16] <temporalfox> and need to use JVM internal features
[13:52:18] <temporalfox> like Signal
[13:52:30] <temporalfox> and hard to maintain
[13:53:09] <temporalfox> do we have documentation on the website for the stack manager ?
[13:53:16] <temporalfox> or it is only in CLI ?
[13:54:16] <cescoffier> yes the stack manager is already on the 32.0. web site
[13:54:22] <cescoffier> (in advanced)
[19:39:54] * ChanServ sets mode: +o temporalfox
[20:43:08] * ChanServ sets mode: +o temporalfox [21:00:29] <befagos> who is using vertx in docker enviroments? [21:19:28] <aesteve> hi :) [21:19:37] <aesteve> I need some advice if anyone's here [21:20:06] <aesteve> https://github.com/aesteve/vertx-groovy-sugar#invoking-an-async-service [21:20:17] <aesteve> it's a common pattern I'd like to write some sugar for [21:20:33] <aesteve> but the '»' stuff isn't self explainatory [21:20:39] <aesteve> if anyone has an idea [21:20:43] <aesteve> … :/ [21:24:01] <aesteve> 'context.onSuccess' or 'context.asyncSuccess' maybe [22:04:42] * ChanServ sets mode: +o temporalfox
[22:05:30] <Sam> hi guys [22:14:33] <Sam> there seems to be a overall url size limit of 4kb for the httpserver. In my use case we do want to support more.
[22:17:15] <Sam> you could make it configurable [22:18:10] <AlexLehm> Sam: for the request size?
[22:18:45] <Sam> yeah [22:19:12] <Sam> i see it hard coded to 4096
[22:19:14] <AlexLehm> i think someone has asked for the a while back, not sure if there is a feature request for that
[22:19:44] <Sam> yeah, i came across that [22:19:50] <AlexLehm> i know the problem, we had a cookie issue on tomcat at some point (in my work project, which has nothing to do with vertx) [22:20:09] <AlexLehm> if this is on the bugzilla, you could write a request [22:22:19] <AlexLehm> no, it doesn't look like there is a ticket for that [22:23:02] <AlexLehm> temporalfox: Julien, I think I remeber someone asked about making the request size limit configurable some time ago, but i am not sure what became of that [22:24:36] <Sam> what is the typical turn around time after i create a ticket?
[22:26:36] <Sam> asking cause I could make the change and issue a pull request [22:27:33] <temporalfox> Sam we plan to release soon, by end of next week
[22:27:43] <temporalfox> Sam make sure you follow guidlines [22:27:46] <AlexLehm> hm, if you already have the cla for eclipse signed that is not a problem, there are a few things to observe when contributing [22:27:48] <temporalfox> Sam provide a test
[22:28:12] <temporalfox> https://github.com/vert-x3/wiki/wiki/How-to-contribute-to-Vert.x
[22:28:18] <temporalfox> if the PR is fine, that can make it
[22:28:29] <temporalfox> we will review it and comment
[22:28:31] <temporalfox> be reactive
[22:29:23] <Sam> cool, will do follow up soon. Thanks. [22:32:17] <Sam> i had another one I will add. Basically I did not find a way a direct way to query the scheme of the url
[22:35:22] <Sam__> the only way I saw was to use absoluteURI. But if the url is invalid the absoluteURI method fails.