{"action":"created","issue":{"url":"https://api.github.com/repos/vert-x3/vertx-lang-python/issues/1","labels_url":"https://api.github.com/repos/vert-x3/vertx-lang-python/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/vert-x3/vertx-lang-python/issues/1/comments","events_url":"https://api.github.com/repos/vert-x3/vertx-lang-python/issues/1/events","html_url":"https://github.com/vert-x3/vertx-lang-python/issues/1","id":66262991,"number":1,"title":"Build fails because of various errors","user":{"login":"dano","id":38807,"avatar_url":"https://avatars.githubusercontent.com/u/38807?v=3","gravatar_id":"","url":"https://api.github.com/users/dano","html_url":"https://github.com/dano","followers_url":"https://api.github.com/users/dano/followers","following_url":"https://api.github.com/users/dano/following{/other_user}","gists_url":"https://api.github.com/users/dano/gists{/gist_id}","starred_url":"https://api.github.com/users/dano/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dano/subscriptions","organizations_url":"https://api.github.com/users/dano/orgs","repos_url":"https://api.github.com/users/dano/repos","events_url":"https://api.github.com/users/dano/events{/privacy}","received_events_url":"https://api.github.com/users/dano/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/vert-x3/vertx-lang-python/labels/deferred","name":"deferred","color":"ededed"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":23,"created_at":"2015-04-04T02:03:12Z","updated_at":"2015-07-17T21:05:23Z","closed_at":null,"body":"Attempting a Maven build fails with a very long stack trace, most of which look something like this:\r\n\r\n`Address.java:27: error: Could not generate element for io.vertx.core.net.SocketAddress: [Error: unable to resolve method: io.vertx.codegen.Helper.getGenericType(java.lang.String) [arglength=1]]`\r\n\r\nA few other errors are mixed in, though:\r\n\r\n`[ERROR] diagnostic: /home/dan/code/vert.x/vertx-lang-python/target/vertx-core/io/vertx/core/dns/DnsClient.java:36: error: Could not generate element for io.vertx.core.dns.DnsClient: [Error: unable to resolve method: io.vertx.codegen.Helper.isBasicType(java.lang.String) [arglength=1]]`\r\n\r\n`[ERROR] diagnostic: /home/dan/code/vert.x/vertx-lang-python/target/vertx-core/io/vertx/core/Vertx.java:87: error: Could not generate model for vertx(io.vertx.core.VertxOptions): type io.vertx.core.VertxOptions is not legal for use for a parameter in code generation\r\n  static Vertx vertx(VertxOptions options) {`\r\n\r\n`[ERROR] diagnostic: /home/dan/code/vert.x/vertx-lang-python/target/vertx-core/io/vertx/core/file/FileSystem.java:492: error: Could not generate model for open(java.lang.String,io.vertx.core.file.OpenOptions,io.vertx.core.Handler<io.vertx.core.AsyncResult<io.vertx.core.file.AsyncFile>>): type io.vertx.core.file.OpenOptions is not legal for use for a parameter in code generation`\r\n\r\n`[ERROR] diagnostic: /home/dan/code/vert.x/vertx-lang-python/target/vertx-core/io/vertx/core/eventbus/Message.java:93: error: Could not generate model for reply(java.lang.Object,io.vertx.core.eventbus.DeliveryOptions): type io.vertx.core.eventbus.DeliveryOptions is not legal for use for a parameter in code generation\r\n`\r\n\r\nIt looks like the `getGenericType` and `isBasicType` methods were removed from vertx-codegen back in Decmber, in this commit: https://github.com/vert-x3/vertx-codegen/commit/e8329c4d940b4eebfd8e7671f1d37b2b97c617c7. I'm not sure if some other method should be used intead, or if those methods need to be added back in. The commit message just said it was cleaning up unused methods, so if that was the only reason for removal, adding them back probably makes sense. No idea about the other errors, though.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/vert-x3/vertx-lang-python/issues/comments/122415544","html_url":"https://github.com/vert-x3/vertx-lang-python/issues/1#issuecomment-122415544","issue_url":"https://api.github.com/repos/vert-x3/vertx-lang-python/issues/1","id":122415544,"user":{"login":"kuujo","id":823318,"avatar_url":"https://avatars.githubusercontent.com/u/823318?v=3","gravatar_id":"","url":"https://api.github.com/users/kuujo","html_url":"https://github.com/kuujo","followers_url":"https://api.github.com/users/kuujo/followers","following_url":"https://api.github.com/users/kuujo/following{/other_user}","gists_url":"https://api.github.com/users/kuujo/gists{/gist_id}","starred_url":"https://api.github.com/users/kuujo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kuujo/subscriptions","organizations_url":"https://api.github.com/users/kuujo/orgs","repos_url":"https://api.github.com/users/kuujo/repos","events_url":"https://api.github.com/users/kuujo/events{/privacy}","received_events_url":"https://api.github.com/users/kuujo/received_events","type":"User","site_admin":false},"created_at":"2015-07-17T21:05:23Z","updated_at":"2015-07-17T21:05:23Z","body":"I think that's awesome and totally possible! We'll have to discuss this on the dev group since it diverges from the Vert.x API, though obviously not much since the future is an additional return value. But I think it's a very interesting proposition.\n\nWhat I'd be concerned about is confusion. We're essentially providing two ways of accomplishing the same task, but we have to make sure users can't use both. I think we'd have to ensure if a typical async handler is passed to a method, None is returned, and that's fine.\n\nThere's some benefit to the async handler approach in comparison to futures, and it may be an issue. Specifically, in many cases Vert.x optimizes cases where no handler is passed to an overloaded method. For instance, if no reply handler is passing to the even bus's send() method, Vert.x doesn't need to store the handler and context for the reply. Assuming that in all cases the user might want some feedback on when an asynchronous operation is complete could dampen performance and create unnecessary garbage in the JVM. There are certainly ways around that, but it really depends on how clean the solutions are.\n\nLet me collect my thoughts on this tonight and bring it up in the dev group where hopefully more people can contribute to the decision making process.\n\n> On Jul 17, 2015, at 1:11 PM, dano <notifications@github.com> wrote:\n> \n> @kuujo That's fair. Another possibility I was thinking about was something along the lines of vertx-sync, but for Python/Jython - basically, suspendable coroutines very much along the lines of what asyncio gives you, but just using native Python coroutine features and the Vert.x event loop, rather relying on the asyncio event loop. Any method that takes a Handler<AsyncResult<X>> as its final argument (just like vertx-sync) would return a Future of some kind, rather than None. Unlike vertx-sync, it could still optionally take a callback. So the Python code would look something like this (I'm leaving out parameter validation, type conversion, etc. here, but you get the idea):\n> \n> def clustered_vertx(self, result_handler=None, **options):\n>     fut = Future()  # This is very similar to `asyncio.Future`, but wouldn't need the asyncio event loop.\n>     _handler = wrap_handler(result_handler, fut)\n>     util.jvm.io.vertx.core.Vertx.clusteredVertx(VertxOptions(options), _handler)\n>     return fut\n> wrap_handler would look like this:\n> \n> def wrap_handler(user_handler, fut):\n>     def set_result(result, exc):\n>         if exc is not None:\n>              fut.set_exception(exc)\n>         else:\n>              fut.set_result(result)\n>         if user_handler is not None:\n>              user_handler(result, exc)\n> A user could optionally wait on the future that's returned using yield/yield from, or just let the callback they passed fire:\n> \n> def on_got_cv(v):\n>     print(\"Got {}\".format(v))\n> \n> if __name__ == \"__main__\":\n>     clustered_vertx(on_got_cv)  # Still returns a future, but you can ignore it.\n> Or\n> \n> @coroutine\n> def main():\n>     v = yield from clustered_vertx()  # You could still pass a callback here.\n>     print(\"Got {}\".format(v))\n> \n> if __name__ == \"__main__\":\n>     vertx_runner.run(main())  # Uses the vertx event loop to drive the app.\n> I haven't actually coded this up, but I think something like it should be possible for both Py4J and Jython. If it proves to be doable, it could theoretically be the default API for both Python and Jython, since it doesn't prevent a purely callback based approach. Of course, it could also just be done as a separate project, same as vertx-sync.\n> \n> —\n> Reply to this email directly or view it on GitHub.\n> \n"}}