Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1448406000 [2017/05/27 13:44]
irc:1448406000 [2017/05/27 13:44] (current)
Line 1: Line 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>​ LOL
 +
 +[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 :-D
 +
 +[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