[09:44:17] <a_> g
[09:44:19] <a_> test
[10:00:45] <purplefox> #help
[10:01:29] <purplefox> temporalfox: cescoffier pmlopes: do any of you know how to get channel ops status in an irc channel if there are no channel ops here already?
[10:01:59] <pmlopes> sorry, no
[10:07:53] <purplefox> pmlopes: cescoffier temporalfox: can we postpone the meeting 15 mins - just in the middle of something right now :(
[10:08:02] <temporalfox> ok
[10:08:10] <cescoffier> purplefox: no problem we are already there
[10:08:11] <pmlopes> no problem
[10:14:34] <SLedunois> Hi!
[10:14:47] <SLedunois> I got an issue with vertx at starting
[10:15:22] <SLedunois> it said : “Unable de find or load the main class org.vertx.java.plateform.impl.cli.Starter”
[10:15:28] <SLedunois> it-'s on windows 7
[10:15:40] <SLedunois> I tried on linux and there is no issues
[10:15:46] <SLedunois> can someone help me about it?
[10:20:17] <purplefox> SLedunois: “plateform” ?
[10:20:41] <purplefox> pmlopes: temporalfox: cescoffier meeting
[10:20:45] <SLedunois> purplefox: Yes. It's the error that appear
[10:22:16] <purplefox> that's the wrong class name: https://github.com/eclipse/vert.x/blob/2.x/vertx-platform/src/main/java/org/vertx/java/platform/impl/cli/Starter.java
[10:24:27] <SLedunois> purplefox: Yes. But I clone a git repo
[10:24:31] <SLedunois> It works on Linux
[10:24:35] <SLedunois> But not on Windows
[10:26:43] <SLedunois> purplefox: When I looked your link, it's the same class name?
[11:44:27] <purplefox> pmlopes: cescoffier temporalfox: one thing I don't really get about asset pipelines, I would have thought it would be more efficient to create minified JS and concatenate resources during build time, not run time….
[11:44:46] <temporalfox> there are two schools
[11:44:53] <cescoffier> purplefox: yes there are two shools
[11:45:03] <temporalfox> I think in java we dont have efficient tools for asset pipelines so it's more runtime-ish
[11:45:06] <purplefox> SLedunois: no your fully qualified classname is wrong it's “platform” not “plateform”
[11:45:13] <temporalfox> and in js on the contrary it's more ahead of time
[11:45:25] <temporalfox> also in Ruby on rails where you have hot reload
[11:45:31] <temporalfox> there is no notion of “ahead” of time
[11:45:39] <cescoffier> in my opinion most of the stuff can be done offline at package time - so here the task is about documenting the integration with how they build their vert.x app
[11:45:58] <cescoffier> however some stuff cannot be done offline (ETAG) this requires runtime support
[11:46:07] <pmlopes> yes i agree with concatenating at compile time
[11:47:00] <pmlopes> at runtime imo i prefer to see the original so if there are bugs i can see what is going wrong
[11:47:12] <purplefox> with a high performance webserver it's usually more efficient to serve a file from sick (e.g. bypassing kernel altogether using sendfile) than trying to serve it dynamically from a stream
[11:47:18] <purplefox> s/sick/disk
[11:47:20] <purplefox> lol
[11:47:42] <purplefox> i can see the advantage during development so you don't have to rebuild all the time
[11:47:45] <purplefox> but.. production?
[11:49:05] <SLedunois> purplefox: Yes. Sorry. I write it, but I french so I write it as a “french” version
[11:49:17] <SLedunois> purplefox: My error is with plaTform
[11:49:45] <cescoffier> for production, if you have lots of static file with lots of traffic, apache or nginx would be much more efficient
[11:49:51] <purplefox> SLedunois: which version of Vert.x are you using and how are you running it?
[11:50:49] <purplefox> cescoffier: yeah, or just use a CDN :)
[11:51:05] <purplefox> (actually Vert.x is not much slower than nginx for static :) )
[11:51:38] <cescoffier> (actually, I'm sruprise no one has ask for webjar support)
[11:51:43] <SLedunois> purplefox: 2.1.1
[11:52:29] <SLedunois> purplefox: And i run it with : vertx runMod org…. 1.13.1 -conf conf-file
[11:52:31] <purplefox> SLedunois: that's pretty old. the latest production Vert.x is 3.0 and the latest on the 2.x branch is 2.1.6
[11:54:06] <aesteve> hi everyone :)
[11:55:21] <purplefox> SLedunois: i recommend upgrading to 2.1.6, if the problem continues post a message on the google group. make sure you follow the install instructions for windows
[11:56:39] <SLedunois> purplefox: I already upgrade to 2.1.6 but i still got the error
[11:56:54] <purplefox> you just said you were using 2.1.1…
[11:57:56] <purplefox> ok (assuming you are using 2.1.6 not 2.1.1)
[11:58:00] <purplefox> edit the vertx.bat script
[11:58:15] <purplefox> after this line:
[11:58:15] <purplefox> set CLASSPATH=%CLASSPATH%;%VERTX_HOME%\conf;%VERTX_HOME%\lib\*
[11:58:25] <purplefox> echo the value of CLASSPATH
[11:58:32] <purplefox> can you tell me what it says?
[11:59:44] <cescoffier> purplefox: about the file resolver PR, can you confirm that two commits were already merged (from another PR) ?
[12:00:14] <cescoffier> purplefox: in other world, am I becoming completely crazy ?
[12:00:33] <purplefox> ah bollocks. no you're not crazy. i created the other pr branch from the previous one not master
[12:00:38] <purplefox> so it contains the other commits
[12:00:46] <purplefox> and since the second PR has been merged first…
[12:01:48] <cescoffier> ourf….
[12:02:00] <cescoffier> ok, so reviewing only the new code
[12:03:23] <SLedunois> purplefox: it says le path to vertx conf folder an vertx lib folder
[12:04:24] <purplefox> which jdk version are you using?
[12:04:49] <purplefox> can you paste the classpath here?
[12:15:21] <purplefox> cescoffier: actually there is an argument that we should ban sys props altogether and have everything configurable programmatically from the options classes
[12:15:39] <purplefox> sys props are kind of ugly coz they're global so they “leak” between vert.x instances
[12:16:02] <cescoffier> it's only useful if you use the Starter class
[12:16:24] <SLedunois> purplefox: It's the 1.7
[12:16:25] <purplefox> well.. in starter we provide an automatic mapping between sys prop and options
[12:16:34] <purplefox> SLedunois: which exact version?
[12:16:40] <SLedunois> purplefox: and in my JDK, I got : C:\developpement\OPEN-ENT-NG\gradle-1.6\bin\;C:\developpement\OPEN-ENT-NG\MongoDB\Server\3.0\bin\;C:\developpement\OPEN-ENT-NG\vert.x-2.1.1\bin\;C:\developpement\OPEN-ENT-NG\apache-maven-3.3.3\bin\;C:\Program Files (x86)\Git\cmd\
[12:16:47] <cescoffier> so in this case, we can get rid of the system property to just use the option
[12:17:05] <purplefox> possibly, but we'll have to do this in several places, so it's a bit of work
[12:17:06] <SLedunois> purplefox: 1.7.0_79
[12:17:30] <SLedunois> purplefox: JAVA SE Environement build 1.7.1_79-b15
[12:17:49] <purplefox> can you just paste the output from java -version?
[12:18:17] <purplefox> SLedunois: also, what is the path that you just pasted above?
[12:18:38] <purplefox> is that the output from echoing the classpath?
[12:19:12] <SLedunois> purplefox: java version “1.7.0_79” Java(TM) SE Runtime Environment (build 1.7.0_79-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
[12:19:33] <purplefox> can you please also post the output from echoing the classpath from the script?
[12:23:24] <SLedunois> purplefox: C:\developpement\OPEN-ENT-NG\vert.x-2.1.1\bin>vertx.bat ;C:\developpement\OPEN-ENT-NG\vert.x-2.1.1\bin\..\conf;C:\developpement\OPEN-ENT -NG\vert.x-2.1.1\bin\..\lib\*
[12:23:46] <SLedunois> purplefox: the first line is the execution of the .bat
[12:24:32] <purplefox> so you're executing vert.x from inside the bin directory of the vert.x install?
[12:24:37] <purplefox> that's a bit strange
[12:25:13] <purplefox> did you add the Vert.x bin directory to your PATH environment variable?
[12:25:14] <SLedunois> purplefox: no. But when I run it in my project, classpath dosen't appear
[12:25:54] <purplefox> ok make sure you have added vert.x to your path
[12:26:25] <SLedunois> purplefox: MY path is : C:\developpement\OPEN-ENT-NG\gradle-1.6\bin\;C:\developpement\OPEN-ENT-NG\MongoDB\Server\3.0\bin\;C:\developpement\OPEN-ENT-NG\vert.x-2.1.1\bin\;C:\developpement\OPEN-ENT-NG\apache-maven-3.3.3\bin\;C:\Program Files (x86)\Git\cmd\
[12:27:23] <purplefox> ok, so go to another directory (not the vert.x bin install directory) and type:
[12:27:29] <purplefox> vertx run foo
[12:27:38] <purplefox> and tell me what the echoed classpath says this time
[12:28:00] <purplefox> btw… you are still running 2.1.1. please upgrade to 2.1.6 first :)
[12:31:15] <SLedunois> purplefox: I got an error : Failed in deploying verticle java.lang.ClassNotFoundException : foo
[12:31:36] <purplefox> ok, but what does the echoed classpath say?
[12:35:05] <purplefox> if you edited the script it will be output the classpath before attempting to run the verticle
[12:35:59] <purplefox> SLedunois: ^
[12:36:45] <purplefox> SLedunois: if you do not see any output before it says “Failed in deploying verticle java.lang.ClassNotFoundException : foo” that implies either a) you didn't edit the script b) it's running a different version of the script
[12:36:58] <purplefox> if b) then check your path you don't have another version of vert.x installed
[13:02:32] <AlexLehm> SLedunois: if you have problems with the vertx.bat script, you could set DEBUG=1 to turn logging on
[13:03:06] <AlexLehm> I can run vertx.bat version with a 2.1.1 dist I just downloaded
[14:26:57] <cescoffier> pmlopes: do you have a link about json interop ?
[14:27:31] <pmlopes> https://www.tbray.org/ongoing/When/201x/2015/03/23/i-json
[14:28:39] <cescoffier> thanks
[15:06:09] <aesteve> purplefox: I saw you were talking about pipeline / reload earlier, still want some enlightenment ? or you're seeing the point already ?
[15:56:02] <cescoffier> aesteve: it was mentioned (maybe by you) on the 3.1 wish list
[15:56:19] <cescoffier> so we start discussing how this can be done, without reinventing the wheel
[15:57:20] <aesteve> someone else mentionned it, I just picked up on it
[15:57:43] <aesteve> but I like the idea of a “plugin” API for static resources indeed
[15:58:06] <aesteve> if someone want to build an SASS plugin, he just could, etc.
[15:59:17] <cescoffier> the question is whether we should provide such pipelining or show how to use gulp, grub or something else
[15:59:42] <aesteve> grub ? grunt ?
[16:00:14] <cescoffier> yes
[16:00:18] <aesteve> gulp/grunt could be pipelines actually
[16:00:39] <aesteve> thing is, you can't do a better job than gulp/grunt/webpack do
[16:00:52] <cescoffier> because the number of processor / pre-processor / polyfill is so high, we cannot really support them all
[16:01:22] <cescoffier> that's why reusing something existing is interesting
[16:01:42] <aesteve> it is
[16:01:45] <cescoffier> while at the same time we should not be tied to one single tool, but just document how to use it
[16:01:55] <aesteve> i disagree
[16:02:16] <aesteve> in fact, using the tools is the developper problem, I agree on that
[16:02:31] <aesteve> but what Vert.x could do is handling “environments”
[16:02:58] <cescoffier> con you explain ?
[16:03:02] <cescoffier> can
[16:04:04] <aesteve> in some environments (local, dev) you'll want your static resources to be evaluated everytime a request is made
[16:04:41] <aesteve> in some, you'll want your resources to be built at startup
[16:04:47] <cescoffier> so you would like a runtime management
[16:04:51] <aesteve> in production, you'll rely on already-built resources
[16:05:50] <aesteve> the idea of a pipeline API is to allow the developer, for a matching resource (i.e. extension, ….) to act depending on the environment
[16:06:04] <aesteve> let's take SCSS files as an example
[16:07:05] <aesteve> if I want to build an SCSS plugin relying on the SCSS compiler, I'd need 3 extensions for the staticHandler
[16:07:15] <cescoffier> well this can be provided by a `watch` mode processing resources
[16:07:34] <cescoffier> without any runtime support - except cache deactivation
[16:08:01] <aesteve> not sure I understand actually :\
[16:10:34] <cescoffier> image a processing that everytime you save your SCSS file it generates the CSS file in the directory served by your vert.x application
[16:10:58] <aesteve> this could work this way, too
[16:10:58] <cescoffier> this is of course a 'dev' environment, because in prod your resources will have been prepared
[16:12:02] <cescoffier> so, in this case the only runtime (in vert.x) requirement is the cache deactivation (ETAG + Cache-Control) to be sure to use the latest generated resoruce
[16:13:43] <aesteve> I understand Vert.x tries to stay agnostic of other tools
[16:13:52] <cescoffier> I looks to me that this solution can be implemented using gulp or grub
[16:15:38] <aesteve> actually, watchify / browerify
[16:15:41] <aesteve> but anyway
[16:16:12] <aesteve> what I'm trying to explain is, when you're building a whole webapp (front + back) and not a simple example
[16:16:25] <aesteve> it's painful to deal with a lot of different tools
[16:17:14] <aesteve> at build-time, for example, Gradle, Maven, … will be responsible for : creating the server jar + building the front stuff. It's OK
[16:18:25] <aesteve> but in a pure development mode, you have a lot of different tools to manage, launch, relaunch, etc. it's simply painful
[16:19:43] <aesteve> if you've ever tried to use webpack / nodejs you'll see what I mean : you simply run one command and everything runs fine, bot front/back resources are managed
[16:20:07] <aesteve> this is a _major_ adoption feature for web developers
[16:20:33] <aesteve> and I think simply embedding node as a worker verticle would allow Vert.x to have the same kind of features
[16:22:27] <cescoffier> what you are describing is more a rails like framework (as wisdom for vert.x 2)
[16:40:48] <aesteve> well, maybe I guess… But asynchronous
[16:42:00] <cescoffier> yes, obviously
[16:46:14] <aesteve> well I guess it's a lost cause anyway since I don't manage to explain the needs properly, nevermind
[17:32:20] <millrossjez> @aesteve, I agree with you, currently we have to do a maven rebuild/redploy (via bower) when we change web resources, which slows down our front end dev quite a lot
[17:33:43] <aesteve> yes millrossjez I just can't find a proper way to explain it. I already tried with Tim and I'm just not sounding crystal clear
[17:34:24] <aesteve> I guess as long as you haven't face this issue in a developer environment, you just can't understand what I mean (in the way I exaplain it), that's really frustrating :(
[19:05:52] <temporalfox> good week end everyone