{"action":"created","issue":{"url":"https://api.github.com/repos/opal/opal/issues/840","repository_url":"https://api.github.com/repos/opal/opal","labels_url":"https://api.github.com/repos/opal/opal/issues/840/labels{/name}","comments_url":"https://api.github.com/repos/opal/opal/issues/840/comments","events_url":"https://api.github.com/repos/opal/opal/issues/840/events","html_url":"https://github.com/opal/opal/issues/840","id":75308069,"number":840,"title":"Provide a way to retrieve code/comments for a method","user":{"login":"fkchang","id":13941,"avatar_url":"https://avatars.githubusercontent.com/u/13941?v=3","gravatar_id":"","url":"https://api.github.com/users/fkchang","html_url":"https://github.com/fkchang","followers_url":"https://api.github.com/users/fkchang/followers","following_url":"https://api.github.com/users/fkchang/following{/other_user}","gists_url":"https://api.github.com/users/fkchang/gists{/gist_id}","starred_url":"https://api.github.com/users/fkchang/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fkchang/subscriptions","organizations_url":"https://api.github.com/users/fkchang/orgs","repos_url":"https://api.github.com/users/fkchang/repos","events_url":"https://api.github.com/users/fkchang/events{/privacy}","received_events_url":"https://api.github.com/users/fkchang/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/opal/opal/labels/compiler","name":"compiler","color":"c5def5"},{"url":"https://api.github.com/repos/opal/opal/labels/feature","name":"feature","color":"02e10c"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2015-05-11T18:06:30Z","updated_at":"2016-09-13T12:58:19Z","closed_at":null,"body":"Per @vais request on gitter, I'll submit this as an issue.  I'm looking for an interface to get the code and/or comments for a method (possibly other things, whole class, lambda's etc.), for use in opal related tools, such as prototyped here https://www.youtube.com/watch?v=TRkhihHVLzQ\r\n\r\n@adambeynon and I have discussed a few times on irc about it, I've pasted the last one in which he had some ideas on how to implement it below.\r\n\r\n```\r\n17:53 <fkchang> adambeynon: any thoughts on code/comment lookup? I thought there was a gist you wanted to show me a little while back. \r\n17:54 <fkchang> I think I'm itching to add some light table inspired goodness into opal-inspector \r\n17:54 <adambeynon> fkchang: I scrapped the old stuff - it was very hacky. The compiler now is also much better as it doesnt destroy the old sexp tree\r\n17:55 <adambeynon> I think its a better idea to walk that sexp tree instead \r\n17:55 <adambeynon> and look for each class, module and def \r\n17:55 <adambeynon> each sexp has the line number and source file \r\n17:55 <adambeynon> so we can track back from there \r\n17:55 <adambeynon> keep a stack of where we are \r\n17:56 <adambeynon> each time we enter a module or class \r\n17:56 <adambeynon> dynamic methods might be tricky \r\n17:56 <adambeynon> but, attr_accessor and friends will be easy to find \r\n17:56 <adambeynon> if sexp.type == :call and sexp[1] == :attr_accessor; ... ; end \r\n17:57 <adambeynon> I think it would be safe to assume attr_accessor doesnt get overriden \r\n17:58 <adambeynon> fkchang: whether or not I can work on a full implementation is a different matter, but I can write a simple proof of concept extension to the compiler which should get you on your way \r\n17:58 <adambeynon> you can then take that and work out what is the best json format to export \r\n18:00 <adambeynon> fkchang: I am also not sure how you would integrate with Opal::Server and/or rails server and/or lissio server \r\n18:00 <adambeynon> I would think basing it on sourcemaps would be a good idea \r\n18:01 <adambeynon> i.e. a rack middleware that can be mounted \r\n18:01 <adambeynon> like we have /__opal_source_maps/* we could have /__opal_code_inspector/* or something \r\n18:03 <fkchang> adambeynon: the rack/ __opal_code_inspector__ seems like a good approach. On the front end, I anticipate \"caching\" that info, as the stuff you change in the browser would take precedence over what's on the server. By the same measure need a mechanism to push changes back to the server -- in my mind I sort of saw some sort of diff/pull request-ish mechanism that a user could ultimately accept or reject \r\n18:05 <fkchang> on the nature \"like source maps\", isn't source maps almost the same basic notion, i.e. give me opal code for this bit of js, where we'd pass it code \"entitye\" (i.e. method, inst variable) index instead of at file/line blah \r\n18:10 <fkchang> adambeynon: on the browser side, I imagine we'd use the same sexp walking mechanism. Maybe it's easier to work out the client side that will do that on the client side in a rudimentary form, and I can start with that w/the eventuality that it will pull in code from the server down the road, but that'd allow me to have an interface and at least show off functionality w/code written from within the browser \r\n```"},"comment":{"url":"https://api.github.com/repos/opal/opal/issues/comments/246672746","html_url":"https://github.com/opal/opal/issues/840#issuecomment-246672746","issue_url":"https://api.github.com/repos/opal/opal/issues/840","id":246672746,"user":{"login":"iliabylich","id":1265492,"avatar_url":"https://avatars.githubusercontent.com/u/1265492?v=3","gravatar_id":"","url":"https://api.github.com/users/iliabylich","html_url":"https://github.com/iliabylich","followers_url":"https://api.github.com/users/iliabylich/followers","following_url":"https://api.github.com/users/iliabylich/following{/other_user}","gists_url":"https://api.github.com/users/iliabylich/gists{/gist_id}","starred_url":"https://api.github.com/users/iliabylich/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/iliabylich/subscriptions","organizations_url":"https://api.github.com/users/iliabylich/orgs","repos_url":"https://api.github.com/users/iliabylich/repos","events_url":"https://api.github.com/users/iliabylich/events{/privacy}","received_events_url":"https://api.github.com/users/iliabylich/received_events","type":"User","site_admin":false},"created_at":"2016-09-13T12:58:19Z","updated_at":"2016-09-13T12:58:19Z","body":"@fkchang Comments and source location will be available after merging https://github.com/opal/opal/pull/1560. Source code can be easily added to the method definition using `@sexp.loc.expression.source` (xstr uses the same code to fetch original code).\r\n\r\nDo you think that it's a good idea to put it to a `$$source` property of the method body? We have to store it in the method body to support inheritance, and as a result it will look like:\r\n``` js\r\nOpal.def(self, 'method_name', TMP = function() {\r\n  // method body\r\n}, TMP.$$arity = 0, TMP.$$source_location = [...], TMP.$$comments = [...], TMP.$$source_code = \"...\")\r\n```\r\n^ Which looks weird to me :smile: "}}
{"actor":{"display_login":"iliabylich"}}