[03:28:27] <voidDotClass> I've installed mysql on an ubuntu instance, opened port 3306 on the server, changed bind-address to 0.0.0.0, but whenever i try to connect remotely to myserver.com:3306, either by telnet or mysql, it times out.
[03:28:30] <voidDotClass> any ideas?
[03:29:04] <voidDotClass> wrong chat
[09:38:23] * ChanServ sets mode: +o temporalfox [10:22:44] <aesteve> hi everyone hi temporalfox sorry for yesterday night I was exhausted :) [10:26:11] <aesteve> It's not a sync implementation as you pointed out. But I think it's the starting point for every AST transformation [10:26:22] <temporalfox> aesteve yes [10:26:43] <aesteve> get the curried closure, then run it on a fiber (if vertx-sync) or wrap it in a RxGroovy promise, etc. [10:26:45] <temporalfox> if you work out an algorithm for rewriting the AST [10:26:52] <temporalfox> to transofmr sync → async [10:27:03] <temporalfox> I would take it [10:27:08] <aesteve> I didn't think about this way [10:27:14] <aesteve> but it sounds interesting :) [10:27:22] <temporalfox> that's what I would like to do [10:27:29] <temporalfox> generate async java code from async code [10:27:37] <temporalfox> from “sync code” [10:27:43] <temporalfox> I think it's doable [10:27:55] <aesteve> I know nothing about AST in Java though [10:28:46] <temporalfox> it's similar [10:28:51] <temporalfox> less powerful than in groovy [10:28:57] <temporalfox> but the idea would not be to rewrite java ast [10:29:05] <temporalfox> rather generate .java from java ast [10:29:16] <temporalfox> so one can see the generated code [10:29:19] <temporalfox> and trace it [10:33:33] <aesteve> that makes sense idd [10:34:12] <aesteve> for now, I just have to change my “Promise” to a RxGroovy thing, and I think it'll be a cool addition [10:35:20] <aesteve> I was hugely inspired by http://beckje01.com/blog/2014/09/10/ratpack-promise/ [10:35:57] <temporalfox> I would like to improve the current Future in vertx [10:36:03] <temporalfox> and provide somethign comparable [10:36:10] <temporalfox> to allow some kind of ocmposition [10:36:18] <temporalfox> it would be similar to promise [10:36:25] <temporalfox> this is quite asked [10:36:37] <temporalfox> on the group [10:36:39] <aesteve> +1000 [10:36:45] <temporalfox> but it would mean some improvements in codegen I think [10:36:49] <temporalfox> to allow more things [10:36:53] <temporalfox> basically I would like at least [10:37:03] <aesteve> futures but also async results [10:37:09] <temporalfox> Future<List<T» join(Future<T> f1, Future<F> f2) [10:37:22] <temporalfox> and a “then” / “map” [10:37:52] <temporalfox> if that's possible [10:37:56] <aesteve> I struggled so much with that in nubes [10:38:05] <temporalfox> most of the time people want join [11:00:31] * ChanServ sets mode: +o temporalfox
[13:15:18] <lichking> hi, i was config hawkular standalone mode and add hawkular metrics to vertx but there is no app server when i login in hawkular. how can i add vertx ass app server to hawkular? is it possible?
[13:24:09] <lichking> please help :(
[13:24:34] * lichking slaps temporalfox around a bit with a large fishbot
[13:30:34] <cescoffier> lichking : ask the question on #hawkular
[13:30:46] <cescoffier> the vertx bridge just send the data to hawkular
[15:12:53] * ChanServ sets mode: +o temporalfox [16:59:52] * ChanServ sets mode: +o temporalfox
[17:11:14] <Narig0> Umm… I need help with MySQL PostgreSQL… some dependency is missing
[17:13:47] <cescoffier> Narig0 : Looking at it
[17:20:54] <Narigo> cescoffier, looks like the package “vertx-dependencies” is gone…?
[17:21:32] <cescoffier> package ?
[17:21:38] <cescoffier> no vertx-dependencies is still there
[17:21:43] <Narigo> so shall we use vertx-dependencies-3.2.0 (release) or 3.3.0-SNAPSHOT
[17:21:52] <cescoffier> works for me, try with -U
[17:22:06] <cescoffier> I would say 3.3.0-SNAPSHOT
[17:22:06] <Narigo> it has a dependency to 3.2.0-SNAPSHOT
[17:22:17] <cescoffier> if we have time we would need to change the async driver
[17:23:09] <cescoffier> so test failed on my machine
[17:23:17] <cescoffier> but the build is ok
[17:23:48] <cescoffier> done, I've updated to 3.3.0-SNAPSHOT
[17:24:13] <Narigo> thanks!
[17:25:15] <Narigo> Another thing - why we never really put out a release for that module…
[17:25:49] <Narigo> I think the “blocking” issue is the part “it doesn't do everything exactly like the JDBC driver”
[17:26:00] <cescoffier> yes.
[17:26:35] <cescoffier> first test failed for a long time and the new addition to the vertx-sql-common has not be added
[17:26:54] <cescoffier> pmlopes is more aware of the issue
[17:28:03] <Narigo> And I'm unsure if it's a good idea to make it behave like that… the JDBC driver in PostgreSQL takes the statement and adds a “RETURNING *” behind queries, which might not always be the best idea
[17:28:19] <Narigo> new addition to sql-common? :S
[17:31:11] <cescoffier> https://github.com/vert-x3/wiki/wiki/3.2.0---Release-Notes#vert-x3vertx-sql-common
[17:33:32] <cescoffier> there are a couple of unsupported operaiton exception
[17:34:03] <Narigo> cescoffier, are there some tests I could reuse…? ;)
[17:34:17] <cescoffier> Probably from the jdbc-client
[17:35:22] <temporalfox> probably also they need some abstraction to be reused like a tck
[17:36:47] <Narigo> like a tck?
[17:43:03] <cescoffier> temporalfox : there is no TCK for SQL (yet)
[17:43:17] <cescoffier> temporalfox : tricky as every driver has its own SQL flavor
[17:43:23] <temporalfox> I meant take the existing sql tests and decouple them from jdbc-client
[17:43:26] <cescoffier> flavor or dialect
[17:43:39] <temporalfox> ah I mean more for the client implemnetation
[17:43:48] <cescoffier> yes but these test are doing some SQL stuff that need to be adapted by driver
[17:43:50] <temporalfox> otheriwse yes, it's very difficult
[17:43:53] <temporalfox> ah yes
[17:44:02] <cescoffier> it's possible
[17:44:03] <temporalfox> indeed with hsqldb for jdbc-client
[17:44:07] <temporalfox> and mysql uses…
[17:44:10] <temporalfox> mysql
[17:44:11] <cescoffier> just need to be “implemented by the implemetor”
[17:55:43] <Narigo> cescoffier, https://github.com/vert-x3/vertx-mysql-postgresql-client/pull/29
[17:55:56] <cescoffier> yes, looks good
[17:55:57] <Narigo> this should fix the failing test (I hope)
[17:58:30] <cescoffier> that's easy to check
[17:59:22] <cescoffier> [INFO] BUILD SUCCESS
[17:59:56] <cescoffier> merged, thanks
[18:00:07] <cescoffier> I will discuss with Paulo about the last issue
[18:00:22] <cescoffier> if he is ok, we can do a release
[18:00:42] <cescoffier> (we would just rever to 3.2.0)
[18:02:46] <Narigo> cescoffier, the biggest issue is the returning ids … we are consistent between mysql and postgresql by not returning last inserted ids - but as i understand it, he wants to support it. doing that in the vert.x wrapper around the driver - is that a good idea at all? should it be done in mauricios driver?
[18:23:07] <Narigo> cescoffier, how can we trigger a build @ mysql-postgresql? :)
[18:33:12] <AlexLehm> Narigo: on the jenkins?
[18:33:59] <Narigo> AlexLehm, yes
[18:34:17] <AlexLehm> i think that can be triggered by everybody who has an account
[18:35:28] <Narigo> Ahh.. I needed to login :D
[18:35:41] <AlexLehm> i can do it for you
[18:35:44] <Narigo> I thought the build triggers whenever something is pushed on master in GitHub
[18:35:56] <Narigo> AlexLehm, it's okay, I already started the build…
[18:36:05] <AlexLehm> it usually does but that depends on a github hook that may be missing
[18:36:10] <Narigo> I wasn't logged in so I didn't see the button…
[18:36:51] <AlexLehm> if you are admin of the project, you can check the hook
[18:41:21] <Narigo> Need to check that next week - got to go :/
[19:36:35] <pbragahe> Has anyone here seen an issue on Vert.x 3.1 where verticles which are undeployed (i.e. the undeploy callback has returned succesfully) are still subscribed to the eventbus and their timers are still firing? I'm seeing it consistently in one of our apps but haven't been able to isolate repro steps yet.
[19:37:01] <pbragahe> (and looking at 3.2 release notes, nothing looks applicable)
[20:02:13] <pmlopes> @Narigo the tests are failing because the serialization to json changed
[20:03:57] <pmlopes> the issue is that the test does assertions on a specific format order and this not correct anymore
[20:21:44] * ChanServ sets mode: +o temporalfox [21:35:44] * ChanServ sets mode: +o temporalfox