Approvals: 0/1
[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