Google Summer of Code 2012 - any mentors?
Alexander Yakushev
I am wondering if there is there anybody willing to take part in this
year's GSoC as a mentor? I would be happy to contribute this summer's
time to hacking Clojure and there are probably more students that
would.
Best regards,
Alexander
Baishampayan Ghose
A discussion is currently ongoing in the Clojure Dev mailing list.
We are still waiting for someone from Clojure/core to chime in.
Regards,
BG
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
Baishampayan Ghose
b.ghose at gmail.com
Simone Mosciatti
+1
Peter Hanak
Devin Walters
'(Devin Walters)
Justin Anthony Hamilton
On Feb 17, 6:07 pm, Devin Walters <dev...@gmail.com> wrote:
> +1, would love to help in any way I can
>
> '(Devin Walters)
>
Alexander Yakushev
tomorrow but sadly there isn't any word about it at least on
Confluence. There are willing mentors on the clojure-dev list and
ideas to submit but as far as I understood from the GSOC site an
organization must apply to host all these project ideas and
subsequently assign mentors.
Here's how a mentoring organization should apply (may save some time):
http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs#mentoring_apply
.
Here's an example of the idea list for GSOC: http://community.kde.org/GSoC/2011/Ideas
Hopefully we will see Clojure as a mentoring organization for the
Clojure itself and third-party projects too. As you can see, there are
students who would like to jump in the development and Clojure
community could make use of them.
David Nolen
Devin Walters
Devesh Mittal
David Nolen
Phil Hagelberg
> Some seeds for project ideas:
> - documentation
> - clooj
> - clojars
> - leiningen
If I had any big ideas for Leiningen I don't think I could wait until
the summer to implement them... but I would be happy to help mentor for
Clojars.
-Phil
David Nolen
Alexander Yakushev
right. It would be interesting for me and may be for someone else.
Decent Emacs-based Clojure IDE
Brief explanation:
Clojure has a critical need for a good novice-friendly IDE.
Counterclockwise certainly has its advantages but Emacs is just too
good "Lisp IDE" to ignore that fact. Things like Slime/Swank, CDT
(http://georgejahad.com/clojure/cdt.html), Paredit being already
developed greatly simplify the creation of a very functional IDE. What
is required is to bring them altogether, write glue code from
different sides (both Emacs and the above-mentioned tools) and provide
a click-and-go distribution (both in the form of an Emacs "meta"
plugin and a complete Emacs for Clojure build). More specific ideas
for the beginning:
- better Emacs-CDT integration - visible breakpoints, understandable
distinction between program and debug REPLs (something like Eclipse
perspectives may be useful)
- better Emacs-lein integration - something like package-list-packages
for clojars might be awesome when choosing dependencies for a project.
- better project experience - bolster the feeling of working with a
specific project rather than a bunch of files (can take some CEDET
stuff for this).
- better immersion experience - docs, guides, screencasts - the usual
kind of new users support.
Expected results:
Emacs that acts as a Clojure IDE on a level how Eclipse handles Java
Knowledge Prerequisite:
Familiarity with Clojure and Clojure/Emacs development tools.
Familiarity with Emacs Lisp.
What do you think? I have a feeling that it's too much for one person
but if wisely split it could be a feasible task.
David Nolen
Cedric Greevey
<yakush...@gmail.com> wrote:
> I post the following proposal here because I'm not sure I've done it
> right. It would be interesting for me and may be for someone else.
>
> Decent Emacs-based Clojure IDE
Whoa, hold your horses. Aren't "Decent" and "Emacs-based" mutually-exclusive?
> Brief explanation:
> Clojure has a critical need for a good novice-friendly IDE.
"Novice-friendly" and "Emacs-based" definitely are.
Sorry, but this is probably a nonstarter...
> Expected results:
> Emacs that acts as a Clojure IDE on a level how Eclipse handles Java
Actual results: a large spike in ibuprofen sales at area pharmacies. :)
The problem is the Emacs UI-paradigm. It's so completely at odds with
what have become defacto industry standards (exemplified by Windows,
MacOS Toolkit GUI, Swing, Gnome, KDE) that there's basically no way to
sugar it up into something novice-friendly, or even just something
that won't have the novice ripping out his hair and banging his head
against sturdy objects struggling to make it behave the way it
"should" when he tries to select, copy, paste, move, deselect,
replace, etc.
Alexander Yakushev
>
> Whoa, hold your horses. Aren't "Decent" and "Emacs-based" mutually-exclusive?
> "Novice-friendly" and "Emacs-based" definitely are.
are probably right. I was particularly talking about new users of
Clojure. A seasoned developer can get acquainted with Emacs pretty
easily and fast. Perhaps without the hairloss you described.
> Sorry, but this is probably a nonstarter...
the Clojure community still uses Emacs and I see a constant growth of
reasons to it. CDT which I had not heard of until recently is a tool
of a great usability improvement. This means that Emacs still matters
for Clojure developers. And I don't think this is where you should
apply a strict dichotomy between the hairy dudes stuck in middle ages
with Emacs and all others who are used to common principles of Eclipse/
VS/etc. The usability is not 0 or 1, it is a ladder with lots of small
steps. The higher you get the more users you have.
However thank you for the comment, I'm still susceptible to choosing
another project.
Cedric Greevey
The emacs learning curve is more like a vertical cliff face than a
ladder with lots of small steps...
Alexander Yakushev
> The emacs learning curve is more like a vertical cliff face than a
> ladder with lots of small steps...
Is it "You can't be productive with Emacs"? If so then you are wrong
and because Clojure developers prove otherwise.
Or is it "You can't teach a new user to use Emacs effectively"? Once
again I don't think this to be true, noone is born with Emacs
shortcuts in his spinal cord.
Please explain you position so I can take a better look from your
perspective.
Phil Hagelberg
> On Feb 27, 10:00 pm, Cedric Greevey <cgree...@gmail.com> wrote:
>> The emacs learning curve is more like a vertical cliff face than a
>> ladder with lots of small steps...
>
> I still don't get the point you are trying to bring.
Feeding the troll just makes things worse.
Thanks for your consideration.
-Phil Hagelberg, on behalf of the list denizens with finely-tuned killfiles
Cedric Greevey
It is, of course, neither of those things. Instead, it is "An
autodidact cannot quickly learn to use Emacs"; also, "a new user will
be frustrated trying to learn Emacs, particularly unassisted". Both
mean that an Emacs newbie cannot, under normal circumstances, expect
to be productive very quickly, not the way they could be in, say,
clooj or Enclojure.
This, in turn, appears to make "novice-friendly" and "Emacs-based"
mutually exclusive, where by "novice" is meant "not a pre-existing
Emacs user, perhaps among other things".
As for the vertical cliff face specifically, the cause (based on my
own attempts to use it on some Unix system some time ago) seems to be
the way Emacs doesn't do *one single thing* in common with *any*
popular software user interface. It's a nearly perfect circle of
protection from newbies getting a grip on it. On the one hand, many
basic editing functions have different and unguessable key bindings.
OK, no problem, right? There's help, even a tutorial, etc. But when
you open the help, it opens by the Emacs editor splitting down the
middle, inside of Emacs, rather than as a separate thing. And because
it's inside Emacs, the help's got idiosyncratic key bindings of its
own. The complete newbie will have no clue how to (or even if they
can) search it (no perceived affordances, in HCI-speak) and will have
to scroll up and down skimming the text to find stuff. Of course, then
there's the final plate in the newbie-proofing armor: once you've
found the section on how to do X (say, paste, or even save and quit),
now you need to get the input focus out of the help side of the
display and back to the side with your text file in order to actually
do it. Only problem is, the obvious (alt-tab, control-tab) of course
don't work and so you can't get back without scrolling around in the
help file some more, to find out how to switch the input focus between
panes.
The final straw will be when you discover that you *can't have the
input focus in the editor with the how-to-do-X instructions displayed
in the help pane*. Either the input focus is in the editor but the
how-to-switch-panes instructions are in the help pane, or the
how-to-do-X instructions are in the help pane but the input focus is
in the help pane. The only way to get to the editor and do X requires
you to either memorize the how-to-do-X instructions, navigate to the
how-to-switch-panes instructions, switch panes, and then do X, or
memorize the how-to-switch-panes instructions, navigate to the
how-to-do-X instructions, switch panes, and then do X. And remember
how to switch panes again when the time comes to now dredge up the
help on how to do Y.
The problem is that both require keeping one set of instructions
memorized *while finding, reading, and performing the other*, which
will tend to cause you to forget the first set, due to the limited
size of human working memory. If even one of the things (say, how to
switch panes) was second-nature from repeated use (like alt-tab
already will be), this wouldn't be an issue, but since *every single
thing* is done differently in Emacs, *none* of them will be
second-nature to a new user, and with the above effect resulting from
that, the new user cannot get anything nontrivial done until at least
a few of these things are second-nature, which point they won't get to
until they have spent a while using Emacs to get things done, which is
a clear Catch-22.
Basically, just to do common editing tasks will require you to
actually *take written notes*, or at least use a separate open
Notepad/whatever window in your operating system, and if you're going
to use Notepad (or even pencil and paper!) why are you not just using
Notepad instead of Emacs? It gets to be a "what's the point" sort of
thing.
(And it used to be even worse, or so I hear, back in the 70s or 80s.
No arrow keys, so even scrolling in the help couldn't be done in an
"obvious" way even to find out how to scroll in the help; and no
"press <whatever> for help" status-line or whatever right after
startup, so if you even got the help to display at all, it was by
sheer accident and/or button-mashing, and you were damned if you knew
how to make it happen again.)
Now, in theory, learning how to use, say, Windows has the same initial
cliff-face hurdle. Once you know alt-tab, you can have help open to
anything alongside anything else you're working on and switch between
them, in particular, but until then, you would have the same
difficulty working on something while having relevant help visible
onscreen. Of course, you probably got shown the ropes early in life,
rather than having to (try to) learn on your own. And there's another
thing: with Windows, MacOS, or any other GUI convention, you only have
to get over that hurdle *once*. Once you know this you know it for
*every native application, existing or yet to be invented*. You also
get the basics for editing in text boxes and input forms in every
native app. And what to expect OK, Cancel, etc. buttons to do. And so
on, and so forth. On the other hand, once you have Emacs's
switch-panes command memorized, you know how to switch panes in Emacs.
Not only can't you leverage your existing knowledge of alt-tab or
anything else in Emacs, you can't leverage your hard-won Emacs
knowledge anywhere else either. And it loses a lot of potential value
that way, by network effects, or rather lack of same.
So, nowadays, in the age of widespread UI conventions, learning Emacs
is like building up a big movie library on Betamax cassettes. You can
use it, sure, given you keep a player in working order; maybe you can
even share it with some enthusiasts; but it's not nearly as valuable
as if you'd chosen some other format. :) Of course, for preexisting
Emacs users it's a sunk cost. They may as well stick with what they
know. But the difficulties, and lack of transferrable knowledge in or
out, make it a dubious proposition for new users.
Cedric Greevey
Responding to someone's reasoned concerns with name-calling just makes
things worse.
Thanks for your consideration.
-Cedric Greevey, on behalf of the list denizens who prefer meaningful
discussions to mud-slinging.
Alexander Yakushev
> ...
Ok, I got the idea now and I for sure understand your frustration with
Emacs. Emacs is definitely not for the weak of spirit (it's not a pun
in any way, I just compare your words to my own beginner's
experiences) requiring you to learn, google and hack a lot to make of
it an editor you want to use (while you can use Eclipse pretty much
out-of-the-box without touching any configuration whatsoever). But
that's not the point I wish to discuss anymore, we had already gotten
too far away from the original topic.
In order to make our discussion somehow productive I propose you to
update the project list on Confluence with ideas for your Clojure IDE
(CCW, Enclojure or something else) improvements. I'm sure you can name
a list of things you want to be improved and there possibly are people
who would like to work on this feature during GSOC.
Cedric Greevey
<yakush...@gmail.com> wrote:
> On Feb 28, 12:59 am, Cedric Greevey <cgree...@gmail.com> wrote:
>> ...
>
> Ok, I got the idea now and I for sure understand your frustration with
> Emacs. Emacs is definitely not for the weak of spirit (it's not a pun
> in any way, I just compare your words to my own beginner's
> experiences) requiring you to learn, google and hack a lot to make of
> it an editor you want to use
Hm. It might not be *quite* as bad nowadays, since now we a) have
google and b) would probably be running Emacs (or connecting to it) in
an emulated terminal in a desktop window with other, more familiar
tools available alongside it, instead of being at a green-glowing
terminal display without any of those resources ...
Still sounds like more startup work for the newbie than basing it off
another IDE, especially if by "another IDE" is meant "clooj". :)
Devin Walters
Alex Miller
specific ideas I had here:
http://dev.clojure.org/display/doc/clojure.org+TODO+list
Many people have picked up parts of it since I wrote it (yay!) but
there are still a number of biggish pieces there that need to be
blessed/vetted by someone in core. I know Fogus made a pass with many
changes recently and perhaps some of the things on the list are moot
now. What needs to be done imho is just web site information design
work. I'm not sure if that falls in GSoC's normal purview.
There are suggested unsessions at Clojure/West about both GSoC and
documentation - I'd love to see a discussion take place about either
during C/W. If anyone is interested, please add yourself to a list
for either if you'll be there - http://clojurewest.wikispaces.com/Unsessions
Alex
On Feb 28, 1:35 am, Devin Walters <dev...@gmail.com> wrote:
> One item that hasn't made the project ideas list that I've seen numerous threads about is documentation. Does this fall within the scope of GSoC?
>
> It seems like there are a lot of opportunities to either organize, revise, update, or generate documentation.
>
> Some ideas:
> - Clojure.org's Libraries section still talks about contrib like it's first class.
> - The Getting Started guide could always use more work.
> - StackOverflow contains nuggets of wisdom that aren't anywhere in official documentation. (It also contains a lot of bad answers, but still…)
> - I've heard it said on more than one occasion that xyz docstring is out of date.
> - This is one of the few communities where you can go back to 2008 and read a transcript of a conversation between Chouser and Rich about why map destructuring is the way it is. Some of these conversations hold some deep wisdom about Why Things Are The Way They Are.
> - This list contains truckloads of information that could be organized for more efficient consumption.
> - ClojureScript wouldn't be hurt by more documentation.
> - Without making this a laundry list I'd just say: Producing and organizing good documentation is hard labor, but it is also something that I think benefits the entire community. Moreover, it might give someone a chance to learn a ton about Clojure over the course of a summer, and make it easier on everyone who decides to try out Clojure in the future as a nice side effect. I'd like to suggest we add an intentionally vague option to "Make Lots of Things Better" and list some ideas for how one might go about doing that.
>
> More ideas that might bear interesting and desirable fruit:
> - Make an album with Overtone. (Kidding (but only a little bit (not kidding at all, actually (I bet we'd get some passionate proposals (and maybe even a record deal ;)))))
> - The sidebar on the left of the GSoC page lists an opening for a Community Manager Internship. I think a lot of what I'm suggesting falls under that umbrella. "creating/editing documentation, helping migrate projects to newer versions of clojure, developing sample applications such as solutions for the alioth benchmarks, answering questions on IRC, administering/maintaing clojure.org, clojure.com, assemble, confluence, mycroft, etc."
>
> I guess what I'm saying is, at the end of the day: Let's add documentation to the list, but also add some other obviously fun projects and see what kind of proposals we receive. It doesn't mean we need to accept them, it just shows (IMO) we're very open minded about people who are passionate about building what /they/ care about, not necessarily what we care about. If some musician in grad school submitted a proposal to make an album exclusively with Overtone and published the source that would be a boon to the Overtone project IMO. If a sophomore in college wants to build some crazy parallelized Rube Goldberg machine with Clojure then I think we should at least entertain the idea of it. More than anything, I think we need to present the people who *might* do something like that with the face of a community that would genuinely appreciate it. I've met many of you personally, so I hardly think that's a stretch for us.
>
> This is getting really long so I apologize, but I'd like to offer up a bit of personal experience w/r/t GSoC:
> I did GSoC years ago for Plan9 (Inferno-OS specifically). I was not very familiar with their community, and I doubt many people have ever read a book about programming Limbo. As a result, a lot of the ideas that were listed were strangely specific from my limited undergrad perspective. I was interested in learning about Plan9 and contributing, not necessarily learning Plan9 to make a distributed authentication system that someone else wanted for reasons that were unknown to me and/or were not well described in the description. As a result, keep in mind that we will potentially have people submitting proposals to write Skynet 1.0 in 3 months who are doing their undergrad and may have only just had an introduction to lisp or scheme. Last note (I promise) is: potential mentors, this is not a small commitment. Trust me on that. It's as much your responsibility to steer someone toward success as it is theirs.
>
> Regards,
> '(Devin Walters)
>
>
>
>
>
>
>
> On Monday, February 27, 2012 at 7:42 PM, Cedric Greevey wrote:
> > On Mon, Feb 27, 2012 at 6:49 PM, Alexander Yakushev
> > > > ...
>
> > > Ok, I got the idea now and I for sure understand your frustration with
> > > Emacs. Emacs is definitely not for the weak of spirit (it's not a pun
> > > in any way, I just compare your words to my own beginner's
> > > experiences) requiring you to learn, google and hack a lot to make of
> > > it an editor you want to use
>
> > Hm. It might not be *quite* as bad nowadays, since now we a) have
> > google and b) would probably be running Emacs (or connecting to it) in
> > an emulated terminal in a desktop window with other, more familiar
> > tools available alongside it, instead of being at a green-glowing
> > terminal display without any of those resources ...
>
> > Still sounds like more startup work for the newbie than basing it off
> > another IDE, especially if by "another IDE" is meant "clooj". :)
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To unsubscribe from this group, send email to
Alexander Yakushev
daly
I'd mentor someone willing to do work on the literate programming
version. See
http://daly.axiom-developer.org/clojure.pdf
http://daly.axiom-developer.org/clojure.pamphlet (src)
Even more interesting... It appears that the ePub standard allows
embedded javascript. So ideally we would like to manipulate a
canvas to show the ideas. For instance, I'd like to see a digital
book that had a canvas element that showed the red-black-trie
evolve, potentially interactively.
Even more interesting... Write the generated javascript for the
above ePub demonstration using ClojureScript
I'd be willing to mentor any of those.
>
>
> More ideas that might bear interesting and desirable fruit:
> - Make an album with Overtone. (Kidding (but only a little bit (not
> kidding at all, actually (I bet we'd get some passionate proposals
> (and maybe even a record deal ;)))))
I watched the overtone video shortly after finishing both the
stanford machine learning course, the signals course and a
genetics course.
It would be possible to extract features from your favorite songs
e.g ( http://www.ams.org/notices/200903/rtx090300356p.pdf ) using
FFT signal processing. (signals) Use the overtone feature set to
define the possible features. (overtone).
It would be possible to rank the features of your favorite songs
by listening to each song and constructing a "like" value for each
song (e.g. hit the + key multiple times, or use a number to rate
the song from 1 to 11 (ala spinal tap). (machine learning)
Having ranked the songs, use the learning algorithm to predict
the kinds of songs you like based on features. Use overtone to
generate new songs with the most popular features (overtone).
Use vector crossovers to generate new songs. (genetic programming).
Rinse and repeat.
Sort of a "sample" without samples :-)
I'm actually working on the ePub idea with a book so the
"mentoring" would actually be more of a collaborative effort
since it travels into what is, for me, new territory.
There are still some things to demonstrate and a lot of reading
of the ePub3 standard but it progresses slowly. An ePub book
with embedded interactive canvas elements seems to be the best
path to inspire people to write literate software.
Tim Daly
da...@axiom-developer.org
Sanel Zukan
Hoping readers will not mind for putting myself as mentor on one of
them, but if there are better candidates, feel free to take it :) I
did a little bit gcj + Clojure playing and I'm eager to see native
Clojure without jvm.
Although I did some exploring on possible optimization techniques, I'm
leaving mentor section on Optimizer empty as there are probably more
experienced colleagues in this field.
Regards,
Sanel
On Feb 26, 6:19 pm, David Nolen <dnolen.li...@gmail.com> wrote:
> http://dev.clojure.org/display/community/Google+Summer+of+Code+2012
>
> Please submit more project ideas :)
>
> David
>
>
>
>
>
>
>
> > wrote:
> > So the application submiting procedure for organizations starts
> > tomorrow but sadly there isn't any word about it at least on
> > Confluence. There are willing mentors on the clojure-dev list and
> > ideas to submit but as far as I understood from the GSOC site an
> > organization must apply to host all these project ideas and
> > subsequently assign mentors.
>
> > Here's how a mentoring organization should apply (may save some time):
>
Christopher Redinger
Alexander Yakushev
Clojure already has a set of benchmarks to test its performance but the data is not so easy to get for an common Clojure user (you need to download benchmarks, run it etc.). Things would be much more convenient if these benchmarks were run on each Clojure build in Hudson. This way everyone could easily track the performance enhancements and lapses following each commit. Even better would be a combination of benchmarks and a profiler that yields data that could be further compared across different commits.
Alexander Yakushev
Christopher Redinger
David Nolen
--
Paul deGrandis
program twice as a student (Nmap and PyPy).
I'll actively help any mentor or pair with any student.
Paul
On Mar 5, 10:38 am, David Nolen <dnolen.li...@gmail.com> wrote:
> Thanks! Unless somebody else wants to - I'm willing to be the backup admin.
>
> David
>
>
>
>
>
>
>
>
> > I've created a new page in Confluence with questions from the application.
>