Would there be interest in a GitHub organization that could house repositories relating to interoperability with other languages and software, like a "JuliaInterop"? For example, the organization could be a good place for PyCall, pyjulia, RCall, maybe Keno's Cxx, maybe AppleAccelerate, and others. If people think it would be useful then I can start one. I don't know how many organizations people actually want or actually make sense.
Anyway, it's just a thought.
This has come up a few times I think; here's one:
I agree with Avik there.
The point of organizations is, IMHO, primarily to group together packages and shared responsibility (i.e. commit rights) for people with a commonality of interest. I don't think that criteria applies well to interop because of limited contributor overlap.
There's a nice advertising benefit too, but I think better solutions exist.
On Wed, May 18, 2016 at 4:30 PM, Alex Arslan <[hidden email]> wrote:
Thanks for your reply! That's funny that Mike came up with the same name.
I guess I've misunderstood the point of organizations. I thought they were for grouping together high quality, similarly themed packages so that people know where to look for that stuff. I guess we should scrap the JuliaInterop idea then for the reasons you mentioned.
Anyway, thanks for your input, I appreciate it!
On Wednesday, May 18, 2016 at 2:13:35 PM UTC-7, Isaiah wrote:
I don't think this is a bad idea. Though many of these are not currently under JuliaLang, they're under individual accounts (the primary author's) or JuliaStats in the case of RCall. It might be good to move IJulia, pyjulia, and maybe a few others out of JuliaLang for CI queue reasons, but the rest are pretty healthy where they are for now. The really important thing for any repo that's under anyone's personal account is that at least one other person (preferably more) are given commit access, in case the maintainer disappears. Granted we can work around that by redirecting metadata to forks as we recently had to do with Showoff.jl, but spreading commit access out a bit helps reduce the chances of needing to do that.
On Wednesday, May 18, 2016 at 2:23:44 PM UTC-7, Alex Arslan wrote:
"In case the maintainer disappears" sounds dramatic, but it could be a vacation or just deciding to take the weekend off when something happens to need fixing somewhat urgently. It's also helpful to spread the responsibility to avoid burnout.
On Wednesday, May 18, 2016, Tony Kelman <[hidden email]> wrote:
In reply to this post by Isaiah Norton
On Wednesday, May 18, 2016 at 9:13:35 PM UTC, Isaiah wrote:
There might be limited contributor overlap, but are there not similar technical issues, to talk about, if not share code? There seem to be, at least to me in three classes of languages:
Languages with memory management, such as C/C++ and Rust, that seems easiest to support. Generally non-VM.
Languages with reference counting (and possibly full GC on top, as in), such as Python, at least CPython. Any with only RC?
Languages with tracing garbage collection (note, CPython fits here and in B, while Jython only in C.), such as Go. And Java.
There are common issues with the . operator (that is not yet overloaded), for traditional OO languages.
Dropbox' Pyson JIT Python was in cat. C. but as of 0.5 is in B.:
[D language is a special case, as it has GC, but it's also optional (as with Julia); while their optional support, seems more developed.]
Maybe the languages are dissimilar enough, that code can't be shared, but I'm not convinced, people can't help each other.
What solutions? I liked the idea of having them grouped together [somewhere], to at least inform people of these possibilities.
|Free forum by Nabble||Edit this page|