[10:57:35] *** ChanServ sets mode: +o temporalfox

[12:32:57] <aesteve> hi everyone :)

[12:33:07] <temporalfox> hi Arnaud!

[12:33:14] <temporalfox> how are you doing ?

[12:33:49] <aesteve> nice Julien, eager to meet you next week !

[12:33:53] <aesteve> and you ?

[12:57:09] <aesteve> actually Julien, I took a look at Ceyla last weekend to have a glimpse on Ceylon, it was a good starting point, thanks

[13:05:43] <temporalfox> aesteve cool

[13:05:55] <temporalfox> have you looked at the new vertx-lang-ceylon stuff ?

[13:06:00] <temporalfox> there is an example repo

[13:06:08] <temporalfox> I'm doing the final touches to it

[13:06:20] <aesteve> not yet, since I didn't work to work with Vert.x

[13:06:29] <temporalfox> https://github.com/vietj/ceylon-vertx-examples

[13:07:54] <aesteve> I'm thinking, but still really ealry in the thinking process : since ceylon compiles to JS, it should be possible to have a React API for building React components and stuff in ceylon (thus in a type-safe way)

[13:09:28] <aesteve> and since ceylon allows to declare “nested” components (like the Table, Column, Border example on the website) this is excellent for emulating React's JSX syntax

[13:09:28] <temporalfox> isomorphic ?

[13:09:35] <aesteve> not necessarily

[13:10:04] <cescoffier> temporalfox : isomorphic is word meaning (wrongly from the math sense) “ use server code on the client, and vice-versa

[13:10:14] <temporalfox>

[13:10:18] <temporalfox> I know you are keen on wording

[13:10:29] <temporalfox> nevertheless that's how people name this stuff

[13:10:36] <cescoffier> I don't get why they call this isomorphic, it's a no sense for me

[13:10:37] <temporalfox> in JS land

[13:10:43] <temporalfox> I name things to be understand by others

[13:10:46] <aesteve> they changed words actually, now they call it “Universal”

[13:10:50] <temporalfox> ah coo

[13:10:52] <temporalfox> cool

[13:10:58] <cescoffier> well… in JS everything is a terrible mistake, even the word they use

[13:10:59] <temporalfox> so it works in Erlang VM too ?

[13:11:16] <temporalfox> declarative programming now!!!!

[13:11:16] <cescoffier> yes, universal is the new word, not sure it's actually better

[13:11:25] <aesteve> but for now, I just don't care of the server-side

[13:11:31] <temporalfox> ok

[13:11:40] <temporalfox> I've done a port of knockout JS in ceylon

[13:11:50] <aesteve> what matters for me is : writing a client side application, in React, but not in JS

[13:13:25] <aesteve> Gavin pointed me to the “native interfaces”

[13:13:52] <aesteve> which are great to start, but I'd like to wrap the React boilerplate like “createClass”, “createElement”, etc.

[13:14:06] <aesteve> so I'll keep on looking, that's an interesting project :)

[13:14:07] <temporalfox> so you would integrate with react ?

[13:15:19] <aesteve> kindof, yes. Still not sure where to go, a native interface would be enough, but I'd like to “mimic” the React API in a typesafe way

[13:16:00] <aesteve> I think this weekend, I'll write some gists to clarify my ideas. Some gists of : “what would the end-user code look like in Ceylon”

[13:17:22] <temporalfox> I see what you mean

[14:24:52] <temporalfox> hi pmlopes

[14:24:59] <pmlopes> hi

[14:25:06] <temporalfox> in the SQL / jdbc stuff

[14:25:15] <temporalfox> can you tell me what types can be annoated with @Nullable ?

[14:25:22] <temporalfox> either type

[14:25:27] <temporalfox> or generics

[14:25:36] <temporalfox> like List<@Nullable Something>

[14:25:46] <temporalfox> I think you know better than me what is possible

[14:26:02] <pmlopes> in sql everything can be null

[14:26:10] <pmlopes> it all depends on the table definition

[14:26:30] <temporalfox> yes but I mean

[14:26:33] <temporalfox> in the API itself

[14:26:40] <temporalfox> the vertx api

[14:26:57] <pmlopes> oh, let me have a look i don't know it by heart

[14:27:16] <temporalfox> ok

[14:27:21] <temporalfox> is it in sql common or in jdbc ?

[14:27:33] <temporalfox> if it's in Json then no need to bother

[14:27:36] <temporalfox> as json can carry null

[14:28:30] <pmlopes> yes, jsons can always have nulls

[14:29:28] <pmlopes> i am looking at the API and there is never directly json being passed, it is all wrapped with a ResultSet DataObject

[14:29:36] <pmlopes> there the results can be null

[14:29:46] <pmlopes> or any value in the results can be null

[14:30:27] <temporalfox> ok

[14:30:38] <temporalfox> I'm not sure we are handling null in data object yet

[14:30:57] <temporalfox> but it's json

[14:30:58] <temporalfox> so it's ok

[14:31:16] <temporalfox> btw I added more code in these data object

[14:31:25] <temporalfox> to have more data when used from javascript

[21:19:26] <aesteve> hello again :) I have a design question regarding mapping a blocking API into an async Vert.x service

[21:20:14] <aesteve> the naive approach I've used so far, was to wrap everything into executeBlocking() stuff

[21:20:48] <aesteve> but when I look at JDBC service for instance, this is absolutely not the pattern you used

[21:24:33] <aesteve> for instance : https://github.com/vert-x3/vertx-jdbc-client/blob/860727425353489fc85686674566718fb2883555/src/main/java/io/vertx/ext/jdbc/impl/JDBCClientImpl.java#L173-L181

[21:25:29] <aesteve> there's a threadPoolExecutor etc. So I'm not really sure if the naive executeBlocking approach is “good enough” ? If anyone has thoughts to share on this subject…

[21:46:28] <AlexLehm> aesteve: I assume the executeBlocking uses a thread pool as well

[21:47:36] <aesteve> hi AlexLehm :) yes I think so too, that's why I'm a bit confused.

[21:48:23] <aesteve> I'm actually looking for an old thread in the google group. I remember someone pointing that out “why using executeBlocking everywhere in JDBC is a bad idea” but pretty hard to find ^^

[21:53:51] <AlexLehm> hm, you probably have to ask that Tim

[21:55:52] <aesteve> yep, no worries, that thread just clinged to my mind when writing “executeBlocking” everywhere