Hey all, Responding here to several things from both Reid and Francesco. I wanted to step back slightly to set some context. I proposed the project that Chris has posted and some of the points that Reid brought up are really source from my proposal so I wanted to take the blame as it were for anything in the original proposal that sucked - not his fault. :)
My intention in the proposal was not that it necessarily capture everything but really convey the core idea. I expected that working through all the details *is* the project and would be done as an iterative process talking to me and other experts (like Reid and Francesco!!). I should also mention that another student has already submitted a proposal to GSOC for this project and only one student can work on it. I'm still not exactly sure how that is supposed to get resolved. Anyhow, more comments below. I may also try to dig out some of the longer form work I've done on this since it seems to have interest now. On Tuesday, March 17, 2015 at 9:07:00 AM UTC-5, Francesco Bellomi wrote: > > Hi Christopher, > > I'm Francesco, the maintainer of crossclj.info > > I think it's a very interesting project. Some comments on your proposal: > > 1) I think the information model is by far most important deliverable. I > agree with Reid that a sound "coordinate system" is very important > Totally agreed, and I've said this to both Chris and the other student. I do not think what's on the proposal page captures many of the important aspects of the problem. Even focusing just on vars ignores what I consider to be equally important pieces like records and protocols. I think it's important to capture the parts of the source that are needed to *use* a project, either as a consumer or as an extender. Some of these fringes are particularly the places where the various existing indexers vary. The coordinate system is particularly important and tricky and I think keeping multiple serialization formats (text-based and Datomic-backed are two reasonably different targets) in mind is a good way to avoid tailoring it to closely to your output needs (html pages). This is indeed the part I've spent the most time hammocking on. I know you guys have as well. > 2) The toolchain you want to implement is in part already there. > Almost all the metadata you list in your current model are already > extracted by codox; codox already separates the extraction phase from the > output phase, so you could simply implement the "indexing library" by > providing a different output module, in order to generate your model > instead of HTML; the internal representation used by codox is already > (somehow) a list of namespaces, each one with a list of vars; codox has a > rich set of tools (lein plugin, etc.) which would be immediately reusable. > Outputting JSON instead of EDN is a one-liner with Cheshire. > I don't think JSON is a valuable serialization target. :) I'd defer any notion of toolchain until there is some consensus on model. 3) I'm not sure about the choice of storing "artifact coordinates" as part > of a namespace's metadata. Currently it's not the case, the publishing > recipe is kept separated (say, in project.clj or in a POM file), and a > namespace at runtime has no notion of its coordinates. I think it's the > same for all JVM languages. Are we providing extra flexibility, or are we > simply complecting two different kind of information? > Yeah, that doesn't make sense to me either. I think versioning needs to happen at a higher level that can sync up with maven coords. > > 4) One relevant use case is IDE integration: IDEs cannot evaluate source > code at runtime in order to generate the relevant metadata (it's not safe), > so having this kind of static info would be really useful, ie. for > providing users hints on vars generated by macros > > Francesco > > > > > > On Monday, March 16, 2015 at 7:53:53 PM UTC+1, Christopher Medrela wrote: >> >> Hello! My name is Christopher Medrela and I'd like to work at "source >> metadata >> information model" project mentored by Alex Miller at Google Summer of >> Code. I >> hope that this mailing list is the right place to discuss such projects >> (if I'm >> wrong, correct me). >> >> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
