{"action":"created","issue":{"url":"https://api.github.com/repos/JuliaMath/Sundials.jl/issues/67","repository_url":"https://api.github.com/repos/JuliaMath/Sundials.jl","labels_url":"https://api.github.com/repos/JuliaMath/Sundials.jl/issues/67/labels{/name}","comments_url":"https://api.github.com/repos/JuliaMath/Sundials.jl/issues/67/comments","events_url":"https://api.github.com/repos/JuliaMath/Sundials.jl/issues/67/events","html_url":"https://github.com/JuliaMath/Sundials.jl/pull/67","id":166595855,"number":67,"title":"WIP: improve wrappers, add handles and NVector","user":{"login":"alyst","id":348591,"avatar_url":"https://avatars.githubusercontent.com/u/348591?v=3","gravatar_id":"","url":"https://api.github.com/users/alyst","html_url":"https://github.com/alyst","followers_url":"https://api.github.com/users/alyst/followers","following_url":"https://api.github.com/users/alyst/following{/other_user}","gists_url":"https://api.github.com/users/alyst/gists{/gist_id}","starred_url":"https://api.github.com/users/alyst/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alyst/subscriptions","organizations_url":"https://api.github.com/users/alyst/orgs","repos_url":"https://api.github.com/users/alyst/repos","events_url":"https://api.github.com/users/alyst/events{/privacy}","received_events_url":"https://api.github.com/users/alyst/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":29,"created_at":"2016-07-20T14:30:54Z","updated_at":"2016-08-24T22:58:25Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/JuliaMath/Sundials.jl/pulls/67","html_url":"https://github.com/JuliaMath/Sundials.jl/pull/67","diff_url":"https://github.com/JuliaMath/Sundials.jl/pull/67.diff","patch_url":"https://github.com/JuliaMath/Sundials.jl/pull/67.patch"},"body":"This is a \"loose\" rebase of #29 to the master. So it has the same goal (avoid memory leaks by enabling some automatic memory management on the Julia side) but does it a little bit differently.\r\n\r\n* `NVector` code (the `N_Vector` wrapper that manages the memory) is mostly taken from #29 \r\n* `Handle` concept (CVODEMem, IDAMem, KINMem wrapper that calls appropriate `XXXFree()` methods upon finalization) generalizes similar idea from #29 by using type parameters\r\n* Wrappers generator is enhanced to facilitate `Handle` and `NVector` and provide more Julia-friendly methods\r\n   * untyped pointers to Sundials objects are replaced with the typed pointers\r\n   * in addition to the low-level wrappers that accept pointers and `N_Vector`, the generator automatically adds higher-levels wrappers that provide automatic conversion of Julia objects (`Handle`, `NVector`, `Vector`) into appropriate low-level types\r\n   * `user_data` is of type `Any` to facilitate passing Julia objects directly\r\n   * definitions from the system headers and implementation details (from `xxx_impl.h` headers) are not wrapped\r\n   * only \"sequantial\" API for `N_Vector` is wrapped (parallel one is not)\r\n* hand-written higher-level wrappers removed\r\n* \"simple\" API is updated to the new low-level API (+ added support for passing Julia user data to Julia functions) and moved to a separate file\r\n\r\nWith these changes I was able to fix the `N_Vector` memory leaks in my Sundials-using code.\r\nBut there must be a lot of issues with the current state of the PR (e.g. lifetime of `NVector`s  that are implicitly generated by \"higher-level\" wrapper functions), so any comments and suggestions are welcome.\r\n\r\ncc @acroy @stevengj "},"comment":{"url":"https://api.github.com/repos/JuliaMath/Sundials.jl/issues/comments/242234362","html_url":"https://github.com/JuliaMath/Sundials.jl/pull/67#issuecomment-242234362","issue_url":"https://api.github.com/repos/JuliaMath/Sundials.jl/issues/67","id":242234362,"user":{"login":"alyst","id":348591,"avatar_url":"https://avatars.githubusercontent.com/u/348591?v=3","gravatar_id":"","url":"https://api.github.com/users/alyst","html_url":"https://github.com/alyst","followers_url":"https://api.github.com/users/alyst/followers","following_url":"https://api.github.com/users/alyst/following{/other_user}","gists_url":"https://api.github.com/users/alyst/gists{/gist_id}","starred_url":"https://api.github.com/users/alyst/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alyst/subscriptions","organizations_url":"https://api.github.com/users/alyst/orgs","repos_url":"https://api.github.com/users/alyst/repos","events_url":"https://api.github.com/users/alyst/events{/privacy}","received_events_url":"https://api.github.com/users/alyst/received_events","type":"User","site_admin":false},"created_at":"2016-08-24T22:58:25Z","updated_at":"2016-08-24T22:58:25Z","body":"@ChrisRackauckas I've cherry-picked `simplified.jl` fixes from your branch, thanks.\r\n\r\nSomething to consider once this PR is merged: `cvode_fulloutput()` definitely makes sense, but maybe it needs a better name, because it was not immediately clear for me that it returns the output of each integration step (`cvode_stepwise()`?). Also there is some code duplication with `cvode()`, so I'm tempting to suggest to merge `cvode_fulloutput()` into `cvode()` by introducing `mode=:normal/:one_step` keyword. The obvious downside is that the return type of `cvode()` would depend on input parameters, but maybe it is ok for simplified interface."}}
{"actor":{"display_login":"alyst"}}