Asumu Takikawa | 1 Mar 20:21 2012

Google Summer of Code 2012 Ideas

Hi all,

We are currently putting together an application as a mentoring
organization for the Google Summer of Code 2012, which is a summer
program in which Google pays students to work on open source/free
software projects.

As part of the application, we are currently collecting project ideas
for our "ideas page" that gives applying students ideas for projects
that can be completed in 12 weeks. If you have any ideas along these
lines, please contribute to our wiki page:

https://github.com/plt/racket/wiki/SoC-Ideas-2012

Feel free to add ideas even if you don't have time to mentor a student.
Please add each idea separately and follow the template on the page.

The deadline for our application is Fri, March 9. If you have any
project ideas, please add them by then. Thanks.

Cheers,
Asumu
____________________
  Racket Users list:
  http://lists.racket-lang.org/users

Stephen Bloch | 2 Mar 05:02 2012

Re: Google Summer of Code 2012 Ideas


On Mar 1, 2012, at 2:21 PM, Asumu Takikawa wrote:

> We are currently putting together an application as a mentoring
> organization for the Google Summer of Code 2012, which is a summer
> program in which Google pays students to work on open source/free
> software projects.
> 
> As part of the application, we are currently collecting project ideas
> for our "ideas page" that gives applying students ideas for projects
> that can be completed in 12 weeks. If you have any ideas along these
> lines, please contribute to our wiki page:
> 
> https://github.com/plt/racket/wiki/SoC-Ideas-2012

I don't actually have a github account, but I wanted to mention the following idea both to current Racket
developers and to potential student programmers.  Could somebody add it to the wiki for me?

Summary: a DrRacket plug-in to enable real-time collaborative editing of a source file, possibly with
fine-grained logging as well.  Two or more different programmers each edit the same file simultaneously,
and edits one of them make show up immediately on the others' screens.

Benefits: The benefits of collaborative editing should be obvious, the benefits of the logging feature
less so.  I attended a SIGCSE talk this morning on a program called CodeWave which provided both
collaboration and (keystroke-level) logging, which the student programmers and/or their instructor
can play back to see what process they were following, what kinds of mistakes they make most often and how
they dealt with those mistakes, etc.

Requirements/Difficulty: Will need to hook into DrRacket.  Will need some kind of server, with user
authentication and permissions (so a specified set of students have access to the shared file); see the
(Continue reading)

Robby Findler | 2 Mar 13:26 2012

Re: Google Summer of Code 2012 Ideas

I would be happy to be a mentor for that one. It is a good project for
GSoC, I think.

Robby

On Thu, Mar 1, 2012 at 10:02 PM, Stephen Bloch <sbloch <at> adelphi.edu> wrote:
>
> On Mar 1, 2012, at 2:21 PM, Asumu Takikawa wrote:
>
>> We are currently putting together an application as a mentoring
>> organization for the Google Summer of Code 2012, which is a summer
>> program in which Google pays students to work on open source/free
>> software projects.
>>
>> As part of the application, we are currently collecting project ideas
>> for our "ideas page" that gives applying students ideas for projects
>> that can be completed in 12 weeks. If you have any ideas along these
>> lines, please contribute to our wiki page:
>>
>> https://github.com/plt/racket/wiki/SoC-Ideas-2012
>
> I don't actually have a github account, but I wanted to mention the following idea both to current Racket
developers and to potential student programmers.  Could somebody add it to the wiki for me?
>
> Summary: a DrRacket plug-in to enable real-time collaborative editing of a source file, possibly with
fine-grained logging as well.  Two or more different programmers each edit the same file
simultaneously, and edits one of them make show up immediately on the others' screens.
>
> Benefits: The benefits of collaborative editing should be obvious, the benefits of the logging feature
less so.  I attended a SIGCSE talk this morning on a program called CodeWave which provided both
(Continue reading)

Eli Barzilay | 2 Mar 13:41 2012

Re: Google Summer of Code 2012 Ideas

9 hours ago, Stephen Bloch wrote:
> 
> I don't actually have a github account, but I wanted to mention the
> following idea both to current Racket developers and to potential
> student programmers.  Could somebody add it to the wiki for me?
> 
> Summary: a DrRacket plug-in to enable real-time collaborative
> editing of a source file, possibly with fine-grained logging as
> well.  Two or more different programmers each edit the same file
> simultaneously, and edits one of them make show up immediately on
> the others' screens.

Having two (or more) people who *edit* the code simultaneously (in
contrast to having a shared screen such as a VNC session), is going to
be hard.  The easy implementation will require each edit to go to the
server that does the shared editing, which is likely going to be too
slow to be convenient even on a LAN.

But there is a perfect fit here: the "Operational Transformation"
thing that is used by etherpad and later by google wave.  Implementing
that might be difficult, but one possibility to make things easier is
to use etherpad-lite (a node.js server) to orchestrate the shared
editing.  As a bonus, it has the fine-grained edit history that you
want.  I don't know how hard it will be to plug into it from an
application though -- but another option is to do the editing in a
browser, using etherpad-lite for the editing backend, and showing the
result of clicking "run" in a window.  (But implementing this is a
different object...)

(BTW, I'm looking into using it for a wiki, with the same goal of
(Continue reading)

Robby Findler | 2 Mar 13:51 2012

Re: Google Summer of Code 2012 Ideas

FWIW, what I had in mind is something lower-tech where we rely on the
users doing the shared editing to help us out when conflicts happen
(perhaps coordinating via chat, perhaps using a token they explicitly
pass around or something).

Robby

On Fri, Mar 2, 2012 at 6:41 AM, Eli Barzilay <eli <at> barzilay.org> wrote:
> 9 hours ago, Stephen Bloch wrote:
>>
>> I don't actually have a github account, but I wanted to mention the
>> following idea both to current Racket developers and to potential
>> student programmers.  Could somebody add it to the wiki for me?
>>
>> Summary: a DrRacket plug-in to enable real-time collaborative
>> editing of a source file, possibly with fine-grained logging as
>> well.  Two or more different programmers each edit the same file
>> simultaneously, and edits one of them make show up immediately on
>> the others' screens.
>
> Having two (or more) people who *edit* the code simultaneously (in
> contrast to having a shared screen such as a VNC session), is going to
> be hard.  The easy implementation will require each edit to go to the
> server that does the shared editing, which is likely going to be too
> slow to be convenient even on a LAN.
>
> But there is a perfect fit here: the "Operational Transformation"
> thing that is used by etherpad and later by google wave.  Implementing
> that might be difficult, but one possibility to make things easier is
> to use etherpad-lite (a node.js server) to orchestrate the shared
(Continue reading)

Eli Barzilay | 2 Mar 13:56 2012

Re: Google Summer of Code 2012 Ideas

A few minutes ago, Robby Findler wrote:
> FWIW, what I had in mind is something lower-tech where we rely on
> the users doing the shared editing to help us out when conflicts
> happen (perhaps coordinating via chat, perhaps using a token they
> explicitly pass around or something).

The problem with that is that it requires some UI for conflict
resolution, and this UI is bound to be disruptive for the actual
work.  The nice thing about editing with etherpad is that you can just
forget about the whole thing, and even if you don't (eg, some laggy
network), then it's nice that it's Not Your Problem...

--

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!
____________________
  Racket Users list:
  http://lists.racket-lang.org/users

Ray Racine | 2 Mar 16:34 2012
Picon

Re: Google Summer of Code 2012 Ideas

I'd like to see more foundational libraries along the lines of say.


 - An Actor/Isolate high level message passing library over Places And Threads.  All the necessary low-level primitives appear to be in place to do something interesting and powerful here.
   - Message passing system should support "remote" Places (i.e. on a different physical node)  transparently.

 - A dataframe / data panels library along the line of Python's Pandas http://pandas.pydata.org/pandas-docs/stable/index.html
    - This should leverage existing stat/sci and the new overhauled plot libraries. 

 - A comprehensive implementation of the entire Amazon Cloud API's with an interactive REPL / scriptable DSL for working with same.

 - A Hadoop integration library Java <-> Racket. (Might be too small for a project.)
   - Hadoop already supports a StdIn StdOut processing of "scripts".   
   - Implement the necessary custom readers/writers in Java supporting Racket serialized Sexps data files.

 - Efficient native Racket implementations of newer web protocols such as SPDY and Websockets.

Ray


On Fri, Mar 2, 2012 at 7:56 AM, Eli Barzilay <eli <at> barzilay.org> wrote:
A few minutes ago, Robby Findler wrote:
> FWIW, what I had in mind is something lower-tech where we rely on
> the users doing the shared editing to help us out when conflicts
> happen (perhaps coordinating via chat, perhaps using a token they
> explicitly pass around or something).

The problem with that is that it requires some UI for conflict
resolution, and this UI is bound to be disruptive for the actual
work.  The nice thing about editing with etherpad is that you can just
forget about the whole thing, and even if you don't (eg, some laggy
network), then it's nice that it's Not Your Problem...

--
         ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                   http://barzilay.org/                   Maze is Life!
____________________
 Racket Users list:
 http://lists.racket-lang.org/users

____________________
  Racket Users list:
  http://lists.racket-lang.org/users
Eduardo Bellani | 6 Mar 04:12 2012
Picon

Re: Google Summer of Code 2012 Ideas


+1 on this.

On 03/02/2012 12:34 PM, Ray Racine wrote:
> I'd like to see more foundational libraries along the lines of
> say.
> 
> - An Actor/Isolate high level message passing library over Places
> And Threads.  All the necessary low-level primitives appear to be
> in place to do something interesting and powerful here. - Message
> passing system should support "remote" Places (i.e. on a different
> physical node)  transparently.
> 
Kevin Tew | 6 Mar 17:28 2012
Picon

Re: Google Summer of Code 2012 Ideas

I'm working on distribute places.
The first version should hit git later today as racket/place/distributed.
The abstraction over places is working pretty well.
The abstraction over threads is planned but not started yet.

Kevin

On 03/05/2012 08:12 PM, Eduardo Bellani wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> +1 on this.
>
> On 03/02/2012 12:34 PM, Ray Racine wrote:
>> I'd like to see more foundational libraries along the lines of
>> say.
>>
>> - An Actor/Isolate high level message passing library over Places
>> And Threads.  All the necessary low-level primitives appear to be
>> in place to do something interesting and powerful here. - Message
>> passing system should support "remote" Places (i.e. on a different
>> physical node)  transparently.
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk9VgIIACgkQSbLl0kCTjGlwAACdGpE0LX7H9QGJWXI3X9XaEnC/
> fSoAniJocz9nymiLw0IPPfsk7mCl8dLn
> =l0fB
> -----END PGP SIGNATURE-----
> ____________________
>    Racket Users list:
>    http://lists.racket-lang.org/users

____________________
  Racket Users list:
  http://lists.racket-lang.org/users

Asumu Takikawa | 2 Mar 17:27 2012

Re: Google Summer of Code 2012 Ideas

On 2012-03-01 23:02:27 -0500, Stephen Bloch wrote:
> I don't actually have a github account, but I wanted to mention the following idea both to current Racket
developers and to potential student programmers.  Could somebody add it to the wiki for me?

Done. Thanks for the suggestion. Let me know if you want anything else
added or the entry fine-tuned.

I've also added myself as a backup mentor for the idea.

Cheers,
Asumu
____________________
  Racket Users list:
  http://lists.racket-lang.org/users

Hendrik Boom | 2 Mar 19:06 2012

Re: Google Summer of Code 2012 Ideas

On Thu, Mar 01, 2012 at 11:02:27PM -0500, Stephen Bloch wrote:
> 
> On Mar 1, 2012, at 2:21 PM, Asumu Takikawa wrote:
> 
> > We are currently putting together an application as a mentoring
> > organization for the Google Summer of Code 2012, which is a summer
> > program in which Google pays students to work on open source/free
> > software projects.
> > 
> > As part of the application, we are currently collecting project ideas
> > for our "ideas page" that gives applying students ideas for projects
> > that can be completed in 12 weeks. If you have any ideas along these
> > lines, please contribute to our wiki page:
> > 
> > https://github.com/plt/racket/wiki/SoC-Ideas-2012
> 
> I don't actually have a github account, but I wanted to mention the following idea both to current Racket
developers and to potential student programmers.  Could somebody add it to the wiki for me?
> 
> Summary: a DrRacket plug-in to enable real-time collaborative editing of a source file, possibly with
fine-grained logging as well.  Two or more different programmers each edit the same file simultaneously,
and edits one of them make show up immediately on the others' screens.
> 
> Benefits: The benefits of collaborative editing should be obvious, the benefits of the logging feature
less so.  I attended a SIGCSE talk this morning on a program called CodeWave which provided both
collaboration and (keystroke-level) logging, which the student programmers and/or their instructor
can play back to see what process they were following, what kinds of mistakes they make most often and how
they dealt with those mistakes, etc.
> 
> Requirements/Difficulty: Will need to hook into DrRacket.  Will need some kind of server, with user
authentication and permissions (so a specified set of students have access to the shared file); see the
project already on the Wiki about adding git support to DrRacket.
> 
> Possible mentor: I don't know.  Guillaume Marceau has done some of this, but I'm hesitant to volunteer him
without asking :-)
> 
> Other:  I'm not wedded to the "log every keystroke" idea: for simultaneous editing, you want to
synchronize no less often than every few keystrokes, but you might not want a separate log entry quite as
often.  Which sort of inverts the git ideal: it encourages you to commit locally fairly frequently, but
push to the server only every several commits.  I'm thinking of something that effectively pushes every
few seconds, but only every several pushes become a distinct "commit" record.
> 
> A less elaborate version wouldn't log much of anything, but would still synchronize with a server every
few keystrokes.

Two parts to this -- the editor, and a message/event/state maintenance system.

YOu don't actually *need* a server as long as clients can communicate.

Timestamp the messages in an unambiguous fashion, possibly 
something like a pair (local time. client identity).  Arrange to have 
all messages processed sorted by such a time-stamp.   Write the 
editor in a functinoal style -- you know, as a mapping that 
takes a state and a sequence of messages and returns a new state.  
When a message arrives out of order, possibly delayed, you can replay 
the sequence of edit commands from an earlier state.  Both client 
machines can do this imdependently.  THe purpose of the unambiguous 
time-stamps is to ensure that they will eventually converge on the same 
sequence of edit operations.

If you replace the editor with something else, you could have a 
multiplayer game.

Conclusion: the message/event/state maintnance system is probably a 
useful tool in its own right, and should be implemented as a 
general-purpose tool.

-- hendrik
____________________
  Racket Users list:
  http://lists.racket-lang.org/users

Eli Barzilay | 2 Mar 20:39 2012

Re: Google Summer of Code 2012 Ideas

An hour and a half ago, Hendrik Boom wrote:
> 
> Two parts to this -- the editor, and a message/event/state
> maintenance system.
> 
> YOu don't actually *need* a server as long as clients can
> communicate.
> 
> Timestamp the messages in an unambiguous fashion, possibly something
> like a pair (local time. client identity).  Arrange to have all
> messages processed sorted by such a time-stamp.  Write the editor in
> a functinoal style -- you know, as a mapping that takes a state and
> a sequence of messages and returns a new state.  When a message
> arrives out of order, possibly delayed, you can replay the sequence
> of edit commands from an earlier state.  Both client machines can do
> this imdependently.  THe purpose of the unambiguous time-stamps is
> to ensure that they will eventually converge on the same sequence of
> edit operations.

That doesn't help -- the problem is when the two clients are not
connected for a while or the connection is not fast enough, and you
get two contradicting edits.  The trivial solution of forcing things
to be sequential mean that typing speed is limited by the network
which can be impractical in many cases.  (In cases where it is
practical, the whole thing is even easier than that, you just need to
bounce messages and make sure that both sides get to see the same
sequence of edit steps.)

This is also relevant:
  http://code.google.com/p/google-diff-match-patch/

--

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!
____________________
  Racket Users list:
  http://lists.racket-lang.org/users

Hendrik Boom | 3 Mar 20:13 2012

Re: Google Summer of Code 2012 Ideas

On Fri, Mar 02, 2012 at 02:39:20PM -0500, Eli Barzilay wrote:
> An hour and a half ago, Hendrik Boom wrote:
> > 
> > Two parts to this -- the editor, and a message/event/state
> > maintenance system.
> > 
> > YOu don't actually *need* a server as long as clients can
> > communicate.
> > 
> > Timestamp the messages in an unambiguous fashion, possibly something
> > like a pair (local time. client identity).  Arrange to have all
> > messages processed sorted by such a time-stamp.  Write the editor in
> > a functinoal style -- you know, as a mapping that takes a state and
> > a sequence of messages and returns a new state.  When a message
> > arrives out of order, possibly delayed, you can replay the sequence
> > of edit commands from an earlier state.  Both client machines can do
> > this imdependently.  THe purpose of the unambiguous time-stamps is
> > to ensure that they will eventually converge on the same sequence of
> > edit operations.
> 
> That doesn't help -- the problem is when the two clients are not
> connected for a while or the connection is not fast enough, and you
> get two contradicting edits.  The trivial solution of forcing things
> to be sequential mean that typing speed is limited by the network
> which can be impractical in many cases.

No.  Locally, it's updated immediately, without any network delay, so 
it doesn't affect typing speed.  Only in the case that both users are 
typing into the same place is there any confusion -- and in that case 
the trouble will soon become evident, and the users will have to 
communicate by other means.

>  (In cases where it is
> practical, the whole thing is even easier than that, you just need to
> bounce messages and make sure that both sides get to see the same
> sequence of edit steps.)
> 
> This is also relevant:
>   http://code.google.com/p/google-diff-match-patch/
> 
> -- 
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!
____________________
  Racket Users list:
  http://lists.racket-lang.org/users

Nevo | 6 Mar 02:08 2012
Picon

Re: Google Summer of Code 2012 Ideas

Hi all!

  I don't quite follow how Racket web app framework has grown for some period, so not sure this may look appropriate as an potential GSoc idea. Currently there's open PaaS platform named cloudfoundry (www.cloudfoundry.com). It's a real cloud platform and developers could use the supported frameworks/runtimes/tools to create/deploy a cloud app in a very fast way without the need of caring the underlying infrastructure setup. At this moment, Ruby/Java/Scala/Node.js are officially supported, although PhP/Python are also added by thirdparty company. Cloudfoundry source is in https://github.com/cloudfoundry and it provides a MicroCloud env (a VM) to facilitate the development of in-house app. So this looks like a place for Racket to go since it does have a modern well designed web framework as well as a powerful language. 
  As a quick reference, here're how Python and PHP work in case you cannot find them from the official page.

Cheers
Nevo

On 2 March 2012 06:21, Asumu Takikawa <asumu <at> ccs.neu.edu> wrote:
Hi all,

We are currently putting together an application as a mentoring
organization for the Google Summer of Code 2012, which is a summer
program in which Google pays students to work on open source/free
software projects.

As part of the application, we are currently collecting project ideas
for our "ideas page" that gives applying students ideas for projects
that can be completed in 12 weeks. If you have any ideas along these
lines, please contribute to our wiki page:

https://github.com/plt/racket/wiki/SoC-Ideas-2012

Feel free to add ideas even if you don't have time to mentor a student.
Please add each idea separately and follow the template on the page.

The deadline for our application is Fri, March 9. If you have any
project ideas, please add them by then. Thanks.

Cheers,
Asumu
____________________
 Racket Users list:
 http://lists.racket-lang.org/users

____________________
  Racket Users list:
  http://lists.racket-lang.org/users

Gmane